Re: [patch] sdhci: correct f_min in sd 3.0

2010-09-24 Thread zhangfei gao 
On Thu, Sep 23, 2010 at 11:24 PM, Chris Ball  wrote:
> Hi,
>
> On Mon, Sep 20, 2010 at 03:32:58AM -0400, zhangfei gao wrote:
>> From: Zhangfei Gao 
>> Date: Mon, 20 Sep 2010 15:15:18 -0400
>> Subject: [PATCH 4/4] sdhci: correct f_min in sd 3.0
>>
>> Change-Id: Ie8604dbb5296b15da67071164564f21c60652b60
>>
>> Signed-off-by: Zhangfei Gao 
>> ---
>>  drivers/mmc/host/sdhci.c |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index f980fb7..5346803 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1835,6 +1835,8 @@ int sdhci_add_host(struct sdhci_host *host)
>>       mmc->ops = &sdhci_ops;
>>       if (host->ops->get_min_clock)
>>               mmc->f_min = host->ops->get_min_clock(host);
>> +     else if (host->version >= SDHCI_SPEC_300)
>> +             mmc->f_min = host->max_clk / 2046;
>>       else
>>               mmc->f_min = host->max_clk / 256;
>>       mmc->f_max = host->max_clk;
>
> Oh, right -- it would be good to #define symbols for 256 and 2046,
> since we're inserting them into sdhci.c for the second time.
> Perhaps SDHCI_MAX_DIV_SPEC_{200,300}?
>
> I can do that in a separate patch if you prefer, or you could roll
> it into this one.
>
> Thanks,
>
> --
> Chris Ball      
> One Laptop Per Child
>

Thanks for your suggestion, here is updated patch.

>From dc098c73df0872269b3d364462672664450d1df4 Mon Sep 17 00:00:00 2001
From: Zhangfei Gao 
Date: Mon, 20 Sep 2010 15:15:18 -0400
Subject: [PATCH] sdhci: correct f_min in sd 3.0

