[PATCH V8] mmc: core: Add Power Off Notify Feature eMMC 4.5

2011-10-13 Thread Girish K S 
This patch adds the support for power off notify feature, available in 
eMMC 4.5 devices. If the the host has support for this feature, then the
mmc core will notify it to the device by setting the POWER_OFF_NOTIFICATION
byte in the extended csd register with a value 1(POWER_ON).

For suspend mode short timeout is used, whereas for the normal poweroff long
timeout is used.
cc: Chris Ball c...@laptop.org
Signed-off-by: Girish K S girish.shivananja...@linaro.org
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
---
Changes in V8:
Updated with review comments of Chris Ball and rebased to 
chris-mmc/mmc-next branch.
Changes in V7:
Rebased to chris-mmc/mmc-next branch. merged to patches 
to single patch.
Changes in V6:
Fixes checkpatch errors. The patches are generated after
rebasing to chris's mmc-next branch.
Changes in V5:
This patch version fixes the problem with power off
notify function, when called for the first time and
card is not yet initialised.
Changes in V4:
Updated with review comments of Jeon
Changes in V2:
Adds poweroff notification handling in suspend/normal.

 drivers/mmc/core/core.c  |   36 
 drivers/mmc/core/mmc.c   |   23 +--
 drivers/mmc/host/sdhci.c |9 +
 include/linux/mmc/card.h |6 ++
 include/linux/mmc/host.h |6 ++
 include/linux/mmc/mmc.h  |8 
 6 files changed, 86 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 61d7730..db368b2 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1212,11 +1212,45 @@ static void mmc_power_up(struct mmc_host *host)
 
 void mmc_power_off(struct mmc_host *host)
 {
+   struct mmc_card *card;
+   unsigned int notify_type;
+   unsigned int timeout;
+   int err;
+
+   BUG_ON(!host);
+
mmc_host_clk_hold(host);
 
+   card = host-card;
host-ios.clock = 0;
host-ios.vdd = 0;
 
+   if (card != NULL  mmc_card_mmc(card) 
+   (card-poweroff_notify_state == MMC_POWERED_ON)) {
+
+   if (host-power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
+   notify_type = EXT_CSD_POWER_OFF_SHORT;
+   timeout = card-ext_csd.generic_cmd6_time;
+   card-poweroff_notify_state = MMC_POWEROFF_SHORT;
+   } else {
+   notify_type = EXT_CSD_POWER_OFF_LONG;
+   timeout = card-ext_csd.power_off_longtime;
+   card-poweroff_notify_state = MMC_POWEROFF_LONG;
+   }
+
+   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_POWER_OFF_NOTIFICATION,
+notify_type, timeout);
+
+   if (err  err != -EBADMSG)
+   pr_err(Device failed to respond within %d poweroff 
+  time. Forcefully powering down the device\n,
+  timeout);
+
+   /* Set the card state to no notification after the poweroff */
+   card-poweroff_notify_state = MMC_NO_POWER_NOTIFICATION;
+   }
+
/*
 * Reset ocr mask to be the highest possible voltage supported for
 * this mmc host. This value will be used at next power up.
@@ -2208,6 +2242,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
 
spin_lock_irqsave(host-lock, flags);
host-rescan_disable = 1;
+   host-power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
spin_unlock_irqrestore(host-lock, flags);
cancel_delayed_work_sync(host-detect);
 
@@ -2231,6 +2266,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
 
spin_lock_irqsave(host-lock, flags);
host-rescan_disable = 0;
+   host-power_notify_type = MMC_HOST_PW_NOTIFY_LONG;
spin_unlock_irqrestore(host-lock, flags);
mmc_detect_change(host, 0);
 
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 4e869d3..f8ea938 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -458,10 +458,12 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 
*ext_csd)
else
card-erased_byte = 0x0;
 
-   if (card-ext_csd.rev = 6)
+   if (card-ext_csd.rev = 6) {
card-ext_csd.generic_cmd6_time = 10 *
ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
-   else
+   card-ext_csd.power_off_longtime = 10 *
+   ext_csd[EXT_CSD_POWER_OFF_LONG_TIME];
+   } else
card-ext_csd.generic_cmd6_time = 0;
 
 out:
@@ -846,6 +848,23 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
}
 
/*
+* If the host supports the power_off_notify capability then
+* set the

Re: [PATCH V4 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names

2011-10-13 Thread Rajeshwari Birje 
Hi Sylwester,

On Wed, Oct 12, 2011 at 9:49 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
 On 10/12/2011 02:36 PM, Rajeshwari Birje wrote:
 On Wed, Oct 12, 2011 at 3:54 PM, Sylwester Nawrocki
 s.nawro...@samsung.com wrote:
 Hi Rajeshwari,

 On 10/12/2011 11:43 AM, Rajeshwari Shinde wrote:
 Add support for lookup of sdhci-s3c controller clocks using generic names
 for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.

 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
 ---
  arch/arm/mach-exynos4/clock.c         |   88 ++---
  arch/arm/mach-s3c2416/clock.c         |   68 +++--
  arch/arm/mach-s3c64xx/clock.c         |  126 +++--
  arch/arm/mach-s5pc100/clock.c         |  130 --
  arch/arm/mach-s5pv210/clock.c         |  167 
 -
  arch/arm/plat-s3c24xx/s3c2443-clock.c |   15 ++-
  6 files changed, 359 insertions(+), 235 deletions(-)

 diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
 index 9f50e33..c6383b9 100644
 --- a/arch/arm/mach-exynos4/clock.c
 +++ b/arch/arm/mach-exynos4/clock.c
 @@ -1157,42 +1157,6 @@ static struct clksrc_clk clksrcs[] = {
               .reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
 ...
 +static struct clksrc_clk clk_sclk_mmc0 = {
 +     .clk            = {
 +             .name           = sclk_mmc,
 +             .devname        = s3c-sdhci.0,

 Would it make sense to drop this 'devname' field here and others
 until sclk_mmc3 

 *** The devname here distinguishes these clocks. So it should be okay
 to have a devname for these clocks.

 I'm not sure what's Mr Kukjin's opinion on that, but I personally would really
 like to see all the devname fields disappear from samsung clk data structures.
 Possibly if all involved people would keep that in mind we could achieve this
 over time.


 Devname field is still required for clocks like hsmmc for driver
to work fine. Hence it would be tough to remove the devname
completely.




 +             .parent         = clk_dout_mmc0.clk,
 +             .enable         = exynos4_clksrc_mask_fsys_ctrl,
 +             .ctrlbit        = (1  0),
 +     },
 +     .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
 +};
 +
 +static struct clksrc_clk clk_sclk_mmc1 = {
 +     .clk            = {
 +             .name           = sclk_mmc,
 +             .devname        = s3c-sdhci.1,

 +             .parent         = clk_dout_mmc1.clk,
 +             .enable         = exynos4_clksrc_mask_fsys_ctrl,
 +             .ctrlbit        = (1  4),
 +     },
 +     .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
 +};
 +
 +static struct clksrc_clk clk_sclk_mmc2 = {
 +     .clk            = {
 +             .name           = sclk_mmc,
 +             .devname        = s3c-sdhci.2,

 +             .parent         = clk_dout_mmc2.clk,
 +             .enable         = exynos4_clksrc_mask_fsys_ctrl,
 +             .ctrlbit        = (1  8),
 +     },
 +     .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
 +};
 +
 +static struct clksrc_clk clk_sclk_mmc3 = {
 +     .clk            = {
 +             .name           = sclk_mmc,
 +             .devname        = s3c-sdhci.3,

 +             .parent         = clk_dout_mmc3.clk,
 +             .enable         = exynos4_clksrc_mask_fsys_ctrl,
 +             .ctrlbit        = (1  12),
 +     },
 +     .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
 +};
 +
  /* Clock initialization code */
  static struct clksrc_clk *sysclks[] = {
       clk_mout_apll,
 @@ -1289,6 +1297,10 @@ static struct clksrc_clk *clksrc_cdev[] = {
       clk_sclk_uart1,
       clk_sclk_uart2,
       clk_sclk_uart3,
 +     clk_sclk_mmc0,
 +     clk_sclk_mmc1,
 +     clk_sclk_mmc2,
 +     clk_sclk_mmc3,

 ..then drop the above 4 lines...

  The registration for these clocks are important. The
 s3c_register_clksrc() function sets the .ops of this clock and also
 its parent. So the registration cannot be dropped.

 OK.



  };

  static struct clk_lookup exynos4_clk_lookup[] = {
 @@ -1296,6 +1308,10 @@ static struct clk_lookup exynos4_clk_lookup[] = {
       CLKDEV_INIT(exynos4210-uart.1, clk_uart_baud0, 
 clk_sclk_uart1.clk),
       CLKDEV_INIT(exynos4210-uart.2, clk_uart_baud0, 
 clk_sclk_uart2.clk),
       CLKDEV_INIT(exynos4210-uart.3, clk_uart_baud0, 
 clk_sclk_uart3.clk),
 +     CLKDEV_INIT(exynos4-sdhci.0, mmc_busclk.2, clk_sclk_mmc0.clk),
 +     CLKDEV_INIT(exynos4-sdhci.1, mmc_busclk.2, clk_sclk_mmc1.clk),
 +     CLKDEV_INIT(exynos4-sdhci.2, mmc_busclk.2, clk_sclk_mmc2.clk),
 +     CLKDEV_INIT(exynos4-sdhci.3, mmc_busclk.2, clk_sclk_mmc3.clk),

 ..and add something like:

  +      CLKDEV_INIT(s3c-sdhci.0, sclk_mmc, clk_sclk_mmc0.clk),
  +      CLKDEV_INIT(s3c-sdhci.1, sclk_mmc, clk_sclk_mmc1.clk),
  +      CLKDEV_INIT(s3c-sdhci.2, sclk_mmc, clk_sclk_mmc2.clk),
  +      CLKDEV_INIT(s3c-sdhci.3, sclk_mmc, clk_sclk_mmc3.clk),

 ?

Re: [PATCH V4 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names

2011-10-13 Thread Sylwester Nawrocki 
On 10/13/2011 09:16 AM, Rajeshwari Birje wrote:
 On Wed, Oct 12, 2011 at 9:49 PM, Sylwester Nawrocki
 s.nawro...@samsung.com wrote:
 On 10/12/2011 02:36 PM, Rajeshwari Birje wrote:
 On Wed, Oct 12, 2011 at 3:54 PM, Sylwester Nawrocki
 s.nawro...@samsung.com wrote:
 Hi Rajeshwari,

 On 10/12/2011 11:43 AM, Rajeshwari Shinde wrote:
 Add support for lookup of sdhci-s3c controller clocks using generic names
 for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.

 Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
 ---
  arch/arm/mach-exynos4/clock.c |   88 ++---
  arch/arm/mach-s3c2416/clock.c |   68 +++--
  arch/arm/mach-s3c64xx/clock.c |  126 +++--
  arch/arm/mach-s5pc100/clock.c |  130 --
  arch/arm/mach-s5pv210/clock.c |  167 
 -
  arch/arm/plat-s3c24xx/s3c2443-clock.c |   15 ++-
  6 files changed, 359 insertions(+), 235 deletions(-)

 diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
 index 9f50e33..c6383b9 100644
 --- a/arch/arm/mach-exynos4/clock.c
 +++ b/arch/arm/mach-exynos4/clock.c
 @@ -1157,42 +1157,6 @@ static struct clksrc_clk clksrcs[] = {
   .reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
 ...
 +static struct clksrc_clk clk_sclk_mmc0 = {
 + .clk= {
 + .name   = sclk_mmc,
 + .devname= s3c-sdhci.0,

 Would it make sense to drop this 'devname' field here and others
 until sclk_mmc3 

 *** The devname here distinguishes these clocks. So it should be okay
 to have a devname for these clocks.

 I'm not sure what's Mr Kukjin's opinion on that, but I personally would 
 really
 like to see all the devname fields disappear from samsung clk data 
 structures.
 Possibly if all involved people would keep that in mind we could achieve this
 over time.
 
 
  Devname field is still required for clocks like hsmmc for driver
 to work fine. Hence it would be tough to remove the devname
 completely.

Yes, it allowed to add clkdev support with minimal changes required.

But let's see what happens when the works on common struct clk for all
architectures are more or less completed and we convert Samsung platforms
to use it;)

Regards,
-- 
Sylwester Nawrocki
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V4 0/3] ARM: SAMSUNG: Add support for sdhci clock lookup using generic names

2011-10-13 Thread Rajeshwari Shinde 
This patchset adds support for sdhci controller clock lookup using
generic names. With this patchset, there will be no need to pass clock
names in sdhci platform data.

This patchset depends on the patchset:
Add a common macro for creating struct clk_lookup entries.
mmc: sdhci-s3c: add default controller configuration.

V2 Changes:
- Added HCLK instance for HSMMC instance 1 as suggested by Heiko.
- Rebased on UART clkdev patches. So these patches should be applied
  after UART clkdev patches are applied.

V3 Changes:
- Removed double registration of hsmmc1 hclk from s3c2416 as suggested by
  Heiko

V4 Changes:
- Changed the devname for bus clocks in Exynos4 to s3c-sdhci. from 
  exynos4-sdhci. as suggested by Sylwester.

Rajeshwari Shinde (3):
  SDHCI: S3C: Use generic clock names for sdhci bus clock options
  ARM: SAMSUNG: Remove SDHCI bus clocks from platform data
  ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names

 arch/arm/mach-exynos4/Makefile |1 -
 arch/arm/mach-exynos4/clock.c  |   88 +--
 arch/arm/mach-exynos4/setup-sdhci.c|   22 
 arch/arm/mach-s3c2416/Makefile |1 -
 arch/arm/mach-s3c2416/clock.c  |   68 ++-
 arch/arm/mach-s3c2416/setup-sdhci.c|   24 
 arch/arm/mach-s3c64xx/Makefile |1 -
 arch/arm/mach-s3c64xx/clock.c  |  126 +
 arch/arm/mach-s3c64xx/setup-sdhci.c|   24 
 arch/arm/mach-s5pc100/Makefile |1 -
 arch/arm/mach-s5pc100/clock.c  |  130 +-
 arch/arm/mach-s5pc100/setup-sdhci.c|   23 
 arch/arm/mach-s5pv210/Makefile |1 -
 arch/arm/mach-s5pv210/clock.c  |  167 +---
 arch/arm/mach-s5pv210/setup-sdhci.c|   22 
 arch/arm/plat-s3c24xx/s3c2443-clock.c  |   15 ++-
 arch/arm/plat-samsung/include/plat/sdhci.h |   31 -
 drivers/mmc/host/sdhci-s3c.c   |6 +-
 18 files changed, 361 insertions(+), 390 deletions(-)
 delete mode 100644 arch/arm/mach-exynos4/setup-sdhci.c
 delete mode 100644 arch/arm/mach-s3c2416/setup-sdhci.c
 delete mode 100644 arch/arm/mach-s3c64xx/setup-sdhci.c
 delete mode 100644 arch/arm/mach-s5pc100/setup-sdhci.c
 delete mode 100644 arch/arm/mach-s5pv210/setup-sdhci.c

-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V4 1/3] SDHCI: S3C: Use generic clock names for sdhci bus clock options

2011-10-13 Thread Rajeshwari Shinde 
This patch modifies the driver to stop depending on the clock names
being passed from the platform and switch over to bus clock lookup
using generic clock names.

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
 drivers/mmc/host/sdhci-s3c.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 82709b6..a5fde87 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -435,14 +435,12 @@ static int __devinit sdhci_s3c_probe(struct 
platform_device *pdev)
 
for (clks = 0, ptr = 0; ptr  MAX_BUS_CLK; ptr++) {
struct clk *clk;
-   char *name = pdata-clocks[ptr];
+   char name[14];
 
-   if (name == NULL)
-   continue;
+   sprintf(name, mmc_busclk.%d, ptr);
 
clk = clk_get(dev, name);
if (IS_ERR(clk)) {
-   dev_err(dev, failed to get clock %s\n, name);
continue;
}
 
-- 
1.7.4.4

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V4 2/3] ARM: SAMSUNG: Remove SDHCI bus clocks from platform data

2011-10-13 Thread Rajeshwari Shinde 
The bus clocks previously sent through platform data to SDHCI controller
are removed.

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
 arch/arm/mach-exynos4/Makefile |1 -
 arch/arm/mach-exynos4/setup-sdhci.c|   22 ---
 arch/arm/mach-s3c2416/Makefile |1 -
 arch/arm/mach-s3c2416/setup-sdhci.c|   24 -
 arch/arm/mach-s3c64xx/Makefile |1 -
 arch/arm/mach-s3c64xx/setup-sdhci.c|   24 -
 arch/arm/mach-s5pc100/Makefile |1 -
 arch/arm/mach-s5pc100/setup-sdhci.c|   23 
 arch/arm/mach-s5pv210/Makefile |1 -
 arch/arm/mach-s5pv210/setup-sdhci.c|   22 ---
 arch/arm/plat-samsung/include/plat/sdhci.h |   31 
 11 files changed, 0 insertions(+), 151 deletions(-)
 delete mode 100644 arch/arm/mach-exynos4/setup-sdhci.c
 delete mode 100644 arch/arm/mach-s3c2416/setup-sdhci.c
 delete mode 100644 arch/arm/mach-s3c64xx/setup-sdhci.c
 delete mode 100644 arch/arm/mach-s5pc100/setup-sdhci.c
 delete mode 100644 arch/arm/mach-s5pv210/setup-sdhci.c

diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 2bb18f4..c47aae3 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_EXYNOS4_SETUP_I2C5)  += setup-i2c5.o
 obj-$(CONFIG_EXYNOS4_SETUP_I2C6)   += setup-i2c6.o
 obj-$(CONFIG_EXYNOS4_SETUP_I2C7)   += setup-i2c7.o
 obj-$(CONFIG_EXYNOS4_SETUP_KEYPAD) += setup-keypad.o
-obj-$(CONFIG_EXYNOS4_SETUP_SDHCI)  += setup-sdhci.o
 obj-$(CONFIG_EXYNOS4_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
 
 obj-$(CONFIG_EXYNOS4_SETUP_USB_PHY)+= setup-usb-phy.o
diff --git a/arch/arm/mach-exynos4/setup-sdhci.c 
b/arch/arm/mach-exynos4/setup-sdhci.c
deleted file mode 100644
index 92937b4..000
--- a/arch/arm/mach-exynos4/setup-sdhci.c
+++ /dev/null
@@ -1,22 +0,0 @@
-/* linux/arch/arm/mach-exynos4/setup-sdhci.c
- *
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4 - Helper functions for settign up SDHCI device(s) (HSMMC)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include linux/types.h
-
-/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
-
-char *exynos4_hsmmc_clksrcs[4] = {
-   [0] = NULL,
-   [1] = NULL,
-   [2] = sclk_mmc,   /* mmc_bus */
-   [3] = NULL,
-};
diff --git a/arch/arm/mach-s3c2416/Makefile b/arch/arm/mach-s3c2416/Makefile
index 7b805b2..ca0cd22 100644
--- a/arch/arm/mach-s3c2416/Makefile
+++ b/arch/arm/mach-s3c2416/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_S3C2416_PM)  += pm.o
 #obj-$(CONFIG_S3C2416_DMA) += dma.o
 
 # Device setup
-obj-$(CONFIG_S3C2416_SETUP_SDHCI) += setup-sdhci.o
 obj-$(CONFIG_S3C2416_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
 
 # Machine support
diff --git a/arch/arm/mach-s3c2416/setup-sdhci.c 
b/arch/arm/mach-s3c2416/setup-sdhci.c
deleted file mode 100644
index cee5395..000
--- a/arch/arm/mach-s3c2416/setup-sdhci.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/* linux/arch/arm/mach-s3c2416/setup-sdhci.c
- *
- * Copyright 2010 Promwad Innovation Company
- * Yauhen Kharuzhy yauhen.kharu...@promwad.com
- *
- * S3C2416 - Helper functions for settign up SDHCI device(s) (HSMMC)
- *
- * Based on mach-s3c64xx/setup-sdhci.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include linux/types.h
-
-/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
-
-char *s3c2416_hsmmc_clksrcs[4] = {
-   [0] = hsmmc,
-   [1] = hsmmc,
-   [2] = hsmmc-if,
-   /* [3] = 48m, - note not successfully used yet */
-};
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 902ab9a..94de24b 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -32,7 +32,6 @@ obj-$(CONFIG_S3C64XX_SETUP_I2C0) += setup-i2c0.o
 obj-$(CONFIG_S3C64XX_SETUP_I2C1) += setup-i2c1.o
 obj-$(CONFIG_S3C64XX_SETUP_IDE) += setup-ide.o
 obj-$(CONFIG_S3C64XX_SETUP_KEYPAD) += setup-keypad.o
-obj-$(CONFIG_S3C64XX_SETUP_SDHCI) += setup-sdhci.o
 obj-$(CONFIG_S3C64XX_SETUP_FB_24BPP) += setup-fb-24bpp.o
 obj-$(CONFIG_S3C64XX_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
 
diff --git a/arch/arm/mach-s3c64xx/setup-sdhci.c 
b/arch/arm/mach-s3c64xx/setup-sdhci.c
deleted file mode 100644
index c75a71b..000
--- a/arch/arm/mach-s3c64xx/setup-sdhci.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/* linux/arch/arm/mach-s3c64xx/setup-sdhci.c
- *
- * Copyright 2008 Simtec Electronics
- * Copyright 2008 Simtec Electronics
- * Ben Dooks b...@simtec.co.uk
- *

[PATCH V5 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names

2011-10-13 Thread Rajeshwari Shinde 
Add support for lookup of sdhci-s3c controller clocks using generic names
for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.

Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
 arch/arm/mach-exynos4/clock.c |   88 ++---
 arch/arm/mach-s3c2416/clock.c |   68 +++--
 arch/arm/mach-s3c64xx/clock.c |  126 +++--
 arch/arm/mach-s5pc100/clock.c |  130 --
 arch/arm/mach-s5pv210/clock.c |  167 -
 arch/arm/plat-s3c24xx/s3c2443-clock.c |   15 ++-
 6 files changed, 359 insertions(+), 235 deletions(-)

diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 9f50e33..8bc7534 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -1157,42 +1157,6 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
}, {
.clk= {
-   .name   = sclk_mmc,
-   .devname= s3c-sdhci.0,
-   .parent = clk_dout_mmc0.clk,
-   .enable = exynos4_clksrc_mask_fsys_ctrl,
-   .ctrlbit= (1  0),
-   },
-   .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
-   }, {
-   .clk= {
-   .name   = sclk_mmc,
-   .devname= s3c-sdhci.1,
-   .parent = clk_dout_mmc1.clk,
-   .enable = exynos4_clksrc_mask_fsys_ctrl,
-   .ctrlbit= (1  4),
-   },
-   .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
-   }, {
-   .clk= {
-   .name   = sclk_mmc,
-   .devname= s3c-sdhci.2,
-   .parent = clk_dout_mmc2.clk,
-   .enable = exynos4_clksrc_mask_fsys_ctrl,
-   .ctrlbit= (1  8),
-   },
-   .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
-   }, {
-   .clk= {
-   .name   = sclk_mmc,
-   .devname= s3c-sdhci.3,
-   .parent = clk_dout_mmc3.clk,
-   .enable = exynos4_clksrc_mask_fsys_ctrl,
-   .ctrlbit= (1  12),
-   },
-   .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
-   }, {
-   .clk= {
.name   = sclk_dwmmc,
.parent = clk_dout_mmc4.clk,
.enable = exynos4_clksrc_mask_fsys_ctrl,
@@ -1250,6 +1214,50 @@ static struct clksrc_clk clk_sclk_uart3 = {
.reg_div = { .reg = S5P_CLKDIV_PERIL0, .shift = 12, .size = 4 },
 };
 
+static struct clksrc_clk clk_sclk_mmc0 = {
+   .clk= {
+   .name   = sclk_mmc,
+   .devname= s3c-sdhci.0,
+   .parent = clk_dout_mmc0.clk,
+   .enable = exynos4_clksrc_mask_fsys_ctrl,
+   .ctrlbit= (1  0),
+   },
+   .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc1 = {
+   .clk= {
+   .name   = sclk_mmc,
+   .devname= s3c-sdhci.1,
+   .parent = clk_dout_mmc1.clk,
+   .enable = exynos4_clksrc_mask_fsys_ctrl,
+   .ctrlbit= (1  4),
+   },
+   .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc2 = {
+   .clk= {
+   .name   = sclk_mmc,
+   .devname= s3c-sdhci.2,
+   .parent = clk_dout_mmc2.clk,
+   .enable = exynos4_clksrc_mask_fsys_ctrl,
+   .ctrlbit= (1  8),
+   },
+   .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc3 = {
+   .clk= {
+   .name   = sclk_mmc,
+   .devname= s3c-sdhci.3,
+   .parent = clk_dout_mmc3.clk,
+   .enable = exynos4_clksrc_mask_fsys_ctrl,
+   .ctrlbit= (1  12),
+   },
+   .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
+};
+
 /* Clock initialization code */
 static struct clksrc_clk *sysclks[] = {
clk_mout_apll,
@@ -1289,6 +1297,10 @@ static struct clksrc_clk *clksrc_cdev[] = {
clk_sclk_uart1,
clk_sclk_uart2,
clk_sclk_uart3,
+

git clone linux-mmc tree issue: remote hung up unexpected

2011-10-13 Thread Shawn.Dong 
Hi Chris,
I want to clone a linux-mmc tree in my local machine by using command:
#git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git

But seems I can always hit remote hung up unexpectedly after using this
command. Also checked git.kernel.org, and didn't find the
linux/kernel/git/cjb/mmc.git data base.

Has linux-mmc server changed its address? Or I was using a wrong
command...Can you help me on this? Thanks in advance

Thanks
Shawn
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names

2011-10-13 Thread Russell King - ARM Linux 
On Thu, Oct 13, 2011 at 09:55:04AM +0200, Sylwester Nawrocki wrote:
 Yes, it allowed to add clkdev support with minimal changes required.
 
 But let's see what happens when the works on common struct clk for all
 architectures are more or less completed and we convert Samsung platforms
 to use it;)

The common struct clk shouldn't have much to do with the clkdev part of
it - clkdev just provides a method to associate a struct clk with the
drivers request.  The common struct clk doesn't change that.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V4 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names

2011-10-13 Thread Sylwester Nawrocki 
On 10/13/2011 10:55 AM, Russell King - ARM Linux wrote:
 On Thu, Oct 13, 2011 at 09:55:04AM +0200, Sylwester Nawrocki wrote:
 Yes, it allowed to add clkdev support with minimal changes required.

 But let's see what happens when the works on common struct clk for all
 architectures are more or less completed and we convert Samsung platforms
 to use it;)
 
 The common struct clk shouldn't have much to do with the clkdev part of
 it - clkdev just provides a method to associate a struct clk with the
 drivers request.  The common struct clk doesn't change that.

Indeed. I was just wondering where we end up with the arch struct clk attribute
which is specific to clkdev processes.
It could just go into the hardware-specific data, although it doesn't sound
like a perfectly right approach.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mmc: core: Prevent too long response times for suspend

2011-10-13 Thread Ulf Hansson 
While trying to suspend the mmc host there could still be
ongoing requests that we need to wait for. At the same time
a device driver must respond to a suspend request rather quickly.

Instead of potentially wait forever by claiming the host we now
try to claim the host instead. If it fails, -EBUSY is returned.

Signed-off-by: Ulf Hansson ulf.hans...@stericsson.com
---
 drivers/mmc/core/core.c |   42 +++---
 1 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 61d7730..b900932 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2121,21 +2121,33 @@ int mmc_suspend_host(struct mmc_host *host)
 
mmc_bus_get(host);
if (host-bus_ops  !host-bus_dead) {
-   if (host-bus_ops-suspend)
-   err = host-bus_ops-suspend(host);
-   if (err == -ENOSYS || !host-bus_ops-resume) {
-   /*
-* We simply remove the card in this case.
-* It will be redetected on resume.
-*/
-   if (host-bus_ops-remove)
-   host-bus_ops-remove(host);
-   mmc_claim_host(host);
-   mmc_detach_bus(host);
-   mmc_power_off(host);
-   mmc_release_host(host);
-   host-pm_flags = 0;
-   err = 0;
+
+   /*
+* A long response time is not acceptable for device drivers
+* when doing suspend. Prevent mmc_claim_host in the suspend
+* sequence, to potentially wait forever by trying to
+* pre-claim the host.
+*/
+   if (mmc_try_claim_host(host)) {
+   if (host-bus_ops-suspend)
+   err = host-bus_ops-suspend(host);
+   if (err == -ENOSYS || !host-bus_ops-resume) {
+   /*
+* We simply remove the card in this case.
+* It will be redetected on resume.
+*/
+   if (host-bus_ops-remove)
+   host-bus_ops-remove(host);
+   mmc_claim_host(host);
+   mmc_detach_bus(host);
+   mmc_power_off(host);
+   mmc_release_host(host);
+   host-pm_flags = 0;
+   err = 0;
+   }
+   mmc_do_release_host(host);
+   } else {
+   err = -EBUSY;
}
}
mmc_bus_put(host);
-- 
1.7.5.4

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

2011-10-13 Thread Ming Lei 
CC Rafael and linux-pm

On Thu, Oct 13, 2011 at 12:09 PM, Grant Likely
grant.lik...@secretlab.ca wrote:
 On Tue, Oct 11, 2011 at 08:29:18PM +0800, Ming Lei wrote:
 On Tue, Oct 11, 2011 at 1:37 AM, Andrei Warkentin awarken...@vmware.com 
 wrote:
  Hi,
 
  - Original Message -
  From: Greg KH g...@kroah.com
  To: Josh Triplett j...@joshtriplett.org
  Cc: G, Manjunath Kondaiah manj...@ti.com, 
  linux-arm-ker...@lists.infradead.org, Grant Likely
  grant.lik...@secretlab.ca, linux-o...@vger.kernel.org, 
  linux-mmc@vger.kernel.org, linux-ker...@vger.kernel.org,
  Dilan Lee di...@nvidia.com, Mark Brown 
  broo...@opensource.wolfsonmicro.com, manjun...@jasper.es
  Sent: Saturday, October 8, 2011 11:55:02 AM
  Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
 
 
  I'm a bit of a fly on the wall here, but I'm curious how this impacts 
  suspend/resume.
  device_initialize-device_pm_init are called from device_register, so 
  certainly this
  patch doesn't also ensure that the PM ordering matches probe ordering, 
  which is bound
  to break suspend, right? Was this ever tested with the OMAP target? 
  Shouldn't the

 Inside device_add(), device_pm_add is called before bus_probe_device,
 so the patch can't change the device order in pm list, and just change
 the driver probe order.

 That's the way it works now, but can it be reworked?  It would be

IMO, it depends on what shape you plan to rework.  Currently, the
deferred probe may found a resource dependency, but I am not sure
that pm dependency is same with the resource dependency found
during probe.

 possible to adjust the list order after successful probe.  However,
 I'm not clear on the ordering rules for the dpm_list.  Right now it is
 explicitly ordered to have parents before children, but as already
 expressed, that doesn't accurately represent ordering constraints for
 multiple device dependancies.

Maybe we should understand the correct model of the ordering constraints
for the multiple device dependancies first, could you give a description or
some examples about it?


 So, reordering the list would probably require maintaining the
 existing parent-child ordering constraint, but to also shift
 devices (and any possible children?) to be after drivers that are
 already probed.  That alone will be difficult to implement and get
 right, but maybe the constraints can be simplified.  It needs some
 further thought.

 g.




thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Linux v3.1-rc8 : SDHC card do not switch to high speed mode

2011-10-13 Thread Hebbar, Gururaja 
Hi all,

We are porting existing OMAP HSMMC driver (omap_hsmmc.c) to an upcoming SOC. 

When testing the driver with SanDisk 16GB SDHC Card (SanDisk Extreme HD Video 
16GB 20Mb/s), we observed that the card doesn't switch to High Speed mode. 

The card shows that it is compatible with SDA spec3. 

We are testing on Linux v3.1-rc8


In mmc_sd_init_card(), rocr received from card is 0xc0ff8000, (S18A bit not 
set).

During mmc_sd_setup_card() -- mmc_decode_scr(), when decoding scr, the card 
specifies that it is sda spec3 compatible 

if (scr-sda_vsn == SCR_SPEC_VER_2)
/* Check if Physical Layer Spec v3.0 is supported */
scr-sda_spec3 = UNSTUFF_BITS(resp, 47, 1); 
-- true

Then during mmc_read_switch(), since it's a sda spec3 card, the code goes to 
read sd3_drv_type  sd3_curr_limit and skips settings hs_max_dtr.

mmc_sd_switch_hs() returns back since hs_max_dtr == 0

if (card-sw_caps.hs_max_dtr == 0)
return 0;

Because of this Card isn't switched to High Speed mode.

Is there any solution for this? Has anyone seen this issue.

Thanks in advance.


I am also attaching the log I get from the sd dev attr

Regards
Gururaja

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat cid
0353445344313647800c03994400ac6f

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat csd
400e00325b5976b27f800a404013

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat date
12/2010

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat erase_size
512

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat fwrev
0x0

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat hwrev
0x8

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat name
SD16G

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat manfid
0x03

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat oemid
0x5344

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat preferred_erase_size
4194304

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat scr
02358000

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat serial
0x0c039944

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat type
SD

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat uevent
DRIVER=mmcblk
MMC_TYPE=SD
MMC_NAME=SD16G
MODALIAS=mmc:block


--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: mmci: Do not release spinlock in request_end

2011-10-13 Thread Russell King - ARM Linux 
On Tue, Oct 11, 2011 at 04:06:41PM +0200, Ulf Hansson wrote:
 The patch mmc: core: move -request() call from atomic context,
 is the reason to why this change is possible. This simplifies the
 error handling code execution path quite a lot and potentially also
 fixes some error handling hang problems.
 
 Signed-off-by: Ulf Hansson ulf.hans...@stericsson.com

This doesn't look right:

void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
{
if (err  cmd-retries) {
host-ops-request(host, mrq);

So, not dropping the spinlock results in calling the request function
with the spinlock held - and as the request function then goes on to
lock the spinlock, we will deadlock.

I don't see anything in current mainline which addresses this, so I'm
not able to queue this patch.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

2011-10-13 Thread Alan Stern 
On Thu, 13 Oct 2011, Ming Lei wrote:

  Inside device_add(), device_pm_add is called before bus_probe_device,
  so the patch can't change the device order in pm list, and just change
  the driver probe order.
 
  That's the way it works now, but can it be reworked? �It would be
 
 IMO, it depends on what shape you plan to rework.  Currently, the
 deferred probe may found a resource dependency, but I am not sure
 that pm dependency is same with the resource dependency found
 during probe.
 
  possible to adjust the list order after successful probe. �However,
  I'm not clear on the ordering rules for the dpm_list. �Right now it is
  explicitly ordered to have parents before children, but as already
  expressed, that doesn't accurately represent ordering constraints for
  multiple device dependancies.
 
 Maybe we should understand the correct model of the ordering constraints
 for the multiple device dependancies first, could you give a description or
 some examples about it?

The requirement is that devices must be capable of resuming in the 
order given by dpm_list, and they must be capable of suspending in 
the reverse order.

Therefore if device A can't work unless device B is functional, then B 
must come before A in dpm_list.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Linux v3.1-rc8 : SDHC card do not switch to high speed mode

2011-10-13 Thread Hebbar, Gururaja 
Hi all,

We are porting existing OMAP HSMMC driver (omap_hsmmc.c) to an upcoming SOC. 

When testing the driver with SanDisk 16GB SDHC Card (SanDisk Extreme HD Video 
16GB 20Mb/s), we observed that the card doesn't switch to High Speed mode. 

The card shows that it is compatible with SDA spec3. 

We are testing on Linux v3.1-rc8


In mmc_sd_init_card(), rocr received from card is 0xc0ff8000, (S18A bit not 
set).

During mmc_sd_setup_card() -- mmc_decode_scr(), when decoding scr, the card 
specifies that it is sda spec3 compatible 

if (scr-sda_vsn == SCR_SPEC_VER_2)
/* Check if Physical Layer Spec v3.0 is supported */
scr-sda_spec3 = UNSTUFF_BITS(resp, 47, 1); 
-- true

Then during mmc_read_switch(), since it's a sda spec3 card, the code goes to 
read sd3_drv_type  sd3_curr_limit and skips settings hs_max_dtr.

mmc_sd_switch_hs() returns back since hs_max_dtr == 0

if (card-sw_caps.hs_max_dtr == 0)
return 0;

Because of this Card isn't switched to High Speed mode.

Is there any solution for this? Has anyone seen this issue.

Thanks in advance.


I am also attaching the log I get from the sd dev attr

Regards
Gururaja

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat cid
0353445344313647800c03994400ac6f

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat csd
400e00325b5976b27f800a404013

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat date
12/2010

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat erase_size
512

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat fwrev
0x0

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat hwrev
0x8

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat name
SD16G

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat manfid
0x03

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat oemid
0x5344

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat preferred_erase_size
4194304

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat scr
02358000

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat serial
0x0c039944

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat type
SD

root@arago-armv7:/sys/devices/platform/omap/omap_hsmmc.0/mmc_host/mmc0/mmc0:#
 cat uevent
DRIVER=mmcblk
MMC_TYPE=SD
MMC_NAME=SD16G
MODALIAS=mmc:block


--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git clone linux-mmc tree issue: remote hung up unexpected

2011-10-13 Thread Chris Ball 
Hi,

On Thu, Oct 13 2011, Shawn.Dong wrote:
 Hi Chris,
 I want to clone a linux-mmc tree in my local machine by using command:
 #git clone git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git

 But seems I can always hit remote hung up unexpectedly after using this
 command. Also checked git.kernel.org, and didn't find the
 linux/kernel/git/cjb/mmc.git data base.

 Has linux-mmc server changed its address? Or I was using a wrong
 command...Can you help me on this? Thanks in advance

The tree is temporarily at:

git://dev.laptop.org/users/cjb/mmc mmc-next

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Linux v3.1-rc3/8 : card insertion/removal not working

2011-10-13 Thread Hebbar, Gururaja 
Hi all,

Hi all,

We are porting existing OMAP HSMMC driver (omap_hsmmc.c) to an upcoming SOC. 
The HSMMC IP is same as the one found in DM814x which uses the IP CD pins to 
detect MMC card insertion/removal rather than using gpio pins.

When testing the driver with SanDisk 16GB SDHC Card (SanDisk Extreme HD Video 
16GB 20Mb/s), we have observed that the card insertion/removal is not detected.

The PSTATE variable CINS do not change across card insertion/removal. However 
we do see a change in the CDPL bit in SD_PSTATE register. 

I have attached the logs[1] on Linux v3.1-rc8 that I get for reference.


Also, I tested the same on Linux v3.1-rc3 and found some interesting point. The 
card insertion/removal is detected when I read the regsparameter from omap 
hsmmc driver debugfs feature. As soon as I read the regs parameter, I get card 
insertion/removal messages on console. However the sad part is that the same 
procedure doesn't work on v3.1-rc8.

I have attached the logs[2] on Linux v3.1-rc3 that I get for reference.

Can someone guide on what could be the probable cause.

Thanks in advance

Regards
Gururaja


[1]Logs

[0.00] Linux version 3.1.0-rc8-51950-g2886ac9-dirty 
(gheb...@linux-psp-server.india.ext.ti.com) (gcc version 4.3.3 (GCC) ) #49 Wed 
Oct 12 15:31:19 IST 2011
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[0.00] Machine: am335xevm
[0.00] Memory policy: ECC disabled, Data cache writeback
...
...
[2.032665] mmc0: new SD card at address 
[2.037800] mmcblk0: mmc0: SD02G 1.84 GiB
[2.045124]  mmcblk0: p1
...
...


root@arago-armv7:~#mkdir -p /debugfs
root@arago-armv7:~#mount -t debugfs debugfs /debugfs
root@arago-armv7:~#cd /debugfs/mmc0/

1.  With card, no write-protect
root@arago-armv7:/debugfs/mmc0# cat clock
2500

root@arago-armv7:/debugfs/mmc0# cat ios
clock:  2500 Hz
vdd:20 (3.2 ~ 3.3 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:0 (legacy)

root@arago-armv7:/debugfs/mmc0# cat regs
mmc0:
enabled:   0
dpm_state: 0
nesting_cnt:   0
ctx_loss:  0:0

regs:
SYSCONFIG:  0x2015
CON:0x0700
HCTL:   0x0d02
SYSCTL: 0x00090107
IE: 0x00c0
ISE:0x00c0
CAPA:   0x06e10080
STAT:   0x
PSTATE: 0x01ff

2. Without card
root@arago-armv7:/debugfs/mmc0# cat clock
2500

root@arago-armv7:/debugfs/mmc0# cat ios
clock:  2500 Hz
vdd:20 (3.2 ~ 3.3 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:0 (legacy)

root@arago-armv7:/debugfs/mmc0# cat regs
mmc0:
enabled:   0
dpm_state: 0
nesting_cnt:   0
ctx_loss:  0:0

regs:
SYSCONFIG:  0x2015
CON:0x0700
HCTL:   0x0d02
SYSCTL: 0x00090107
IE: 0x00c0
ISE:0x00c0
CAPA:   0x06e10080
STAT:   0x
PSTATE: 0x01fb



[2]Logs

Uncompressing Linux... done, booting the kernel.
[0.00] Linux version 3.1.0-rc3-50824-gbd42c3b-dirty (user@linux-server) 
(gcc version 4.3.3 (GCC) ) #7 SMP Thu Oct 13 15:37:58 IST 2011
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f
[0.00] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache

1.  1st case. Card is present while booting kernel. 
Removal of card is not detected. Since omap hsmmc driver supports debugfs, I 
mounted debugfs. 
Inside mmc0 entry, I read regs parameter. As soon as I read, card removal got 
detected and I saw the log. 
Same for Card insertion also. Initially no response on console. As soon as I 
read the regs parameter, I was able to get console output and the card was 
mounted

2.  2nd case. Card is not present while booting kernel. 
Upon booting
...
...
[2.091839] Driver for 1-wire Dallas network protocol.
[2.101173] OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
[2.113554] omap_hsmmc omap_hsmmc.0: omap_hsmmc_runtime_resume : 2416 - 
enabled -- all these added for debugging
[2.123089] omap_hsmmc omap_hsmmc.0: omap_hsmmc_runtime_suspend : 2405 - 
disabled
[2.131592] omap_hsmmc omap_hsmmc.0: omap_hsmmc_enable_fclk : 1890 - enabled 
fclk
[2.139781] omap_hsmmc omap_hsmmc.0: omap_hsmmc_runtime_resume : 2416 - 
enabled
[2.147576] omap_hsmmc omap_hsmmc.0: omap_hsmmc_disable_fclk : 1899 - 
disabled fclk
[2.158232] usbcore: registered new interface driver usbhid
[2.164218] usbhid: USB HID core driver
...
...

Card insertion is not detected. After card insertion waited for 1 min. no 
console output

root@arago-armv7:~# mkdir -p /debugfs
root@arago-armv7:~# mount -t debugfs

Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

2011-10-13 Thread Ming Lei 
Hi,

On Thu, Oct 13, 2011 at 10:31 PM, Alan Stern st...@rowland.harvard.edu
 Maybe we should understand the correct model of the ordering constraints
 for the multiple device dependancies first, could you give a description or
 some examples about it?

 The requirement is that devices must be capable of resuming in the
 order given by dpm_list, and they must be capable of suspending in
 the reverse order.

 Therefore if device A can't work unless device B is functional, then B
 must come before A in dpm_list.

If all devices can support async suspend and resume correctly, looks like
the device order given by dpm_list is not needed any longer, doesn't it?


thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] mmc: mmci: Bugfix in pio read for small packets

2011-10-13 Thread Russell King - ARM Linux 
On Mon, Oct 10, 2011 at 10:23:02AM +0200, Ulf Hansson wrote:
 Linus Walleij wrote:
 On Sat, Oct 8, 2011 at 11:10 AM, Russell King - ARM Linux
 li...@arm.linux.org.uk wrote:
 On Fri, Oct 07, 2011 at 03:45:48PM +0200, Ulf Hansson wrote:

 Well, the patch system says that each one depends on the previous one,
 and the first one in the series contains the PIO read thing.

 Do 7108/1 onwards depend on 7106/1 and 7107/1 ?

 Probably my fault, since I was helping Ulf out with the patch tracker
 introduction.

 The patches should be pretty much semantically orthogonal as
 far as I can tell, the only reason dependency was stated that way
 was that I couldn't tell from head-parsing whether there were
 syntactical dependencies. (And wanted to avoid the annoyance
 of non-applying patches...)

 So if they apply, they are independent AFAICT.

 7108/1 and 7109/1, have real dependencies. Otherwise there none.

Ok, I assume that those depend on the first two patches.

So, I tried applying 7110/1 .. 7112/1 but the first rejects because it
doesn't have the non-power-of-2 support patch applied (7107/1).  And
it seems sensible that 7107/1 depends on 7106/1 (the PIO patch) which
I believe to be a problem.

Therefore, I don't think any of these can be applied without the
initial PIO patch.

One thing I haven't yet mentioned is about the non-power-of-2 support -
surely this can only be supported if blksz_datactrl16 is set?  If so,
shouldn't it key off that?  I don't see how it could otherwise support
non-power of 2 block sizes with just a log2 of the block size programmed
into the data control register.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

2011-10-13 Thread Alan Stern 
On Thu, 13 Oct 2011, Ming Lei wrote:

 Hi,
 
 On Thu, Oct 13, 2011 at 10:31 PM, Alan Stern st...@rowland.harvard.edu
  Maybe we should understand the correct model of the ordering constraints
  for the multiple device dependancies first, could you give a description or
  some examples about it?
 
  The requirement is that devices must be capable of resuming in the
  order given by dpm_list, and they must be capable of suspending in
  the reverse order.
 
  Therefore if device A can't work unless device B is functional, then B
  must come before A in dpm_list.
 
 If all devices can support async suspend and resume correctly, looks like
 the device order given by dpm_list is not needed any longer, doesn't it?

It _is_ needed, because the user can disable async suspend/resume via 
/sys/power/pm_async.

Also, not all devices do support async suspend/resume.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: mmci: Do not release spinlock in request_end

2011-10-13 Thread Jon Medhurst (Tixy) 
On Thu, 2011-10-13 at 15:29 +0100, Russell King - ARM Linux wrote:
 On Tue, Oct 11, 2011 at 04:06:41PM +0200, Ulf Hansson wrote:
  The patch mmc: core: move -request() call from atomic context,
  is the reason to why this change is possible. This simplifies the
  error handling code execution path quite a lot and potentially also
  fixes some error handling hang problems.
  
  Signed-off-by: Ulf Hansson ulf.hans...@stericsson.com
 
 This doesn't look right:
 
 void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
 {
 if (err  cmd-retries) {
 host-ops-request(host, mrq);
 
 So, not dropping the spinlock results in calling the request function
 with the spinlock held - and as the request function then goes on to
 lock the spinlock, we will deadlock.

Indeed, deadlock behaviour at this point is what I see with this patch
on a Versatile Express board running 3.0-rc9.

-- 
Tixy

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

2011-10-13 Thread Grant Likely 
On Thu, Oct 13, 2011 at 10:31:45AM -0400, Alan Stern wrote:
 On Thu, 13 Oct 2011, Ming Lei wrote:
 
   Inside device_add(), device_pm_add is called before bus_probe_device,
   so the patch can't change the device order in pm list, and just change
   the driver probe order.
  
   That's the way it works now, but can it be reworked? ?It would be
  
  IMO, it depends on what shape you plan to rework.  Currently, the
  deferred probe may found a resource dependency, but I am not sure
  that pm dependency is same with the resource dependency found
  during probe.
  
   possible to adjust the list order after successful probe. ?However,
   I'm not clear on the ordering rules for the dpm_list. ?Right now it is
   explicitly ordered to have parents before children, but as already
   expressed, that doesn't accurately represent ordering constraints for
   multiple device dependancies.
  
  Maybe we should understand the correct model of the ordering constraints
  for the multiple device dependancies first, could you give a description or
  some examples about it?
 
 The requirement is that devices must be capable of resuming in the 
 order given by dpm_list, and they must be capable of suspending in 
 the reverse order.
 
 Therefore if device A can't work unless device B is functional, then B 
 must come before A in dpm_list.

For the deferred case; here is an example of the additional
constraint.  Consider the following hierarchy:

-A
 +-B
 | +-C
 | +-D
 |
 +-E
   +-F
   +-G

dpm_list could be ordered in at least the following ways (depending on
exactly when devices get registered).  There are many permutation, but
children are always be listed after its direct parent.

1) ABECDFG (breadth first)
2) AEBFGCD (breadth first)
3) ABCDEFG (depth first)
4) AEFGBCD (depth first)

Now, assume that device B depends on device F, and also assume that
there is no way either to express that in the hierarchy or even for
the constraint to be known at device registration time (the is exactly
the situation we're dealing with on embedded platforms).  Only the
driver for B knows that it needs a resource provided by F's driver.
So, the situation becomes that the ordering of dpm_list must now also
be sorted so that non-tree dependencies are also accounted for.  Of
the list above, only sort order 4 meets the new constraint.

The question then becomes, how can the dpm_list get resorted
dynamically at runtime to ensure that the new constraints are always
met without breaking old ones.  Here are some options I can think of:

1) When a deferred probe succeeds, move the deferred device to the
end of the dpm_list.  Then the new sort order might be one of:

1) AECDFGB
2) AEFGCDB
3) ACDEFGB
4) AEFGCDB

However, that approach breaks the guarantee that children appear after
their parents (C  D appear before B in all cases above)

2a) When a deferred probe succeeds, move the deferred device and it's
entire child hierarchy to the end of the list to become one of:

