date:20110118

Re: A MMC card transfer issue

2011-01-18 Thread Philip Rakity


For 1 bit transcend cards you need these 2 patches.


>From 22113efd00491310da802f3b1a9a66cfcf415fac Mon Sep 17 00:00:00 2001
From: Aries Lee 
Date: Wed, 15 Dec 2010 08:14:24 +0100
Subject: [PATCH] mmc: Test bus-width for old MMC devices

Some old MMC devices fail with the 4/8 bits the driver tries to use
exclusively.  This patch adds a test for the given bus setup and falls
back to the lower bit mode (until 1-bit mode) when the test fails.

[Major rework and refactoring by tiwai]
[Quirk addition and many fixes by prakity]

Signed-off-by: Aries Lee 
Signed-off-by: Takashi Iwai 
Signed-off-by: Philip Rakity 
Tested-by: Philip Rakity 
Signed-off-by: Chris Ball 
---
 drivers/mmc/core/mmc.c |   76 -
 drivers/mmc/core/mmc_ops.c |  101 
 drivers/mmc/core/mmc_ops.h |1 +
 drivers/mmc/host/sdhci.c   |7 +++-
 drivers/mmc/host/sdhci.h   |1 +
 include/linux/mmc/host.h   |1 +
 include/linux/mmc/mmc.h|2 +
 7 files changed, 159 insertions(+), 30 deletions(-)

diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 76bb621..1d8409f 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -534,39 +534,57 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
 */