Signed-off-by: Zhangfei Gao 
---
 drivers/mmc/host/sdhci.c |8 +---
 drivers/mmc/host/sdhci.h |3 +++
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 5928b0a..829e78a 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1007,14 +1007,14 @@ static void sdhci_set_clock(struct sdhci_host
*host, unsigned int clock)
if (host->max_clk <= clock)
div = 1;
else {
-   for (div = 2; div < 2046; div += 2) {
+   for (div = 2; div < SDHCI_MAX_DIV_SPEC_300; div += 2) {
if ((host->max_clk / div) <= clock)
break;
}
}
} else {
/* Version 2.00 divisors must be a power of 2. */
-   for (div = 1; div < 256; div *= 2) {
+   for (div = 1; div < SDHCI_MAX_DIV_SPEC_200; div *= 2) {
if ((host->max_clk / div) <= clock)
break;
}
@@ -1836,8 +1836,10 @@ int sdhci_add_host(struct sdhci_host *host)
mmc->ops = &sdhci_ops;
if (host->ops->get_min_clock)
mmc->f_min = host->ops->get_min_clock(host);
+   else if (host->version >= SDHCI_SPEC_300)
+   mmc->f_min = host->max_clk / SDHCI_MAX_DIV_SPEC_300;
else
-   mmc->f_min = host->max_clk / 256;
+   mmc->f_min = host->max_clk / SDHCI_MAX_DIV_SPEC_200;
mmc->f_max = host->max_clk;
mmc->caps |= MMC_CAP_SDIO_IRQ;

diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index ae28a31..d35fb3d 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -185,6 +185,9 @@
 #define   SDHCI_SPEC_200   1
 #define   SDHCI_SPEC_300   2

+#defineSDHCI_MAX_DIV_SPEC_200  256
+#defineSDHCI_MAX_DIV_SPEC_300  2046
+
 struct sdhci_ops;

 struct sdhci_host {
-- 
1.7.0.4
From dc098c73df0872269b3d364462672664450d1df4 Mon Sep 17 00:00:00 2001
From: Zhangfei Gao 
Date: Mon, 20 Sep 2010 15:15:18 -0400
Subject: [PATCH] sdhci: correct f_min in sd 3.0

Signed-off-by: Zhangfei Gao 
---
 drivers/mmc/host/sdhci.c |8 +---
 drivers/mmc/host/sdhci.h |3 +++
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 5928b0a..829e78a 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1007,14 +1007,14 @@ static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
 		if (host->max_clk <= clock)
 			div = 1;
 		else {
-			for (div = 2; div < 2046; div += 2) {
+			for (div = 2; div < SDHCI_MAX_DIV_SPEC_300; div += 2) {
 if ((host->max_clk / div) <= clock)
 	break;
 			}
 		}
 	} else {
 		/* Version 2.00 divisors must be a power of 2. */
-		for (div = 1; div < 256; div *= 2) {
+		for (div = 1; div < SDHCI_MAX_DIV_SPEC_200; div *= 2) {
 			if ((host->max_clk / div) <= clock)
 break;
 		}
@@ -1836,8 +1836,10 @@ int sdhci_add_host(struct sdhci_host *host)
 	mmc->ops = &sdhci_ops;
 	if (host->ops->get_min_clock)
 		mmc->f_min = host->ops->get_min_clock(host);
+	else if (host->version >= SDHCI_SPEC_300)
+		mmc->f_min = host->max_clk / SDHCI_MAX_DIV_SPEC_300;
 	else
-		mmc->f_min = host->max_clk /

Re: [patch] mmc: fix init f_min

2010-09-24 Thread zhangfei gao 
On Mon, Sep 20, 2010 at 10:34 AM, David Vrabel  wrote:
> zhangfei gao wrote:
>> From fa357144df43e6c1a9e5e36af497c53437cd41e1 Mon Sep 17 00:00:00 2001
>> From: Zhangfei Gao 
>> Date: Mon, 20 Sep 2010 15:12:26 -0400
>> Subject: [PATCH 3/4] mmc: fix init f_min
>>
>> Change-Id: I7fab1a1a162d9f26fc92c497078f26912c04a3fc
>
> What's this line in the description for?
>
>> Signed-off-by: Zhangfei Gao 
>> ---
>>  drivers/mmc/core/core.c |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>> index 5db49b1..9114c87 100644
>> --- a/drivers/mmc/core/core.c
>> +++ b/drivers/mmc/core/core.c
>> @@ -910,9 +910,9 @@ static void mmc_power_up(struct mmc_host *host)
>>       if (host->f_min > 40) {
>>               pr_warning("%s: Minimum clock frequency too high for "
>>                               "identification mode\n", mmc_hostname(host));
>> -             host->ios.clock = host->f_min;
>> -     } else
>>               host->ios.clock = 40;
>> +     } else
>> +             host->ios.clock = host->f_min;
>
> NAK.
>
> The code is already correctly requesting 400 kHz (unless the controller
> can't go that slow).

Original code
if (host->f_min > 40) {
pr_warning("%s: Minimum clock frequency too high for "
"identification mode\n", mmc_hostname(host));
host->ios.clock = host->f_min;
} else
host->ios.clock = 40;

With this code, the init clock is would be at lease 400 kHz, and no
matter how bigger the host->f_min it is, is this really correct?

>
> David
> --
> David Vrabel, Senior Software Engineer, Drivers
> CSR, Churchill House, Cambridge Business Park,  Tel: +44 (0)1223 692562
> Cowley Road, Cambridge, CB4 0WZ                 http://www.csr.com/
>
>
> Member of the CSR plc group of companies. CSR plc registered in England and 
> Wales, registered number 4187346, registered office Churchill House, 
> Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
>
--
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 1/4] omap4 hsmmc: Adding card detect support for MMC1

2010-09-24 Thread Tony Lindgren 
* kishore kadiyala  [100924 10:05]:
> Adding card detect callback function and card detect configuration
> function for MMC1 Controller on OMAP4.
> 
> Card detect configuration function does initial configuration of the
> MMC Control & PullUp-PullDown registers of Phoenix.
> 
> For MMC1 Controller, card detect interrupt source is
> twl6030 which is non-gpio. The card detect call back function provides
> card present/absent status by reading MMC Control register present
> on twl6030.
> 
> Since OMAP4 doesn't use any GPIO line as used in OMAP3 for card detect,
> the suspend/resume initialization which was done in omap_hsmmc_gpio_init
> previously is moved to the probe thus making it generic for both OMAP3 & 
> OMAP4.

> --- a/drivers/mfd/twl6030-irq.c
> +++ b/drivers/mfd/twl6030-irq.c

Looks like this patch should be sent to Samuel Ortiz as it's mostly
mfd related.

Tony
--
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/2] mmc_test: fix memory allocation segment limits

2010-09-24 Thread Chris Ball 
Hi Adrian,

On Thu, Sep 23, 2010 at 02:51:29PM +0300, Adrian Hunter wrote:
> From: Adrian Hunter 
> Date: Thu, 23 Sep 2010 12:55:15 +0300
> Subject: [PATCH 1/2] mmc_test: fix memory allocation segment limits
> 
> Correctly allocate memory to meet the host controller
> driver's maximum segment size and count limits.

Thanks very much, this fixes my problems.  I've pushed it to mmc-next.

Output below, just in case you're curious:

mmc_test mmc0:e624: Card claimed for testing.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 1. Basic write (no data verification)...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 2. Basic read (no data verification)...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 3. Basic write (with data verification)...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 4. Basic read (with data verification)...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 5. Multi-block write...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 6. Multi-block read...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 7. Power of two block writes...
mmc0: Result: UNSUPPORTED (by card)
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 8. Power of two block reads...
mmc0: Result: UNSUPPORTED (by card)
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 9. Weird sized block writes...
mmc0: Result: UNSUPPORTED (by card)
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 10. Weird sized block reads...
mmc0: Result: UNSUPPORTED (by card)
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 11. Badly aligned write...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 12. Badly aligned read...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 13. Badly aligned multi-block write...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 14. Badly aligned multi-block read...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 15. Correct xfer_size at write (start failure)...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 16. Correct xfer_size at read (start failure)...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 17. Correct xfer_size at write (midway failure)...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 18. Correct xfer_size at read (midway failure)...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 19. Highmem write...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 20. Highmem read...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 21. Multi-block highmem write...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 22. Multi-block highmem read...
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 23. Best-case read performance...
mmc0: Transfer of 1024 sectors (512 KiB) took 0.033058904 seconds (15859 kB/s, 
15487 KiB/s)
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 24. Best-case write performance...
mmc0: Transfer of 1024 sectors (512 KiB) took 0.036752587 seconds (14265 kB/s, 
13930 KiB/s)
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 25. Best-case read performance into scattered pages...
mmc0: Transfer of 8 sectors (4 KiB) took 0.000796178 seconds (5144 kB/s, 5024 
KiB/s)
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 26. Best-case write performance from scattered pages...
mmc0: Transfer of 8 sectors (4 KiB) took 0.002371540 seconds (1727 kB/s, 1686 
KiB/s)
mmc0: Result: OK
mmc0: Tests completed.
mmc0: Starting tests of card mmc0:e624...
mmc0: Test case 27. Single read performance by transfer size...
mmc0: Transfer of 1 sectors (0.5 KiB) took 0.000551456 seconds (928 kB/s, 906 
KiB/s)
mmc0: Transfer of 2 sectors (1 KiB) took 0.000552924 seconds (1851 kB/s, 1808 
KiB/s)
mmc0: Transfer of 4 sectors (2 KiB) took 0.000668650 seconds (3062 kB/s, 2991 
KiB/s)
mmc0: Transfer of 8 sectors (4 KiB) took 0.000696796 seconds (5878 kB/s, 5740 
KiB/s)
mmc0: Transfer of 16 sectors (8 KiB) took 0.001019670 seconds (8033 kB/s, 7845 
KiB/s)
mmc0: Transfer of 32 sectors (16 KiB) took 0.0

Re: [PATCH] sdhci: allow controller private registers to be changaed on reset

2010-09-24 Thread Philip Rakity 

Alan,

Cannot find you patch for sdhci.c for reset -- can you send it to me.  

The approach of having a reset call into the platform specific code is fine.  
This is the way I implemented our code originally but    this was not felt 
when I did the code as the right direction to go in.  What I did in my code was 
call back into the driver reset and then reset the private registers.  I felt 
this gave me more control.

Philip


On Sep 24, 2010, at 10:26 AM, Alan Cox wrote:

> On Fri, 24 Sep 2010 09:42:15 -0700
> Philip Rakity  wrote:
> 
>>> From 9d64df0fa6874371446147f67c071e78c587c0d6 Mon Sep 17 00:00:00 2001
>> From: Philip Rakity 
>> Date: Fri, 24 Sep 2010 05:27:11 -0700
>> Subject: [PATCH] sdhci: allow controller private registers to be changaed on 
>> reset
>> 
>> allow controllers that have private registers that are reset when
>> the controller is reset. They need to be reprogrammed back to their
>> values when the reset happens.  Provide a hook to allow this to happen.
>> 
>> Signed-off-by: Philip Rakity 
>> ---
>> drivers/mmc/host/sdhci.c |3 +++
>> drivers/mmc/host/sdhci.h |1 +
>> 2 files changed, 4 insertions(+), 0 deletions(-)
>> 
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 401527d..0774dad 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -174,6 +174,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
>> 
>>  if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
>>  sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
>> +
>> +if (host->ops->platform_specific_reset)
>> +host->ops->platform_specific_reset(host, mask);
>> }
>> 
>> static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
>> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
>> index d316bc7..f68af47 100644
>> --- a/drivers/mmc/host/sdhci.h
>> +++ b/drivers/mmc/host/sdhci.h
>> @@ -323,6 +323,7 @@ struct sdhci_ops {
>>  unsigned int(*get_max_clock)(struct sdhci_host *host);
>>  unsigned int(*get_min_clock)(struct sdhci_host *host);
>>  unsigned int(*get_timeout_clock)(struct sdhci_host *host);
>> +void(*platform_specific_reset)(struct sdhci_host *host, u8 mask);
> 
> See the patches I posted earlier about reset. All of sdhci_reset could be
> cleaned up further by replacing sdhci_reset as a whole with a hookable
> interface, and the hook you propose isn't sufficient for the Intel
> devices, nor can it eliminate some of the other quirk flags.
> 
> Alan

--
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 14/24] mmc: change to new flag variable

2010-09-24 Thread matt mooney 
The EXTRA_CFLAGS assignment in mmc/Makefile was not accomplishing
anything because this flag only has effect on sources at the same level
as the makefile (i.e., per directory). Since card/, core/, and host/
rely on MMC_DEBUG, the subdir-ccflags-y variant seems to be the
appropriate choice.

Signed-off-by: matt mooney 
---
 drivers/mmc/Makefile  |4 +---
 drivers/mmc/card/Makefile |4 
 drivers/mmc/core/Makefile |4 
 drivers/mmc/host/Makefile |4 
 4 files changed, 1 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 9979f5e..12eef39 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -2,9 +2,7 @@
 # Makefile for the kernel mmc device drivers.
 #
 
-ifeq ($(CONFIG_MMC_DEBUG),y)
-   EXTRA_CFLAGS+= -DDEBUG
-endif
+subdir-ccflags-$(CONFIG_MMC_DEBUG) := -DDEBUG
 
 obj-$(CONFIG_MMC)  += core/
 obj-$(CONFIG_MMC)  += card/
diff --git a/drivers/mmc/card/Makefile b/drivers/mmc/card/Makefile
index 0d40751..c73b406 100644
--- a/drivers/mmc/card/Makefile
+++ b/drivers/mmc/card/Makefile
@@ -2,10 +2,6 @@
 # Makefile for MMC/SD card drivers
 #
 
-ifeq ($(CONFIG_MMC_DEBUG),y)
-   EXTRA_CFLAGS+= -DDEBUG
-endif
-
 obj-$(CONFIG_MMC_BLOCK)+= mmc_block.o
 mmc_block-objs := block.o queue.o
 obj-$(CONFIG_MMC_TEST) += mmc_test.o
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index 889e5f8..86b4791 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -2,10 +2,6 @@
 # Makefile for the kernel mmc core.
 #
 
-ifeq ($(CONFIG_MMC_DEBUG),y)
-   EXTRA_CFLAGS+= -DDEBUG
-endif
-
 obj-$(CONFIG_MMC)  += mmc_core.o
 mmc_core-y := core.o bus.o host.o \
   mmc.o mmc_ops.o sd.o sd_ops.o \
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 840bcb5..e35e778 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -2,10 +2,6 @@
 # Makefile for MMC/SD host controller drivers
 #
 
-ifeq ($(CONFIG_MMC_DEBUG),y)
-   EXTRA_CFLAGS+= -DDEBUG
-endif
-
 obj-$(CONFIG_MMC_ARMMMCI)  += mmci.o
 obj-$(CONFIG_MMC_PXA)  += pxamci.o
 obj-$(CONFIG_MMC_IMX)  += imxmmc.o
-- 
1.7.2.1

--
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 4/4] omap4 hsmmc: Update ocr mask for MMC2 for regulator to use

2010-09-24 Thread kishore kadiyala 
On OMAP4, MMC2 controller has eMMC which draws power from VAUX regulator
on TWL. Though the eMMC supports dual voltage[1.8v/3v] as per ocr register,
its VCC is fixed at 3V for operation. With this once the mmc core selects
the minimum voltage[1.8] supported based on the ocr value read from OCR 
register,
eMMC will not get detected. Thus the platform data for MMC2 is updated with ocr
mask and same will be communicated to core which will set the regulator to
always operate at 3V when ever turned ON.

Cc: Tony Lindgren 
Cc: Andrew Morton 
Cc: Madhusudhan Chikkature 
Cc: Adrian Hunter 
Signed-off-by: Kishore Kadiyala 
---
 arch/arm/mach-omap2/board-4430sdp.c |1 +
 drivers/mmc/host/omap_hsmmc.c   |   12 
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 7978a79..8b0e71a 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -202,6 +202,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.nonremovable   = true,
+   .ocr_mask   = MMC_VDD_29_30,
},
{}  /* Terminator */
 };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8cb007c..f629acf 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -364,6 +364,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
 {
struct regulator *reg;
int ret = 0;
+   int ocr_value = 0;

switch (host->id) {
case OMAP_MMC1_DEVID:
@@ -396,6 +397,17 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
}
} else {
host->vcc = reg;
+   ocr_value = mmc_regulator_get_ocrmask(reg);
+   if (!mmc_slot(host).ocr_mask) {
+   mmc_slot(host).ocr_mask = ocr_value;
+   } else {
+   if (!(mmc_slot(host).ocr_mask & ocr_value)) {
+   pr_err("MMC%d ocrmask %x is not supported\n",
+   host->id, mmc_slot(host).ocr_mask);
+   mmc_slot(host).ocr_mask = 0;
+   return -EINVAL;
+   }
+   }
mmc_slot(host).ocr_mask = mmc_regulator_get_ocrmask(reg);

/* Allow an aux regulator */
-- 
1.7.0.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 3/4] omap4 hsmmc: Register offset handling