1) AEFGBCD
2) AEFGBCD
3) AEFGBCD
4) AEFGBCD (hey! they're all the same now, but there are other
orderings possible that aren't)  :-)

Problem: Complexity increases.  This requires iterating through all
the children and performing a reorder for each.  Fortunately, this
should be too expensive since I believe each individual move is an
O(1) operation.  I don't think the code will need to walk the list for
each device.

Potential problem: This may result in unnecessary sorting in a lot of
cases.  It may be that the newly probed device is already after the
device it depends on, but the driver just hadn't been probed early
enough to avoid deferral.

Potential problem: It may end up exposing implicit dependencies
between drivers that weren't observed before.

Potential problem: This completely breaks if a parent gets probed
*after* its child which might happen if something other than the
parent driver creates the child devices.  I don't think this is a real
problem, but I think the kernel would first need to ensure that none
of the children are bound to drivers, and complain loudly if they are.
Otherwise the dpm_list won't reflect probe order.

2b) alternately, when *any* probe succeeds, move the deferred device
and its children to the end of the list.  This continues to maintain
the parent-child relationship, and it ensures that the dpm_list is
always also sorted in probe-order (devices bound to drivers will
collect at the end of the list).

Potential problem: On a big device hierarchy, this will mean a lot of
moves.  It should still only be O(1) for each move, but O(N^2) over
probing the entire hierarchy.  Devices will end up being moved once
for itself, and once for each parent and grandparent bound to a
driver.  It could become slow.