if ((card->csd.mmca_vsn >= CSD_SPEC_VER_4) &&
(host->caps & (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA))) {
-   unsigned ext_csd_bit, bus_width;
-
-   if (host->caps & MMC_CAP_8_BIT_DATA) {
-   if (ddr)
-   ext_csd_bit = EXT_CSD_DDR_BUS_WIDTH_8;
-   else
-   ext_csd_bit = EXT_CSD_BUS_WIDTH_8;
-   bus_width = MMC_BUS_WIDTH_8;
-   } else {
-   if (ddr)
-   ext_csd_bit = EXT_CSD_DDR_BUS_WIDTH_4;
-   else
-   ext_csd_bit = EXT_CSD_BUS_WIDTH_4;
-   bus_width = MMC_BUS_WIDTH_4;
+   static unsigned ext_csd_bits[][2] = {
+   { EXT_CSD_BUS_WIDTH_8, EXT_CSD_DDR_BUS_WIDTH_8 },
+   { EXT_CSD_BUS_WIDTH_4, EXT_CSD_DDR_BUS_WIDTH_4 },
+   { EXT_CSD_BUS_WIDTH_1, EXT_CSD_BUS_WIDTH_1 },
+   };
+   static unsigned bus_widths[] = {
+   MMC_BUS_WIDTH_8,
+   MMC_BUS_WIDTH_4,
+   MMC_BUS_WIDTH_1
+   };
+   unsigned idx, bus_width = 0;
+
+   if (host->caps & MMC_CAP_8_BIT_DATA)
+   idx = 0;
+   else
+   idx = 1;
+   for (; idx < ARRAY_SIZE(bus_widths); idx++) {
+   bus_width = bus_widths[idx];
+   if (bus_width == MMC_BUS_WIDTH_1)
+   ddr = 0; /* no DDR for 1-bit width */
+   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+EXT_CSD_BUS_WIDTH,
+ext_csd_bits[idx][0]);
+   if (!err) {
+   /*
+* If controller can't handle bus width test,
+* use the highest bus width to maintain
+* compatibility with previous MMC behavior.
+*/
+   if (!(host->caps & MMC_CAP_BUS_WIDTH_TEST))
+   break;
+   mmc_set_bus_width_ddr(card->host,
+ bus_width, MMC_SDR_MODE);
+   err = mmc_bus_test(card, bus_width);
+   if (!err)
+   break;
+   }
}
 
-   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
-EXT_CSD_BUS_WIDTH, ext_csd_bit);
-
-   if (err && err != -EBADMSG)
-   goto free_card;
-
+   if (!err && ddr) {
+   err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+   EXT_CSD_BUS_WIDTH,
+   ext_csd_bits[idx][1]);
+   }
if (err) {
printk(KERN_WARNING "%s: switch to bus width %d ddr %d "
-  "failed\n", mmc_hostname(card->host),
-  1 << bus_width, ddr);
-   err = 0;
-   } else {
-   if (ddr)
-   mmc_card_set_ddr_mode(card);
-   else
-   ddr = MMC_SDR_MODE;
-
+   "failed\n", mmc_hostname(card->host),
+

Re: SDHC Read Performance

2011-01-18 Thread Magnus Damm

Hi Simon,

On Wed, Jan 19, 2011 at 9:09 AM, Simon Horman  wrote:
> Hi,
>
> I am currently interested in the read performance of the SDHI driver.  I
> ran the following tests on a Mackerel board using Linus's latest tree
> (6845a44a), which I believe has all of the outstanding patches from Arnd
> and Guennadi merged.

Nice, thanks for testing this.

> I have made the following crude performance measurements using
> several different cards.
>
> dd if=/dev/mmcblk1 of=/dev/null bs=512 count=10
>
> SD1.1:          7.0 MB/s
> SD2.0:          7.0 MB/s
> SDHC Class 2:   7.1 MB/s
> SDHC Class 10:  7.2 MB/s
>
> Whereas I would expect something like:
>
> SD1.1 card:     12 MB/s
> SD2.0 card:     24 MB/s
> SDHC Class 2:   24 MB/s
> SDHC Class 10:  Faster?

Please have a look at the clock frequency set by the SDHI MFD driver
(hclk), together with the tmio-mmc settings in tmio_mmc_set_clock().
For the clock to be bumped up properly some capability/feature flags
may be needed:

MMC_CAP_MMC_HIGHSPEED
MMC_CAP_SD_HIGHSPEED

Not sure if they are set properly. Probably not.

> Possibly relevant portions of my .config are:
>
> CONFIG_MFD_SH_MOBILE_SDHI=y
> CONFIG_TMIO_MMC_DMA=y
> CONFIG_MMC_TMIO=y

These two are also relevant:

CONFIG_SH_DMAE=y
CONFIG_DMA_ENGINE=y

DMA controller platform data is also needed, not sure the state of
your board. You can check out the counters in /proc/interrupts to see
if the DMA controller is active or not.

Cheers,

/ magnus
--
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: A MMC card transfer issue

2011-01-18 Thread Philip Rakity


Chris,

transcend card is 1 bit card.  Requires bus_width patches.

Philip

On Jan 18, 2011, at 5:41 PM, Chris Ball wrote:

> On Wed, Jan 19, 2011 at 10:29:21AM +0900, Tomoya MORINAGA wrote:
>> On Wednesday, January 19, 2011 10:00 AM, Philip Rakity wrote:
>>> I just looked in the 2.6.37 code and the fix is not there.  
>>> It is in the 2.6.37 linus  tree.  
>>> 
>>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.g
>>> it;a=blob;f=drivers/mmc/core/mmc.c;h=16006ef153fe081c2f0f0a09c
>>> d4443ce7f3c49a1;hb=a25cecce88194b2edf38b8c3b1665e9318eb2d22
>> 
>> Do you know when the above patch will be integrated to kernel ?
> 
> I don't understand, sorry.  The link is to a file, not a patch, and
> Philip's statement above talks about a patch being in 2.6.37 but not
> being in 2.6.37, which I don't understand either.
> 
> Looking back farther in the thread, I think you're both talking about:
> http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=15ec44611904be0dcc97b84c29fbf964e5e2b36f
> 
> This patch was merged into Linus' 2.6.37-rc4 on Nov 27 2010, and
> released as part of 2.6.37.
> 
> Can you elaborate on your question, if it's still outstanding?
> 
> 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: A MMC card transfer issue

2011-01-18 Thread Chris Ball

On Wed, Jan 19, 2011 at 10:29:21AM +0900, Tomoya MORINAGA wrote:
> On Wednesday, January 19, 2011 10:00 AM, Philip Rakity wrote:
> > I just looked in the 2.6.37 code and the fix is not there.  
> > It is in the 2.6.37 linus  tree.  
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.g
> > it;a=blob;f=drivers/mmc/core/mmc.c;h=16006ef153fe081c2f0f0a09c
> > d4443ce7f3c49a1;hb=a25cecce88194b2edf38b8c3b1665e9318eb2d22
> 
> Do you know when the above patch will be integrated to kernel ?

I don't understand, sorry.  The link is to a file, not a patch, and
Philip's statement above talks about a patch being in 2.6.37 but not
being in 2.6.37, which I don't understand either.

Looking back farther in the thread, I think you're both talking about:
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=15ec44611904be0dcc97b84c29fbf964e5e2b36f

This patch was merged into Linus' 2.6.37-rc4 on Nov 27 2010, and
released as part of 2.6.37.

Can you elaborate on your question, if it's still outstanding?

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: A MMC card transfer issue

2011-01-18 Thread Tomoya MORINAGA

Hi Chris,

On Wednesday, January 19, 2011 10:00 AM, Philip Rakity wrote:
> I just looked in the 2.6.37 code and the fix is not there.  
> It is in the 2.6.37 linus  tree.  
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.g
> it;a=blob;f=drivers/mmc/core/mmc.c;h=16006ef153fe081c2f0f0a09c
> d4443ce7f3c49a1;hb=a25cecce88194b2edf38b8c3b1665e9318eb2d22
> 
> Chris Ball who maintains this should know when it will be 
> pushed upwards.

Do you know when the above patch will be integrated to kernel ?

Thanks,
-
Tomoya MORINAGA
OKI SEMICONDUCTOR CO., LTD.

--
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: A MMC card transfer issue

2011-01-18 Thread Philip Rakity


I just looked in the 2.6.37 code and the fix is not there.  It is in the 2.6.37 
linus  tree.  

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/mmc/core/mmc.c;h=16006ef153fe081c2f0f0a09cd4443ce7f3c49a1;hb=a25cecce88194b2edf38b8c3b1665e9318eb2d22

Chris Ball who maintains this should know when it will be pushed upwards.

Philip 
On Jan 18, 2011, at 4:36 PM, Tomoya MORINAGA wrote:

> Hi Philip,
>  
> On Wednesday, December 01, 2010 10:31 AM, Philip Rakity wrote:
> > Thanks very much, I'll plan on sending this to Linus tomorrow, along
> > with the rest of my .37 queue, unless there are any more review
> > comments from anyone.
>  
> We tried to use the MMC card like the following on kernel-2.6.37.
>  
> On Tuesday, November 09, 2010 2:40 PM, Tomoya MORINAGA wrote:
> > I am facing the issue about some MMC cards on Intel EG20T PCH 
> > (Platform Controller Hub).
> > The linux version is 2.6.36.
> > I can not transfer data the MMC cards (e.g. Transcned MMC card).
> > The card is 1 bit bus width. And the card is according to MMC 
> > specification V3.x.
> > And the EG20T has a 4 bit bus width capability Linux MMC 
> > standard driver decides the card bus width as 4 bit, if the 
> > MMC specification version is larger than or equal to V4.0 like below.
>  
> However it seems the issue remains to be seen.
> Have you fixed the MMC unrecognized issue in kernel-2.6.37?
>  
> Thanks,
> -
> Tomoya MORINAGA
> OKI SEMICONDUCTOR CO., LTD.

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

SDHC Read Performance

2011-01-18 Thread Simon Horman

Hi,

I am currently interested in the read performance of the SDHI driver.  I
ran the following tests on a Mackerel board using Linus's latest tree
(6845a44a), which I believe has all of the outstanding patches from Arnd
and Guennadi merged.

I have made the following crude performance measurements using
several different cards.

dd if=/dev/mmcblk1 of=/dev/null bs=512 count=10

SD1.1:  7.0 MB/s
SD2.0:  7.0 MB/s
SDHC Class 2:   7.1 MB/s
SDHC Class 10:  7.2 MB/s

Whereas I would expect something like:

SD1.1 card: 12 MB/s
SD2.0 card: 24 MB/s
SDHC Class 2:   24 MB/s
SDHC Class 10:  Faster?

Possibly relevant portions of my .config are:

CONFIG_MFD_SH_MOBILE_SDHI=y
CONFIG_TMIO_MMC_DMA=y
CONFIG_MMC_TMIO=y


Arnd, Guennadi, I believe that you have been working on SDHI recently.
If you have any suggestions I would be most grateful. Else I will
poke some more and see what I can come up with.

--
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] msm: 8x50: Add initial support for SDCC