2010-09-24 Thread kishore kadiyala 

In OMAP4, as per new PM programming model, the legacy registers
which were there in OMAP3 are all shifted by 0x100 while new one's
are added from offset 0 to 0x10.
For OMAP4, the register offset appending of 0x100 done in devices.c
currently, is moved to driver file.This change fits in for current
implementation as well as once the driver undergoes hwmod adaptation.

Cc: Tony Lindgren 
Cc: Andrew Morton 
Cc: Madhusudhan Chikkature 
Cc: Adrian Hunter 
Cc: Benoit Cousson 
Signed-off-by: Kishore Kadiyala 
---
 arch/arm/mach-omap2/devices.c |8 +++-
 arch/arm/mach-omap2/hsmmc.c   |4 
 arch/arm/plat-omap/include/plat/mmc.h |3 +++
 drivers/mmc/host/omap_hsmmc.c |2 ++
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..bb7ec13 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -745,13 +745,13 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data 
**mmc_data,
case 3:
if (!cpu_is_omap44xx())
return;
-   base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
+   base = OMAP4_MMC4_BASE;
irq = OMAP44XX_IRQ_MMC4;
break;
case 4:
if (!cpu_is_omap44xx())
return;
-   base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
+   base = OMAP4_MMC5_BASE;
irq = OMAP44XX_IRQ_MMC5;
break;
default:
@@ -762,10 +762,8 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data 
**mmc_data,
size = OMAP2420_MMC_SIZE;
name = "mmci-omap";
} else if (cpu_is_omap44xx()) {
-   if (i < 3) {
-   base += OMAP4_MMC_REG_OFFSET;
+   if (i < 3)
irq += OMAP44XX_IRQ_GIC_START;
-   }
size = OMAP4_HSMMC_SIZE;
name = "mmci-omap-hs";
} else {
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index c8f647b..49d76a7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -261,6 +261,10 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info 
*controllers)
mmc->slots[0].wires = c->wires;
mmc->slots[0].internal_clock = !c->ext_clock;
mmc->dma_mask = 0x;
+   if (cpu_is_omap44xx())
+   mmc->reg_offset = OMAP4_MMC_REG_OFFSET;
+   else
+   mmc->reg_offset = 0;