This option also has the potential problem when a parent gets probed
after its child as discussed in 2a.

3) Add devices to dpm_list after successful probe instead of at

Re: [RFC/PATCH] mmc: core: Kill block requests if card is removed

2011-10-13 Thread Sujit Reddy Thumma 

On 10/12/2011 4:04 PM, Pavan Kondeti wrote:

Hello Sujit,

On 10/12/2011 1:06 PM, Sujit Reddy Thumma wrote:

Kill block requests when the host knows that the card is
removed from the slot and is sure that it can no longer
accept any requests.

Kill this silently so that the block layer don't output
error messages unnecessarily.

Signed-off-by: Sujit Reddy Thummasthu...@codeaurora.org


snip


diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 0ea4a06..7cdbc14 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -196,6 +196,7 @@ struct mmc_card {
  #define MMC_STATE_HIGHSPEED_DDR (14)  /* card is in high speed mode 
*/
  #define MMC_STATE_ULTRAHIGHSPEED (15) /* card is in ultra high 
speed mode */
  #define MMC_CARD_SDXC (16)/* card is SDXC */
+#define MMC_STATE_INSERTED  (17)  /* card present in the slot */
unsigned intquirks; /* card quirks */
  #define MMC_QUIRK_LENIENT_FN0 (10)/* allow SDIO FN0 writes 
outside of the VS CCCR range */
  #define MMC_QUIRK_BLKSZ_FOR_BYTE_MODE (11)/* use func-cur_blksize */
@@ -344,6 +345,7 @@ static inline void __maybe_unused remove_quirk(struct 
mmc_card *card, int data)
  #define mmc_card_sdio(c)  ((c)-type == MMC_TYPE_SDIO)

  #define mmc_card_present(c)   ((c)-state  MMC_STATE_PRESENT)
+#define mmc_card_inserted(c) ((c)-state  MMC_STATE_INSERTED)
  #define mmc_card_readonly(c)  ((c)-state  MMC_STATE_READONLY)
  #define mmc_card_highspeed(c) ((c)-state  MMC_STATE_HIGHSPEED)
  #define mmc_card_blockaddr(c) ((c)-state  MMC_STATE_BLOCKADDR)
@@ -352,6 +354,7 @@ static inline void __maybe_unused remove_quirk(struct 
mmc_card *card, int data)
  #define mmc_card_ext_capacity(c) ((c)-state  MMC_CARD_SDXC)

  #define mmc_card_set_present(c)   ((c)-state |= MMC_STATE_PRESENT)
+#define mmc_card_set_inserted(c) ((c)-state |= MMC_STATE_INSERTED)
  #define mmc_card_set_readonly(c) ((c)-state |= MMC_STATE_READONLY)
  #define mmc_card_set_highspeed(c) ((c)-state |= MMC_STATE_HIGHSPEED)
  #define mmc_card_set_blockaddr(c) ((c)-state |= MMC_STATE_BLOCKADDR)


Why do we need another flag to indicate card's presence? can not we use
MMC_STATE_PRESENT flag? This flag is set in mmc_add_card(). But not
cleared any where...

MMC_STATE_PRESENT signifies the card presence in sysfs i.e. after 
device_add() is called we can be sure that kobject for card device is 
created. This will be cleared automatically when we do 
mmc_release_card() after card removal. But before this when doing 
device_del() is called the FS layer flush/sync the dirty data onto card. 
This creates unnecessary noise in dmesg log when the card is removed 
from the slot (without unmounting).

Thanks,
Pavan



Thanks,
Sujit
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

2011-10-13 Thread Alan Stern 
On Thu, 13 Oct 2011, Grant Likely wrote:

 For the deferred case; here is an example of the additional
 constraint.  Consider the following hierarchy:
 
 -A
  +-B
  | +-C
  | +-D
  |
  +-E
+-F
+-G
 
 dpm_list could be ordered in at least the following ways (depending on
 exactly when devices get registered).  There are many permutation, but
 children are always be listed after its direct parent.
 
 1) ABECDFG (breadth first)
 2) AEBFGCD (breadth first)
 3) ABCDEFG (depth first)
 4) AEFGBCD (depth first)
 
 Now, assume that device B depends on device F, and also assume that
 there is no way either to express that in the hierarchy or even for
 the constraint to be known at device registration time (the is exactly
 the situation we're dealing with on embedded platforms).  Only the
 driver for B knows that it needs a resource provided by F's driver.
 So, the situation becomes that the ordering of dpm_list must now also
 be sorted so that non-tree dependencies are also accounted for.  Of
 the list above, only sort order 4 meets the new constraint.
 
 The question then becomes, how can the dpm_list get resorted
 dynamically at runtime to ensure that the new constraints are always
 met without breaking old ones.  Here are some options I can think of:

This was a long message and I haven't absorbed the whole thing.  
However it's worth pointing out right at the start that we already have
device_pm_move_before(), device_pm_move_after(), and
device_pm_move_last().  They are intended specifically to provide
drivers with a way of making sure that dpm_list is in the right order 
-- people have been aware of these issues for some time.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

2011-10-13 Thread Grant Likely 
On Thu, Oct 13, 2011 at 02:16:42PM -0400, Alan Stern wrote:
 On Thu, 13 Oct 2011, Grant Likely wrote:
 
  For the deferred case; here is an example of the additional
  constraint.  Consider the following hierarchy:
  
  -A
   +-B
   | +-C
   | +-D
   |
   +-E
 +-F
 +-G
  
  dpm_list could be ordered in at least the following ways (depending on
  exactly when devices get registered).  There are many permutation, but
  children are always be listed after its direct parent.
  
  1) ABECDFG (breadth first)
  2) AEBFGCD (breadth first)
  3) ABCDEFG (depth first)
  4) AEFGBCD (depth first)
  
  Now, assume that device B depends on device F, and also assume that
  there is no way either to express that in the hierarchy or even for
  the constraint to be known at device registration time (the is exactly
  the situation we're dealing with on embedded platforms).  Only the
  driver for B knows that it needs a resource provided by F's driver.
  So, the situation becomes that the ordering of dpm_list must now also
  be sorted so that non-tree dependencies are also accounted for.  Of
  the list above, only sort order 4 meets the new constraint.
  
  The question then becomes, how can the dpm_list get resorted
  dynamically at runtime to ensure that the new constraints are always
  met without breaking old ones.  Here are some options I can think of:
 
 This was a long message and I haven't absorbed the whole thing.  

heh; I did get rather verbose there.

 However it's worth pointing out right at the start that we already have
 device_pm_move_before(), device_pm_move_after(), and
 device_pm_move_last().  They are intended specifically to provide
 drivers with a way of making sure that dpm_list is in the right order 
 -- people have been aware of these issues for some time.

I saw those.  I also notice that they are only used by device_move()
when reparenting a device (which is another wrinkle I hadn't though
about).  Reparenting a device becomes problematic if the probe order
is also represented in the list.  If device_move() gets called, then
any implicit probe-order sorting for that device would be lost.

I also notice that device_move disregards any children when moving a
device, which could also be a problem.

Although it looks like the only users of device_move are:

drivers/media/video/pvrusb2/pvrusb2-v4l2.c
drivers/s390/cio/device.c
net/bluetooth/hci_sysfs.c
net/bluetooth/rfcomm/tty.c

So it may not be significant to adapt.

g.

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V8] mmc: core: Add Power Off Notify Feature eMMC 4.5