2011-01-18 Thread David Brown

On Mon, Jan 17 2011, Sahitya Tummala wrote:

> Signed-off-by: Sahitya Tummala 
> ---
>  arch/arm/mach-msm/board-qsd8x50.c   |   81 +-
>  arch/arm/mach-msm/devices-qsd8x50.c |  196 
> +++
>  arch/arm/mach-msm/gpiomux-8x50.c|   23 +++
>  arch/arm/mach-msm/include/mach/msm_iomap-8x50.h |8 +-
>  4 files changed, 303 insertions(+), 5 deletions(-)

This will have to wait until the msm_sdcc driver itself is cleaned up to
not use the internal dma api calls (and compiles again with the current
kernel).

-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
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 4/4] omap4: hsmmc: enable ADMA for MMC1 & MMC2

2011-01-18 Thread Kishore Kadiyala

Enable ADMA support for MMC1 & MMC2 controller on omap4 by updating
"features" of struct omap_mmc_platform_data.

Signed-off-by: Kishore Kadiyala 
Signed-off-by: Venkatraman S 
Reviewed-by: Sukumar Ghorai 
---
 arch/arm/mach-omap2/hsmmc.c |   13 +++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 34272e4..2ac7271 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -307,8 +307,17 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info 
*controllers)
else
mmc->slots[0].features |= HSMMC_HAS_PBIAS;
 