mmc->get_context_loss_count = hsmmc_get_context_loss;

diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
b/arch/arm/plat-omap/include/plat/mmc.h
index 9b89ec6..4e6ef07 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -71,6 +71,9 @@ struct omap_mmc_platform_data {

u64 dma_mask;

+   /* Register offset deviation */
+   u16 reg_offset;
+
struct omap_mmc_slot_data {

/* 4 wire signaling is optional, and is used for SD/SDIO/HSMMC;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a51894d..8cb007c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2009,6 +2009,8 @@ static int __init omap_hsmmc_probe(struct platform_device 
*pdev)
if (res == NULL || irq < 0)
return -ENXIO;

+   res->start += pdata->reg_offset;
+   res->end += pdata->reg_offset;
res = request_mem_region(res->start, res->end - res->start + 1,
pdev->name);
if (res == NULL)
-- 
1.7.0.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/4] omap4 hsmmc: Fix the init if CONFIG_MMC_OMAP_HS is not set

2010-09-24 Thread kishore kadiyala 
From: Benoit Cousson 

Avoid possible crash if CONFIG_MMC_OMAP_HS is not set

Cc: Tony Lindgren 
Cc: Andrew Morton 
Cc: Madhusudhan Chikkature 
Cc: Adrian Hunter 
Signed-off-by: Benoit Cousson 
Signed-off-by: Kishore Kadiyala 
---
 arch/arm/mach-omap2/board-4430sdp.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index a49f285..7978a79 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -240,8 +240,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device 
*dev)

 static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
 {
-   struct omap_mmc_platform_data *pdata = dev->platform_data;
+   struct omap_mmc_platform_data *pdata;

+   /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
+   if (!dev) {
+   pr_err("Failed %s\n", __func__);
+   return;
+   }
+   pdata = dev->platform_data;
pdata->init =   omap4_twl6030_hsmmc_late_init;
 }

-- 
1.7.0.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/4] omap4 hsmmc: Adding card detect support for MMC1

2010-09-24 Thread kishore kadiyala 
Adding card detect callback function and card detect configuration
function for MMC1 Controller on OMAP4.

Card detect configuration function does initial configuration of the
MMC Control & PullUp-PullDown registers of Phoenix.

For MMC1 Controller, card detect interrupt source is
twl6030 which is non-gpio. The card detect call back function provides
card present/absent status by reading MMC Control register present
on twl6030.

Since OMAP4 doesn't use any GPIO line as used in OMAP3 for card detect,
the suspend/resume initialization which was done in omap_hsmmc_gpio_init
previously is moved to the probe thus making it generic for both OMAP3 & OMAP4.

Cc: Tony Lindgren 
Cc: Andrew Morton 
Cc: Madhusudhan Chikkature 
Cc: Adrian Hunter 
Signed-off-by: Kishore Kadiyala 
---
 arch/arm/mach-omap2/board-4430sdp.c |7 +++-
 drivers/mfd/twl6030-irq.c   |   73 +++
 drivers/mmc/host/omap_hsmmc.c   |4 +-
 include/linux/i2c/twl.h |   31 +++
 4 files changed, 112 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..a49f285 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device 
*dev)
struct omap_mmc_platform_data *pdata = dev->platform_data;

/* Setting MMC1 Card detect Irq */
-   if (pdev->id == 0)
+   if (pdev->id == 0) {
+   ret = twl6030_mmc_card_detect_config();
+   if (ret)
+   pr_err("Failed configuring MMC1 card detect\n");
pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+   pdata->slots[0].card_detect = twl6030_mmc_card_detect;
+   }
return ret;
 }

diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..2d3bb82 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 

 /*
  * TWL6030 (unlike its predecessors, which had two level interrupt handling)
@@ -223,6 +224,78 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
 }
 EXPORT_SYMBOL(twl6030_interrupt_mask);

+int twl6030_mmc_card_detect_config(void)
+{
+   int ret;
+   u8 reg_val = 0;
+
+   /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
+   twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+   REG_INT_MSK_LINE_B);
+   twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+   REG_INT_MSK_STS_B);
+   /*
+* Intially Configuring MMC_CTRL for receving interrupts &
+* Card status on TWL6030 for MMC1
+*/
+   ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val, TWL6030_MMCCTRL);
+   if (ret < 0) {
+   pr_err("twl6030: Failed to read MMCCTRL, error %d\n", ret);
+   return ret;
+   }
+   reg_val &= ~VMMC_AUTO_OFF;
+   reg_val |= SW_FC;
+   ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+   if (ret < 0) {
+   pr_err("twl6030: Failed to write MMCCTRL, error %d\n", ret);
+   return ret;
+   }
+
+   /* Configuring PullUp-PullDown register */
+   ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_val,
+   TWL6030_CFG_INPUT_PUPD3);
+   if (ret < 0) {
+   pr_err("twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n",
+   ret);
+   return ret;
+   }
+   reg_val &= ~(MMC_PU | MMC_PD);
+   ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
+   TWL6030_CFG_INPUT_PUPD3);
+   if (ret < 0) {
+   pr_err("twl6030: Failed to write CFG_INPUT_PUPD3, error %d\n",
+   ret);
+   return ret;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
+
+int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+   int ret = -EIO;
+   u8 read_reg = 0;
+   struct platform_device *pdev = to_platform_device(dev);
+
+   if (pdev->id) {
+   /* TWL6030 provide's Card detect support for
+* only MMC1 controller.
+*/
+   pr_err("Unkown MMC controller %d in %s\n", pdev->id, __func__);
+   return ret;
+   }
+   /*
+* BIT0 of MMC_CTRL on TWL6030 provides card status for MMC1
+* 0 - Card not present ,1 - Card present
+*/
+   ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, &read_reg,
+   TWL6030_MMCCTRL);
+   if (ret >= 0)
+