2011-10-13 Thread Chris Ball 
Hi Girish, just trivial changes below.

Does anyone have a Tested-by: to add to the patch?

On Thu, Oct 13 2011, Girish K S wrote:
 This patch adds the support for power off notify feature, available in 
 eMMC 4.5 devices. If the the host has support for this feature, then the
 mmc core will notify it to the device by setting the POWER_OFF_NOTIFICATION
 byte in the extended csd register with a value 1(POWER_ON).

 For suspend mode short timeout is used, whereas for the normal poweroff long
 timeout is used.
 cc: Chris Ball c...@laptop.org
 Signed-off-by: Girish K S girish.shivananja...@linaro.org
 Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
 ---
 Changes in V8:
   Updated with review comments of Chris Ball and rebased to 
   chris-mmc/mmc-next branch.
 Changes in V7:
   Rebased to chris-mmc/mmc-next branch. merged to patches 
   to single patch.
 Changes in V6:
   Fixes checkpatch errors. The patches are generated after
   rebasing to chris's mmc-next branch.
 Changes in V5:
   This patch version fixes the problem with power off
   notify function, when called for the first time and
   card is not yet initialised.
 Changes in V4:
   Updated with review comments of Jeon
 Changes in V2:
   Adds poweroff notification handling in suspend/normal.

  drivers/mmc/core/core.c  |   36 
  drivers/mmc/core/mmc.c   |   23 +--
  drivers/mmc/host/sdhci.c |9 +
  include/linux/mmc/card.h |6 ++
  include/linux/mmc/host.h |6 ++
  include/linux/mmc/mmc.h  |8 
  6 files changed, 86 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
 index 61d7730..db368b2 100644
 --- a/drivers/mmc/core/core.c
 +++ b/drivers/mmc/core/core.c
 @@ -1212,11 +1212,45 @@ static void mmc_power_up(struct mmc_host *host)
  
  void mmc_power_off(struct mmc_host *host)
  {
 + struct mmc_card *card;

struct mmc_card *card = host-card;

 + unsigned int notify_type;
 + unsigned int timeout;
 + int err;
 +
 + BUG_ON(!host);

Not necessary.

 +
   mmc_host_clk_hold(host);
  
 + card = host-card;
   host-ios.clock = 0;
   host-ios.vdd = 0;
  
 + if (card != NULL  mmc_card_mmc(card) 

!= NULL is unnecessary.

 + (card-poweroff_notify_state == MMC_POWERED_ON)) {

Extra set of parens unnecessary.

 +
 + if (host-power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
 + notify_type = EXT_CSD_POWER_OFF_SHORT;
 + timeout = card-ext_csd.generic_cmd6_time;
 + card-poweroff_notify_state = MMC_POWEROFF_SHORT;
 + } else {
 + notify_type = EXT_CSD_POWER_OFF_LONG;
 + timeout = card-ext_csd.power_off_longtime;
 + card-poweroff_notify_state = MMC_POWEROFF_LONG;
 + }
 +
 + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
 +  EXT_CSD_POWER_OFF_NOTIFICATION,
 +  notify_type, timeout);
 +
 + if (err  err != -EBADMSG)
 + pr_err(Device failed to respond within %d poweroff 
 +time. Forcefully powering down the device\n,
 +timeout);
 +
 + /* Set the card state to no notification after the poweroff */
 + card-poweroff_notify_state = MMC_NO_POWER_NOTIFICATION;
 + }
 +
   /*
* Reset ocr mask to be the highest possible voltage supported for
* this mmc host. This value will be used at next power up.
 @@ -2208,6 +2242,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
  
   spin_lock_irqsave(host-lock, flags);
   host-rescan_disable = 1;
 + host-power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
   spin_unlock_irqrestore(host-lock, flags);
   cancel_delayed_work_sync(host-detect);
  
 @@ -2231,6 +2266,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
  
   spin_lock_irqsave(host-lock, flags);
   host-rescan_disable = 0;
 + host-power_notify_type = MMC_HOST_PW_NOTIFY_LONG;
   spin_unlock_irqrestore(host-lock, flags);
   mmc_detect_change(host, 0);
  
 diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
 index 4e869d3..f8ea938 100644
 --- a/drivers/mmc/core/mmc.c
 +++ b/drivers/mmc/core/mmc.c
 @@ -458,10 +458,12 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 
 *ext_csd)
   else
   card-erased_byte = 0x0;
  
 - if (card-ext_csd.rev = 6)
 + if (card-ext_csd.rev = 6) {
   card-ext_csd.generic_cmd6_time = 10 *
   ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
 - else
 + card-ext_csd.power_off_longtime = 10 *
 + ext_csd[EXT_CSD_POWER_OFF_LONG_TIME];
 + } else

Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism

2011-10-13 Thread Ming Lei 
On Fri, Oct 14, 2011 at 12:04 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Thu, 13 Oct 2011, Ming Lei wrote:

 Hi,

 On Thu, Oct 13, 2011 at 10:31 PM, Alan Stern st...@rowland.harvard.edu
  Maybe we should understand the correct model of the ordering constraints
  for the multiple device dependancies first, could you give a description 
  or
  some examples about it?
 
  The requirement is that devices must be capable of resuming in the
  order given by dpm_list, and they must be capable of suspending in
  the reverse order.
 
  Therefore if device A can't work unless device B is functional, then B
  must come before A in dpm_list.

 If all devices can support async suspend and resume correctly, looks like
 the device order given by dpm_list is not needed any longer, doesn't it?

 It _is_ needed, because the user can disable async suspend/resume via
 /sys/power/pm_async.

 Also, not all devices do support async suspend/resume.

Basically, the devices which don't support async suspend/resume
should have out of tree PM dependency. If out of tree PM dependency
issue is solved, all devices can support async suspend/resume.

thanks,
-- 
Ming Lei
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html