Re: [PATCH] tegra/mmc: add pm_flags

[Chris Ball]

Hi,

On Fri, Mar 25 2011, Grant Grundler wrote:
> Sorry about that. Can you please add the "From" line you've shown
> above since it's clearly Venkat's.

Done, thanks.

- Chris.
-- 
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] tegra/mmc: add pm_flags

[Grant Grundler]

On Fri, Mar 25, 2011 at 5:43 PM, Chris Ball  wrote:
> Hi Grant,
>
> On Fri, Mar 25 2011, Grant Grundler wrote:
>> Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.
>>
>> This part allows the mach-tegra support tell the tegra MMC host controller
>> to NOT turn off power for the MMC controller the WIFI part lives behind.
>> Thus bcm4329 firmware doesn't need to be reloaded.
>>
>> Signed-off-by: Venkat Rao 
>> Tested-by: Grant Grundler 
>> Reviewed-by: Olof Johansson 
>
> One more thing -- who wrote this patch?  If Venkat, it should have a:
>
> From: Venkat Rao 

Yes, Venkat wrote it which is why it has his S-o-b line listed first.

> line in either the mail headers or the message body.  If you, it should
> have your S-o-b.  The way you've sent it tells Git that you wrote the
> patch.

Sorry about that. Can you please add the "From" line you've shown
above since it's clearly Venkat's.

thanks!
grant
--
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] tegra/mmc: add pm_flags

[Chris Ball]

Hi Grant,

On Fri, Mar 25 2011, Grant Grundler wrote:
> Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.
>
> This part allows the mach-tegra support tell the tegra MMC host controller
> to NOT turn off power for the MMC controller the WIFI part lives behind.
> Thus bcm4329 firmware doesn't need to be reloaded.
>
> Signed-off-by: Venkat Rao 
> Tested-by: Grant Grundler 
> Reviewed-by: Olof Johansson 

One more thing -- who wrote this patch?  If Venkat, it should have a:

From: Venkat Rao 

line in either the mail headers or the message body.  If you, it should
have your S-o-b.  The way you've sent it tells Git that you wrote the
patch.

Thanks,

- Chris.
-- 
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] tegra/mmc: add pm_flags

[Olof Johansson]

On Fri, Mar 25, 2011 at 5:27 PM, Chris Ball  wrote:
> Hi,
>
> On Fri, Mar 25 2011, Grant Grundler wrote:
>> Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.
>>
>> This part allows the mach-tegra support tell the tegra MMC host controller
>> to NOT turn off power for the MMC controller the WIFI part lives behind.
>> Thus bcm4329 firmware doesn't need to be reloaded.
>>
>> Signed-off-by: Venkat Rao 
>> Tested-by: Grant Grundler 
>> Reviewed-by: Olof Johansson 
>> 
>> I'm not certain if this should go through tegra or mmc tree.
>> Can you advise please?
>
> I'm happy to take it through the MMC tree for .40, but would like
> an Acked-by: from an arch/arm/mach-tegra maintainer to show Linus.
> Olof is one such person, so getting an Acked-by from him would work.
>
> (Also, Venkat's e-mail address is malformed in the S-o-b.)

Acked-by: Olof Johansson 


-Olof
--
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] tegra/mmc: add pm_flags

[Chris Ball]

Hi,

On Fri, Mar 25 2011, Grant Grundler wrote:
> Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.
>
> This part allows the mach-tegra support tell the tegra MMC host controller
> to NOT turn off power for the MMC controller the WIFI part lives behind.
> Thus bcm4329 firmware doesn't need to be reloaded.
>
> Signed-off-by: Venkat Rao 
> Tested-by: Grant Grundler 
> Reviewed-by: Olof Johansson 
> 
> I'm not certain if this should go through tegra or mmc tree.
> Can you advise please?

I'm happy to take it through the MMC tree for .40, but would like
an Acked-by: from an arch/arm/mach-tegra maintainer to show Linus.
Olof is one such person, so getting an Acked-by from him would work.

(Also, Venkat's e-mail address is malformed in the S-o-b.)

Thanks,

- Chris.
-- 
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] tegra/mmc: add pm_flags

[Olof Johansson]

[Gah, now without HTML formatting.]

On Fri, Mar 25, 2011 at 5:07 PM, Grant Grundler  wrote:
>
> Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.
>
> This part allows the mach-tegra support tell the tegra MMC host controller
> to NOT turn off power for the MMC controller the WIFI part lives behind.
> Thus bcm4329 firmware doesn't need to be reloaded.
>
> Signed-off-by: Venkat Rao 
> Tested-by: Grant Grundler 
> Reviewed-by: Olof Johansson 
> 
> I'm not certain if this should go through tegra or mmc tree.
> Can you advise please?

Chris, please take it through the MMC tree.

Feel free to s/ol...@chromium.org/o...@lixom.net/ above, either way works.

-Olof
--
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] tegra/mmc: add pm_flags

[Grant Grundler]

Enable fast bcm4329 WIFI suspend/resume on Tegra2 board.

This part allows the mach-tegra support tell the tegra MMC host controller
to NOT turn off power for the MMC controller the WIFI part lives behind.
Thus bcm4329 firmware doesn't need to be reloaded.

Signed-off-by: Venkat Rao 
Tested-by: Grant Grundler 
Reviewed-by: Olof Johansson 

I'm not certain if this should go through tegra or mmc tree.
Can you advise please?

This is part of http://codereview.chromium.org/6474032 .
The other three change sets required for Seaboard (Tegra2):
http://codereview.chromium.org/6484021
http://codereview.chromium.org/6488018
http://codereview.chromium.org/6489022


diff --git a/arch/arm/mach-tegra/include/mach/sdhci.h 
b/arch/arm/mach-tegra/include/mach/sdhci.h
index 3ad086e..4231bc7 100644
--- a/arch/arm/mach-tegra/include/mach/sdhci.h
+++ b/arch/arm/mach-tegra/include/mach/sdhci.h
@@ -24,6 +24,7 @@ struct tegra_sdhci_platform_data {
int wp_gpio;
int power_gpio;
int is_8bit;
+   int pm_flags;
 };
 
 #endif
diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
index f7e1f96..343c97e 100644
--- a/drivers/mmc/host/sdhci-tegra.c
+++ b/drivers/mmc/host/sdhci-tegra.c
@@ -184,6 +184,8 @@ static int tegra_sdhci_pltfm_init(struct sdhci_host *host,
clk_enable(clk);
pltfm_host->clk = clk;
 
+   host->mmc->pm_caps = plat->pm_flags;
+
if (plat->is_8bit)
host->mmc->caps |= MMC_CAP_8_BIT_DATA;
 
--
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 2/2] sdio: add power_restore support with MMC_PM_KEEP_POWER mode

[Ohad Ben-Cohen]

On Fri, Mar 25, 2011 at 7:08 PM, Wilson Loi  wrote:
> Therefore, there is a case that we power save for the host CPU and let the
> firmware handle the wlan state.
> WLAN card will wake up the host by SDIO IRQ or GPIO if there is a new
> incoming packet later.

Then you're talking about keeping the card powered during system
suspend, which is already supported (as mentioned by Nicolas and
Chris), but your patches really changed SDIO's runtime PM path (which
is not needed since anyway the driver fully controls it).
--
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 2/2] sdio: add power_restore support with MMC_PM_KEEP_POWER mode

[Chris Ball]

Hi,

On Fri, Mar 25 2011, Nicolas Pitre wrote:
> On Sat, 26 Mar 2011, Wilson Loi wrote:
>
>> Sorry, this is the first time I sent a patch.
>> 
>> There are two case for the WLAN SDIO card to do power saving.
>> 1. Totally cut off the power of WLAN network interface.
>> 2. offload the network state to WLAN SDIO firmware.
>
> Case #2 is already supported with current code.  Patches for the 
> libertas driver are in the OLPC repository (no idea if they were 
> submitted upstream yet).

Yes, they're upstream now.  libertas/if_sdio.c:if_sdio_suspend() sets
MMC_PM_KEEP_POWER if a wakeup source has been set with "ethtool wol".

- Chris.
-- 
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 v1 2/2] sdio: add power_restore support with MMC_PM_KEEP_POWER mode

[Nicolas Pitre]

On Sat, 26 Mar 2011, Wilson Loi wrote:

> Sorry, this is the first time I sent a patch.
> 
> There are two case for the WLAN SDIO card to do power saving.
> 1. Totally cut off the power of WLAN network interface.
> 2. offload the network state to WLAN SDIO firmware.

Case #2 is already supported with current code.  Patches for the 
libertas driver are in the OLPC repository (no idea if they were 
submitted upstream yet).


Nicolas
--
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 2/2] sdio: add power_restore support with MMC_PM_KEEP_POWER mode

[Ohad Ben-Cohen]

On Fri, Mar 25, 2011 at 6:00 AM, Wilson Loi  wrote:
> Another patch file
> 
>
> diff -ruN a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c

Please follow Documentation/SubmittingPatches when submitting patches,
or at least just add -p to diff, otherwise it's a bit difficult to
follow. thanks.

>  mmc_bus_put(host);
>
> -    mmc_power_off(host);
> +    if (!ret && !(host->pm_flags & MMC_PM_KEEP_POWER))
> +        mmc_power_off(host);

...
>
> -    mmc_power_up(host);
> +    if (!(host->pm_flags & MMC_PM_KEEP_POWER))
> +        mmc_power_up(host);
>  ret = host->bus_ops->power_restore(host);