[PATCH v4 0/4] omap4 hsmmc: Card detect and Register offset handling

2010-09-24 Thread kishore kadiyala 
The patch series is based on mainline 2.6.36-rc5.
The series is tested on OMAP3430SDP and OMAP4430SDP and has dependency on
http://www.mail-archive.com/linux-o...@vger.kernel.org/msg34718.html

V3:
http://www.mail-archive.com/linux-o...@vger.kernel.org/msg35423.html

V2:
http://www.mail-archive.com/linux-o...@vger.kernel.org/msg35135.html

V1:
http://www.mail-archive.com/linux-o...@vger.kernel.org/msg34040.html

Kishore Kadiyala (3):
  omap4 hsmmc : Adding card detect support for MMC1
  omap4 hsmmc: Register offset handling
  omap4 hsmmc: Update ocr mask for MMC2 for regulator to use

Benoit Cousson (1);
  omap4 hsmmc: Fix the init if CONFIG_MMC_OMAP_HS is not set

 arch/arm/mach-omap2/board-4430sdp.c   |   16 ++-
 arch/arm/mach-omap2/devices.c |8 +--
 arch/arm/mach-omap2/hsmmc.c   |4 ++
 arch/arm/plat-omap/include/plat/mmc.h |3 +
 drivers/mfd/twl6030-irq.c |   73 +
 drivers/mmc/host/omap_hsmmc.c |   18 +++-
 include/linux/i2c/twl.h   |   31 ++
 7 files changed, 144 insertions(+), 9 deletions(-)


--
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] sdhci: allow controller private registers to be changaed on reset

2010-09-24 Thread Alan Cox 
On Fri, 24 Sep 2010 09:42:15 -0700
Philip Rakity  wrote:

> >From 9d64df0fa6874371446147f67c071e78c587c0d6 Mon Sep 17 00:00:00 2001
> From: Philip Rakity 
> Date: Fri, 24 Sep 2010 05:27:11 -0700
> Subject: [PATCH] sdhci: allow controller private registers to be changaed on 
> reset
> 
> allow controllers that have private registers that are reset when
> the controller is reset. They need to be reprogrammed back to their
> values when the reset happens.  Provide a hook to allow this to happen.
> 
> Signed-off-by: Philip Rakity 
> ---
>  drivers/mmc/host/sdhci.c |3 +++
>  drivers/mmc/host/sdhci.h |1 +
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 401527d..0774dad 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -174,6 +174,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
>  
>   if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
>   sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
> +
> + if (host->ops->platform_specific_reset)
> + host->ops->platform_specific_reset(host, mask);
>  }
>  
>  static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index d316bc7..f68af47 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -323,6 +323,7 @@ struct sdhci_ops {
>   unsigned int(*get_max_clock)(struct sdhci_host *host);
>   unsigned int(*get_min_clock)(struct sdhci_host *host);
>   unsigned int(*get_timeout_clock)(struct sdhci_host *host);
> + void(*platform_specific_reset)(struct sdhci_host *host, u8 mask);

See the patches I posted earlier about reset. All of sdhci_reset could be
cleaned up further by replacing sdhci_reset as a whole with a hookable
interface, and the hook you propose isn't sufficient for the Intel
devices, nor can it eliminate some of the other quirk flags.

Alan
--
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] sdhci: allow controller private registers to be changaed on reset

2010-09-24 Thread Philip Rakity 
>From 9d64df0fa6874371446147f67c071e78c587c0d6 Mon Sep 17 00:00:00 2001
From: Philip Rakity 
Date: Fri, 24 Sep 2010 05:27:11 -0700
Subject: [PATCH] sdhci: allow controller private registers to be changaed on 
reset

allow controllers that have private registers that are reset when
the controller is reset. They need to be reprogrammed back to their
values when the reset happens.  Provide a hook to allow this to happen.

Signed-off-by: Philip Rakity 
---
 drivers/mmc/host/sdhci.c |3 +++
 drivers/mmc/host/sdhci.h |1 +
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 401527d..0774dad 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -174,6 +174,9 @@ static void sdhci_reset(struct sdhci_host *host, u8 mask)
 