-   if (cpu_is_omap44xx() && (omap_rev() > OMAP4430_REV_ES1_0))
-   mmc->slots[0].features |= HSMMC_HAS_UPDATED_RESET;
+   /*
+* OMAP4: MMC1 & MMC2 controllers support ADMA.
+* Default works with SDMA.
+* For ADMA support, update respective BIT in features.
+*/
+   if (cpu_is_omap44xx()) {
+   mmc->slots[0].features |= HSMMC_HAS_ADMA_SUPPORT;
+   if (omap_rev() > OMAP4430_REV_ES1_0)
+   mmc->slots[0].features |=
+   HSMMC_HAS_UPDATED_RESET;
+   }
 
switch (c->mmc) {
case 1:
-- 
1.7.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 3/4] omap4: hsmmc: Adding ADMA support for MMC1 & MMC2 controllers

2011-01-18 Thread Kishore Kadiyala

On OMAP4, MMC1 & MMC2 controllers support ADMA feature which will
provide direct access to internal data.
Basically ADMA is a DMA controller embedded in the MMC controller.
It fetches each descriptor line [address+length+attributes] from a
descriptor table and executes the corresponding action [based on attributes].
Base address of Descriptor table in stored in MMCHS_ADMASAL register.

Signed-off-by: Kishore Kadiyala 
Signed-off-by: Venkatraman S 
Signed-off-by: Santosh Shilimkar 
Reviewed-by: Sukumar Ghorai 
---
 arch/arm/plat-omap/include/plat/mmc.h |1 +
 drivers/mmc/host/omap_hsmmc.c |  223 +++--
 2 files changed, 184 insertions(+), 40 deletions(-)

diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
b/arch/arm/plat-omap/include/plat/mmc.h
index f57f36a..b13e927 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -110,6 +110,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
 #define HSMMC_HAS_PBIAS(1 << 0)
 #define HSMMC_HAS_UPDATED_RESET(1 << 1)
+#define HSMMC_HAS_ADMA_SUPPORT (1 << 2)
unsigned features;
 
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 7cf0383..aaa113b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -51,12 +51,15 @@
 #define OMAP_HSMMC_RSP54   0x0118
 #define OMAP_HSMMC_RSP76   0x011C
 #define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE  0x0124
 #define OMAP_HSMMC_HCTL0x0128
 #define OMAP_HSMMC_SYSCTL  0x012C
 #define OMAP_HSMMC_STAT0x0130
 #define OMAP_HSMMC_IE  0x0134
 #define OMAP_HSMMC_ISE 0x0138
 #define OMAP_HSMMC_CAPA0x0140