I have the same question here: if you driver doesn't want its card to
be powered down, why does it invoke (or let runtime PM invoke on its
behalf) mmc_power_save_host() in the first place ?
--
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/2] sdio: add power_restore support with MMC_PM_KEEP_POWER mode

[Ohad Ben-Cohen]

Hello Wilson,

On Fri, Mar 25, 2011 at 5:58 AM, Wilson Loi  wrote:
> The current power_restore handler only support cut off mode.
> It is better to support keep power mode too.

This doesn't make much sense really;

mmc_power_save_host() and mmc_power_restore_host() are invoked by
runtime PM when it is time to power off/on the card.

If your driver doesn't want the power to go, it should just maintain a
positive runtime PM usage_count (e.g. in case it's an SDIO driver,
don't call pm_runtime_put{_sync} after being probed).

>  static const struct mmc_bus_ops mmc_sdio_ops = {
>  .remove = mmc_sdio_remove,
>  .detect = mmc_sdio_detect,
>  .suspend = mmc_sdio_suspend,
>  .resume = mmc_sdio_resume,
> -    .power_restore = mmc_sdio_power_restore,
> +    .power_save = mmc_sdio_suspend,
> +    .power_restore = mmc_sdio_resume,

This can break SDIO runtime PM.

While -ENOSYS is a valid return value for mmc_sdio_suspend (it tells
mmc_suspend_host to remove the entire MMC card on system suspend), it
will be treated as an error by runtime PM.

In addition, this can really yield unexpected results, since drivers
do not expect their suspend/resume handlers to be called during
runtime PM transitions.
--
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: [comments] MMC: Reliable write support.

[Arnd Bergmann]

On Thursday 24 March 2011, Andrei Warkentin wrote:
> This is a request-for-comments patch. Please provide your feedback.
> 
> Allows reliable writes to be used for MMC writes. Reliable writes are used
> to service write REQ_FUA/REQ_META requests. Handles both the legacy and the 
> enhanced
> reliable write support in MMC cards.
> 
> Beyond REQ_FUA/REQ_META, this was meant to be used by a following patch that 
> aimed
> to reduce write amplification issues in cards employing a small (usually 
> flash page-sized)
> buffer and a large (usually erase-block sized) buffer, at the expense of 
> performance.

Looks good to me, but I don't really understand some of the block layer
specifics here. One question:

> +static int mmc_blk_issue_flush(struct mmc_queue *mq, struct request *req)
> +{
> + struct mmc_blk_data *md = mq->data;
> +
> + /*
> +No-op, only service this because we need REQ_FUA
> +for reliable writes.
> + */
> + spin_lock_irq(&md->lock);
> + __blk_end_request_all(req, 0);
> + spin_unlock_irq(&md->lock);
> +
> + return 1;
> +}

How does this work when you have a flush that does not directly follow
a REQ_FUA or REQ_META request? I would assume that we still need to
flush in some way, which you don't seem to do here.

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: outstanding tmio patches

[Chris Ball]

Hi,

On Fri, Mar 25 2011, Guennadi Liakhovetski wrote:
> Hm, strange, now all patches should be correct - if the correct versions 
> are taken. Let's do it easier: I've uploaded all 15 patches (14 mine and 1 
> from Simon) as a quilt series to
>
> http://download.open-technology.de/tmio-for-2.6.39/

Thanks, I just needed to pull changes from Linus into mmc-next.

I've pushed everything out to mmc-next now.  If anyone else is able to
grab mmc-next and supply a Tested-by: for their hardware, that'd be
appreciated.

Also, if anyone thinks that some of this should wait until .40, now's a
good time to speak up.  :)

- Chris.
-- 
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: outstanding tmio patches

[Guennadi Liakhovetski]

On Fri, 25 Mar 2011, Chris Ball wrote:

> Hi Guennadi,
> 
> On Thu, Mar 24 2011, Chris Ball wrote:
> >> [1/2] mmc: tmio: Improve DMA stability on sh-mobile
> >> [2/2] mmc: tmio: use PIO for short transfers
> 
> Thanks, these two are applied now.
> 
> >> [1/6,v2] mmc: tmio: split core functionality, DMA and MFD glue
> 
> But now we have a merge conflict here, since we just changed the
> codebase that this patch moves around.

Hm, strange, now all patches should be correct - if the correct versions 
are taken. Let's do it easier: I've uploaded all 15 patches (14 mine and 1 
from Simon) as a quilt series to

http://download.open-technology.de/tmio-for-2.6.39/

Please, just try those.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.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: outstanding tmio patches

[Chris Ball]

Hi Guennadi,

On Thu, Mar 24 2011, Chris Ball wrote:
>> [1/2] mmc: tmio: Improve DMA stability on sh-mobile
>> [2/2] mmc: tmio: use PIO for short transfers

Thanks, these two are applied now.

>> [1/6,v2] mmc: tmio: split core functionality, DMA and MFD glue

But now we have a merge conflict here, since we just changed the
codebase that this patch moves around.

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

[PATCH 1/2 v2] mmc: tmio-mmc: Improve DMA stability on sh-mobile

[Guennadi Liakhovetski]

On some SDHI tmio implementations the order of DMA and command completion
interrupts swaps, which leads to malfunction. This patch postpones
DMA activation until the MMC command completion IRQ time.

Signed-off-by: Guennadi Liakhovetski 
---

v2: rebased on top of patches from Linus Walleij

 drivers/mmc/host/tmio_mmc.c |   63 +++---
 1 files changed, 34 insertions(+), 29 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index ab1adea..e88627b 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -485,7 +485,10 @@ static void tmio_mmc_pio_irq(struct tmio_mmc_host *host)
unsigned int count;
unsigned long flags;
 
-   if (!data) {
+   if (host->chan_tx || host->chan_rx) {
+   pr_err("PIO IRQ in DMA mode!\n");
+   return;
+   } else if (!data) {
pr_debug("Spurious PIO IRQ\n");
return;
}
@@ -648,6 +651,8 @@ static void tmio_mmc_cmd_irq(struct tmio_mmc_host *host,
if (host->data->flags & MMC_DATA_READ) {
if (!host->chan_rx)
enable_mmc_irqs(host, TMIO_MASK_READOP);
+   else
+   tasklet_schedule(&host->dma_issue);
} else {
if (!host->chan_tx)
enable_mmc_irqs(host, TMIO_MASK_WRITEOP);
@@ -779,18 +784,6 @@ static void tmio_mmc_enable_dma(struct tmio_mmc_host 
*host, bool enable)
 #endif
 }
 
-static void tmio_dma_complete(void *arg)
-{
-   struct tmio_mmc_host *host = arg;
-
-   dev_dbg(&host->pdev->dev, "Command completed\n");
-
-   if (!host->data)
-   dev_warn(&host->pdev->dev, "NULL data in DMA completion!\n");
-   else
-   enable_mmc_irqs(host, TMIO_STAT_DATAEND);
-}
-
 static void tmio_mmc_start_dma_rx(struct tmio_mmc_host *host)
 {
struct scatterlist *sg = host->sg_ptr, *sg_tmp;
@@ -817,6 +810,8 @@ static void tmio_mmc_start_dma_rx(struct tmio_mmc_host 
*host)
goto pio;
}
 
+   disable_mmc_irqs(host, TMIO_STAT_RXRDY);
+
/* The only sg element can be unaligned, use our bounce buffer then */
if (!aligned) {
sg_init_one(&host->bounce_sg, host->bounce_buf, sg->length);
@@ -827,14 +822,11 @@ static void tmio_mmc_start_dma_rx(struct tmio_mmc_host 
*host)
ret = dma_map_sg(chan->device->dev, sg, host->sg_len, DMA_FROM_DEVICE);
if (ret > 0)
desc = chan->device->device_prep_slave_sg(chan, sg, ret,
-   DMA_FROM_DEVICE, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   DMA_FROM_DEVICE, DMA_CTRL_ACK);
 
-   if (desc) {
-   desc->callback = tmio_dma_complete;
-   desc->callback_param = host;
+   if (desc)
cookie = dmaengine_submit(desc);
-   dma_async_issue_pending(chan);
-   }
+
dev_dbg(&host->pdev->dev, "%s(): mapped %d -> %d, cookie %d, rq %p\n",
__func__, host->sg_len, ret, cookie, host->mrq);
 
@@ -886,6 +878,8 @@ static void tmio_mmc_start_dma_tx(struct tmio_mmc_host 
*host)
goto pio;
}
 
+   disable_mmc_irqs(host, TMIO_STAT_TXRQ);
+
/* The only sg element can be unaligned, use our bounce buffer then */
if (!aligned) {
unsigned long flags;
@@ -900,13 +894,11 @@ static void tmio_mmc_start_dma_tx(struct tmio_mmc_host 
*host)
ret = dma_map_sg(chan->device->dev, sg, host->sg_len, DMA_TO_DEVICE);
if (ret > 0)
desc = chan->device->device_prep_slave_sg(chan, sg, ret,
-   DMA_TO_DEVICE, DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+   DMA_TO_DEVICE, DMA_CTRL_ACK);
 
-   if (desc) {
-   desc->callback = tmio_dma_complete;
-   desc->callback_param = host;
+   if (desc)
cookie = dmaengine_submit(desc);
-   }
+
dev_dbg(&host->pdev->dev, "%s(): mapped %d -> %d, cookie %d, rq %p\n",
__func__, host->sg_len, ret, cookie, host->mrq);
 
@@ -947,17 +939,30 @@ static void tmio_mmc_start_dma(struct tmio_mmc_host *host,
 static void tmio_issue_tasklet_fn(unsigned long priv)
 {
struct tmio_mmc_host *host = (struct tmio_mmc_host *)priv;
-   struct dma_chan *chan = host->chan_tx;
+   struct dma_chan *chan = NULL;
+
+   spin_lock_irq(&host->lock);
+
+   if (host && host->data) {
+   if (host->data->flags & MMC_DATA_READ)
+   chan = host->chan_rx;
+   else
+   chan = host->chan_tx;
+   }
+
+   spin_unlock_irq(&host->lock);
 
-   dma_async_issue_pending(chan);
+   enable_mmc_irqs(host, TMIO_STAT_DATAEND);
+
+   if (chan)
+   dma_async_issue_pending(chan);
 }
 
 static void tmio_tasklet_fn(unsigned long arg

[PATCH 2/2 v2] mmc: tmio: use PIO for short transfers

[Guennadi Liakhovetski]

This patch allows transferring of some requests in PIO and some in DMA
mode and defaults to using DMA only for transfers longer than 8 bytes.
This is especially useful with SDIO, which can have lots of 2- and 4-byte
transfers, creating unnecessary high overhead, when executed in DMA.

Signed-off-by: Guennadi Liakhovetski 
---

v2: rebased on top of DMA API update patches from Linus Walleij

 drivers/mmc/host/tmio_mmc.c |   33 +++--
 1 files changed, 23 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index e88627b..32ab145 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -100,6 +100,8 @@
TMIO_STAT_CARD_REMOVE | TMIO_STAT_CARD_INSERT)
 #define TMIO_MASK_IRQ (TMIO_MASK_READOP | TMIO_MASK_WRITEOP | 
TMIO_MASK_CMD)
 
+#define TMIO_MIN_DMA_LEN 8
+
 #define enable_mmc_irqs(host, i) \
do { \
u32 mask;\
@@ -147,6 +149,7 @@ struct tmio_mmc_host {
struct platform_device *pdev;
 
/* DMA support */
+   boolforce_pio;
struct dma_chan *chan_rx;
struct dma_chan *chan_tx;
struct tasklet_struct   dma_complete;
@@ -385,6 +388,7 @@ static void tmio_mmc_reset_work(struct work_struct *work)
host->cmd = NULL;
host->data = NULL;
host->mrq = NULL;
+   host->force_pio = false;
 
spin_unlock_irqrestore(&host->lock, flags);
 
@@ -404,6 +408,7 @@ tmio_mmc_finish_request(struct tmio_mmc_host *host)
host->mrq = NULL;
host->cmd = NULL;
host->data = NULL;
+   host->force_pio = false;
 
cancel_delayed_work(&host->delayed_reset_work);
 
@@ -485,7 +490,7 @@ static void tmio_mmc_pio_irq(struct tmio_mmc_host *host)
unsigned int count;
unsigned long flags;
 
-   if (host->chan_tx || host->chan_rx) {
+   if ((host->chan_tx || host->chan_rx) && !host->force_pio) {
pr_err("PIO IRQ in DMA mode!\n");
return;
} else if (!data) {
@@ -551,15 +556,11 @@ static void tmio_mmc_do_data_irq(struct tmio_mmc_host 
*host)
 */
 
if (data->flags & MMC_DATA_READ) {
-   if (!host->chan_rx)
-   disable_mmc_irqs(host, TMIO_MASK_READOP);
-   else
+   if (host->chan_rx && !host->force_pio)
tmio_check_bounce_buffer(host);
dev_dbg(&host->pdev->dev, "Complete Rx request %p\n",
host->mrq);
} else {
-   if (!host->chan_tx)
-   disable_mmc_irqs(host, TMIO_MASK_WRITEOP);
dev_dbg(&host->pdev->dev, "Complete Tx request %p\n",
host->mrq);
}
@@ -583,7 +584,7 @@ static void tmio_mmc_data_irq(struct tmio_mmc_host *host)
if (!data)
goto out;
 
-   if (host->chan_tx && (data->flags & MMC_DATA_WRITE)) {
+   if (host->chan_tx && (data->flags & MMC_DATA_WRITE) && 
!host->force_pio) {
/*
 * Has all data been written out yet? Testing on SuperH showed,
 * that in most cases the first interrupt comes already with the
@@ -596,11 +597,12 @@ static void tmio_mmc_data_irq(struct tmio_mmc_host *host)
disable_mmc_irqs(host, TMIO_STAT_DATAEND);
tasklet_schedule(&host->dma_complete);
}
-   } else if (host->chan_rx && (data->flags & MMC_DATA_READ)) {
+   } else if (host->chan_rx && (data->flags & MMC_DATA_READ) && 
!host->force_pio) {
disable_mmc_irqs(host, TMIO_STAT_DATAEND);
tasklet_schedule(&host->dma_complete);
} else {
tmio_mmc_do_data_irq(host);
+   disable_mmc_irqs(host, TMIO_MASK_READOP | TMIO_MASK_WRITEOP);
}
 out:
spin_unlock(&host->lock);
@@ -649,12 +651,12 @@ static void tmio_mmc_cmd_irq(struct tmio_mmc_host *host,
 */
if (host->data && !cmd->error) {
if (host->data->flags & MMC_DATA_READ) {
-   if (!host->chan_rx)
+   if (host->force_pio || !host->chan_rx)
enable_mmc_irqs(host, TMIO_MASK_READOP);
else
tasklet_schedule(&host->dma_issue);
} else {
-   if (!host->chan_tx)
+   if (host->force_pio || !host->chan_tx)
enable_mmc_irqs(host, TMIO_MASK_WRITEOP);
else
tasklet_schedule(&host->dma_issue);
@@ -810,6 +812,11 @@ static void tmio_mmc_start_dma_rx(struct tmio_mmc_host 
*host)
goto pio;
}
 
+   if (sg->length < TMIO_MIN_DMA_LEN) {
+   host->force_pio = true;
+   return;
+   }
+
disable_mmc_irqs(host, TMIO_STAT_R

[PATCH 0/2 v2] tmio_mmc: improve DMA reliability (fwd)

[Guennadi Liakhovetski]

v2: rebased on top of DMA API update patches from Linus Walleij

Chris, sorry again, forgot to send these out...

On my test hardware I am getting different results with different SD and 
SDIO cards on different boards in different slots. The first patch in this 
series fixes DMA for all my available hardware, the second one is a 
further improvement to make switching between DMA and PIO possible at 
run-time on a per-transfer basis and uses PIO for short transfers also 
when DMA is available.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.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: outstanding tmio patches

[Guennadi Liakhovetski]

On Fri, 25 Mar 2011, Chris Ball wrote:

> Hi,
> 
> On Fri, Mar 25 2011, Guennadi Liakhovetski wrote:
> >> > [1/2] mmc: tmio: Improve DMA stability on sh-mobile
> >> 
> >> Some serious merge conflicts with Linus W's dmaengine cleanup here.
> >
> > Sorry, I must be missing something. I'm basing my patches on the current 
> > (of yesterday) next tree, which already contains Linus' patches:
> 
> I agree that linux-next contains these patches, but I don't agree that
> "mmc: tmio: Improve DMA stability on sh-mobile" (which was written back
> on March 7th before they were merged) avoids merge conflicts with them.

Ok, now I understand: I rebased those patches locally, but forgot to 
resend, sorry. Coming in a minute.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.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 1/1] mmc: remove redundant irq disabling

[Chris Ball]

Hi John,

On Fri, Mar 25 2011, John Ogness wrote:
> From: John Ogness 
>
> There is no need to disable irq's when using the sg_copy_*_buffer()
> functions because those functions do that already. There are also
> no races for the mm_queue struct here that would require the irq's
> to be disabled before calling sg_copy_*_buffer().
>
> Signed-off-by: John Ogness 
> ---
> Patch against linux-next-20110324.
>
>  drivers/mmc/card/queue.c |8 
>  1 files changed, 0 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
> index 2ae7275..c07322c 100644
> --- a/drivers/mmc/card/queue.c
> +++ b/drivers/mmc/card/queue.c
> @@ -343,18 +343,14 @@ unsigned int mmc_queue_map_sg(struct mmc_queue *mq)
>   */
>  void mmc_queue_bounce_pre(struct mmc_queue *mq)
>  {
> - unsigned long flags;
> -
>   if (!mq->bounce_buf)
>   return;
>  
>   if (rq_data_dir(mq->req) != WRITE)
>   return;
>  
> - local_irq_save(flags);
>   sg_copy_to_buffer(mq->bounce_sg, mq->bounce_sg_len,
>   mq->bounce_buf, mq->sg[0].length);
> - local_irq_restore(flags);
>  }
>  
>  /*
> @@ -363,17 +359,13 @@ void mmc_queue_bounce_pre(struct mmc_queue *mq)
>   */
>  void mmc_queue_bounce_post(struct mmc_queue *mq)
>  {
> - unsigned long flags;
> -
>   if (!mq->bounce_buf)
>   return;
>  
>   if (rq_data_dir(mq->req) != READ)
>   return;
>  
> - local_irq_save(flags);
>   sg_copy_from_buffer(mq->bounce_sg, mq->bounce_sg_len,
>   mq->bounce_buf, mq->sg[0].length);
> - local_irq_restore(flags);
>  }

Thanks, I'll push this to mmc-next for .40.

- Chris.
-- 
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 resend] mmc: fix the mmc_app_send_scr() for dma transfer

[Chris Ball]

Hi Yoshihiro,

On Fri, Mar 25 2011, Yoshihiro Shimoda wrote:
> This patch is based on the commit "af51715079e7fb6b290e1881d63d815dc4de5011":
>
>* Bugfix to that mmc_send_cxd_data() code:  dma-to-stack is
>  unsafe/nonportable, so kmalloc a bounce buffer instead.
>
> The driver may invalidate the mmc_card->csd when host driver uses dma.
> So the subroutine also needs kmalloc buffer.
>
> Signed-off-by: Yoshihiro Shimoda 

Thanks for the resend, pushed to mmc-next for .39-rc2.

- Chris.
-- 
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 V8 1/4] mmc: sdhci-esdhc: remove SDHCI_QUIRK_NO_CARD_NO_RESET from ESDHC_DEFAULT_QUIRKS

[Chris Ball]

Hi Richard,

Thanks, I've pushed all four patches to mmc-next for .39-rc2.

- Chris.
-- 
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: outstanding tmio patches

[Chris Ball]

Hi,

On Fri, Mar 25 2011, Guennadi Liakhovetski wrote:
>> > [1/2] mmc: tmio: Improve DMA stability on sh-mobile
>> 
>> Some serious merge conflicts with Linus W's dmaengine cleanup here.
>
> Sorry, I must be missing something. I'm basing my patches on the current 
> (of yesterday) next tree, which already contains Linus' patches:

I agree that linux-next contains these patches, but I don't agree that
"mmc: tmio: Improve DMA stability on sh-mobile" (which was written back
on March 7th before they were merged) avoids merge conflicts with them.

Thanks,

- Chris.
-- 
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: [RFC PATCH 0/1] dw_mmc: checking card busy with Status register

[Will Newton]

On Fri, Mar 25, 2011 at 6:00 AM, Jaehoon Chung  wrote:
> This RFC patch is applied checking card busy with status register.
>
> In Status register, bit[9] indicate the card busy or not.
> So, if we use this bit in status register, we can check the card busy or not.
>
> Maybe, didn't increased the performance, but i think this approach is 
> decreased
> the CPU usage.
>
> Anyone, let me know how think about this patch.

Do you have any numbers to report how this patch altered CPU usage or
card throughput for you? e.g. oprofile output or dd performance
--
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: [RFC PATCH 1/1] dw_mmc: add quirk about using only one slot

[Jaehoon Chung]

Hi Will

Will Newton wrote:
> On Fri, Mar 25, 2011 at 6:00 AM, Jaehoon Chung  wrote:
>> If assume only using one slot, i think that dw_mci_queue_request() need not.
>>
>> Signed-off-by: Jaehoon Chung 
>> Signed-off-by: Kyungmin Park > ---
>>  drivers/mmc/host/dw_mmc.c  |9 +++--
>>  include/linux/mmc/dw_mmc.h |3 ++-
>>  2 files changed, 9 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 882d004..e3f26ea 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -673,8 +673,13 @@ static void dw_mci_request(struct mmc_host *mmc, struct 
>> mmc_request *mrq)
>>return;
>>}
>>
>> -   /* We don't support multiple blocks of weird lengths. */
>> -   dw_mci_queue_request(host, slot, mrq);
>> +   if (host->quirks & DW_MCI_QUIRK_FORCE_ONE_SLOT) {
> 
> Do we really need a quirk for this? Why not use host->num_slots

Yes, you'r right. if using this patch, can use host->num_slots.

> 
>> +   slot->mrq = mrq;
>> +   host->state = STATE_SENDING_CMD;
> 
> I don't think it is safe to manipulate these structures without taking
> the host->lock. If we are to do this then I think I would like to know
> why (e.g. do we have performance numbers to support this change) and
> some analysis of what is protected by host->lock and which functions
> need the lock to be held. For example I do not think it is safe to
> call dw_mci_start_request without taking the lock.
> 

I know this patch didn't increase the performance.
BUt If we want to know some analysis..I should analysis what protected by 
host->lock.
Did you analysis what protect by host->lock?

>> +   dw_mci_start_request(host, slot);
>> +   } else
>> +   /* We don't support multiple blocks of weird lengths. */
> 
> This comment is obsolete I think and can be removed.

Anyway, Thanks for your comment.
 

Regards,
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: [RFC PATCH 1/1] dw_mmc: add quirk about using only one slot

[Will Newton]

On Fri, Mar 25, 2011 at 6:00 AM, Jaehoon Chung  wrote:
> If assume only using one slot, i think that dw_mci_queue_request() need not.
>
> Signed-off-by: Jaehoon Chung 
> Signed-off-by: Kyungmin Park  ---
>  drivers/mmc/host/dw_mmc.c  |    9 +++--
>  include/linux/mmc/dw_mmc.h |    3 ++-
>  2 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 882d004..e3f26ea 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -673,8 +673,13 @@ static void dw_mci_request(struct mmc_host *mmc, struct 
> mmc_request *mrq)
>                return;
>        }
>
> -       /* We don't support multiple blocks of weird lengths. */
> -       dw_mci_queue_request(host, slot, mrq);
> +       if (host->quirks & DW_MCI_QUIRK_FORCE_ONE_SLOT) {

Do we really need a quirk for this? Why not use host->num_slots?

> +               slot->mrq = mrq;
> +               host->state = STATE_SENDING_CMD;

I don't think it is safe to manipulate these structures without taking
the host->lock. If we are to do this then I think I would like to know
why (e.g. do we have performance numbers to support this change) and
some analysis of what is protected by host->lock and which functions
need the lock to be held. For example I do not think it is safe to
call dw_mci_start_request without taking the lock.

> +               dw_mci_start_request(host, slot);
> +       } else
> +               /* We don't support multiple blocks of weird lengths. */

This comment is obsolete I think and can be removed.
--
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/5] mmc: sdhci: make sdhci-esdhc-imx driver self registered

[Shawn Guo]

On Wed, Mar 23, 2011 at 10:28:58PM -0600, Grant Likely wrote:
> On Mon, Mar 21, 2011 at 04:06:59PM +0800, Shawn Guo wrote:
> > The patch turns the common stuff to in sdhci-pltfm.c into functions,
> > and add sdhci-esdhc-imx its own .probe and .remove which in turn call
> > into the common functions, so that sdhci-esdhc-imx driver registers
> > itself and keep all sdhci-esdhc-imx specific things like
> > sdhci_esdhc_imx_pdata away from sdhci-pltfm.c which is common.
> > 
> > Signed-off-by: Shawn Guo 
> 
> Hi Shawn,
> 
Hi Grant,

> Thanks for all this work, I think it is the right thing to do.  A few
> relatively minor comments below, but otherwise I like it.
> 
> g.
> 
> > ---
> >  drivers/mmc/host/sdhci-esdhc-imx.c |   98 
> > +---
> >  drivers/mmc/host/sdhci-pltfm.c |   84 +--
> >  drivers/mmc/host/sdhci-pltfm.h |   11 -
> 
> I think this patch should be split in 2.  One patch to refactor
> edhci-pltfm* to create the common utility functions, and one patch to
> convert the imx driver.
> 
I squashed this whole series into one patch in a relevant patch set
I just posted out minutes ago, primarily to reduce the patch quantity
and ease the bisect, since it's logically integral.

[...]
> > +static int __init sdhci_esdhc_imx_init(void)
> > +{
> > +   return platform_driver_register(&sdhci_esdhc_imx_driver);
> > +}
> > +
> > +static void __exit sdhci_esdhc_imx_exit(void)
> > +{
> > +   platform_driver_unregister(&sdhci_esdhc_imx_driver);
> > +}
> > +
> > +module_init(sdhci_esdhc_imx_init);
> > +module_exit(sdhci_esdhc_imx_exit);
> 
> Typically, I like to see module_init() and module_exit() immediately
> adjacent to the functions they register.
> 
Incorporated in the new patch set just posted ...

> > +
> > +MODULE_DESCRIPTION("SDHCI driver for i.MX eSDHC");
> > +MODULE_AUTHOR("Wolfram Sang ");
> > +MODULE_LICENSE("GPL v2");
> > diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
> > index ccc04ac..38b8cb4 100644
> > --- a/drivers/mmc/host/sdhci-pltfm.c
> > +++ b/drivers/mmc/host/sdhci-pltfm.c
> > @@ -44,6 +44,83 @@
> >  static struct sdhci_ops sdhci_pltfm_ops = {
> >  };
> >  
> > +struct sdhci_host *sdhci_pltfm_init(struct platform_device *pdev,
> > +   struct sdhci_pltfm_data *pdata)
> 
> Since there is no chance of *pdata being passed via the
> pdev->dev.platform_data pointer (there aren't any users in mainline of
> that feature) then I would take the opportunity to rename this
> parameter and structure to eliminate any confusion.  'struct
> sdhci_pltfm' would be sufficient I think.
> 
The chance comes along with the new patch set (function
sdhci_esdhc_probe in sdhci-esdhc.c).  And I would not rename 'struct
sdhci_pltfmi_data' to 'struct sdhci_pltfm' in terms of that we have
another name of 'struct sdhci_pltfm_host'.  But yes, pdata does
confuse.  Any suggestion?  I can fix all of them with a follow-up
patch against the new series.

> > +{
> > +   struct sdhci_host *host;
> > +   struct sdhci_pltfm_host *pltfm_host;
> > +   struct resource *iomem;
> > +   int ret;
> > +
> > +   iomem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > +   if (!iomem) {
> > +   ret = -ENOMEM;
> > +   goto err;
> > +   }
> > +
> > +   if (resource_size(iomem) < 0x100)
> > +   dev_err(&pdev->dev, "Invalid iomem size!\n");
> > +
> > +   /* Some PCI-based MFD need the parent here */
> > +   if (pdev->dev.parent != &platform_bus)
> > +   host = sdhci_alloc_host(pdev->dev.parent, sizeof(*pltfm_host));
> > +   else
> > +   host = sdhci_alloc_host(&pdev->dev, sizeof(*pltfm_host));
> > +
> > +   if (IS_ERR(host)) {
> > +   ret = PTR_ERR(host);
> > +   goto err;
> > +   }
> > +
> > +   pltfm_host = sdhci_priv(host);
> > +
> > +   host->hw_name = "SDHCI";
> > +   if (pdata && pdata->ops)
> > +   host->ops = pdata->ops;
> > +   else
> > +   host->ops = &sdhci_pltfm_ops;
> > +   if (pdata)
> > +   host->quirks = pdata->quirks;
> > +   host->irq = platform_get_irq(pdev, 0);
> > +
> > +   if (!request_mem_region(iomem->start, resource_size(iomem),
> > +   mmc_hostname(host->mmc))) {
> > +   dev_err(&pdev->dev, "cannot request region\n");
> > +   ret = -EBUSY;
> > +   goto err_request;
> > +   }
> > +
> > +   host->ioaddr = ioremap(iomem->start, resource_size(iomem));
> > +   if (!host->ioaddr) {
> > +   dev_err(&pdev->dev, "failed to remap registers\n");
> > +   ret = -ENOMEM;
> > +   goto err_remap;
> > +   }
> > +
> > +   platform_set_drvdata(pdev, host);
> > +
> > +   return host;
> > +
> > +err_remap:
> > +   release_mem_region(iomem->start, resource_size(iomem));
> > +err_request:
> > +   sdhci_free_host(host);
> > +err:
> > +   pr_err("%s failed %d\n", __func__, ret);
> > +   return NULL;
> > +}
> 
> Since the bulk of this function is a direct clone of the
> body of sdhci_pltfm

[PATCH 1/1] mmc: remove redundant irq disabling

[John Ogness]

From: John Ogness 

There is no need to disable irq's when using the sg_copy_*_buffer()
functions because those functions do that already. There are also
no races for the mm_queue struct here that would require the irq's
to be disabled before calling sg_copy_*_buffer().

Signed-off-by: John Ogness 
---
Patch against linux-next-20110324.

 drivers/mmc/card/queue.c |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index 2ae7275..c07322c 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -343,18 +343,14 @@ unsigned int mmc_queue_map_sg(struct mmc_queue *mq)
  */
 void mmc_queue_bounce_pre(struct mmc_queue *mq)
 {
-   unsigned long flags;
-
if (!mq->bounce_buf)
return;
 
if (rq_data_dir(mq->req) != WRITE)
return;
 
-   local_irq_save(flags);
sg_copy_to_buffer(mq->bounce_sg, mq->bounce_sg_len,
mq->bounce_buf, mq->sg[0].length);
-   local_irq_restore(flags);
 }
 
 /*
@@ -363,17 +359,13 @@ void mmc_queue_bounce_pre(struct mmc_queue *mq)
  */
 void mmc_queue_bounce_post(struct mmc_queue *mq)
 {
-   unsigned long flags;
-
if (!mq->bounce_buf)
return;
 
if (rq_data_dir(mq->req) != READ)
return;
 
-   local_irq_save(flags);
sg_copy_from_buffer(mq->bounce_sg, mq->bounce_sg_len,
mq->bounce_buf, mq->sg[0].length);
-   local_irq_restore(flags);
 }
 
-- 
1.7.2.5
--
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 3/4] mmc: sdhci-esdhc: make the writel/readl as the general APIs

[Zhu Richard-R65037]

Hi Wolfram:
Got that.
Thanks for your reminder.
Would follow your advice in future.

Best Regards
Richard Zhu

> -Original Message-
> From: Wolfram Sang [mailto:w.s...@pengutronix.de]
> Sent: Friday, March 25, 2011 4:53 PM
> To: Zhu Richard-R65037
> Cc: linux-arm-ker...@lists.infradead.org; ker...@pengutronix.de; linux-
> m...@vger.kernel.org; c...@laptop.org; avoront...@ru.mvista.com;
> e...@eukrea.com; linux...@gmail.com; eric.m...@linaro.org
> Subject: Re: [PATCH V8 3/4] mmc: sdhci-esdhc: make the writel/readl as
> the general APIs
>
> On Fri, Mar 25, 2011 at 11:39:05AM +0800, Richard Zhu wrote:
> > Add one flag to indicate the GPIO CD/WP is enabled or not on imx
> > platforms, and reuse the writel/readl as the general APIs for imx
> > SOCs.
> >
> > Signed-off-by: Richard Zhu 
> > ---
>
> Please provide something like "changes since last time" _below_ this
> dashed line "---" next time. Or use --cover-letter to introduce the
> changes.
>
> Other than that
>
> Reviewed-by: Wolfram Sang 
>
> 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 V8 4/4] mmc: sdhci-esdhc: enable esdhc on imx53

[Wolfram Sang]

On Fri, Mar 25, 2011 at 11:39:06AM +0800, Richard Zhu wrote:
> Fix the NO INT in the Multi-BLK IO in SD/MMC, and Multi-BLK
> read in SDIO on imx53.
> 
> The CMDTYPE of the CMD register (offset 0xE) should be set to
> "11" when the STOP CMD12 is issued on imx53 to abort one
> open ended multi-blk IO. Otherwise one the TC INT wouldn't
> be generated.
> 
> In exact block transfer, the controller doesn't complete the
> operations automatically as required at the end of the
> transfer and remains on hold if the abort command is not sent on
> imx53.
> As a result, the TC flag is not asserted and SW  received timeout
> exeception. set bit1 of Vendor Spec registor to fix it.
> 
> Signed-off-by: Richard Zhu 
> Signed-off-by: Richard Zhao 

Reviewed-by: Wolfram Sang 

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


signature.asc
Description: Digital signature

Re: [PATCH V8 3/4] mmc: sdhci-esdhc: make the writel/readl as the general APIs

[Wolfram Sang]

On Fri, Mar 25, 2011 at 11:39:05AM +0800, Richard Zhu wrote:
> Add one flag to indicate the GPIO CD/WP is enabled or not
> on imx platforms, and reuse the writel/readl as the general
> APIs for imx SOCs.
> 
> Signed-off-by: Richard Zhu 
> ---

Please provide something like "changes since last time" _below_ this
dashed line "---" next time. Or use --cover-letter to introduce the
changes.

Other than that

Reviewed-by: Wolfram Sang  

Regards,

   Wolfram

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


signature.asc
Description: Digital signature

[PATCH 3/5] mmc: sdhci: make sdhci-of device drivers self registered

[Shawn Guo]

The patch turns the sdhci-of-core common stuff into helper functions
added into sdhci-pltfm.c, and makes sdhci-of device drviers self
registered using the same pair of .probe and .remove used by
sdhci-pltfm device drivers.

As a result, sdhci-of-core.c and sdhci-of.h can be eliminated with
those common things merged into sdhci-pltfm.c and sdhci-pltfm.h
respectively.

Signed-off-by: Shawn Guo 
---
 drivers/mmc/host/Kconfig  |   15 +--
 drivers/mmc/host/Makefile |7 +-
 drivers/mmc/host/sdhci-of-core.c  |  247 -
 drivers/mmc/host/sdhci-of-esdhc.c |   75 +++-
 drivers/mmc/host/sdhci-of-hlwd.c  |   73 +++-
 drivers/mmc/host/sdhci-of.h   |   33 -
 drivers/mmc/host/sdhci-pltfm.c|  100 +++-
 drivers/mmc/host/sdhci-pltfm.h|   14 ++
 8 files changed, 263 insertions(+), 301 deletions(-)
 delete mode 100644 drivers/mmc/host/sdhci-of-core.c
 delete mode 100644 drivers/mmc/host/sdhci-of.h

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 1db9347..9f360b5 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -81,19 +81,11 @@ config MMC_RICOH_MMC
 
  If unsure, say Y.
 
-config MMC_SDHCI_OF
-   tristate "SDHCI support on OpenFirmware platforms"
-   depends on MMC_SDHCI && OF
-   help
- This selects the OF support for Secure Digital Host Controller
- Interfaces.
-
- If unsure, say N.
-
 config MMC_SDHCI_OF_ESDHC
bool "SDHCI OF support for the Freescale eSDHC controller"
-   depends on MMC_SDHCI_OF
+   depends on MMC_SDHCI
depends on PPC_OF
+   select MMC_SDHCI_PLTFM
select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
help
  This selects the Freescale eSDHC controller support.
@@ -102,8 +94,9 @@ config MMC_SDHCI_OF_ESDHC
 
 config MMC_SDHCI_OF_HLWD
bool "SDHCI OF support for the Nintendo Wii SDHCI controllers"
-   depends on MMC_SDHCI_OF
+   depends on MMC_SDHCI
depends on PPC_OF
+   select MMC_SDHCI_PLTFM
select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
help
  This selects the Secure Digital Host Controller Interface (SDHCI)
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 1d8e43d..0ea8815 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -41,11 +41,8 @@ obj-$(CONFIG_MMC_SDHCI_CNS3XXX)  += 
sdhci-cns3xxx.o
 obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX)  += sdhci-esdhc-imx.o
 obj-$(CONFIG_MMC_SDHCI_DOVE)   += sdhci-dove.o
 obj-$(CONFIG_MMC_SDHCI_TEGRA)  += sdhci-tegra.o
-
-obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
-sdhci-of-y := sdhci-of-core.o
-sdhci-of-$(CONFIG_MMC_SDHCI_OF_ESDHC)  += sdhci-of-esdhc.o
-sdhci-of-$(CONFIG_MMC_SDHCI_OF_HLWD)   += sdhci-of-hlwd.o
+obj-$(CONFIG_MMC_SDHCI_OF_ESDHC)   += sdhci-of-esdhc.o
+obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
 
 ifeq ($(CONFIG_CB710_DEBUG),y)
CFLAGS-cb710-mmc+= -DDEBUG
diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
deleted file mode 100644
index a6c0132..000
--- a/drivers/mmc/host/sdhci-of-core.c
+++ /dev/null
@@ -1,247 +0,0 @@
-/*
- * OpenFirmware bindings for Secure Digital Host Controller Interface.
- *
- * Copyright (c) 2007 Freescale Semiconductor, Inc.
- * Copyright (c) 2009 MontaVista Software, Inc.
- *
- * Authors: Xiaobo Xie 
- * Anton Vorontsov 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at
- * your option) any later version.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#ifdef CONFIG_PPC
-#include 
-#endif
-#include "sdhci-of.h"
-#include "sdhci.h"
-
-#ifdef CONFIG_MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
-
-/*
- * These accessors are designed for big endian hosts doing I/O to
- * little endian controllers incorporating a 32-bit hardware byte swapper.
- */
-
-u32 sdhci_be32bs_readl(struct sdhci_host *host, int reg)
-{
-   return in_be32(host->ioaddr + reg);
-}
-
-u16 sdhci_be32bs_readw(struct sdhci_host *host, int reg)
-{
-   return in_be16(host->ioaddr + (reg ^ 0x2));
-}
-
-u8 sdhci_be32bs_readb(struct sdhci_host *host, int reg)
-{
-   return in_8(host->ioaddr + (reg ^ 0x3));
-}
-
-void sdhci_be32bs_writel(struct sdhci_host *host, u32 val, int reg)
-{
-   out_be32(host->ioaddr + reg, val);
-}
-
-void sdhci_be32bs_writew(struct sdhci_host *host, u16 val, int reg)
-{
-   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-   int base = reg & ~0x3;
-   int shift = (reg & 0x2) * 8;
-
-   switch (reg) {
-   case SDHCI_TRANSFER_MODE:
-   /*
-* Postpone this write, we must do it togethe

[PATCH 1/5] mmc: sdhci: make sdhci-pltfm device drivers self registered

[Shawn Guo]

The patch turns the common stuff in sdhci-pltfm.c into functions, and
add device drivers their own .probe and .remove which in turn call
into the common functions, so that those sdhci-pltfm device drivers
register itself and keep all device specific things away from common
sdhci-pltfm file.

Signed-off-by: Shawn Guo 
---
 drivers/mmc/host/Kconfig   |   24 +++--
 drivers/mmc/host/Makefile  |   11 +-
 drivers/mmc/host/sdhci-cns3xxx.c   |   67 +-
 drivers/mmc/host/sdhci-dove.c  |   69 +-
 drivers/mmc/host/sdhci-esdhc-imx.c |   97 +++
 drivers/mmc/host/sdhci-pltfm.c |  165 ++-
 drivers/mmc/host/sdhci-pltfm.h |   14 ++-
 drivers/mmc/host/sdhci-tegra.c |  187 +---
 include/linux/mmc/sdhci-pltfm.h|6 -
 9 files changed, 360 insertions(+), 280 deletions(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index afe8c6f..1db9347 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -113,20 +113,17 @@ config MMC_SDHCI_OF_HLWD
  If unsure, say N.
 
 config MMC_SDHCI_PLTFM
-   tristate "SDHCI support on the platform specific bus"
+   bool
depends on MMC_SDHCI
help
- This selects the platform specific bus support for Secure Digital Host
- Controller Interface.
-
- If you have a controller with this interface, say Y or M here.
-
- If unsure, say N.
+ This selects the platform common function support for Secure Digital
+ Host Controller Interface.
 
 config MMC_SDHCI_CNS3XXX
bool "SDHCI support on the Cavium Networks CNS3xxx SoC"
depends on ARCH_CNS3XXX
-   depends on MMC_SDHCI_PLTFM
+   depends on MMC_SDHCI
+   select MMC_SDHCI_PLTFM
help
  This selects the SDHCI support for CNS3xxx System-on-Chip devices.
 
@@ -134,7 +131,9 @@ config MMC_SDHCI_CNS3XXX
 
 config MMC_SDHCI_ESDHC_IMX
bool "SDHCI platform support for the Freescale eSDHC i.MX controller"
-   depends on MMC_SDHCI_PLTFM && (ARCH_MX25 || ARCH_MX35 || ARCH_MX5)
+   depends on ARCH_MX25 || ARCH_MX35 || ARCH_MX5
+   depends on MMC_SDHCI
+   select MMC_SDHCI_PLTFM
select MMC_SDHCI_IO_ACCESSORS
help
  This selects the Freescale eSDHC controller support on the platform
@@ -145,7 +144,8 @@ config MMC_SDHCI_ESDHC_IMX
 config MMC_SDHCI_DOVE
bool "SDHCI support on Marvell's Dove SoC"
depends on ARCH_DOVE
-   depends on MMC_SDHCI_PLTFM
+   depends on MMC_SDHCI
+   select MMC_SDHCI_PLTFM
select MMC_SDHCI_IO_ACCESSORS
help
  This selects the Secure Digital Host Controller Interface in
@@ -155,7 +155,9 @@ config MMC_SDHCI_DOVE
 
 config MMC_SDHCI_TEGRA
tristate "SDHCI platform support for the Tegra SD/MMC Controller"
-   depends on MMC_SDHCI_PLTFM && ARCH_TEGRA
+   depends on ARCH_TEGRA
+   depends on MMC_SDHCI
+   select MMC_SDHCI_PLTFM
select MMC_SDHCI_IO_ACCESSORS
help
  This selects the Tegra SD/MMC controller. If you have a Tegra
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index e834fb2..1d8e43d 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -36,12 +36,11 @@ obj-$(CONFIG_MMC_SH_MMCIF)  += sh_mmcif.o
 obj-$(CONFIG_MMC_JZ4740)   += jz4740_mmc.o
 obj-$(CONFIG_MMC_USHC) += ushc.o
 
-obj-$(CONFIG_MMC_SDHCI_PLTFM)  += sdhci-platform.o
-sdhci-platform-y   := sdhci-pltfm.o
-sdhci-platform-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
-sdhci-platform-$(CONFIG_MMC_SDHCI_ESDHC_IMX)   += sdhci-esdhc-imx.o
-sdhci-platform-$(CONFIG_MMC_SDHCI_DOVE)+= sdhci-dove.o
-sdhci-platform-$(CONFIG_MMC_SDHCI_TEGRA)   += sdhci-tegra.o
+obj-$(CONFIG_MMC_SDHCI_PLTFM)  += sdhci-pltfm.o
+obj-$(CONFIG_MMC_SDHCI_CNS3XXX)+= sdhci-cns3xxx.o
+obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX)  += sdhci-esdhc-imx.o
+obj-$(CONFIG_MMC_SDHCI_DOVE)   += sdhci-dove.o
+obj-$(CONFIG_MMC_SDHCI_TEGRA)  += sdhci-tegra.o
 
 obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
 sdhci-of-y := sdhci-of-core.o
diff --git a/drivers/mmc/host/sdhci-cns3xxx.c b/drivers/mmc/host/sdhci-cns3xxx.c
index 9ebd1d7..95b9080 100644
--- a/drivers/mmc/host/sdhci-cns3xxx.c
+++ b/drivers/mmc/host/sdhci-cns3xxx.c
@@ -86,7 +86,7 @@ static struct sdhci_ops sdhci_cns3xxx_ops = {
.set_clock  = sdhci_cns3xxx_set_clock,
 };
 
-struct sdhci_pltfm_data sdhci_cns3xxx_pdata = {
+static struct sdhci_pltfm_data sdhci_cns3xxx_pdata = {
.ops = &sdhci_cns3xxx_ops,
.quirks = SDHCI_QUIRK_BROKEN_DMA |
  SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
@@ -95,3 +95,68 @@ struct sdhci_pltfm_data sdhci_cns3xxx_pdata = {
  SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
  SDHCI_QUIRK_NONSTANDARD_CLO

[PATCH 5/5] mmc: sdhci: merge two sdhci-pltfm.h into one

[Shawn Guo]

The structure sdhci_pltfm_data is not necessarily to be in a public
header like include/linux/mmc/sdhci-pltfm.h, so the patch moves it
into drivers/mmc/host/sdhci-pltfm.h and eliminates the former one.

Signed-off-by: Shawn Guo 
---
 drivers/mmc/host/sdhci-cns3xxx.c |1 -
 drivers/mmc/host/sdhci-esdhc.c   |1 -
 drivers/mmc/host/sdhci-pltfm.h   |6 +-
 include/linux/mmc/sdhci-pltfm.h  |   29 -
 4 files changed, 5 insertions(+), 32 deletions(-)
 delete mode 100644 include/linux/mmc/sdhci-pltfm.h

diff --git a/drivers/mmc/host/sdhci-cns3xxx.c b/drivers/mmc/host/sdhci-cns3xxx.c
index 95b9080..2238d34 100644
--- a/drivers/mmc/host/sdhci-cns3xxx.c
+++ b/drivers/mmc/host/sdhci-cns3xxx.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include "sdhci.h"
 #include "sdhci-pltfm.h"
diff --git a/drivers/mmc/host/sdhci-esdhc.c b/drivers/mmc/host/sdhci-esdhc.c
index b3d1bc1..fd041d9 100644
--- a/drivers/mmc/host/sdhci-esdhc.c
+++ b/drivers/mmc/host/sdhci-esdhc.c
@@ -20,7 +20,6 @@
 #include 
 #include 
 #include 
-#include 
 #ifdef CONFIG_MMC_SDHCI_ESDHC_IMX
 #include 
 #endif
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index 05fe25d..e2d143c 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -14,9 +14,13 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
+struct sdhci_pltfm_data {
+   struct sdhci_ops *ops;
+   unsigned int quirks;
+};
+
 struct sdhci_pltfm_host {
struct clk *clk;
u32 scratchpad; /* to handle quirks across io-accessor calls */
diff --git a/include/linux/mmc/sdhci-pltfm.h b/include/linux/mmc/sdhci-pltfm.h
deleted file mode 100644
index f1c2ac3..000
--- a/include/linux/mmc/sdhci-pltfm.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * Platform data declarations for the sdhci-pltfm driver.
- *
- * Copyright (c) 2010 MontaVista Software, LLC.
- *
- * Author: Anton Vorontsov 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at
- * your option) any later version.
- */
-
-#ifndef _SDHCI_PLTFM_H
-#define _SDHCI_PLTFM_H
-
-struct sdhci_ops;
-
-/**
- * struct sdhci_pltfm_data - SDHCI platform-specific information & hooks
- * @ops: optional pointer to the platform-provided SDHCI ops
- * @quirks: optional SDHCI quirks
- */
-struct sdhci_pltfm_data {
-   struct sdhci_ops *ops;
-   unsigned int quirks;
-};
-
-#endif /* _SDHCI_PLTFM_H */
-- 
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 4/5] mmc: sdhci: consolidate sdhci-of-esdhc and sdhci-esdhc-imx

[Shawn Guo]

This patch is to consolidate SDHCI driver for Freescale eSDHC
controller found on both MPCxxx and i.MX platforms.  It turns
sdhci-of-esdhc.c and sdhci-esdhc-imx.c into one sdhci-esdhc.c,
which gets the same pair of .probe and .remove serving two cases.

Signed-off-by: Shawn Guo 
---
 drivers/mmc/host/Kconfig   |   38 ++--
 drivers/mmc/host/Makefile  |3 +-
 drivers/mmc/host/sdhci-esdhc-imx.c |  210 --
 drivers/mmc/host/sdhci-esdhc.c |  413 
 drivers/mmc/host/sdhci-of-esdhc.c  |  162 --
 drivers/mmc/host/sdhci-pltfm.c |2 +
 drivers/mmc/host/sdhci-pltfm.h |2 -
 7 files changed, 439 insertions(+), 391 deletions(-)
 delete mode 100644 drivers/mmc/host/sdhci-esdhc-imx.c
 create mode 100644 drivers/mmc/host/sdhci-esdhc.c
 delete mode 100644 drivers/mmc/host/sdhci-of-esdhc.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9f360b5..e39c145 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -81,17 +81,6 @@ config MMC_RICOH_MMC
 
  If unsure, say Y.
 
-config MMC_SDHCI_OF_ESDHC
-   bool "SDHCI OF support for the Freescale eSDHC controller"
-   depends on MMC_SDHCI
-   depends on PPC_OF
-   select MMC_SDHCI_PLTFM
-   select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
-   help
- This selects the Freescale eSDHC controller support.
-
- If unsure, say N.
-
 config MMC_SDHCI_OF_HLWD
bool "SDHCI OF support for the Nintendo Wii SDHCI controllers"
depends on MMC_SDHCI
@@ -122,15 +111,34 @@ config MMC_SDHCI_CNS3XXX
 
  If unsure, say N.
 
+config MMC_SDHCI_ESDHC
+   bool
+   depends on MMC_SDHCI
+   select MMC_SDHCI_PLTFM
+   help
+ This selects SDHCI driver for Freescale eSDHC controller.
+
+config MMC_SDHCI_ESDHC_MPC
+   bool "SDHCI support for the Freescale eSDHC MPC controller"
+   depends on MMC_SDHCI
+   depends on PPC_OF
+   select MMC_SDHCI_ESDHC
+   select MMC_SDHCI_BIG_ENDIAN_32BIT_BYTE_SWAPPER
+   help
+ This selects the Freescale eSDHC controller support on platforms
+ like mpc8379/mpc8536.
+
+ If unsure, say N.
+
 config MMC_SDHCI_ESDHC_IMX
-   bool "SDHCI platform support for the Freescale eSDHC i.MX controller"
+   bool "SDHCI support for the Freescale eSDHC i.MX controller"
depends on ARCH_MX25 || ARCH_MX35 || ARCH_MX5
depends on MMC_SDHCI
-   select MMC_SDHCI_PLTFM
+   select MMC_SDHCI_ESDHC
select MMC_SDHCI_IO_ACCESSORS
help
- This selects the Freescale eSDHC controller support on the platform
- bus, found on platforms like mx35/51.
+ This selects the Freescale eSDHC controller support on platforms
+ like mx35/51.
 
  If unsure, say N.
 
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 0ea8815..e6e3aaa 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -38,10 +38,9 @@ obj-$(CONFIG_MMC_USHC)   += ushc.o
 
 obj-$(CONFIG_MMC_SDHCI_PLTFM)  += sdhci-pltfm.o
 obj-$(CONFIG_MMC_SDHCI_CNS3XXX)+= sdhci-cns3xxx.o
-obj-$(CONFIG_MMC_SDHCI_ESDHC_IMX)  += sdhci-esdhc-imx.o
+obj-$(CONFIG_MMC_SDHCI_ESDHC)  += sdhci-esdhc.o
 obj-$(CONFIG_MMC_SDHCI_DOVE)   += sdhci-dove.o
 obj-$(CONFIG_MMC_SDHCI_TEGRA)  += sdhci-tegra.o
-obj-$(CONFIG_MMC_SDHCI_OF_ESDHC)   += sdhci-of-esdhc.o
 obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
 
 ifeq ($(CONFIG_CB710_DEBUG),y)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
deleted file mode 100644
index c9eb507..000
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ /dev/null
@@ -1,210 +0,0 @@
-/*
- * Freescale eSDHC i.MX controller driver for the platform bus.
- *
- * derived from the OF-version.
- *
- * Copyright (c) 2010 Pengutronix e.K.
- *   Author: Wolfram Sang 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "sdhci.h"
-#include "sdhci-pltfm.h"
-#include "sdhci-esdhc.h"
-
-static inline void esdhc_clrset_le(struct sdhci_host *host, u32 mask, u32 val, 
int reg)
-{
-   void __iomem *base = host->ioaddr + (reg & ~0x3);
-   u32 shift = (reg & 0x3) * 8;
-
-   writel(((readl(base) & ~(mask << shift)) | (val << shift)), base);
-}
-
-static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
-{
-   if (unlikely(reg == SDHCI_HOST_VERSION))
-   reg ^= 2;
-
-   return readw(host->ioaddr + reg);
-}
-
-static void esdhc_writew_le(struct sdhci_host *host, u16 val, int reg)
-{
-   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
-
-   switch (reg) {
-   case SD

[PATCH 2/5] mmc: sdhci: eliminate sdhci_of_host and sdhci_of_data

[Shawn Guo]

The patch is to migrate the use of sdhci_of_host and sdhci_of_data
to sdhci_pltfm_host and sdhci_pltfm_data, so that the former pair can
be eliminated.

Signed-off-by: Shawn Guo 
---
 drivers/mmc/host/sdhci-of-core.c  |   30 +++---
 drivers/mmc/host/sdhci-of-esdhc.c |   36 +++-
 drivers/mmc/host/sdhci-of-hlwd.c  |   20 +++-
 drivers/mmc/host/sdhci-of.h   |   15 +++
 drivers/mmc/host/sdhci-pltfm.h|4 
 5 files changed, 52 insertions(+), 53 deletions(-)

diff --git a/drivers/mmc/host/sdhci-of-core.c b/drivers/mmc/host/sdhci-of-core.c
index dd84124..a6c0132 100644
--- a/drivers/mmc/host/sdhci-of-core.c
+++ b/drivers/mmc/host/sdhci-of-core.c
@@ -59,7 +59,7 @@ void sdhci_be32bs_writel(struct sdhci_host *host, u32 val, 
int reg)
 
 void sdhci_be32bs_writew(struct sdhci_host *host, u16 val, int reg)
 {
-   struct sdhci_of_host *of_host = sdhci_priv(host);
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
int base = reg & ~0x3;
int shift = (reg & 0x2) * 8;
 
@@ -69,10 +69,10 @@ void sdhci_be32bs_writew(struct sdhci_host *host, u16 val, 
int reg)
 * Postpone this write, we must do it together with a
 * command write that is down below.
 */
-   of_host->xfer_mode_shadow = val;
+   pltfm_host->xfer_mode_shadow = val;
return;
case SDHCI_COMMAND:
-   sdhci_be32bs_writel(host, val << 16 | of_host->xfer_mode_shadow,
+   sdhci_be32bs_writel(host, val << 16 | 
pltfm_host->xfer_mode_shadow,
SDHCI_TRANSFER_MODE);
return;
}
@@ -128,9 +128,9 @@ static int __devinit sdhci_of_probe(struct platform_device 
*ofdev,
 const struct of_device_id *match)
 {
struct device_node *np = ofdev->dev.of_node;
-   struct sdhci_of_data *sdhci_of_data = match->data;
+   struct sdhci_pltfm_data *pdata = match->data;
struct sdhci_host *host;
-   struct sdhci_of_host *of_host;
+   struct sdhci_pltfm_host *pltfm_host;
const __be32 *clk;
int size;
int ret;
@@ -138,11 +138,11 @@ static int __devinit sdhci_of_probe(struct 
platform_device *ofdev,
if (!of_device_is_available(np))
return -ENODEV;
 
-   host = sdhci_alloc_host(&ofdev->dev, sizeof(*of_host));
+   host = sdhci_alloc_host(&ofdev->dev, sizeof(*pltfm_host));
if (IS_ERR(host))
return -ENOMEM;
 
-   of_host = sdhci_priv(host);
+   pltfm_host = sdhci_priv(host);
dev_set_drvdata(&ofdev->dev, host);
 
host->ioaddr = of_iomap(np, 0);
@@ -158,9 +158,9 @@ static int __devinit sdhci_of_probe(struct platform_device 
*ofdev,
}
 
host->hw_name = dev_name(&ofdev->dev);
-   if (sdhci_of_data) {
-   host->quirks = sdhci_of_data->quirks;
-   host->ops = &sdhci_of_data->ops;
+   if (pdata) {
+   host->quirks = pdata->quirks;
+   host->ops = &pdata->ops;
}
 
if (of_get_property(np, "sdhci,auto-cmd12", NULL))
@@ -175,7 +175,7 @@ static int __devinit sdhci_of_probe(struct platform_device 
*ofdev,
 
clk = of_get_property(np, "clock-frequency", &size);
if (clk && size == sizeof(*clk) && *clk)
-   of_host->clock = be32_to_cpup(clk);
+   pltfm_host->clock = be32_to_cpup(clk);
 
ret = sdhci_add_host(host);
if (ret)
@@ -205,12 +205,12 @@ static int __devexit sdhci_of_remove(struct 
platform_device *ofdev)
 
 static const struct of_device_id sdhci_of_match[] = {
 #ifdef CONFIG_MMC_SDHCI_OF_ESDHC
-   { .compatible = "fsl,mpc8379-esdhc", .data = &sdhci_esdhc, },
-   { .compatible = "fsl,mpc8536-esdhc", .data = &sdhci_esdhc, },
-   { .compatible = "fsl,esdhc", .data = &sdhci_esdhc, },
+   { .compatible = "fsl,mpc8379-esdhc", .data = &sdhci_esdhc_pdata, },
+   { .compatible = "fsl,mpc8536-esdhc", .data = &sdhci_esdhc_pdata, },
+   { .compatible = "fsl,esdhc", .data = &sdhci_esdhc_pdata, },
 #endif
 #ifdef CONFIG_MMC_SDHCI_OF_HLWD
-   { .compatible = "nintendo,hollywood-sdhci", .data = &sdhci_hlwd, },
+   { .compatible = "nintendo,hollywood-sdhci", .data = &sdhci_hlwd_pdata, 
},
 #endif
{ .compatible = "generic-sdhci", },
{},
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
b/drivers/mmc/host/sdhci-of-esdhc.c
index fcd0e1f..702a98b 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -60,30 +60,32 @@ static int esdhc_of_enable_dma(struct sdhci_host *host)
 
 static unsigned int esdhc_of_get_max_clock(struct sdhci_host *host)
 {
-   struct sdhci_of_host *of_host = sdhci_priv(host);
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
 
-   return of_host->clock;
+   return pltfm_host->clock;
 }
 
 static unsi

[PATCH 0/5] consolidate sdhci pltfm & OF drivers and get them self registered

[Shawn Guo]

Here are what the patch set does.

* Remove .probe and .remove hooks from sdhci-pltfm.c and make it be
  a pure common helper function providers.
* Add .probe and .remove hooks for sdhci pltfm drivers sdhci-cns3xxx,
  sdhci-dove, sdhci-tegra, and sdhci-esdhc-imx to make them self
  registered with calling helper functions created above.
* Migrate the use of sdhci_of_host and sdhci_of_data to
  sdhci_pltfm_host and sdhci_pltfm_data, so that OF version host and
  data structure works can be saved, and pltfm version works for both
  cases.
* Add OF common helper stuff into sdhci-pltfm.c, and make OF version
  sdhci drivers sdhci-of-esdhc and sdhci-of-hlwd become self
  registered as well, so that sdhci-of-core.c and sdhci-of.h can be
  removed.
* Consolidate the OF and pltfm esdhc drivers into one with sharing
  the same pair of .probe and .remove hooks.  As a result,
  sdhci-esdhc-imx.c and sdhci-of-esdhc.c go away, while
  sdhci-esdhc.c comes in and works for both MPCxxx and i.MX.
* Eliminate include/linux/mmc/sdhci-pltfm.h with moving stuff into
  drivers/mmc/host/sdhci-pltfm.h.

And the benefits we gain from the changes are:

* Get the sdhci device driver follow the Linux trend that driver
  makes the registration by its own.
* sdhci-pltfm.c becomes simple and clean as it only has common helper
  stuff there now.
* All sdhci device specific things are going back its own driver.
* The dt and non-dt drivers are consolidated to use the same pair of
  .probe and .remove hooks.
* SDHCI driver for Freescale eSDHC controller found on both MPCxxx
  and i.MX platforms is consolidated to use the same one .probe
  function.

The patch set works against the tree below, and was only tested on
i.mx51 babbage board, all other targets were build tested.

  git://git.secretlab.ca/git/linux-2.6.git devicetree/test

Comments are welcomed and appreciated.

Regards,
Shawn

PS: The first patch is a squashing of the patch set below, which was
posted for review a few days back.

  [PATCH 0/5] make sdhci device drivers self registered

Some patches in this series are relatively large, involving more
changes than expected, I chose to not split considering they are
logically integral, and doing so can reduce the patch quantity much,
and make bisect much easier.  But sorry for that it makes reviewers'
life harder.

Shawn Guo (5):
  mmc: sdhci: make sdhci-pltfm device drivers self registered
  mmc: sdhci: eliminate sdhci_of_host and sdhci_of_data
  mmc: sdhci: make sdhci-of device drivers self registered
  mmc: sdhci: consolidate sdhci-of-esdhc and sdhci-esdhc-imx
  mmc: sdhci: merge two sdhci-pltfm.h into one

 drivers/mmc/host/Kconfig   |   71 ---
 drivers/mmc/host/Makefile  |   17 +-
 drivers/mmc/host/sdhci-cns3xxx.c   |   68 ++-
 drivers/mmc/host/sdhci-dove.c  |   69 ++-
 drivers/mmc/host/sdhci-esdhc-imx.c |  149 -
 drivers/mmc/host/sdhci-esdhc.c |  412 
 drivers/mmc/host/sdhci-of-core.c   |  247 -
 drivers/mmc/host/sdhci-of-esdhc.c  |   89 
 drivers/mmc/host/sdhci-of-hlwd.c   |   89 +++-
 drivers/mmc/host/sdhci-of.h|   42 
 drivers/mmc/host/sdhci-pltfm.c |  251 +-
 drivers/mmc/host/sdhci-pltfm.h |   36 +++-
 drivers/mmc/host/sdhci-tegra.c |  187 ++---
 include/linux/mmc/sdhci-pltfm.h|   35 ---
 14 files changed, 912 insertions(+), 850 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: outstanding tmio patches

[Guennadi Liakhovetski]

Hi Chris

On Thu, 24 Mar 2011, Chris Ball wrote:

> Hi Guennadi,
> 
> On Wed, Mar 23 2011, Guennadi Liakhovetski wrote:
> > I thought it might help to list all the recent patches in the order they 
> > should apply to make it a bit easier...
> >
> > [1/2] mmc: tmio: Improve DMA stability on sh-mobile
> 
> Some serious merge conflicts with Linus W's dmaengine cleanup here.

Sorry, I must be missing something. I'm basing my patches on the current 
(of yesterday) next tree, which already contains Linus' patches:

mmc: tmio_mmc: use dmaengine helpers, drop submit check
mmc: tmio_mmc: drop dma_sglen state variable
mmc: tmio_mmc: unmap with the proper sglen
mmc: tmio_mmc: map DMA buffers on the DMA engine device

or which his patches do you mean?

Thanks
Guennadi

> > [2/2] mmc: tmio: use PIO for short transfers
> > [1/6,v2] mmc: tmio: split core functionality, DMA and MFD glue
> 
> And again here.  These flag-day patches that move around thousands of
> lines of code are extremely difficult to pull off without announcing
> them far ahead of time and getting everyone else to hold off from
> merging code first; you're essentially saying that development is closed
> and everyone else has to wait for your patch to be merged and then
> rebase onto it.
> 
> I'm open to suggestions on what to do next -- if you find it easier
> to prepare a git tree with everything applied for me to pull from
> I'd be happy to do that, although I think we should be preparing this
> much churn long before the merge window opens if it's supposed to go
> into mainline for the current cycle; the merge window should be for
> merging linux-next into mainline.
> 
> I think my own suggestion, without knowing too much about tmio, would be
> to apply the four patches that provide hardware fixes now, for -rc2:
> 
> [1/4,v3] mmc: tmio: only access registers above 0xff, if available
> [2/4,v3] ARM: mach-shmobile: fix SDHI IO address-range
> [3/4,v3] sh: fix SDHI IO address-range
> [4/4,v3] mmc: tmio: remove work-around for unmasked SDIO interrupts
> 
> and push the module split and clock gating work out to the start of the
> next merge window.
> 
> Let me know what you think, thanks,
> 
> - Chris.
> -- 
> Chris Ball  
> One Laptop Per Child
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.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