if (host->quirks & SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET)
sdhci_clear_set_irqs(host, SDHCI_INT_ALL_MASK, ier);
+
+   if (host->ops->platform_specific_reset)
+   host->ops->platform_specific_reset(host, mask);
 }
 
 static void sdhci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index d316bc7..f68af47 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -323,6 +323,7 @@ struct sdhci_ops {
unsigned int(*get_max_clock)(struct sdhci_host *host);
unsigned int(*get_min_clock)(struct sdhci_host *host);
unsigned int(*get_timeout_clock)(struct sdhci_host *host);
+   void(*platform_specific_reset)(struct sdhci_host *host, u8 mask);
 };
 
 #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
-- 
1.6.0.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 v3 1/4] omap4 hsmmc: Adding card detect support for MMC1

2010-09-24 Thread kishore kadiyala 
Hi Hari,


On Thu, Sep 23, 2010 at 11:22 AM, kishore kadiyala
 wrote:
> Hi Hari,
>
> On Thu, Sep 23, 2010 at 1:19 AM, Kanigeri, Hari  wrote:
>> Kishore,
>>
>>> +int twl6030_mmc_card_detect(struct device *dev, int slot)
>>> +{
>>> +     int ret = -EIO;
>>> +     u8 read_reg = 0;
>>> +     struct platform_device *pdev = to_platform_device(dev);
>>> +
>>> +     switch (pdev->id) {
>>> +     case 0:
>>> +             /*
>>> +              * BIT0 of REG_MMC_CTRL
>>> +              * 0 - Card not present ,1 - Card present
>>> +              */
>>> +             ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, &read_reg,
>>> +                                                     TWL6030_MMCCTRL);
>>> +             if (ret >= 0)
>>> +                     ret = read_reg & STS_MMC;
>>> +             break;
>>
>> nitpick: may be you don't need a switch statement for only one case.
>
> From future perspective,since there are 5 MMC controllers on OMAP4
> and current patch supports card detect feature only for one controller i.e 
> MMC1
> as of now. Once the interfaces connected on the remaining 4 MMC controllers
> are defined further additions will be required for respective cases.


Correcting my previous comment, I've just verified twl6030 current
version spec on OMAP4
which can provide card detect interrupt only for one MMC controller i.e MMC1.
I will replace switch with if.

Regards,
Kishore
--
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 v3 2/4] omap4 hsmmc: Fix the init if CONFIG_MMC_OMAP_HS is not set

2010-09-24 Thread kishore kadiyala 
On Wed, Sep 22, 2010 at 11:35 PM, Sergei Shtylyov  wrote:
> Hello.
>
> kishore kadiyala wrote:
>
>> From: Benoit Cousson 
>
>> Avoid possible crash if CONFIG_MMC_OMAP_HS is not set
>
>> Signed-off-by: Benoit Cousson 
>> Signed-off-by: Kishore Kadiyala 
>> ---
>>  arch/arm/mach-omap2/board-4430sdp.c |    8 +++-
>>  1 files changed, 7 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/board-4430sdp.c
>> b/arch/arm/mach-omap2/board-4430sdp.c
>> index a49f285..ac8541c 100644
>> --- a/arch/arm/mach-omap2/board-4430sdp.c
>> +++ b/arch/arm/mach-omap2/board-4430sdp.c
>> @@ -240,8 +240,14 @@ static int omap4_twl6030_hsmmc_late_init(struct
>> device *dev)
>>
>>  static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
>>  {
>> -       struct omap_mmc_platform_data *pdata = dev->platform_data;
>> +       struct omap_mmc_platform_data *pdata;
>>
>> +       /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
>> +       if (!dev) {
>> +               pr_err("Failed omap4_twl6030_hsmmc_set_late_init\n");
>
>   pr_err("Failed %s\n", __func__);

OK , will have as mentioned
>
> WBR, Sergei

Regards,
Kishore
--
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: failure of block read wait for long time

2010-09-24 Thread Ghorai, Sukumar 
Chris and Adrian,

[..snip..]
> 
> > -Original Message-
> > From: Chris Ball [mailto:c...@laptop.org]
> > Sent: Wednesday, September 22, 2010 6:13 PM
> > To: Ghorai, Sukumar
> > Cc: Adrian Hunter; linux-mmc@vger.kernel.org; linux-arm-
> > ker...@lists.infradead.org; Russell King - ARM Linux
> > Subject: Re: [PATCH] mmc: failure of block read wait for long time
> >
> > On Wed, Sep 22, 2010 at 11:02:08AM +0530, Ghorai, Sukumar wrote:
> > > Would you please review and merge this patch [1] (attached too)?
> > > [1] http://comments.gmane.org/gmane.linux.kernel.mmc/2714
> >
> > I've been following the thread.  I believe Adrian has NACKed this patch,
> > by saying "It is absolutely unacceptable to return I/O errors to the
> > upper layers for segments that do not have errors."
> 
> [Ghorai]
> I think Russell also mentioned his opinion. Would you please add your idea
> too?
> 
> 1. I would prefer Adrian to explain again what this statement means, in
> the context - data read fail and how we make it success?
> 
> 2. if data read fail for sector(x) why we have to try for
> sector(x+1, ..x+n)?
> 
> 3. how to inform reader function which sector having the valid data out of
> (1...n) sectors.
> 
> 4. do we have any driver/code in Linux or any other os, which give inter-
> leave data and return as success?
> 
[Ghorai] please reply with your input on my/ Russell's suggestion?

> >
> > I think it's possible to merge patches to improve the situation (such
> > as the idea of noticing a card disappearing earlier), but your initial
> > patch is not the patch to do that.  You should continue to work with
> > Adrian -- when he's happy that a patch does not break the semantics
> > above, we can consider merging it.
> >
> > Thanks,
> >
> > --
> > Chris Ball  
> > 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

Re: [PATCH 0/4] Adding support for esdhc on mx35/51

2010-09-24 Thread Wolfram Sang 
On Fri, Sep 24, 2010 at 05:40:15PM +0800, Zhu Richard-R65037 wrote:

> Hi Wolfram:
> Sorry to bring the confusions to you.

Well, no worries, maybe I was not clear as well. Hope we have everything
clear now :)