+#define OMAP_HSMMC_ADMA_ES 0x0154
+#define OMAP_HSMMC_ADMA_SAL0x0158
 
 #define VS18   (1 << 26)
 #define VS30   (1 << 25)
@@ -104,6 +107,25 @@
 #define SRD(1 << 26)
 #define SOFTRESET  (1 << 1)
 #define RESETDONE  (1 << 0)
+#define DMAS   (0x2 << 3)
+#define CAPA_ADMA_SUPPORT  (1 << 19)
+#define ADMA_XFER_VALID(1 << 0)
+#define ADMA_XFER_END  (1 << 1)
+#define ADMA_XFER_LINK (1 << 4)
+#define ADMA_XFER_DESC (1 << 5)
+#define DMA_MNS_ADMA_MODE  (1 << 20)
+#define ADMA_ERR   (1 << 25)
+#define ADMA_XFER_INT  (1 << 3)
+
+#define ADMA_TABLE_SZ  (PAGE_SIZE)
+#define ADMA_TABLE_NUM_ENTRIES (ADMA_TABLE_SZ / sizeof(struct adma_desc_table))
+
+/*
+ * According to TRM, it is possible to transfer upto 64kB per ADMA table entry.
+ * But 64kB = 0x1 cannot be represented using a 16bit integer
+ * in 1 ADMA table row. Hence rounding it to a lesser value.
+ */
+#define ADMA_MAX_XFER_PER_ROW (63 * 1024)
 
 /*
  * FIXME: Most likely all the data using these _DEVID defines should come
@@ -146,6 +168,13 @@
 #define OMAP_HSMMC_WRITE(base, reg, val) \
__raw_writel((val), (base) + OMAP_HSMMC_##reg)
 
+/* ADMA descriptor table entry */
+struct adma_desc_table {
+   u16 attr;
+   u16 length;
+   dma_addr_t addr;
+};
+
 struct omap_hsmmc_host {
struct  device  *dev;
struct  mmc_host*mmc;
@@ -179,6 +208,8 @@ struct omap_hsmmc_host {
int irq;
int dma_ch;
int xfer_type; /* Transfer can be PIO/SDMA/ADMA */
+   struct adma_desc_table  *adma_table;
+   dma_addr_t  phy_adma_table;
int dma_line_tx, dma_line_rx;
int slot_id;
int got_dbclk;
@@ -877,6 +908,44 @@ static void omap_hsmmc_request_done(struct omap_hsmmc_host 
*host, struct mmc_req
 }
 
 /*
+ * SDMA clean up during SDMA transfers.
+ * Also unmapping of sg list in case of error/transfer done during
+ * SDMA/ADMA transfers.
+ */
+static void omap_hsmmc_xfer_cleanup(struct omap_hsmmc_host *host, int errno)
+{
+   int dma_ch;
+   struct mmc_data *data = errno ? host->data : host->mrq->data;
+
+   switch (host->xfer_type) {
+   case OMAP_HSMMC_USE_SDMA_XFER:
+   spin_lock(&host->irq_lock);
+   dma_ch = host->dma_ch;
+   host->dma_ch = -1;
+   spin_unlock(&host->irq_lock);
+   if (dma_ch != -1)
+   dma_unmap_sg(mmc_dev(host->mmc), data->sg,
+   host->dma_len,
+   omap_hsmmc_get_dma_dir(host, data));
+   omap_free_dma(dma_ch);
+   break;
+   case OMAP_HSMMC_USE_ADMA_XFER:
+   dma_unmap_sg(mmc_dev(host->mmc), data->sg,
+   host->dma_len, omap_hsmmc_get_dma_dir(host, data));
+   break;
+

[PATCH 1/4] omap: hsmmc: Rename use_dma to xfer_type and define possible transfers

2011-01-18 Thread Kishore Kadiyala

OMAP4 introduces dedicated internal DMA which is ADMA for its MMC
controllers HSMMC1 & HSMMC2.
Renaming "use_dma" member of the struct omap_hsmmc_host to "xfer_type"
and defining the transfer modes PIO/SDMA/ADMA that can be used by the
MMC controller.

Signed-off-by: Kishore Kadiyala 
Reviewed-by: Sukumar Ghorai 
---
 drivers/mmc/host/omap_hsmmc.c |   20 +---
 1 files changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5d46021..8fb8586 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -125,6 +125,11 @@
 #define OMAP_MMC_SLEEP_TIMEOUT 1000
 #define OMAP_MMC_OFF_TIMEOUT   8000
 
+/* Transfer Modes used by MMC controller */
+#defineOMAP_HSMMC_USE_PIO_XFER 0
+#defineOMAP_HSMMC_USE_SDMA_XFER1
+#defineOMAP_HSMMC_USE_ADMA_XFER2
+
 /*
  * One controller can have multiple slots, like on some omap boards using
  * omap.c controller driver. Luckily this is not currently done on any known
@@ -172,7 +177,8 @@ struct omap_hsmmc_host {
u32 bytesleft;
int suspended;
int irq;
-   int use_dma, dma_ch;
+   int dma_ch;
+   int xfer_type; /* Transfer can be PIO/SDMA/ADMA */
int dma_line_tx, dma_line_rx;
int slot_id;
int got_dbclk;
@@ -545,7 +551,7 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host 
*host,
 {
unsigned int irq_mask;
 
-   if (host->use_dma)
+   if (host->xfer_type != OMAP_HSMMC_USE_PIO_XFER)
irq_mask = INT_EN_MASK & ~(BRR_ENABLE | BWR_ENABLE);
else
irq_mask = INT_EN_MASK;
@@ -835,7 +841,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host, 
struct mmc_command *cmd,
cmdreg &= ~(DDIR);
}
 
-   if (host->use_dma)
+   if (host->xfer_type != OMAP_HSMMC_USE_PIO_XFER)
cmdreg |= DMA_EN;
 
host->req_in_progress = 1;
@@ -864,7 +870,7 @@ static void omap_hsmmc_request_done(struct omap_hsmmc_host 
*host, struct mmc_req
 
omap_hsmmc_disable_irq(host);
/* Do not complete the request if DMA is still in progress */
-   if (mrq->data && host->use_dma && dma_ch != -1)
+   if (mrq->data && host->xfer_type && dma_ch != -1)
return;
host->mrq = NULL;
mmc_request_done(host->mmc, mrq);
@@ -942,7 +948,7 @@ static void omap_hsmmc_dma_cleanup(struct omap_hsmmc_host 
*host, int errno)
host->dma_ch = -1;
spin_unlock(&host->irq_lock);
 
-   if (host->use_dma && dma_ch != -1) {
+   if (host->xfer_type && dma_ch != -1) {
dma_unmap_sg(mmc_dev(host->mmc), host->data->sg, host->dma_len,
omap_hsmmc_get_dma_dir(host, host->data));
omap_free_dma(dma_ch);
@@ -1451,7 +1457,7 @@ omap_hsmmc_prepare_data(struct omap_hsmmc_host *host, 
struct mmc_request *req)
| (req->data->blocks << 16));
set_data_timeout(host, req->data->timeout_ns, req->data->timeout_clks);
 
-   if (host->use_dma) {
+   if (host->xfer_type) {
ret = omap_hsmmc_start_dma_transfer(host, req);
if (ret != 0) {
dev_dbg(mmc_dev(host->mmc), "MMC start dma failure\n");
@@ -2050,7 +2056,7 @@ static int __init omap_hsmmc_probe(struct platform_device 
*pdev)
host->mmc   = mmc;
host->pdata = pdata;
host->dev   = &pdev->dev;
-   host->use_dma   = 1;
+   host->xfer_type = OMAP_HSMMC_USE_SDMA_XFER;
host->dev->dma_mask = &pdata->dma_mask;
host->dma_ch= -1;
host->irq   = irq;
-- 
1.7.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 2/4] omap: hsmmc: Rename and cleanup omap_hsmmc_dma_cleanup

2011-01-18 Thread Kishore Kadiyala

Renaming omap_hsmmc_dma_cleanup as omap_hsmmc_xfer_cleanup and doing some
cleanup by handling the error & success scenarios during a transfer for
different xfer_type.

Signed-off-by: Kishore Kadiyala 
Reviewed-by: Sukumar Ghorai 
---
 drivers/mmc/host/omap_hsmmc.c |   52 ++--
 1 files changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8fb8586..7cf0383 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -935,25 +935,37 @@ omap_hsmmc_cmd_done(struct omap_hsmmc_host *host, struct 
mmc_command *cmd)
 }
 
 /*
- * DMA clean up for command errors
+ * SDMA clean up during SDMA transfers.
+ * Also unmapping of sg list in case of error/transfer done during
+ * SDMA/ADMA transfers.
  */
-static void omap_hsmmc_dma_cleanup(struct omap_hsmmc_host *host, int errno)
+static void omap_hsmmc_xfer_cleanup(struct omap_hsmmc_host *host, int errno)
 {
int dma_ch;
+   struct mmc_data *data = errno ? host->data : host->mrq->data;
 
-   host->data->error = errno;
-
-   spin_lock(&host->irq_lock);
-   dma_ch = host->dma_ch;
-   host->dma_ch = -1;
-   spin_unlock(&host->irq_lock);
-
-   if (host->xfer_type && dma_ch != -1) {
-   dma_unmap_sg(mmc_dev(host->mmc), host->data->sg, host->dma_len,
-   omap_hsmmc_get_dma_dir(host, host->data));
+   switch (host->xfer_type) {
+   case OMAP_HSMMC_USE_SDMA_XFER:
+   spin_lock(&host->irq_lock);
+   dma_ch = host->dma_ch;
+   host->dma_ch = -1;
+   spin_unlock(&host->irq_lock);
+   if (dma_ch != -1)
+   dma_unmap_sg(mmc_dev(host->mmc), data->sg,
+   host->dma_len,
+   omap_hsmmc_get_dma_dir(host, data));
omap_free_dma(dma_ch);
+   break;
+   case OMAP_HSMMC_USE_PIO_XFER:
+   /* TODO */
+   break;
+   default:
+   dev_dbg(mmc_dev(host->mmc), "Unknown xfer_type\n");
+   }
+   if (errno) {
+   host->data->error = errno;
+   host->data = NULL;
}
-   host->data = NULL;
 }
 
 /*
@@ -1059,7 +1071,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
}
if (host->data || host->response_busy) {
if (host->data)
-   omap_hsmmc_dma_cleanup(host,
+   omap_hsmmc_xfer_cleanup(host,
-ETIMEDOUT);
host->response_busy = 0;
omap_hsmmc_reset_controller_fsm(host, SRD);
@@ -1072,7 +1084,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host 
*host, int status)
-ETIMEDOUT : -EILSEQ;
 
if (host->data)
-   omap_hsmmc_dma_cleanup(host, err);
+   omap_hsmmc_xfer_cleanup(host, err);
else
host->mrq->cmd->error = err;
host->response_busy = 0;
@@ -1310,7 +1322,7 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status, 
void *cb_data)
 {
struct omap_hsmmc_host *host = cb_data;
struct mmc_data *data = host->mrq->data;
-   int dma_ch, req_in_progress;
+   int req_in_progress;
 
if (!(ch_status & OMAP_DMA_BLOCK_IRQ)) {
dev_warn(mmc_dev(host->mmc), "unexpected dma status %x\n",
@@ -1332,16 +1344,10 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status, 
void *cb_data)
spin_unlock(&host->irq_lock);
return;
}
-
-   dma_unmap_sg(mmc_dev(host->mmc), data->sg, host->dma_len,
-   omap_hsmmc_get_dma_dir(host, data));
-
req_in_progress = host->req_in_progress;
-   dma_ch = host->dma_ch;
-   host->dma_ch = -1;
spin_unlock(&host->irq_lock);
 
-   omap_free_dma(dma_ch);
+   omap_hsmmc_xfer_cleanup(host, 0);
 
/* If DMA has finished after TC, complete the request */
if (!req_in_progress) {
-- 
1.7.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 0/4] omap4: hsmmc: Adding ADMA support

2011-01-18 Thread Kishore Kadiyala

This patch series adds support for ADMA on MMC1 & MMC2 controllers on OMAP4.
There is no performance improvement observed using ADMA over SDMA.
Advantage using ADMA could be reducing contention over SDMA.
Also the series includes some cleanup.

The series is based on 2.6.37-rc8 and tested on OMAP4430SDP & OMAP3430SDP.


Kishore Kadiyala (4):
  omap: hsmmc: Rename use_dma to xfer_type and define possible
transfers
  omap: hsmmc: Rename and cleanup omap_hsmmc_dma_cleanup
  omap4: hsmmc: Adding ADMA support for MMC1 & MMC2 controllers
  omap4: hsmmc: enable ADMA for MMC1 & MMC2

 arch/arm/mach-omap2/hsmmc.c   |   13 ++-
 arch/arm/plat-omap/include/plat/mmc.h |1 +
 drivers/mmc/host/omap_hsmmc.c |  241 +++--
 3 files changed, 210 insertions(+), 45 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 v1 1/3]mmc: implemented runtime pm for mmc host

2011-01-18 Thread Tardy, Pierre

> > I'm also worried about this patch not taking in account the 8 clock cycles 
> > before
> > shutting down the clock, contrary to the clock gating fw.
> > If you power down hc, you will also gate the clock. So the sdio protocol 
> > might not be
> > strictly followed.
> As mmc spec said, 8 clock cycles is needed. That is right.
> But I think if we have set the auto suspended delay for host, runtime pm core 
> could make sure host to
> wait at least the auto suspended delay before shutting down the power of the 
> device. So if the auto
> suspended delay is longer than 8 clock cycles, the mmc protocol can be 
> followed, right?
I disagree. You cannot enforce this. It depends on clock speed, that can vary 
with sdio cards. 
User can change the autosuspend delay to whatever he wants, it should just 
change performance, but not functionality.

Why don't you just take my clock gating version?
Its working well, I'm using this for 2 weeks, and follow the linux-mmc latest 
improvement.

Regards,
Pierre


-
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--
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] dw_mmc: Add Synopsys DesignWare mmc host driver.

2011-01-18 Thread Will Newton

On Tue, Jan 18, 2011 at 7:54 AM, Jaehoon Chung  wrote:
> Hi Will.
>
> I have some question...i'm testing dw_mmc in our environment.
> but i didn't understand pdata->init(?)...what initialize in there?

In most of our platforms init is empty so I guess it would be fine to
change that code to ignore a null init pointer. An example of one of
the things we do use the init function for is to switch pins to GPIO
to handle card detect.
--
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/5] mmc: add double buffering for mmc block requests

2011-01-18 Thread Per Forlin

On 18 January 2011 03:35, Jaehoon Chung  wrote:
> Hi Per..
>
> it is interesting approach..so
> we want to test your double buffering in our environment(Samsung SoC).
>
> Did you test with SDHCI?
So far I have only tested on mmci for board u5500 and u8500. I happily
test on a different board if I can get hold of one.

> If you tested with SDHCI, i want to know how much increase the performance.
>
> Thanks,
> Jaehoon Chung
--
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: A MMC card transfer issue

Re: SDHC Read Performance

Re: A MMC card transfer issue

Re: A MMC card transfer issue

RE: A MMC card transfer issue

Re: A MMC card transfer issue

SDHC Read Performance

Re: [PATCH 2/2] msm: 8x50: Add initial support for SDCC

[PATCH 4/4] omap4: hsmmc: enable ADMA for MMC1 & MMC2

[PATCH 3/4] omap4: hsmmc: Adding ADMA support for MMC1 & MMC2 controllers

[PATCH 1/4] omap: hsmmc: Rename use_dma to xfer_type and define possible transfers

[PATCH 2/4] omap: hsmmc: Rename and cleanup omap_hsmmc_dma_cleanup

[PATCH 0/4] omap4: hsmmc: Adding ADMA support

RE: [PATCH v1 1/3]mmc: implemented runtime pm for mmc host

Re: [PATCH v4] dw_mmc: Add Synopsys DesignWare mmc host driver.

Re: [PATCH 0/5] mmc: add double buffering for mmc block requests

16 matches

Site Navigation

Mail list logo

Footer information