> I will use your git repos and make up the missing bits (i.e:the
> HOST_CONROL and so on) and verify the func on MX51 BBG boards later.
> BTW, Is the URL of your git repos the following one?
> git://git.pengutronix.de/git/wsa/linux-2.6.git

Yes. I pushed out the current status of my branch, but I haven't
implemented all requested changes from Anton yet. Will do on Monday.
If you can't afford to wait for this updated branch, please keep your
changes well separated to reduce merge conflicts.

Thanks!

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature

Re: [PATCH (mmc-next) 1/3] mmc: add suspend/resume in the sdhci-pltfm driver

2010-09-24 Thread Peppe CAVALLARO 
On 09/24/2010 11:04 AM, Wolfram Sang wrote:
> On Fri, Sep 24, 2010 at 07:54:53AM +0200, Peppe CAVALLARO wrote:
>> Hello
>> I wonder if you could review the three patches I sent the mailing list:
>> especially the following ones:
> 
> I intend to have a closer look at them, but please give me a few days. I
> first need to get my "official" tasks done...

Hi Wolfram,
no problem take it easy. Let me know as soon as you complete it.

Kind Regards
Peppe

> 
> Regards,
> 
>Wolfram
> 
--
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 0/4] Adding support for esdhc on mx35/51

2010-09-24 Thread Zhu Richard-R65037 
Hi Wolfram:
Sorry to bring the confusions to you.
I will use your git repos and make up the missing bits (i.e:the
HOST_CONROL and so on) and verify the func on MX51 BBG boards later.
BTW, Is the URL of your git repos the following one?
git://git.pengutronix.de/git/wsa/linux-2.6.git

Best Regards,
Richard Zhu
Freescale Semiconductor
Tel: +86-021-28937189
Email:hong-xing@freescale.com 


-Original Message-
From: Wolfram Sang [mailto:w.s...@pengutronix.de] 
Sent: Friday, 24 September, 2010 16:58
To: Zhu Richard-R65037
Cc: linux-mmc@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Anton Vorontsov
Subject: Re: [PATCH 0/4] Adding support for esdhc on mx35/51

On Fri, Sep 24, 2010 at 03:08:52PM +0800, Zhu Richard-R65037 wrote:
> Hi Wolfram:
> See my comments.

BTW can't you get your mailer to quote like all others do? It is
inconvenient to read this way.

> > It would bring the conveniences to maintain stuff in the future if 
> > we separate them.
> 
> If you can name these conveniences and they are convincing, we can 
> keep them seperate. At the moment, I don't see them (what doesn't mean

> they don't exist) [] As Anton's description 
> different eSDHC IP on the i.MX and the PPC may have the different IC 
> bugs or limitations.

Sure thing. I don't see any problem with that as I don't want to merge
them completely, but just to share the common parts. Fixups can be done
in the specific part.

> As I know that although in the i.MX SOC family, there are a few 
> differences between different SOCs. And the behaviors of SW driver may

> be impacted by these differences.

If you have even more incarnations of a similar core in the future to
come, that is another reason to share those parts which are in common.
Smaller differences can easily be handled in sdhci-esdhc-imx.c, I think.
For example, if stuff like

if (cpu_is_mx35())
quirks |= SDHCI_QUIRKS_NO_MULTIBLOCK;

will do, why would you want to duplicate all the code covering the
non-standard register layouts? Check the imx-spi driver how to handle
variations of a similar core.

> I'm afraid that the differences of eSDHC IP module between i.MX and 
> PPC maybe bigger and bigger in future.

If the core of a future IMX99 might be too different, we can have a
custom driver then, but for now, I think a common driver is the way to
go.

> BTW, the block size of the i.MX eSDHC is not forced to 2K size. Up to 
> now, the default 512byes per sector is used in FSL i.MX Linux BSP.

It is forced to 2K, because it would be otherwise set to 4K (according
to the cap-register) which is not conform to the spec 2.0. What is the
advantage of 512 byte?

> > And there is already one set of eSDHC driver for all the i.MX SOCs.
> 
> I am confused: which set do you mean?
> [] The driver used for i.MX eSDHC. The one used by
> i.MX35 in Linux kernel now, and the coming MX51 and so on.
> It is better that one driver supports all i.MX SOC's eSDHC modules in 
> future (MX25, MX35, MX51, MX53...).

? Now I am totally confused. That is what I am aiming for :D My driver
was mainly tested on MX35 back then, but was clearly intended to be for
MX51. It was clearly mentioned in the subject "[PATCH 0/4] Adding
support for esdhc on mx35/51". Frankly, I was hoping for a patchset from
you adding the stuff you need for you MX51-board on top of mine, and not
a completely new series. Will have a look at that now...

Regards,

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang
|
Industrial Linux Solutions | http://www.pengutronix.de/
|

--
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] sdhci: add quirk for controllers that don't support write only detect

2010-09-24 Thread Philip Rakity 

looked at richard code for get_ro.  It will work.  

On Sep 23, 2010, at 9:49 PM, Wolfram Sang wrote:

> On Thu, Sep 23, 2010 at 04:18:02PM -0700, Philip Rakity wrote:
>>   Since your patches are not available yet -- I think it makes more sense if
>>   this patch is considered for inclusion and you can add then include its
>>   functionality in your code.
> 
> Hmm, I don't think so. As I mentioned elsewhere, Richard Zhu has posted such
> patches you could base your work on. And if his approach works for you and you
> like it, you could ack them, or say Tested-by or so...
> 
> Regards,
> 
>   Wolfram
> 
> -- 
> Pengutronix e.K.   | Wolfram Sang|
> Industrial Linux Solutions | http://www.pengutronix.de/  |

--
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-next) 1/3] mmc: add suspend/resume in the sdhci-pltfm driver

2010-09-24 Thread Wolfram Sang 
On Fri, Sep 24, 2010 at 07:54:53AM +0200, Peppe CAVALLARO wrote:
> Hello
> I wonder if you could review the three patches I sent the mailing list:
> especially the following ones:

I intend to have a closer look at them, but please give me a few days. I
first need to get my "official" tasks done...

Regards,

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature

Re: [PATCH 0/4] Adding support for esdhc on mx35/51

2010-09-24 Thread Wolfram Sang 
On Fri, Sep 24, 2010 at 03:08:52PM +0800, Zhu Richard-R65037 wrote:
> Hi Wolfram:
> See my comments.

BTW can't you get your mailer to quote like all others do? It is
inconvenient to read this way.

> > It would bring the conveniences to maintain stuff in the future if we 
> > separate them.
> 
> If you can name these conveniences and they are convincing, we can keep
> them seperate. At the moment, I don't see them (what doesn't mean they
> don't exist)
> [] As Anton's description different eSDHC IP on the
> i.MX and the PPC may have the different IC bugs or limitations.

Sure thing. I don't see any problem with that as I don't want to merge
them completely, but just to share the common parts. Fixups can be done
in the specific part.

> As I know that although in the i.MX SOC family, there are a few
> differences between different SOCs. And the behaviors of SW driver may
> be impacted by these differences.

If you have even more incarnations of a similar core in the future to
come, that is another reason to share those parts which are in common.
Smaller differences can easily be handled in sdhci-esdhc-imx.c, I think.
For example, if stuff like

if (cpu_is_mx35())
quirks |= SDHCI_QUIRKS_NO_MULTIBLOCK;

will do, why would you want to duplicate all the code covering the
non-standard register layouts? Check the imx-spi driver how to handle
variations of a similar core.

> I'm afraid that the differences of eSDHC IP module between i.MX and PPC
> maybe bigger and bigger in future.

If the core of a future IMX99 might be too different, we can have a
custom driver then, but for now, I think a common driver is the way to
go.

> BTW, the block size of the i.MX eSDHC is not forced to 2K size. Up to
> now, the default 512byes per sector is used in FSL i.MX Linux BSP.

It is forced to 2K, because it would be otherwise set to 4K (according
to the cap-register) which is not conform to the spec 2.0. What is the
advantage of 512 byte?

> > And there is already one set of eSDHC driver for all the i.MX SOCs.
> 
> I am confused: which set do you mean?
> [] The driver used for i.MX eSDHC. The one used by
> i.MX35 in Linux kernel now, and the coming MX51 and so on.
> It is better that one driver supports all i.MX SOC's eSDHC modules in
> future (MX25, MX35, MX51, MX53...).

? Now I am totally confused. That is what I am aiming for :D My driver
was mainly tested on MX35 back then, but was clearly intended to be for
MX51. It was clearly mentioned in the subject "[PATCH 0/4] Adding
support for esdhc on mx35/51". Frankly, I was hoping for a patchset from
you adding the stuff you need for you MX51-board on top of mine, and not
a completely new series. Will have a look at that now...

Regards,

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature

Re: [PATCH 1/2] tmio_mmc: handle missing HW interrupts

2010-09-24 Thread Arnd Hannemann 
Added MLs into CC

Am 23.09.2010 21:30, schrieb Ian Molton:
> this looks like something we should have... did you get any feedback?

No not yet.

Regards
Arnd

--
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/2] tmio_mmc: fix CMD irq handling

2010-09-24 Thread Arnd Hannemann 
Added MLs into CC

Am 23.09.2010 21:28, schrieb Ian Molton:
> This looks good - what testing has it had ?

Tested with the SDHI hardware block in sh7372 (on AP4EVB).
Both with PIO and DMA. Tested with MMC and SD cards.

Regards
Arnd
--
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 0/4] Adding support for esdhc on mx35/51

2010-09-24 Thread Zhu Richard-R65037 
Hi Wolfram:
See my comments.

Best Regards,
Richard Zhu
Freescale Semiconductor
Tel: +86-021-28937189
Email:hong-xing@freescale.com 


-Original Message-
From: Wolfram Sang [mailto:w.s...@pengutronix.de] 
Sent: Friday, 24 September, 2010 14:43
To: Zhu Richard-R65037
Cc: linux-mmc@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
Anton Vorontsov
Subject: Re: [PATCH 0/4] Adding support for esdhc on mx35/51

Hi Richard,

> * About the share between i.MX and PPC eSDHC.
> Why configure a few parts be shared between the i.MX eSDHC and PPC 
> eSDHC? Can they be separated into two independent systems?

The rule of thumb is to avoid code-duplication. Assume the PPC driver
gets fixed an off-by-one error in the freq-calculation, you surely want
to have that fix on imx, too.

> It would bring the conveniences to maintain stuff in the future if we 
> separate them.

If you can name these conveniences and they are convincing, we can keep
them seperate. At the moment, I don't see them (what doesn't mean they
don't exist)
[] As Anton's description different eSDHC IP on the
i.MX and the PPC may have the different IC bugs or limitations.
As I know that although in the i.MX SOC family, there are a few
differences between different SOCs. And the behaviors of SW driver may
be impacted by these differences.
I'm afraid that the differences of eSDHC IP module between i.MX and PPC
maybe bigger and bigger in future.

BTW, the block size of the i.MX eSDHC is not forced to 2K size. Up to
now, the default 512byes per sector is used in FSL i.MX Linux BSP.

> And there is already one set of eSDHC driver for all the i.MX SOCs.

I am confused: which set do you mean?
[] The driver used for i.MX eSDHC. The one used by
i.MX35 in Linux kernel now, and the coming MX51 and so on.
It is better that one driver supports all i.MX SOC's eSDHC modules in
future (MX25, MX35, MX51, MX53...).

> As we know that i.MX and PPC are the disparate SOC families.

Well, if the eSDHC-core itself is the same or very similar, that doesn't
really matter IMO. Especially as the of-platform-bus might disappear
somewhen in the future, the PPC and imx-drivers could become more
similar.

> * About the driver name of i.MX eSDHC driver, I think that use the imx

> to identify it is better than esdhc.

I picked up Anton's suggestion 'sdhci-esdhc-imx.c' so far. Although I am
still not sure if 'sdhci-esdhc-pltfm.c' would be more precise.

> As I know that the eSDHC name wouldn't be used anymore in next 
> generation SOCs of i.MX family.
> So the name of imx would be much clear and exact.

Not really, because all _existing_ implementations are called eSDHC, no?
:) If some future incarnations have a different name, but behave the
same or very similar, this is usually no problem. Check for example the
I2C eeprom driver which is named 'at24' but support basically all
EEPROMs and not only Atmel ones. Same goes for a couple of RTC-drivers,
etc...
[] :), ok.

Kind regards,

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang
|
Industrial Linux Solutions | http://www.pengutronix.de/
|

--
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