Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Guennadi Liakhovetski]

Hello Kobayashi-san

On Tue, 18 Sep 2012, Tetsuyuki Kobayashi wrote:

> Hello Guennadi
> 
> (2012/08/31 12:05), Tetsuyuki Kobayashi wrote:
> 
> > (2012/08/22 15:49), Guennadi Liakhovetski wrote:
> > > On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
> > > interrupts without any active request. To prevent the Oops, that results
> > > in such cases, don't dereference the mmc request pointer until we make
> > > sure, that we are indeed processing such a request.
> > > 
> > > Reported-by: Tetsuyuki Kobayashi 
> > > Signed-off-by: Guennadi Liakhovetski 
> > > ---
> > > 
> > > Hello Kobayashi-san
> > > 
> > > On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:
> > > 
> > > ...
> > > 
> > > > After applying this patch on kzm9g board, I got this error regarding
> > > > eMMC.
> > > > I think this is another problem.
> > > > 
> > > > 
> > > > Unable to handle kernel NULL pointer dereference at virtual address
> > > > 0008
> > > > pgd = c0004000
> > > > [0008] *pgd=
> > > > Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> > > > Modules linked in:
> > > > CPU: 1Not tainted  (3.6.0-rc2+ #103)
> > > > PC is at sh_mmcif_irqt+0x20/0xb30
> > > > LR is at irq_thread+0x94/0x16c
> > > 
> > > [snip]
> > > 
> > > > My quick fix is below.
> > > > 
> > > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > > index 5d81427..e587fbc 100644
> > > > --- a/drivers/mmc/host/sh_mmcif.c
> > > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > > @@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > > *dev_id)
> > > >   {
> > > >  struct sh_mmcif_host *host = dev_id;
> > > >  struct mmc_request *mrq = host->mrq;
> > > > -   struct mmc_data *data = mrq->data;
> > > > +   /*struct mmc_data *data = mrq->data; -- this cause null
> > > > pointer access*/
> > > > +   struct mmc_data *data;
> > > > +
> > > > +   /* quick fix by koba */
> > > > +   if (mrq == NULL) {
> > > > +   printk("sh_mmcif_irqt: mrq == NULL:
> > > > host->wait_for=%d\n", host->wait_for);
> > > > +   } else {
> > > > +   data = mrq->data;
> > > > +   }
> > > > 
> > > >  cancel_delayed_work_sync(&host->timeout_work);
> > > > 
> > > > 
> > > > With this patch, there is no null pointer accesses and got this log.
> > > > 
> > > > sh_mmcif_irqt: mrq == NULL: host->wait_for=0
> > > > sh_mmcif_irqt: mrq == NULL: host->wait_for=0
> > > >...
> > > > 
> > > > host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
> > > > There is code such like:
> > > > 
> > > > host->wait_for = MMCIF_WAIT_FOR_REQUEST;
> > > > host->mrq = NULL;
> > > > 
> > > > So, at the top of sh_mmcif_irqt, if host->wait_for ==
> > > > MMCIF_WAIT_FOR_REQUEST,
> > > > host->mrq = NULL.
> > > > It is too earlier to access mrq->data before checking host->mrq. it may
> > > > cause null pointer access.
> > > > 
> > > > Goda-san, could you check this and refine the code of sh_mmcif_irqt?
> > > 
> > > Thanks for your report and a fix. Could you please double-check, whether
> > > the below patch also fixes your problem? Since such spurious interrupts
> > > are possible I would commit a check like this one, but in the longer run
> > > we want to identify and eliminate them, if possible. But since so far
> > > these interrupts only happen on 1 board model and also not on all units
> > > and not upon each boot, this could be a bit tricky.
> > > 
> > > One more question - is this only needed for 3.7 or also for 3.6 / stable?
> > > 
> > > Thanks
> > > Guennadi
> > > 
> > >   drivers/mmc/host/sh_mmcif.c |4 ++--
> > >   1 files changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> > > index 5d81427..82bf921 100644
> > > --- a/drivers/mmc/host/sh_mmcif.c
> > > +++ b/drivers/mmc/host/sh_mmcif.c
> > > @@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > *dev_id)
> > >   {
> > >   struct sh_mmcif_host *host = dev_id;
> > >   struct mmc_request *mrq = host->mrq;
> > > -struct mmc_data *data = mrq->data;
> > > 
> > >   cancel_delayed_work_sync(&host->timeout_work);
> > > 
> > > @@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
> > > *dev_id)
> > >   case MMCIF_WAIT_FOR_READ_END:
> > >   case MMCIF_WAIT_FOR_WRITE_END:
> > >   if (host->sd_error)
> > > -data->error = sh_mmcif_error_manage(host);
> > > +mrq->data->error = sh_mmcif_error_manage(host);
> > >   break;
> > >   default:
> > >   BUG();
> > >   }
> > > 
> > >   if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
> > > +struct mmc_data *data = mrq->data;
> > >   if (!mrq->cmd->error && data && !data->error)
> > >   data->bytes_xfered =
> > >   data->blocks * data->blksz;
> > > 
> > 
> > I tried this patch. It seems better.
> > But I think this still have potential race condition.
> 

Re: [PATCH] mmc: sh-mmcif: avoid Oops on spurious interrupts

[Tetsuyuki Kobayashi]

Hello Guennadi

(2012/08/31 12:05), Tetsuyuki Kobayashi wrote:


(2012/08/22 15:49), Guennadi Liakhovetski wrote:

On some systems, e.g., kzm9g, MMCIF interfaces can produce spurious
interrupts without any active request. To prevent the Oops, that results
in such cases, don't dereference the mmc request pointer until we make
sure, that we are indeed processing such a request.

Reported-by: Tetsuyuki Kobayashi 
Signed-off-by: Guennadi Liakhovetski 
---

Hello Kobayashi-san

On Mon, 20 Aug 2012, Tetsuyuki Kobayashi wrote:

...


After applying this patch on kzm9g board, I got this error regarding
eMMC.
I think this is another problem.


Unable to handle kernel NULL pointer dereference at virtual address
0008
pgd = c0004000
[0008] *pgd=
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 1Not tainted  (3.6.0-rc2+ #103)
PC is at sh_mmcif_irqt+0x20/0xb30
LR is at irq_thread+0x94/0x16c


[snip]


My quick fix is below.

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 5d81427..e587fbc 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1104,7 +1104,15 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
*dev_id)
  {
 struct sh_mmcif_host *host = dev_id;
 struct mmc_request *mrq = host->mrq;
-   struct mmc_data *data = mrq->data;
+   /*struct mmc_data *data = mrq->data; -- this cause null
pointer access*/
+   struct mmc_data *data;
+
+   /* quick fix by koba */
+   if (mrq == NULL) {
+   printk("sh_mmcif_irqt: mrq == NULL:
host->wait_for=%d\n", host->wait_for);
+   } else {
+   data = mrq->data;
+   }

 cancel_delayed_work_sync(&host->timeout_work);


With this patch, there is no null pointer accesses and got this log.

sh_mmcif_irqt: mrq == NULL: host->wait_for=0
sh_mmcif_irqt: mrq == NULL: host->wait_for=0
   ...

host->wait_for is 0. it is MMCIF_WAIT_FOR_REQUEST.
There is code such like:

host->wait_for = MMCIF_WAIT_FOR_REQUEST;
host->mrq = NULL;

So, at the top of sh_mmcif_irqt, if host->wait_for ==
MMCIF_WAIT_FOR_REQUEST,
host->mrq = NULL.
It is too earlier to access mrq->data before checking host->mrq. it may
cause null pointer access.

Goda-san, could you check this and refine the code of sh_mmcif_irqt?


Thanks for your report and a fix. Could you please double-check, whether
the below patch also fixes your problem? Since such spurious interrupts
are possible I would commit a check like this one, but in the longer run
we want to identify and eliminate them, if possible. But since so far
these interrupts only happen on 1 board model and also not on all units
and not upon each boot, this could be a bit tricky.

One more question - is this only needed for 3.7 or also for 3.6 / stable?

Thanks
Guennadi

  drivers/mmc/host/sh_mmcif.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 5d81427..82bf921 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -1104,7 +1104,6 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
*dev_id)
  {
  struct sh_mmcif_host *host = dev_id;
  struct mmc_request *mrq = host->mrq;
-struct mmc_data *data = mrq->data;

  cancel_delayed_work_sync(&host->timeout_work);

@@ -1152,13 +1151,14 @@ static irqreturn_t sh_mmcif_irqt(int irq, void
*dev_id)
  case MMCIF_WAIT_FOR_READ_END:
  case MMCIF_WAIT_FOR_WRITE_END:
  if (host->sd_error)
-data->error = sh_mmcif_error_manage(host);
+mrq->data->error = sh_mmcif_error_manage(host);
  break;
  default:
  BUG();
  }

  if (host->wait_for != MMCIF_WAIT_FOR_STOP) {
+struct mmc_data *data = mrq->data;
  if (!mrq->cmd->error && data && !data->error)
  data->bytes_xfered =
  data->blocks * data->blksz;



I tried this patch. It seems better.
But I think this still have potential race condition.
I am afraid that one cpu enter sh_mmcif_irqt and other cpu write to
host->wait_for for new request at the same time.
How about add this code at the top of sh_mmcif_irqt or before returning
IRQ_WAKE_THREAD in sh_mmcif_intr ?

 if (host->state == STATE_IDLE)
 return IRQ_HANDLED;

I will rebase my test environment to v3.6-rc3 or later. Then I will
send you my .config.


How is this?
I hope this fixed in v3.6.



--
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/3] powerpc/esdhc: add property to disable the CMD23

[Chris Ball]

Hi,

On Tue, Sep 18 2012, Kumar Gala wrote:
 I've got a mild preference for handling quirk assignment in the DT
 rather than in driver code, so I'd prefer to just push the original
 patch to mmc-next as-is.  Does that sound okay?
>>> 
>>> Why?  I only ask because I agree with Scott that this means you have to
>>> update your device tree to get proper functionality.
>>> 
>> When the new silicon does not support CMD23,
>> if we don't update the device tree, then we must update the SDHC driver.
>> I prefer to add the property in device tree,
>> because we just add this property in new device tree, we don't need more 
>> effort to modify driver.
>
> Jerry,
>
> I think doing it driver makes more sense because:
>
> 1. means older device tree's still work
> 2. odds that CMD23 not being supported in future devices is near 0%
>(Now that we support AutoCMD23 [and thus CMD23] we aren't likely to stop 
> supporting it in future)
> 3. If IP changes you are going to have to update driver anyways for new 
> features
>
> I really think we should NOT utilize device tree for this.

Of course, we could also make both (or perhaps neither) of you happy by
merging both:  if your DT says you don't support cmd23 *or* you hit the
driver's blacklist, we avoid it.

- 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 2/3] powerpc/esdhc: add property to disable the CMD23

[Kumar Gala]

On Sep 17, 2012, at 8:09 PM, Huang Changming-R66093 wrote:

>> On Sep 17, 2012, at 7:36 AM, Chris Ball wrote:
>> 
>>> Hi,
>>> 
>>> On Thu, Sep 13 2012, Kumar Gala wrote:
>> Can you list out which SoCs support it and which don't.  Having
>> this list will be useful in understanding which controller versions
>> supported it.
>> 
> P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
> Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041)
>> support it.
 
 Based on this, why don't we use the HOSTVER register to detect instead
>> of device tree:
>>> 
>>> I've got a mild preference for handling quirk assignment in the DT
>>> rather than in driver code, so I'd prefer to just push the original
>>> patch to mmc-next as-is.  Does that sound okay?
>> 
>> Why?  I only ask because I agree with Scott that this means you have to
>> update your device tree to get proper functionality.
>> 
> When the new silicon does not support CMD23,
> if we don't update the device tree, then we must update the SDHC driver.
> I prefer to add the property in device tree,
> because we just add this property in new device tree, we don't need more 
> effort to modify driver.
> 

Jerry,

I think doing it driver makes more sense because:

1. means older device tree's still work
2. odds that CMD23 not being supported in future devices is near 0%
   (Now that we support AutoCMD23 [and thus CMD23] we aren't likely to stop 
supporting it in future)
3. If IP changes you are going to have to update driver anyways for new features

I really think we should NOT utilize device tree for this.

- k



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

[PATCH] mmc: sdhci-s3c: fix the wrong number of max bus clock

[Jaehoon Chung]

We can use the four bus-clock at sdhci-s3c.c
But when removed, didn't check the fourth bus clock.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
---
 drivers/mmc/host/sdhci-s3c.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 0c77b10..f2b76ef 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -788,7 +788,7 @@ static int __devexit sdhci_s3c_remove(struct 
platform_device *pdev)
 
pm_runtime_disable(&pdev->dev);
 
-   for (ptr = 0; ptr < 3; ptr++) {
+   for (ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
if (sc->clk_bus[ptr]) {
clk_disable(sc->clk_bus[ptr]);
clk_put(sc->clk_bus[ptr]);
-- 
1.7.4.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

Re: [PATCH v5] mmc: sdhci-s3c: Add device tree support

[Jaehoon Chung]

On 09/18/2012 12:50 PM, Chris Ball wrote:
> Hi,
> 
> On Mon, Sep 17 2012, Thomas Abraham wrote:
>> On 23 August 2012 22:40, Thomas Abraham  wrote:
>>> Add device tree based discovery support for Samsung's sdhci controller
>>>
>>> Cc: Ben Dooks 
>>> Cc: Kukjin Kim 
>>> Cc: Chris Ball 
>>> Signed-off-by: Thomas Abraham 
>>> ---
>>> Changes since v4:
>>> Adapted to new mmc core card detection bindings as specfied in the patch:
>>> [PATCH] mmc: dt: Add card-detection properties to core binding
>>> and extends it "samsung,cd-pinmux-gpio" property as suggested by
>>> Mitch Bradley 
>>>
>>> Changes since v3:
>>>
>>> The patch series that adds device tree support for Samsung sdhci controller
>>> had six patches in total, of which, the first five patches have been 
>>> accepted.
>>> The sixth patch in the series was dropped since it was using custom Samsung
>>> properties for descrbing the bus-width and card-detect gpio, but had 
>>> otherwise
>>> addressed all the comments.
>>>
>>> This patch reworks the sixth patch in v3 of the sdhci device tree support
>>> patch series. The only change in this patch from the v3 version is the use 
>>> of
>>> generic mmc bindings for descrbing the bus-width and card-detect gpio.
>>>
>>>  .../devicetree/bindings/mmc/samsung-sdhci.txt  |   53 +++
>>>  drivers/mmc/host/sdhci-s3c.c   |  162 
>>> +++-
>>>  2 files changed, 209 insertions(+), 6 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>>
>> Hi Chris,
>>
>> This patch adds device tree support for sdhci-s3c driver. All the
>> comments for this patch has been addressed. Can this be queued for
>> v3.7?
> 
> Yes, sounds good.  Jaehoon, perhaps you could give your Reviewed-by
> for me to add to the patch?  I've pushed this to mmc-next for 3.7
> now, after adding Jaehoon's else-if suggestion that wasn't acted on:
Right, I suggested them. thanks Chris. Looks good to me this patch except for 
them.

Reviewed-by: Jaehoon Chung 
> 
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 3d91c7a..0c77b10 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -461,22 +461,18 @@ static int __devinit sdhci_s3c_parse_dt(struct device 
> *dev,
>   if (gpio_is_valid(gpio)) {
>   pdata->cd_type = S3C_SDHCI_CD_GPIO;
>   goto found_cd;
> - } else {
> - if (gpio != -ENOENT) {
> - dev_err(dev, "invalid card detect gpio specified\n");
> - return -EINVAL;
> - }
> + } else if (gpio != -ENOENT) {
> + dev_err(dev, "invalid card detect gpio specified\n");
> + return -EINVAL;
>   }
>  
>   gpio = of_get_named_gpio(node, "samsung,cd-pinmux-gpio", 0);
>   if (gpio_is_valid(gpio)) {
>   pdata->cd_type = S3C_SDHCI_CD_INTERNAL;
>   goto found_cd;
> - } else {
> - if (gpio != -ENOENT) {
> - dev_err(dev, "invalid card detect gpio specified\n");
> - return -EINVAL;
> - }
> + } else if (gpio != -ENOENT) {
> + dev_err(dev, "invalid card detect gpio specified\n");
> + return -EINVAL;
>   }
>  
>   dev_info(dev, "assuming no card detect line available\n");
> 
> Thanks,
> 
> - Chris.
> 

--
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 v5] mmc: sdhci-s3c: Add device tree support

[Thomas Abraham]

On 18 September 2012 09:20, Chris Ball  wrote:
> Hi,
>
> On Mon, Sep 17 2012, Thomas Abraham wrote:
>> On 23 August 2012 22:40, Thomas Abraham  wrote:
>>> Add device tree based discovery support for Samsung's sdhci controller
>>>
>>> Cc: Ben Dooks 
>>> Cc: Kukjin Kim 
>>> Cc: Chris Ball 
>>> Signed-off-by: Thomas Abraham 
>>> ---
>>> Changes since v4:
>>> Adapted to new mmc core card detection bindings as specfied in the patch:
>>> [PATCH] mmc: dt: Add card-detection properties to core binding
>>> and extends it "samsung,cd-pinmux-gpio" property as suggested by
>>> Mitch Bradley 
>>>
>>> Changes since v3:
>>>
>>> The patch series that adds device tree support for Samsung sdhci controller
>>> had six patches in total, of which, the first five patches have been 
>>> accepted.
>>> The sixth patch in the series was dropped since it was using custom Samsung
>>> properties for descrbing the bus-width and card-detect gpio, but had 
>>> otherwise
>>> addressed all the comments.
>>>
>>> This patch reworks the sixth patch in v3 of the sdhci device tree support
>>> patch series. The only change in this patch from the v3 version is the use 
>>> of
>>> generic mmc bindings for descrbing the bus-width and card-detect gpio.
>>>
>>>  .../devicetree/bindings/mmc/samsung-sdhci.txt  |   53 +++
>>>  drivers/mmc/host/sdhci-s3c.c   |  162 
>>> +++-
>>>  2 files changed, 209 insertions(+), 6 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>>
>> Hi Chris,
>>
>> This patch adds device tree support for sdhci-s3c driver. All the
>> comments for this patch has been addressed. Can this be queued for
>> v3.7?
>
> Yes, sounds good.  Jaehoon, perhaps you could give your Reviewed-by
> for me to add to the patch?  I've pushed this to mmc-next for 3.7
> now, after adding Jaehoon's else-if suggestion that wasn't acted on:
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 3d91c7a..0c77b10 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -461,22 +461,18 @@ static int __devinit sdhci_s3c_parse_dt(struct device 
> *dev,
> if (gpio_is_valid(gpio)) {
> pdata->cd_type = S3C_SDHCI_CD_GPIO;
> goto found_cd;
> -   } else {
> -   if (gpio != -ENOENT) {
> -   dev_err(dev, "invalid card detect gpio specified\n");
> -   return -EINVAL;
> -   }
> +   } else if (gpio != -ENOENT) {
> +   dev_err(dev, "invalid card detect gpio specified\n");
> +   return -EINVAL;
> }
>
> gpio = of_get_named_gpio(node, "samsung,cd-pinmux-gpio", 0);
> if (gpio_is_valid(gpio)) {
> pdata->cd_type = S3C_SDHCI_CD_INTERNAL;
> goto found_cd;
> -   } else {
> -   if (gpio != -ENOENT) {
> -   dev_err(dev, "invalid card detect gpio specified\n");
> -   return -EINVAL;
> -   }
> +   } else if (gpio != -ENOENT) {
> +   dev_err(dev, "invalid card detect gpio specified\n");
> +   return -EINVAL;
> }

Thank you Chris for your modification.

Regards,
Thomas.

>
> dev_info(dev, "assuming no card detect line available\n");
>
> 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 v5] mmc: sdhci-s3c: Add device tree support

[Chris Ball]

Hi,

On Mon, Sep 17 2012, Thomas Abraham wrote:
> On 23 August 2012 22:40, Thomas Abraham  wrote:
>> Add device tree based discovery support for Samsung's sdhci controller
>>
>> Cc: Ben Dooks 
>> Cc: Kukjin Kim 
>> Cc: Chris Ball 
>> Signed-off-by: Thomas Abraham 
>> ---
>> Changes since v4:
>> Adapted to new mmc core card detection bindings as specfied in the patch:
>> [PATCH] mmc: dt: Add card-detection properties to core binding
>> and extends it "samsung,cd-pinmux-gpio" property as suggested by
>> Mitch Bradley 
>>
>> Changes since v3:
>>
>> The patch series that adds device tree support for Samsung sdhci controller
>> had six patches in total, of which, the first five patches have been 
>> accepted.
>> The sixth patch in the series was dropped since it was using custom Samsung
>> properties for descrbing the bus-width and card-detect gpio, but had 
>> otherwise
>> addressed all the comments.
>>
>> This patch reworks the sixth patch in v3 of the sdhci device tree support
>> patch series. The only change in this patch from the v3 version is the use of
>> generic mmc bindings for descrbing the bus-width and card-detect gpio.
>>
>>  .../devicetree/bindings/mmc/samsung-sdhci.txt  |   53 +++
>>  drivers/mmc/host/sdhci-s3c.c   |  162 
>> +++-
>>  2 files changed, 209 insertions(+), 6 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>
> Hi Chris,
>
> This patch adds device tree support for sdhci-s3c driver. All the
> comments for this patch has been addressed. Can this be queued for
> v3.7?

Yes, sounds good.  Jaehoon, perhaps you could give your Reviewed-by
for me to add to the patch?  I've pushed this to mmc-next for 3.7
now, after adding Jaehoon's else-if suggestion that wasn't acted on:

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 3d91c7a..0c77b10 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -461,22 +461,18 @@ static int __devinit sdhci_s3c_parse_dt(struct device 
*dev,
if (gpio_is_valid(gpio)) {
pdata->cd_type = S3C_SDHCI_CD_GPIO;
goto found_cd;
-   } else {
-   if (gpio != -ENOENT) {
-   dev_err(dev, "invalid card detect gpio specified\n");
-   return -EINVAL;
-   }
+   } else if (gpio != -ENOENT) {
+   dev_err(dev, "invalid card detect gpio specified\n");
+   return -EINVAL;
}
 
gpio = of_get_named_gpio(node, "samsung,cd-pinmux-gpio", 0);
if (gpio_is_valid(gpio)) {
pdata->cd_type = S3C_SDHCI_CD_INTERNAL;
goto found_cd;
-   } else {
-   if (gpio != -ENOENT) {
-   dev_err(dev, "invalid card detect gpio specified\n");
-   return -EINVAL;
-   }
+   } else if (gpio != -ENOENT) {
+   dev_err(dev, "invalid card detect gpio specified\n");
+   return -EINVAL;
}
 
dev_info(dev, "assuming no card detect line available\n");

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 v6 0/9] mmc: dw_mmc: add support for device tree based instantiation

[Thomas Abraham]

On 17 September 2012 23:46, Thomas Abraham  wrote:
> This series add device tree support for Synopsis Designware IP - Mobile 
> Storage
> Host Controller (MSHC). I had addressed all comments for the v5 version of 
> this
> patch series and had reposted only those patches that were modified. The 
> version
> number of those reposted patches was maintained as v5 as the changes did not
> need any major rework.
>
> This is mainly a repost of the v5 patches with all patches marked as v6. The
> only new change in this series is adding a comment about bus_hz in platform
> data structure of the driver as suggested by Seungwon Jeon.
>
> Thomas Abraham (9):
>   mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference
>   mmc: dw_mmc: Use devm_* functions in dw_mmc platform driver
>   mmc: dw_mmc: allow probe to succeed even if one slot is initialized
>   mmc: dw_mmc: lookup for optional biu and ciu clocks
>   mmc: dw_mmc: add quirk to indicate missing write protect line
>   mmc: dw_mmc: add device tree support
>   mmc: dw_mmc: prepare functions in dw_mmc-pltfm for reuse
>   mmc: dw_mmc: add support for implementation specific callbacks
>   mmc: dw_mmc: add support for exynos specific implementation of dw-mshc
>
>  .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   87 ++
>  .../devicetree/bindings/mmc/synposis-dw-mshc.txt   |   79 +
>  drivers/mmc/host/Kconfig   |9 +
>  drivers/mmc/host/Makefile  |1 +
>  drivers/mmc/host/dw_mmc-exynos.c   |  253 
>  drivers/mmc/host/dw_mmc-pci.c  |2 +-
>  drivers/mmc/host/dw_mmc-pltfm.c|   60 +++--
>  drivers/mmc/host/dw_mmc-pltfm.h|   20 ++
>  drivers/mmc/host/dw_mmc.c  |  308 
> +---
>  drivers/mmc/host/dw_mmc.h  |   24 ++
>  include/linux/mmc/dw_mmc.h |   15 +-
>  11 files changed, 782 insertions(+), 76 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
>  create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
>  create mode 100644 drivers/mmc/host/dw_mmc-exynos.c
>  create mode 100644 drivers/mmc/host/dw_mmc-pltfm.h

Hi Jaehoon, Seungwon,

All the changes you have suggested for this patch series has been
completed. If you could ack this series, it would be great.

Thanks,
Thomas.
--
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 v5] mmc: sdhci-s3c: Add device tree support

[Thomas Abraham]

On 23 August 2012 22:40, Thomas Abraham  wrote:
> Add device tree based discovery support for Samsung's sdhci controller
>
> Cc: Ben Dooks 
> Cc: Kukjin Kim 
> Cc: Chris Ball 
> Signed-off-by: Thomas Abraham 
> ---
> Changes since v4:
> Adapted to new mmc core card detection bindings as specfied in the patch:
> [PATCH] mmc: dt: Add card-detection properties to core binding
> and extends it "samsung,cd-pinmux-gpio" property as suggested by
> Mitch Bradley 
>
> Changes since v3:
>
> The patch series that adds device tree support for Samsung sdhci controller
> had six patches in total, of which, the first five patches have been accepted.
> The sixth patch in the series was dropped since it was using custom Samsung
> properties for descrbing the bus-width and card-detect gpio, but had otherwise
> addressed all the comments.
>
> This patch reworks the sixth patch in v3 of the sdhci device tree support
> patch series. The only change in this patch from the v3 version is the use of
> generic mmc bindings for descrbing the bus-width and card-detect gpio.
>
>  .../devicetree/bindings/mmc/samsung-sdhci.txt  |   53 +++
>  drivers/mmc/host/sdhci-s3c.c   |  162 
> +++-
>  2 files changed, 209 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt

Hi Chris,

This patch adds device tree support for sdhci-s3c driver. All the
comments for this patch has been addressed. Can this be queued for
v3.7?

Thanks,
Thomas.


>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt 
> b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> new file mode 100644
> index 000..361c2ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> @@ -0,0 +1,53 @@
> +* Samsung's SDHCI Controller device tree bindings
> +
> +Samsung's SDHCI controller is used as a connectivity interface with external
> +MMC, SD and eMMC storage mediums. This file documents differences between the
> +core mmc properties described by mmc.txt and the properties used by the
> +Samsung implmentation of the SDHCI controller.
> +
> +Note: The mmc core bindings documentation states that if none of the core
> +card-detect bindings are used, then the standard sdhci card detect mechanism
> +is used. The Samsung's SDHCI controller bindings extends this as listed 
> below.
> +
> +[A] The property "samsung,cd-pinmux-gpio" can be used as stated in the
> +"Optional Board Specific Properties" section below.
> +
> +[B] If core card-detect bindings and "samsung,cd-pinmux-gpio" property
> +is not specified, it is assumed that there is no card detection
> +mechanism used.
> +
> +Required SoC Specific Properties:
> +- compatible: should be one of the following
> +  - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
> +controller.
> +  - "samsung,exynos4210-sdhci": For controllers compatible with Exynos4 sdhci
> +controller.
> +
> +Required Board Specific Properties:
> +- gpios: Should specify the gpios used for clock, command and data lines. The
> +  gpio specifier format depends on the gpio controller.
> +
> +Optional Board Specific Properties:
> +- samsung,cd-pinmux-gpio: Specifies the card detect line that is routed
> +  through a pinmux to the card-detect pin of the card slot. This property
> +  should be used only if none of the mmc core card-detect properties are
> +  used.
> +
> +Example:
> +   sdhci@1253 {
> +   compatible = "samsung,exynos4210-sdhci";
> +   reg = <0x1253 0x100>;
> +   interrupts = <0 75 0>;
> +   bus-width = <4>;
> +   cd-gpios = <&gpk2 2 2 3 3>;
> +   gpios = <&gpk2 0 2 0 3>,  /* clock line */
> +   <&gpk2 1 2 0 3>,  /* command line */
> +   <&gpk2 3 2 3 3>,  /* data line 0 */
> +   <&gpk2 4 2 3 3>,  /* data line 1 */
> +   <&gpk2 5 2 3 3>,  /* data line 2 */
> +   <&gpk2 6 2 3 3>;  /* data line 3 */
> +   };
> +
> +   Note: This example shows both SoC specific and board specific 
> properties
> +   in a single device node. The properties can be actually be seperated
> +   into SoC specific node and board specific node.
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index a50c205..445910e 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -34,6 +34,9 @@
>
>  #define MAX_BUS_CLK(4)
>
> +/* Number of gpio's used is max data bus width + command and clock lines */
> +#define NUM_GPIOS(x)   (x + 2)
> +
>  /**
>   * struct sdhci_s3c - S3C SDHCI instance
>   * @host: The SDHCI host created
> @@ -41,6 +44,7 @@
>   * @ioarea: The resource created when we claimed the IO area.
>   * @pdata: The platform data for this controller.
>   * @cur_clk: The index of the current bus clock.
> + * @gpios: List of gpio numbers pars

RE: [PATCH 2/3] powerpc/esdhc: add property to disable the CMD23

[Huang Changming-R66093]

> On Sep 17, 2012, at 7:36 AM, Chris Ball wrote:
> 
> > Hi,
> >
> > On Thu, Sep 13 2012, Kumar Gala wrote:
>  Can you list out which SoCs support it and which don't.  Having
>  this list will be useful in understanding which controller versions
> supported it.
> 
> >>> P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
> >>> Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041)
> support it.
> >>
> >> Based on this, why don't we use the HOSTVER register to detect instead
> of device tree:
> >
> > I've got a mild preference for handling quirk assignment in the DT
> > rather than in driver code, so I'd prefer to just push the original
> > patch to mmc-next as-is.  Does that sound okay?
> 
> Why?  I only ask because I agree with Scott that this means you have to
> update your device tree to get proper functionality.
> 
When the new silicon does not support CMD23,
if we don't update the device tree, then we must update the SDHC driver.
I prefer to add the property in device tree,
because we just add this property in new device tree, we don't need more effort 
to modify driver.


--
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: [RESEND PATCH v12] mmc: support BKOPS feature for eMMC

[Jaehoon Chung]

On 09/17/2012 09:21 PM, Chris Ball wrote:
> Hi Jaehoon,
> 
> On Mon, Sep 17 2012, Jaehoon Chung wrote:
>> Enable eMMC background operations (BKOPS) feature.
>>
>> If URGENT_BKOPS is set after a response, note that BKOPS
>> are required. Immediately run BKOPS if required.
>> read/write operations should be requested during BKOPS(LEVEL-1),
>> then issue HPI to interrupt the ongoing BKOPS 
>> and service the foreground operation.
>> (This patch is only control the LEVEL2/3.)
>>
>> When repeating the writing 1GB data, at a certain time, performance is 
>> decreased.
>> At that time, card is also triggered the Level-3 or Level-2.
>> After running bkops, performance is recovered.
>>
>> Future considerations
>>  * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
>>  * Interrupt ongoing BKOPS before powering off the card.
>>  * How get BKOPS_STATUS value.(periodically send ext_csd command?)
>>  * If use periodic bkops, also consider runtime_pm control.
>>
>> Signed-off-by: Jaehoon Chung 
>> Signed-off-by: Kyungmin Park 
>> Signed-off-by: Konstantin Dorfman 
>> Reviewed-by: Maya Erez 
> 
> Thanks, looks good now.  Is it okay if I apply this stylistic patch
> before pushing to mmc-next?
Sure, Thanks Chris.

Best Regards,
Jaehoon Chung
> 
> 
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 4749557..044cd01 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -43,8 +43,8 @@
>  #include "sdio_ops.h"
>  
>  /*
> - * The Background operation can take a long time, depends on the house 
> keeping
> - * operations the card has to peform
> + * Background operations can take a long time, depending on the housekeeping
> + * operations the card has to perform.
>   */
>  #define MMC_BKOPS_MAX_TIMEOUT(4 * 60 * 1000) /* max time to wait in 
> ms */
>  
> @@ -255,11 +255,11 @@ mmc_start_request(struct mmc_host *host, struct 
> mmc_request *mrq)
>  /**
>   *   mmc_start_bkops - start BKOPS for supported cards
>   *   @card: MMC card to start BKOPS
> - *   @form_exception: A flags to indicate if this function was
> - *   called due to an exception raised by the card
> + *   @form_exception: A flag to indicate if this function was
> + *called due to an exception raised by the card
>   *
>   *   Start background operations whenever requested.
> - *   when the urgent BKOPS bit is set in a R1 command response
> + *   When the urgent BKOPS bit is set in a R1 command response
>   *   then background operations should be started immediately.
>  */
>  void mmc_start_bkops(struct mmc_card *card, bool from_exception)
> @@ -275,7 +275,7 @@ void mmc_start_bkops(struct mmc_card *card, bool 
> from_exception)
>  
>   err = mmc_read_bkops_status(card);
>   if (err) {
> - pr_err("%s: Didn't read bkops status : %d\n",
> + pr_err("%s: Failed to read bkops status: %d\n",
>  mmc_hostname(card->host), err);
>   return;
>   }
> @@ -283,8 +283,8 @@ void mmc_start_bkops(struct mmc_card *card, bool 
> from_exception)
>   if (!card->ext_csd.raw_bkops_status)
>   return;
>  
> - if (card->ext_csd.raw_bkops_status < EXT_CSD_BKOPS_LEVEL_2
> - && (from_exception))
> + if (card->ext_csd.raw_bkops_status < EXT_CSD_BKOPS_LEVEL_2 &&
> + from_exception)
>   return;
>  
>   mmc_claim_host(card->host);
> @@ -299,8 +299,8 @@ void mmc_start_bkops(struct mmc_card *card, bool 
> from_exception)
>   err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
>   EXT_CSD_BKOPS_START, 1, timeout, use_busy_signal);
>   if (err) {
> - pr_warn("%s: error %d starting bkops\n",
> -mmc_hostname(card->host), err);
> + pr_warn("%s: Error %d starting bkops\n",
> + mmc_hostname(card->host), err);
>   goto out;
>   }
>  
> @@ -429,9 +429,9 @@ struct mmc_async_req *mmc_start_req(struct mmc_host *host,
>* Check BKOPS urgency for each R1 response
>*/
>   if (host->card && mmc_card_mmc(host->card) &&
> - ((mmc_resp_type(host->areq->mrq->cmd) == MMC_RSP_R1) ||
> -  (mmc_resp_type(host->areq->mrq->cmd) == MMC_RSP_R1B)) &&
> - (host->areq->mrq->cmd->resp[0] & R1_EXCEPTION_EVENT))
> + ((mmc_resp_type(host->areq->mrq->cmd) == MMC_RSP_R1) ||
> +  (mmc_resp_type(host->areq->mrq->cmd) == MMC_RSP_R1B)) &&
> + (host->areq->mrq->cmd->resp[0] & R1_EXCEPTION_EVENT))
>   mmc_start_bkops(host->card, true);
>   }
>  
> @@ -477,7 +477,7 @@ EXPORT_SYMBOL(mmc_wait_for_req);
>   *   @card: the MMC card associated with the HPI transfer
>   *
>   *   Issued High Priority Interrupt, and check for card status
> - *   util out-of prg-state.
> + *   until out-of prg-state.
>   */
>  int mmc_interrupt_hpi(struct mmc_card *card)
>  {
> @@ -572,8 +57

Re: [PATCH V2] mmc: omap_hsmmc: Pass on the suspend failure to the PM core

[S, Venkatraman]

On Thu, Sep 13, 2012 at 12:01 PM, Hebbar, Gururaja
 wrote:
> From: Vaibhav Bedia 
>
> In some cases mmc_suspend_host() is not able to claim the
> host and proceed with the suspend process. The core returns
> -EBUSY to the host controller driver. Unfortunately, the
> host controller driver does not pass on this information
> to the PM core and hence the system suspend process continues.
>
> ret = mmc_suspend_host(host->mmc);
> if (ret) {
> host->suspended = 0;
> if (host->pdata->resume) {
> ret = host->pdata->resume(dev, host->slot_id);
>
> The return status from mmc_suspend_host() is overwritten by return
> status from host->pdata->resume. So the original return status is lost.
>
> In these cases the MMC core gets to an unexpected state
> during resume and multiple issues related to MMC crop up.
> 1. Host controller driver starts accessing the device registers
> before the clocks are enabled which leads to a prefetch abort.
> 2. A file copy thread which was launched before suspend gets
> stuck due to the host not being reclaimed during resume.
>
> To avoid such problems pass on the -EBUSY status to the PM core
> from the host controller driver. With this change, MMC core
> suspend might still fail but it does not end up making the
> system unusable. Suspend gets aborted and the user can try
> suspending the system again.
>
> Signed-off-by: Vaibhav Bedia 
> Signed-off-by: Hebbar, Gururaja 
This version is good.

Acked-by: Venkatraman S 

> ---
> Changes from V1:
> - Instead of forcibly returning -EBUSY on err, retain old
> status and pass on the same to the caller.
> - add more detail to commit message (explanation with code
> snippet)
>
> :100644 100644 9afdd20... d9af5f1... M  drivers/mmc/host/omap_hsmmc.c
>  drivers/mmc/host/omap_hsmmc.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 9afdd20..d9af5f1 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2050,8 +2050,7 @@ static int omap_hsmmc_suspend(struct device *dev)
> if (ret) {
> host->suspended = 0;
> if (host->pdata->resume) {
> -   ret = host->pdata->resume(dev, host->slot_id);
> -   if (ret)
> +   if (host->pdata->resume(dev, host->slot_id))
> dev_dbg(dev, "Unmask interrupt failed\n");
> }
> goto err;
> --
> 1.7.0.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] drivers/mmc/host/omap_hsmmc.c: fix error return code

[S, Venkatraman]

On Mon, Sep 17, 2012 at 1:45 PM, Peter Senna Tschudin
 wrote:
> From: Peter Senna Tschudin 
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> // 
>
> Signed-off-by: Peter Senna Tschudin 

Looks good.
Acked-by: Venkatraman S 
--
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 v6 9/9] mmc: dw_mmc: add support for exynos specific implementation of dw-mshc

[Thomas Abraham]

From: Thomas Abraham 

Samsung Exynos SoC's extend the dw-mshc controller for additional clock and bus
control. Add support for these extensions and include provide device tree based
discovery suppory as well.

Signed-off-by: Thomas Abraham 
Acked-by: Will Newton 
---
 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   87 +++
 drivers/mmc/host/Kconfig   |9 +
 drivers/mmc/host/Makefile  |1 +
 drivers/mmc/host/dw_mmc-exynos.c   |  253 
 include/linux/mmc/dw_mmc.h |2 +-
 5 files changed, 351 insertions(+), 1 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 create mode 100644 drivers/mmc/host/dw_mmc-exynos.c

diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
new file mode 100644
index 000..7927689
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -0,0 +1,87 @@
+* Samsung Exynos specific extensions to the Synopsis Designware Mobile
+  Storage Host Controller
+
+The Synopsis designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsis dw mshc controller properties described
+by synposis-dw-mshc.txt and the properties used by the Samsung Exynos specific
+extensions to the Synopsis Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be
+   - "samsung,exynos4210-dw-mshc": for controllers with Samsung Exynos4210
+ specific extentions.
+   - "samsung,exynos4412-dw-mshc": for controllers with Samsung Exynos4412
+ specific extentions.
+   - "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250
+ specific extentions.
+
+* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
+  unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
+  ignored for Exynos4 SoC's. The valid range of divider value is 0 to 7.
+
+* samsung,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift 
value
+  in transmit mode and CIU clock phase shift value in receive mode for single
+  data rate mode operation. Refer notes below for the order of the cells and 
the
+  valid values.
+
+* samsung,dw-mshc-ddr-timing: Specifies the value of CUI clock phase shift 
value
+  in transmit mode and CIU clock phase shift value in receive mode for double
+  data rate mode operation. Refer notes below for the order of the cells and 
the
+  valid values.
+
+  Notes for the sdr-timing and ddr-timing values:
+
+The order of the cells should be
+  - First Cell: CIU clock phase shift value for tx mode.
+  - Second Cell: CIU clock phase shift value for rx mode.
+
+Valid values for SDR and DDR CIU clock timing for Exynos5250:
+  - valid value for tx phase shift and rx phase shift is 0 to 7.
+  - when CIU clock divider value is set to 3, all possible 8 phase shift
+values can be used.
+  - if CIU clock divider value is 0 (that is divide by 1), both tx and rx
+phase shift clocks should be 0.
+
+Required properties for a slot:
+
+* gpios: specifies a list of gpios used for command, clock and data bus. The
+  first gpio is the command line and the second gpio is the clock line. The
+  rest of the gpios (depending on the bus-width property) are the data lines in
+  no particular order. The format of the gpio specifier depends on the gpio
+  controller.
+
+Example:
+
+  The MSHC controller node can be split into two portions, SoC specific and
+  board specific portions as listed below.
+
+   dwmmc0@1220 {
+   compatible = "samsung,exynos5250-dw-mshc";
+   reg = <0x1220 0x1000>;
+   interrupts = <0 75 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   dwmmc0@1220 {
+   num-slots = <1>;
+   supports-highspeed;
+   broken-cd;
+   fifo-depth = <0x80>;
+   card-detect-delay = <200>;
+   samsung,dw-mshc-ciu-div = <3>;
+   samsung,dw-mshc-sdr-timing = <2 3>;
+   samsung,dw-mshc-ddr-timing = <1 2>;
+
+   slot@0 {
+   reg = <0>;
+   bus-width = <8>;
+   gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>,
+   <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>,
+   <&gpc1 2 2 3 3>, <&gpc1 3 2 3 3>,
+   <&gpc0 3 2 3 3>, <&gpc0 4 2 3 3>,
+   <&gpc0 5 2 3 3>, <&gpc0 6 2 3 3>;
+   };
+   };
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index d588a27..dee73c0 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -540,

[PATCH v6 8/9] mmc: dw_mmc: add support for implementation specific callbacks

[Thomas Abraham]

The core dw-mshc controller driver can let platform specific implementations
of the dw-mshc controller to control the hardware as required by such
implementations. This is acheived by invoking implementation specific (optional)
callbacks. Define the list of callbacks supported the add invocation points
for the same.

Signed-off-by: Thomas Abraham 
Acked-by: Will Newton 
---
 drivers/mmc/host/dw_mmc-pltfm.c |   12 -
 drivers/mmc/host/dw_mmc-pltfm.h |3 +-
 drivers/mmc/host/dw_mmc.c   |   47 ++-
 drivers/mmc/host/dw_mmc.h   |   24 
 include/linux/mmc/dw_mmc.h  |4 +++
 5 files changed, 86 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index e17da91..c960ca7 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -23,7 +23,8 @@
 
 #include "dw_mmc.h"
 
-int dw_mci_pltfm_register(struct platform_device *pdev)
+int dw_mci_pltfm_register(struct platform_device *pdev,
+   struct dw_mci_drv_data *drv_data)
 {
struct dw_mci *host;
struct resource *regs;
@@ -41,6 +42,7 @@ int dw_mci_pltfm_register(struct platform_device *pdev)
if (host->irq < 0)
return host->irq;
 
+   host->drv_data = drv_data;
host->dev = &pdev->dev;
host->irq_flags = 0;
host->pdata = pdev->dev.platform_data;
@@ -48,6 +50,12 @@ int dw_mci_pltfm_register(struct platform_device *pdev)
if (!host->regs)
return -ENOMEM;
 
+   if (host->drv_data->init) {
+   ret = host->drv_data->init(host);
+   if (ret)
+   return ret;
+   }
+
platform_set_drvdata(pdev, host);
ret = dw_mci_probe(host);
return ret;
@@ -56,7 +64,7 @@ EXPORT_SYMBOL_GPL(dw_mci_pltfm_register);
 
 static int __devinit dw_mci_pltfm_probe(struct platform_device *pdev)
 {
-   return dw_mci_pltfm_register(pdev);
+   return dw_mci_pltfm_register(pdev, NULL);
 }
 
 static int __devexit dw_mci_pltfm_remove(struct platform_device *pdev)
diff --git a/drivers/mmc/host/dw_mmc-pltfm.h b/drivers/mmc/host/dw_mmc-pltfm.h
index 6c065d9..301f245 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.h
+++ b/drivers/mmc/host/dw_mmc-pltfm.h
@@ -12,7 +12,8 @@
 #ifndef _DW_MMC_PLTFM_H_
 #define _DW_MMC_PLTFM_H_
 
-extern int dw_mci_pltfm_register(struct platform_device *pdev);
+extern int dw_mci_pltfm_register(struct platform_device *pdev,
+   struct dw_mci_drv_data *drv_data);
 extern int __devexit dw_mci_pltfm_remove(struct platform_device *pdev);
 extern const struct dev_pm_ops dw_mci_pltfm_pmops;
 
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index c792466..9f8e487 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -231,6 +231,7 @@ static void dw_mci_set_timeout(struct dw_mci *host)
 static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command 
*cmd)
 {
struct mmc_data *data;
+   struct dw_mci_slot *slot = mmc_priv(mmc);
u32 cmdr;
cmd->error = -EINPROGRESS;
 
@@ -260,6 +261,9 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc, 
struct mmc_command *cmd)
cmdr |= SDMMC_CMD_DAT_WR;
}
 
+   if (slot->host->drv_data->prepare_command)
+   slot->host->drv_data->prepare_command(slot->host, &cmdr);
+
return cmdr;
 }
 
@@ -815,6 +819,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
slot->clock = ios->clock;
}
 
+   if (slot->host->drv_data->set_ios)
+   slot->host->drv_data->set_ios(slot->host, ios);
+
switch (ios->power_mode) {
case MMC_POWER_UP:
set_bit(DW_MMC_CARD_NEED_INIT, &slot->flags);
@@ -1820,6 +1827,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned 
int id)
 {
struct mmc_host *mmc;
struct dw_mci_slot *slot;
+   int ctrl_id, ret;
u8 bus_width;
 
mmc = mmc_alloc_host(sizeof(struct dw_mci_slot), host->dev);
@@ -1851,6 +1859,16 @@ static int dw_mci_init_slot(struct dw_mci *host, 
unsigned int id)
if (host->pdata->caps)
mmc->caps = host->pdata->caps;
 
+   if (host->dev->of_node) {
+   ctrl_id = of_alias_get_id(host->dev->of_node, "mshc");
+   if (ctrl_id < 0)
+   ctrl_id = 0;
+   } else {
+   ctrl_id = to_platform_device(host->dev)->id;
+   }
+   if (host->drv_data && host->drv_data->caps)
+   mmc->caps |= host->drv_data->caps[ctrl_id];
+
if (host->pdata->caps2)
mmc->caps2 = host->pdata->caps2;
 
@@ -1861,6 +1879,14 @@ static int dw_mci_init_slot(struct dw_mci *host, 
unsigned int id)
else
bus_width = 1;
 
+   if (host->drv_data->setup_bus) {
+   struct device_nod

[PATCH v6 7/9] mmc: dw_mmc: prepare functions in dw_mmc-pltfm for reuse

[Thomas Abraham]

Platform implementations of dw-mshc controller may choose to exterd the features
of the standard dw-mshc controller such as adding additional clocking options or
modifying the bus interface. Support for such implementation specific extensions
can be incorporated into dw_mmc-pltfm, but including multiple such platform
specific implementations would convolute the existing dw_mmc-pltfm code.

Instead, it would be better to create implementation specific platform drivers
to support implementation specific features. Such platforms drivers can reuse
the existing infrastructure in dw_mmc-pltfm for resource identification and
controller registration and provide support for implementation specific
features. So, allow the infrastructure in dw_mmc-pltfm to be reused by other
implementation specific platform drivers.

Signed-off-by: Thomas Abraham 
Acked-by: Will Newton 
---
 drivers/mmc/host/dw_mmc-pltfm.c |   12 ++--
 drivers/mmc/host/dw_mmc-pltfm.h |   19 +++
 2 files changed, 29 insertions(+), 2 deletions(-)
 create mode 100644 drivers/mmc/host/dw_mmc-pltfm.h

diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 7205905..e17da91 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -23,7 +23,7 @@
 
 #include "dw_mmc.h"
 
-static int __devinit dw_mci_pltfm_probe(struct platform_device *pdev)
+int dw_mci_pltfm_register(struct platform_device *pdev)
 {
struct dw_mci *host;
struct resource *regs;
@@ -52,6 +52,12 @@ static int __devinit dw_mci_pltfm_probe(struct 
platform_device *pdev)
ret = dw_mci_probe(host);
return ret;
 }
+EXPORT_SYMBOL_GPL(dw_mci_pltfm_register);
+
+static int __devinit dw_mci_pltfm_probe(struct platform_device *pdev)
+{
+   return dw_mci_pltfm_register(pdev);
+}
 
 static int __devexit dw_mci_pltfm_remove(struct platform_device *pdev)
 {
@@ -61,6 +67,7 @@ static int __devexit dw_mci_pltfm_remove(struct 
platform_device *pdev)
dw_mci_remove(host);
return 0;
 }
+EXPORT_SYMBOL_GPL(dw_mci_pltfm_remove);
 
 #ifdef CONFIG_PM_SLEEP
 /*
@@ -94,7 +101,8 @@ static int dw_mci_pltfm_resume(struct device *dev)
 #define dw_mci_pltfm_resumeNULL
 #endif /* CONFIG_PM_SLEEP */
 
-static SIMPLE_DEV_PM_OPS(dw_mci_pltfm_pmops, dw_mci_pltfm_suspend, 
dw_mci_pltfm_resume);
+SIMPLE_DEV_PM_OPS(dw_mci_pltfm_pmops, dw_mci_pltfm_suspend, 
dw_mci_pltfm_resume);
+EXPORT_SYMBOL_GPL(dw_mci_pltfm_pmops);
 
 static const struct of_device_id dw_mci_pltfm_match[] = {
{ .compatible = "snps,dw-mshc", },
diff --git a/drivers/mmc/host/dw_mmc-pltfm.h b/drivers/mmc/host/dw_mmc-pltfm.h
new file mode 100644
index 000..6c065d9
--- /dev/null
+++ b/drivers/mmc/host/dw_mmc-pltfm.h
@@ -0,0 +1,19 @@
+/*
+ * Synopsys DesignWare Multimedia Card Interface Platform driver
+ *
+ * Copyright (C) 2012, Samsung Electronics Co., Ltd.
+ *
+ * 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 _DW_MMC_PLTFM_H_
+#define _DW_MMC_PLTFM_H_
+
+extern int dw_mci_pltfm_register(struct platform_device *pdev);
+extern int __devexit dw_mci_pltfm_remove(struct platform_device *pdev);
+extern const struct dev_pm_ops dw_mci_pltfm_pmops;
+
+#endif /* _DW_MMC_PLTFM_H_ */
-- 
1.6.6.rc2

--
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 v6 6/9] mmc: dw_mmc: add device tree support

[Thomas Abraham]

Add device tree based discovery support.

Signed-off-by: Thomas Abraham 
Acked-by: Will Newton 
---
 .../devicetree/bindings/mmc/synposis-dw-mshc.txt   |   79 
 drivers/mmc/host/dw_mmc-pltfm.c|9 ++
 drivers/mmc/host/dw_mmc.c  |  130 ++-
 3 files changed, 211 insertions(+), 7 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt

diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt 
b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
new file mode 100644
index 000..06cd32d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
@@ -0,0 +1,79 @@
+* Synopsis Designware Mobile Storage Host Controller
+
+The Synopsis designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core mmc properties described by mmc.txt and the
+properties used by the Synopsis Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be
+   - snps,dw-mshc: for controllers compliant with synopsis dw-mshc.
+* #address-cells: should be 1.
+* #size-cells: should be 0.
+
+# Slots: The slot specific information are contained within child-nodes with
+  each child-node representing a supported slot. There should be atleast one
+  child node representing a card slot. The name of the child node representing
+  the slot is recommended to be slot@n where n is the unique number of the slot
+  connnected to the controller. The following are optional properties which
+  can be included in the slot child node.
+
+   * reg: specifies the physical slot number. The valid values of this
+ property is 0 to (num-slots -1), where num-slots is the value
+ specified by the num-slots property.
+
+   * bus-width: as documented in mmc core bindings.
+
+   * wp-gpios: specifies the write protect gpio line. The format of the
+ gpio specifier depends on the gpio controller. If the write-protect
+ line is not available, this property is optional.
+
+Optional properties:
+
+* num-slots: specifies the number of slots supported by the controller.
+  The number of physical slots actually used could be equal or less than the
+  value specified by num-slots. If this property is not specified, the value
+  of num-slot property is assumed to be 1.
+
+* fifo-depth: The maximum size of the tx/rx fifo's. If this property is not
+  specified, the default value of the fifo size is determined from the
+  controller registers.
+
+* card-detect-delay: Delay in milli-seconds before detecting card after card
+  insert event. The default value is 0.
+
+* supports-highspeed: Enables support for high speed cards (upto 50MHz)
+
+* broken-cd: as documented in mmc core bindings.
+
+Aliases:
+
+- All the MSHC controller nodes should be represented in the aliases node using
+  the following format 'mshc{n}' where n is a unique number for the alias.
+
+Example:
+
+The MSHC controller node can be split into two portions, SoC specific and
+board specific portions as listed below.
+
+   dwmmc0@1220 {
+   compatible = "snps,dw-mshc";
+   reg = <0x1220 0x1000>;
+   interrupts = <0 75 0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   dwmmc0@1220 {
+   num-slots = <1>;
+   supports-highspeed;
+   broken-cd;
+   fifo-depth = <0x80>;
+   card-detect-delay = <200>;
+
+   slot@0 {
+   reg = <0>;
+   bus-width = <8>;
+   };
+   };
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index ce7be1a..7205905 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include "dw_mmc.h"
 
 static int __devinit dw_mci_pltfm_probe(struct platform_device *pdev)
@@ -94,10 +96,17 @@ static int dw_mci_pltfm_resume(struct device *dev)
 
 static SIMPLE_DEV_PM_OPS(dw_mci_pltfm_pmops, dw_mci_pltfm_suspend, 
dw_mci_pltfm_resume);
 
+static const struct of_device_id dw_mci_pltfm_match[] = {
+   { .compatible = "snps,dw-mshc", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, dw_mci_pltfm_match);
+
 static struct platform_driver dw_mci_pltfm_driver = {
.remove = __exit_p(dw_mci_pltfm_remove),
.driver = {
.name   = "dw_mmc",
+   .of_match_table = of_match_ptr(dw_mci_pltfm_match),
.pm = &dw_mci_pltfm_pmops,
},
 };
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 455a155..c792466 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 

[PATCH v6 5/9] mmc: dw_mmc: add quirk to indicate missing write protect line

[Thomas Abraham]

If the write protect pad of the controller is not connected to the write
protect pin of the slot, the driver should be notified of this condition
so that incorrect check for write protection by reading the WRTORT
register can avoided. The get_ro platform callback can be used for in
such cases, but with device tree support enabled, such platform callbacks
cannot be supported.

Add a new quirk for notifying the driver about the missing write protect
line so the driver can assume that the card write protection is disabled.

Signed-off-by: Thomas Abraham 
Acked-by: Will Newton 
---
 drivers/mmc/host/dw_mmc.c  |4 +++-
 include/linux/mmc/dw_mmc.h |3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index de45ad2..455a155 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -830,7 +830,9 @@ static int dw_mci_get_ro(struct mmc_host *mmc)
struct dw_mci_board *brd = slot->host->pdata;
 
/* Use platform get_ro function, else try on board write protect */
-   if (brd->get_ro)
+   if (brd->quirks & DW_MCI_QUIRK_NO_WRITE_PROTECT)
+   read_only = 0;
+   else if (brd->get_ro)
read_only = brd->get_ro(slot->id);
else
read_only =
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 787ad56..b72e4aa 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -205,7 +205,8 @@ struct dw_mci_dma_ops {
 #define DW_MCI_QUIRK_HIGHSPEED BIT(2)
 /* Unreliable card detection */
 #define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
-
+/* Write Protect detection not available */
+#define DW_MCI_QUIRK_NO_WRITE_PROTECT  BIT(4)
 
 struct dma_pdata;
 
-- 
1.6.6.rc2

--
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 v6 4/9] mmc: dw_mmc: lookup for optional biu and ciu clocks

[Thomas Abraham]

Some platforms allow for clock gating and control of bus interface unit clock
and card interface unit clock. Add support for clock lookup of optional biu
and ciu clocks for clock gating and clock speed determination.

Signed-off-by: Abhilash Kesavan 
Signed-off-by: Thomas Abraham 
Acked-by: Will Newton 
---
 drivers/mmc/host/dw_mmc.c  |   52 +--
 include/linux/mmc/dw_mmc.h |4 +++
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 227c42e..de45ad2 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1960,13 +1960,42 @@ int dw_mci_probe(struct dw_mci *host)
return -ENODEV;
}
 
-   if (!host->pdata->bus_hz) {
+   host->biu_clk = clk_get(host->dev, "biu");
+   if (IS_ERR(host->biu_clk)) {
+   dev_dbg(host->dev, "biu clock not available\n");
+   } else {
+   ret = clk_prepare_enable(host->biu_clk);
+   if (ret) {
+   dev_err(host->dev, "failed to enable biu clock\n");
+   clk_put(host->biu_clk);
+   return ret;
+   }
+   }
+
+   host->ciu_clk = clk_get(host->dev, "ciu");
+   if (IS_ERR(host->ciu_clk)) {
+   dev_dbg(host->dev, "ciu clock not available\n");
+   } else {
+   ret = clk_prepare_enable(host->ciu_clk);
+   if (ret) {
+   dev_err(host->dev, "failed to enable ciu clock\n");
+   clk_put(host->ciu_clk);
+   goto err_clk_biu;
+   }
+   }
+
+   if (IS_ERR(host->ciu_clk))
+   host->bus_hz = host->pdata->bus_hz;
+   else
+   host->bus_hz = clk_get_rate(host->ciu_clk);
+
+   if (!host->bus_hz) {
dev_err(host->dev,
"Platform data must supply bus speed\n");
-   return -ENODEV;
+   ret = -ENODEV;
+   goto err_clk_ciu;
}
 
-   host->bus_hz = host->pdata->bus_hz;
host->quirks = host->pdata->quirks;
 
spin_lock_init(&host->lock);
@@ -2116,6 +2145,17 @@ err_dmaunmap:
regulator_disable(host->vmmc);
regulator_put(host->vmmc);
}
+
+err_clk_ciu:
+   if (!IS_ERR(host->ciu_clk)) {
+   clk_disable_unprepare(host->ciu_clk);
+   clk_put(host->ciu_clk);
+   }
+err_clk_biu:
+   if (!IS_ERR(host->biu_clk)) {
+   clk_disable_unprepare(host->biu_clk);
+   clk_put(host->biu_clk);
+   }
return ret;
 }
 EXPORT_SYMBOL(dw_mci_probe);
@@ -2149,6 +2189,12 @@ void dw_mci_remove(struct dw_mci *host)
regulator_put(host->vmmc);
}
 
+   if (!IS_ERR(host->ciu_clk))
+   clk_disable_unprepare(host->ciu_clk);
+   if (!IS_ERR(host->biu_clk))
+   clk_disable_unprepare(host->biu_clk);
+   clk_put(host->ciu_clk);
+   clk_put(host->biu_clk);
 }
 EXPORT_SYMBOL(dw_mci_remove);
 
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index a37a573..787ad56 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -78,6 +78,8 @@ struct mmc_data;
  * @data_offset: Set the offset of DATA register according to VERID.
  * @dev: Device associated with the MMC controller.
  * @pdata: Platform data associated with the MMC controller.
+ * @biu_clk: Pointer to bus interface unit clock instance.
+ * @ciu_clk: Pointer to card interface unit clock instance.
  * @slot: Slots sharing this MMC controller.
  * @fifo_depth: depth of FIFO.
  * @data_shift: log2 of FIFO item size.
@@ -158,6 +160,8 @@ struct dw_mci {
u16 data_offset;
struct device   *dev;
struct dw_mci_board *pdata;
+   struct clk  *biu_clk;
+   struct clk  *ciu_clk;
struct dw_mci_slot  *slot[MAX_MCI_SLOTS];
 
/* FIFO push and pull */
-- 
1.6.6.rc2

--
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 v6 3/9] mmc: dw_mmc: allow probe to succeed even if one slot is initialized

[Thomas Abraham]

Instead of aborting the probe in case a slot initialization fails, allow
initialization of as many slots as possible. If there are atleast one
instance of slot that is successfully initialized, allow the driver probe
to succeed.

Signed-off-by: Thomas Abraham 
Acked-by: Will Newton 
---
 drivers/mmc/host/dw_mmc.c |   23 +--
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index a18e73c..227c42e 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1946,6 +1946,7 @@ int dw_mci_probe(struct dw_mci *host)
 {
int width, i, ret = 0;
u32 fifo_size;
+   int init_slots = 0;
 
if (!host->pdata || !host->pdata->init) {
dev_err(host->dev,
@@ -2054,10 +2055,18 @@ int dw_mci_probe(struct dw_mci *host)
/* We need at least one slot to succeed */
for (i = 0; i < host->num_slots; i++) {
ret = dw_mci_init_slot(host, i);
-   if (ret) {
-   ret = -ENODEV;
-   goto err_init_slot;
-   }
+   if (ret)
+   dev_dbg(host->dev, "slot %d init failed\n", i);
+   else
+   init_slots++;
+   }
+
+   if (init_slots) {
+   dev_info(host->dev, "%d slots initialized\n", init_slots);
+   } else {
+   dev_dbg(host->dev, "attempted to initialize %d slots, "
+   "but failed on all\n", host->num_slots);
+   goto err_init_slot;
}
 
/*
@@ -2092,12 +2101,6 @@ int dw_mci_probe(struct dw_mci *host)
return 0;
 
 err_init_slot:
-   /* De-init any initialized slots */
-   while (i > 0) {
-   if (host->slot[i])
-   dw_mci_cleanup_slot(host->slot[i], i);
-   i--;
-   }
free_irq(host->irq, host);
 
 err_workqueue:
-- 
1.6.6.rc2

--
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 v6 2/9] mmc: dw_mmc: Use devm_* functions in dw_mmc platform driver

[Thomas Abraham]

Use devm_* managed functions for simpler error handling.

Signed-off-by: Thomas Abraham 
Acked-by: Will Newton 
---
 drivers/mmc/host/dw_mmc-pltfm.c |   29 -
 1 files changed, 8 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index 528d37b..ce7be1a 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -27,38 +27,27 @@ static int __devinit dw_mci_pltfm_probe(struct 
platform_device *pdev)
struct resource *regs;
int ret;
 
-   host = kzalloc(sizeof(struct dw_mci), GFP_KERNEL);
+   host = devm_kzalloc(&pdev->dev, sizeof(struct dw_mci), GFP_KERNEL);
if (!host)
return -ENOMEM;
 
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (!regs) {
-   ret = -ENXIO;
-   goto err_free;
-   }
+   if (!regs)
+   return -ENXIO;
 
host->irq = platform_get_irq(pdev, 0);
-   if (host->irq < 0) {
-   ret = host->irq;
-   goto err_free;
-   }
+   if (host->irq < 0)
+   return host->irq;
 
host->dev = &pdev->dev;
host->irq_flags = 0;
host->pdata = pdev->dev.platform_data;
-   ret = -ENOMEM;
-   host->regs = ioremap(regs->start, resource_size(regs));
+   host->regs = devm_request_and_ioremap(&pdev->dev, regs);
if (!host->regs)
-   goto err_free;
+   return -ENOMEM;
+
platform_set_drvdata(pdev, host);
ret = dw_mci_probe(host);
-   if (ret)
-   goto err_out;
-   return ret;
-err_out:
-   iounmap(host->regs);
-err_free:
-   kfree(host);
return ret;
 }
 
@@ -68,8 +57,6 @@ static int __devexit dw_mci_pltfm_remove(struct 
platform_device *pdev)
 
platform_set_drvdata(pdev, NULL);
dw_mci_remove(host);
-   iounmap(host->regs);
-   kfree(host);
return 0;
 }
 
-- 
1.6.6.rc2

--
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 v6 1/9] mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference

[Thomas Abraham]

The 'struct dw_mci' maintains a copy of the pdev->dev instance instead of
maintaining a reference to that 'struct device' instance. Any resource
allocated using the device resource management kernel API with the instance
of 'struct device' in 'struct dw_mci' is then incorrect. Fix this by
converting the copy of 'struct device' in 'struct dw_mci' to a reference.

Signed-off-by: Thomas Abraham 
Acked-by: Will Newton 
---
 drivers/mmc/host/dw_mmc-pci.c   |2 +-
 drivers/mmc/host/dw_mmc-pltfm.c |2 +-
 drivers/mmc/host/dw_mmc.c   |   56 +++---
 include/linux/mmc/dw_mmc.h  |2 +-
 4 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc-pci.c b/drivers/mmc/host/dw_mmc-pci.c
index f5ab03d..edb37e9 100644
--- a/drivers/mmc/host/dw_mmc-pci.c
+++ b/drivers/mmc/host/dw_mmc-pci.c
@@ -59,7 +59,7 @@ static int __devinit dw_mci_pci_probe(struct pci_dev *pdev,
 
host->irq = pdev->irq;
host->irq_flags = IRQF_SHARED;
-   host->dev = pdev->dev;
+   host->dev = &pdev->dev;
host->pdata = &pci_board_data;
 
host->regs = pci_iomap(pdev, PCI_BAR_NO, COMPLETE_BAR);
diff --git a/drivers/mmc/host/dw_mmc-pltfm.c b/drivers/mmc/host/dw_mmc-pltfm.c
index a54d3a3..528d37b 100644
--- a/drivers/mmc/host/dw_mmc-pltfm.c
+++ b/drivers/mmc/host/dw_mmc-pltfm.c
@@ -43,7 +43,7 @@ static int __devinit dw_mci_pltfm_probe(struct 
platform_device *pdev)
goto err_free;
}
 
-   host->dev = pdev->dev;
+   host->dev = &pdev->dev;
host->irq_flags = 0;
host->pdata = pdev->dev.platform_data;
ret = -ENOMEM;
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 36f98c0..a18e73c 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -266,7 +266,7 @@ static void dw_mci_start_command(struct dw_mci *host,
 struct mmc_command *cmd, u32 cmd_flags)
 {
host->cmd = cmd;
-   dev_vdbg(&host->dev,
+   dev_vdbg(host->dev,
 "start command: ARGR=0x%08x CMDR=0x%08x\n",
 cmd->arg, cmd_flags);
 
@@ -308,7 +308,7 @@ static void dw_mci_dma_cleanup(struct dw_mci *host)
 
if (data)
if (!data->host_cookie)
-   dma_unmap_sg(&host->dev,
+   dma_unmap_sg(host->dev,
 data->sg,
 data->sg_len,
 dw_mci_get_dma_dir(data));
@@ -334,7 +334,7 @@ static void dw_mci_idmac_complete_dma(struct dw_mci *host)
 {
struct mmc_data *data = host->data;
 
-   dev_vdbg(&host->dev, "DMA complete\n");
+   dev_vdbg(host->dev, "DMA complete\n");
 
host->dma_ops->cleanup(host);
 
@@ -414,13 +414,13 @@ static int dw_mci_idmac_init(struct dw_mci *host)
dma_support = (mci_readl(host, HCON) >> 16) & 0x3;
 
if (!dma_support || dma_support > 2) {
-   dev_err(&host->dev,
+   dev_err(host->dev,
"Host Controller does not support IDMA Tx.\n");
host->dma_ops = NULL;
return -ENODEV;
}
 
-   dev_info(&host->dev, "Using internal DMA controller.\n");
+   dev_info(host->dev, "Using internal DMA controller.\n");
 
/* Forward link the descriptor list */
for (i = 0, p = host->sg_cpu; i < host->ring_size - 1; i++, p++)
@@ -476,7 +476,7 @@ static int dw_mci_pre_dma_transfer(struct dw_mci *host,
return -EINVAL;
}
 
-   sg_len = dma_map_sg(&host->dev,
+   sg_len = dma_map_sg(host->dev,
data->sg,
data->sg_len,
dw_mci_get_dma_dir(data));
@@ -519,7 +519,7 @@ static void dw_mci_post_req(struct mmc_host *mmc,
return;
 
if (data->host_cookie)
-   dma_unmap_sg(&slot->host->dev,
+   dma_unmap_sg(slot->host->dev,
 data->sg,
 data->sg_len,
 dw_mci_get_dma_dir(data));
@@ -545,7 +545,7 @@ static int dw_mci_submit_data_dma(struct dw_mci *host, 
struct mmc_data *data)
 
host->using_dma = 1;
 
-   dev_vdbg(&host->dev,
+   dev_vdbg(host->dev,
 "sd sg_cpu: %#lx sg_dma: %#lx sg_len: %d\n",
 (unsigned long)host->sg_cpu, (unsigned long)host->sg_dma,
 sg_len);
@@ -939,12 +939,12 @@ static void dw_mci_request_end(struct dw_mci *host, 
struct mmc_request *mrq)
slot = list_entry(host->queue.next,
  struct dw_mci_slot, queue_node);
list_del(&slot->queue_node);
-   dev_vdbg(&host->dev, "list not empty: %s is next\n",
+   dev_vdbg(host->dev, "list not empty: %s is next\n",
 mmc_hostname(slot->mmc));
host->state 

[PATCH v6 0/9] mmc: dw_mmc: add support for device tree based instantiation

[Thomas Abraham]

This series add device tree support for Synopsis Designware IP - Mobile Storage
Host Controller (MSHC). I had addressed all comments for the v5 version of this
patch series and had reposted only those patches that were modified. The version
number of those reposted patches was maintained as v5 as the changes did not
need any major rework.

This is mainly a repost of the v5 patches with all patches marked as v6. The
only new change in this series is adding a comment about bus_hz in platform
data structure of the driver as suggested by Seungwon Jeon.

Thomas Abraham (9):
  mmc: dw_mmc: convert copy of struct device in struct dw_mci to a reference
  mmc: dw_mmc: Use devm_* functions in dw_mmc platform driver
  mmc: dw_mmc: allow probe to succeed even if one slot is initialized
  mmc: dw_mmc: lookup for optional biu and ciu clocks
  mmc: dw_mmc: add quirk to indicate missing write protect line
  mmc: dw_mmc: add device tree support
  mmc: dw_mmc: prepare functions in dw_mmc-pltfm for reuse
  mmc: dw_mmc: add support for implementation specific callbacks
  mmc: dw_mmc: add support for exynos specific implementation of dw-mshc

 .../devicetree/bindings/mmc/exynos-dw-mshc.txt |   87 ++
 .../devicetree/bindings/mmc/synposis-dw-mshc.txt   |   79 +
 drivers/mmc/host/Kconfig   |9 +
 drivers/mmc/host/Makefile  |1 +
 drivers/mmc/host/dw_mmc-exynos.c   |  253 
 drivers/mmc/host/dw_mmc-pci.c  |2 +-
 drivers/mmc/host/dw_mmc-pltfm.c|   60 +++--
 drivers/mmc/host/dw_mmc-pltfm.h|   20 ++
 drivers/mmc/host/dw_mmc.c  |  308 +---
 drivers/mmc/host/dw_mmc.h  |   24 ++
 include/linux/mmc/dw_mmc.h |   15 +-
 11 files changed, 782 insertions(+), 76 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
 create mode 100644 Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
 create mode 100644 drivers/mmc/host/dw_mmc-exynos.c
 create mode 100644 drivers/mmc/host/dw_mmc-pltfm.h

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

Re: [PATCH] mmc: mxs-mmc: implement broken-cd

[Lauri Hintsala]

Hi,

On 09/17/2012 05:01 PM, Chris Ball wrote:

Hi,

On Mon, Sep 17 2012, Lauri Hintsala wrote:

Is it OK to use broken-cd? broken-cd feature is documented as "There
is no card detection available; polling must be used". In this case
the card detect is not broken but it is unrouted so it is unavailable.

Documentation about broken-cd has been added by commit:
https://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commitdiff;h=abe1e05da365350ac282ba5f6831aae13d97074e


I'm having trouble following the problem; it sounds like perhaps all you
need is:

 if (of_find_property(np, "non-removable", NULL))
 mmc->caps |= MMC_CAP_NONREMOVABLE;

Have you tried that?


Yes I have and it does not work. Current mxs-mmc driver uses polling 
method and it reads the CARD_DETECT bit of STATUS register. In our case 
card detect is signal is unrouted so SDIO device is never detect.


Another problem with NONREMOVABLE feature is in case where power cycle 
or reset is done for SDIO device. A device drive doesn't detect HW 
reset. After reset the device driver is still in running state and it 
does not reinitialize the device. So after reset device stops to work.


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

Re: [PATCH] mmc: mxs-mmc: implement broken-cd

[Chris Ball]

Hi,

On Mon, Sep 17 2012, Lauri Hintsala wrote:
> Is it OK to use broken-cd? broken-cd feature is documented as "There
> is no card detection available; polling must be used". In this case
> the card detect is not broken but it is unrouted so it is unavailable.
>
> Documentation about broken-cd has been added by commit:
> https://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commitdiff;h=abe1e05da365350ac282ba5f6831aae13d97074e

I'm having trouble following the problem; it sounds like perhaps all you
need is:

if (of_find_property(np, "non-removable", NULL))
mmc->caps |= MMC_CAP_NONREMOVABLE;

Have you tried that?

- 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 2/3] powerpc/esdhc: add property to disable the CMD23

[Chris Ball]

Hi,

On Mon, Sep 17 2012, Kumar Gala wrote:
 P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
 Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041) 
 support it.
>>> 
>>> Based on this, why don't we use the HOSTVER register to detect instead of 
>>> device tree:
>> 
>> I've got a mild preference for handling quirk assignment in the DT
>> rather than in driver code, so I'd prefer to just push the original
>> patch to mmc-next as-is.  Does that sound okay?
>
> Why?  I only ask because I agree with Scott that this means you have to 
> update your device tree to get proper functionality.

Thanks, I'd missed that.  I withdraw my preference; I'll pick up
whichever method you all prefer.

- 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] mmc: mxs-mmc: implement broken-cd

[Lauri Hintsala]

Hi,

Is it OK to use broken-cd? broken-cd feature is documented as "There is 
no card detection available; polling must be used". In this case the 
card detect is not broken but it is unrouted so it is unavailable.


Documentation about broken-cd has been added by commit:
https://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commitdiff;h=abe1e05da365350ac282ba5f6831aae13d97074e

Any tips about power management implementation are welcome if I have to 
use PM instead of polling method.


Regards,
Lauri


On 09/12/2012 05:06 PM, Lauri Hintsala wrote:

Hi,

On 09/10/2012 05:58 PM, Matt Sealey wrote:

I think this describes three use cases which are different, as Shawn
said we have here;

* missing card detect support (card detect is not wired so it's
impossible to tell, and the controller doesn't support the SD standard
card detection)
* non-removable device
* broken card detect support

The third one is what the property sounds like it describes, but this
is not the use case you are describing at all. This kind of property
naming is more like describing "card detect doesn't operate reliably"
which is true of i.MX devices with certain versions of the eSDHC and
uSDHC controllers, where non-GPIO card detection interferes with SDIO
interrupts, but in this case a board designer should add a real card
detect pin to the board (most more expensive push-push SD card slots
come with a pin you can wire for CD). In cases where errata is
published after boards are shipped, broken-cd is a meaningful
description when described in the absense of a gpio cd description, or
presence of some cd-handled-internally style property (forgive me for
not cross-referencing the FSL definition for this property, we don't
use it here at Genesi since all our boards have GPIO CD)

It seems your device is a combination of the top two in the list, it
is not down to a broken feature at all, but one that should be
possible to not implement for devices which are permanently connected.
A non-removable device should be able to be powered down, at least
using runtime PM or clock gating (if this works, remember to whitelist
the card for clock gating!) but card detect shouldn't be used in this
case to detect if the card is powered or not (this is a problem for
your card controller and card driver state tracker. The MMC subsystem
already tracks this state fairly well for power management).


Do you mean the polling mode shouldn't been used to detect if the device
is powered?

Is there any examples how PM support could be implemented? I'm not
familiar with PM subsystem. How is it done in practice? Should I play
with fixed regulators?

BR,
Lauri



I would refrain from calling a feature "broken card detect" if there
is actually no breakage involved especially if it would be more
prudent instead look into how to figure out how to track power
management state properly without cluttering the device tree.


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

--
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/3] powerpc/esdhc: add property to disable the CMD23

[Kumar Gala]

On Sep 17, 2012, at 7:36 AM, Chris Ball wrote:

> Hi,
> 
> On Thu, Sep 13 2012, Kumar Gala wrote:
 Can you list out which SoCs support it and which don't.  Having this list
 will be useful in understanding which controller versions supported it.
 
>>> P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
>>> Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041) 
>>> support it.
>> 
>> Based on this, why don't we use the HOSTVER register to detect instead of 
>> device tree:
> 
> I've got a mild preference for handling quirk assignment in the DT
> rather than in driver code, so I'd prefer to just push the original
> patch to mmc-next as-is.  Does that sound okay?

Why?  I only ask because I agree with Scott that this means you have to update 
your device tree to get proper functionality.

> (I think the argument that there isn't going to be any new hardware
> with this problem is equally in favor of both methods.)

- k--
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/3] powerpc/esdhc: add property to disable the CMD23

[Chris Ball]

Hi,

On Thu, Sep 13 2012, Kumar Gala wrote:
>>> Can you list out which SoCs support it and which don't.  Having this list
>>> will be useful in understanding which controller versions supported it.
>>> 
>> P1020, p1021, p1022, p1024, p1015 and p4080 can't support it.
>> Mpc8536, p2020, and the other current DPAA silicon (e.g. p5020, p3041) 
>> support it.
>
> Based on this, why don't we use the HOSTVER register to detect instead of 
> device tree:

I've got a mild preference for handling quirk assignment in the DT
rather than in driver code, so I'd prefer to just push the original
patch to mmc-next as-is.  Does that sound okay?

(I think the argument that there isn't going to be any new hardware
with this problem is equally in favor of both methods.)

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: [RESEND PATCH v12] mmc: support BKOPS feature for eMMC

[Chris Ball]

Hi Jaehoon,

On Mon, Sep 17 2012, Jaehoon Chung wrote:
> Enable eMMC background operations (BKOPS) feature.
>
> If URGENT_BKOPS is set after a response, note that BKOPS
> are required. Immediately run BKOPS if required.
> read/write operations should be requested during BKOPS(LEVEL-1),
> then issue HPI to interrupt the ongoing BKOPS 
> and service the foreground operation.
> (This patch is only control the LEVEL2/3.)
>
> When repeating the writing 1GB data, at a certain time, performance is 
> decreased.
> At that time, card is also triggered the Level-3 or Level-2.
> After running bkops, performance is recovered.
>
> Future considerations
>  * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
>  * Interrupt ongoing BKOPS before powering off the card.
>  * How get BKOPS_STATUS value.(periodically send ext_csd command?)
>  * If use periodic bkops, also consider runtime_pm control.
>
> Signed-off-by: Jaehoon Chung 
> Signed-off-by: Kyungmin Park 
> Signed-off-by: Konstantin Dorfman 
> Reviewed-by: Maya Erez 

Thanks, looks good now.  Is it okay if I apply this stylistic patch
before pushing to mmc-next?


diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 4749557..044cd01 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -43,8 +43,8 @@
 #include "sdio_ops.h"
 
 /*
- * The Background operation can take a long time, depends on the house keeping
- * operations the card has to peform
+ * Background operations can take a long time, depending on the housekeeping
+ * operations the card has to perform.
  */
 #define MMC_BKOPS_MAX_TIMEOUT  (4 * 60 * 1000) /* max time to wait in ms */
 
@@ -255,11 +255,11 @@ mmc_start_request(struct mmc_host *host, struct 
mmc_request *mrq)
 /**
  * mmc_start_bkops - start BKOPS for supported cards
  * @card: MMC card to start BKOPS
- * @form_exception: A flags to indicate if this function was
- * called due to an exception raised by the card
+ * @form_exception: A flag to indicate if this function was
+ *  called due to an exception raised by the card
  *
  * Start background operations whenever requested.
- * when the urgent BKOPS bit is set in a R1 command response
+ * When the urgent BKOPS bit is set in a R1 command response
  * then background operations should be started immediately.
 */
 void mmc_start_bkops(struct mmc_card *card, bool from_exception)
@@ -275,7 +275,7 @@ void mmc_start_bkops(struct mmc_card *card, bool 
from_exception)
 
err = mmc_read_bkops_status(card);
if (err) {
-   pr_err("%s: Didn't read bkops status : %d\n",
+   pr_err("%s: Failed to read bkops status: %d\n",
   mmc_hostname(card->host), err);
return;
}
@@ -283,8 +283,8 @@ void mmc_start_bkops(struct mmc_card *card, bool 
from_exception)
if (!card->ext_csd.raw_bkops_status)
return;
 
-   if (card->ext_csd.raw_bkops_status < EXT_CSD_BKOPS_LEVEL_2
-   && (from_exception))
+   if (card->ext_csd.raw_bkops_status < EXT_CSD_BKOPS_LEVEL_2 &&
+   from_exception)
return;
 
mmc_claim_host(card->host);
@@ -299,8 +299,8 @@ void mmc_start_bkops(struct mmc_card *card, bool 
from_exception)
err = __mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_BKOPS_START, 1, timeout, use_busy_signal);
if (err) {
-   pr_warn("%s: error %d starting bkops\n",
-  mmc_hostname(card->host), err);
+   pr_warn("%s: Error %d starting bkops\n",
+   mmc_hostname(card->host), err);
goto out;
}
 
@@ -429,9 +429,9 @@ struct mmc_async_req *mmc_start_req(struct mmc_host *host,
 * Check BKOPS urgency for each R1 response
 */
if (host->card && mmc_card_mmc(host->card) &&
-   ((mmc_resp_type(host->areq->mrq->cmd) == MMC_RSP_R1) ||
-(mmc_resp_type(host->areq->mrq->cmd) == MMC_RSP_R1B)) &&
-   (host->areq->mrq->cmd->resp[0] & R1_EXCEPTION_EVENT))
+   ((mmc_resp_type(host->areq->mrq->cmd) == MMC_RSP_R1) ||
+(mmc_resp_type(host->areq->mrq->cmd) == MMC_RSP_R1B)) &&
+   (host->areq->mrq->cmd->resp[0] & R1_EXCEPTION_EVENT))
mmc_start_bkops(host->card, true);
}
 
@@ -477,7 +477,7 @@ EXPORT_SYMBOL(mmc_wait_for_req);
  * @card: the MMC card associated with the HPI transfer
  *
  * Issued High Priority Interrupt, and check for card status
- * util out-of prg-state.
+ * until out-of prg-state.
  */
 int mmc_interrupt_hpi(struct mmc_card *card)
 {
@@ -572,8 +572,8 @@ EXPORT_SYMBOL(mmc_wait_for_cmd);
  * mmc_stop_bkops - stop ongoing BKOPS
  * @card: MMC card to check BKOPS
  *
- * Send HPI command to stop ongoing background operations,
- * to allow rapid servici

[PATCH v2 1/4] drivers/mmc/host/dw_mmc.c: fix error return code

[Peter Senna Tschudin]

From: Peter Senna Tschudin 

Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
  ... when != ret = e2
  when forall
 return ret;
}
// 

Signed-off-by: Peter Senna Tschudin 
---
 drivers/mmc/host/dw_mmc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 36f98c0..43a2663 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2039,8 +2039,10 @@ int dw_mci_probe(struct dw_mci *host)
tasklet_init(&host->tasklet, dw_mci_tasklet_func, (unsigned long)host);
host->card_workqueue = alloc_workqueue("dw-mci-card",
WQ_MEM_RECLAIM | WQ_NON_REENTRANT, 1);
-   if (!host->card_workqueue)
+   if (!host->card_workqueue) {
+   ret = -ENOMEM;
goto err_dmaunmap;
+   }
INIT_WORK(&host->card_work, dw_mci_work_routine_card);
ret = request_irq(host->irq, dw_mci_interrupt, host->irq_flags, 
"dw-mci", host);
if (ret)
-- 
1.7.11.4

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

Re: [PATCH 00/34] i.MX multi-platform support

[Arnd Bergmann]

On Monday 17 September 2012, Sascha Hauer wrote:
> On Mon, Sep 17, 2012 at 01:34:29PM +0800, Shawn Guo wrote:
> > The series enables multi-platform support for imx.  Since the required
> > frameworks (clk, pwm) and spare_irq have already been adopted on imx,
> > the series is all about cleaning up mach/* headers.  Along with the
> > changes, arch/arm/plat-mxc gets merged into arch/arm/mach-imx.
> > 
> > It's based on a bunch of branches (works from others), Rob's initial
> > multi-platform series, Arnd's platform-data and smp_ops (Marc's) and
> > imx 3.7 material (Sascha and myself).
> > 
> > It's available on branch below.
> > 
> >   git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform
> > 
> > It's been tested on imx5 and imx6, and only compile-tested on imx2 and
> > imx3, so testing on imx2/3 are appreciated.
> 
> Great work! This really pushes the i.MX architecture one step closer to
> a clean code base.

I agree, this series is wonderful, I thought it would take much longer
to get this far.

Two small comments on the last two patches from me, but overall I really
love it.

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

Re: [PATCH 1/4] drivers/mmc/host/dw_mmc.c: fix error return code

[Peter Senna Tschudin]

On Mon, Sep 17, 2012 at 11:54 AM, Seungwon Jeon  wrote:
> On Monday, September 17, 2012, Peter Senna Tschudin  
> wrote:
>> From: Peter Senna Tschudin 
>>
>> Convert a nonnegative error return code to a negative one, as returned
>> elsewhere in the function.
>>
>> A simplified version of the semantic match that finds this problem is as
>> follows: (http://coccinelle.lip6.fr/)
>>
>> // 
>> (
>> if@p1 (\(ret < 0\|ret != 0\))
>>  { ... return ret; }
>> |
>> ret@p1 = 0
>> )
>> ... when != ret = e1
>> when != &ret
>> *if(...)
>> {
>>   ... when != ret = e2
>>   when forall
>>  return ret;
>> }
>> // 
>>
>> Signed-off-by: Peter Senna Tschudin 
>> ---
>>  drivers/mmc/host/dw_mmc.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 36f98c0..7ad5176 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -2039,8 +2039,10 @@ int dw_mci_probe(struct dw_mci *host)
>>   tasklet_init(&host->tasklet, dw_mci_tasklet_func, (unsigned long)host);
>>   host->card_workqueue = alloc_workqueue("dw-mci-card",
>>   WQ_MEM_RECLAIM | WQ_NON_REENTRANT, 1);
>> - if (!host->card_workqueue)
>> + if (!host->card_workqueue) {
>> + err = -ENOMEM;
> ret is expected instead of err.
> err isn't defined.

I'm sorry. Somehow I did not compile for testing this one before
sending. I'll fix, test and resend.

>
> Thanks,
> Seungwon Jeon
>
>>   goto err_dmaunmap;
>> + }
>>   INIT_WORK(&host->card_work, dw_mci_work_routine_card);
>>   ret = request_irq(host->irq, dw_mci_interrupt, host->irq_flags, 
>> "dw-mci", host);
>>   if (ret)
>> --
>> 1.7.11.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Peter
--
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] Revert "mmc: dw_mmc: Add check for IDMAC configuration"

[Will Newton]

On Tue, Sep 11, 2012 at 3:23 AM, Seungwon Jeon  wrote:
> This reverts commit 94c6cee91(Add check for IDMAC configuration).
> Synopsys says that only if internal dmac is not present, optional
> external dma interface is present. When internal dmac is present,
> '0' value in DMA_INTERFACE of HCON is reasonable. DMA_INTERFACE
> indicates external dma interface. And idmac initialization is
> prohibited now. So, let's revert this commit.
>
> CC: Girish K S 
> Signed-off-by: Seungwon Jeon 
> ---
>  drivers/mmc/host/dw_mmc.c |   15 ++-
>  1 files changed, 2 insertions(+), 13 deletions(-)

I think this revert is a good idea. The original patch tries to check
whether IDMAC is supported and falls back to PIO, but it is not clear
to me that HCON gives you the appropriate information to do this (at
least in my version of the manual, I have not tried to clarify this
with Synopsys). Also falling back to PIO mode seems like it would
provide pretty awful performance, I would not expect to see instances
of this block with no DMA support anywhere other than FPGA so
configuring with IDMAC without it's presence would be a serious
misconfiguration in any case.

Acked-by: Will Newton 
--
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

[RESEND PATCH v12] mmc: support BKOPS feature for eMMC

[Jaehoon Chung]

Enable eMMC background operations (BKOPS) feature.

If URGENT_BKOPS is set after a response, note that BKOPS
are required. Immediately run BKOPS if required.
read/write operations should be requested during BKOPS(LEVEL-1),
then issue HPI to interrupt the ongoing BKOPS 
and service the foreground operation.
(This patch is only control the LEVEL2/3.)

When repeating the writing 1GB data, at a certain time, performance is 
decreased.
At that time, card is also triggered the Level-3 or Level-2.
After running bkops, performance is recovered.

Future considerations
 * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
 * Interrupt ongoing BKOPS before powering off the card.
 * How get BKOPS_STATUS value.(periodically send ext_csd command?)
 * If use periodic bkops, also consider runtime_pm control.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
Signed-off-by: Konstantin Dorfman 
Reviewed-by: Maya Erez 
---
Changelog v12:
- use the kamlloc for allocating the ext_csd.
: If use the periodic bkops, it should be modified.
Changelog v11:
- removed the MMC_CAP2_BKOPS.
: if card support and enable bkops, then use it.
Changelog v10:
- Based on latest mmc-next
- Only control the level-2/3.
: If triggered upper than level2, immediately start bkops.
- Remove the BKOPS_CAP2_INIT_BKOPS (move into mmc-util)
- change use_busy_signal instead of waiting_for_prog_done for 
__mmc_switch
- Remove the useless code.
- Add the from_exception to prepare the periodic bkops.
Changelog V9:
- Rebased on patch-v7.
- Added Konstantin and Maya's patch
: mmc:core: Define synchronous BKOPS timeout
: mmc:core: eMMC4.5 BKOPS fixes
- Removed periodic bkops
: This feature will do in future work
- Add __mmc_switch() for waiting_for_prod_done.

Changelog V8:
- Remove host->lock spin lock reviewed by Adrian
- Support periodic start bkops
- when bkops_status is level-3, if timeout is set to 0, send hpi.
- Move the start-bkops point
Changelog V7:
- Use HPI command when issued URGENT_BKOPS
- Recheck until clearing the bkops-status bit.
Changelog V6:
- Add the flag of check-bkops-status.
  (For fixing async_req problem)
- Add the capability for MMC_CAP2_INIT_BKOPS.
  (When unset the bkops_en bit in ext_csd register)
- modify the wrong condition.
Changelog V5:
- Rebase based on the latest mmc-next.
- modify codes based-on Chris's comment
Changelog V4:
- Add mmc_read_bkops_status
- When URGENT_BKOPS(level2-3), didn't use HPI command.
- In mmc_switch(), use R1B/R1 according to level.
Changelog V3:
- move the bkops setting's location in mmc_blk_issue_rw_rq
- modify condition checking
- bkops_en is assigned ext_csd[EXT_CSD_BKOPS_EN] instead of "1"
- remove the unused code
- change pr_debug instead of pr_warn in mmc_send_hpi_cmd
- Add the Future consideration suggested by Per
Changelog V2:
- Use EXCEPTION_STATUS instead of URGENT_BKOPS
- Add function to check Exception_status(for eMMC4.5)
---
 drivers/mmc/core/core.c|  157 +++-
 drivers/mmc/core/mmc.c |   11 +++
 drivers/mmc/core/mmc_ops.c |   26 ++-
 include/linux/mmc/card.h   |8 ++
 include/linux/mmc/core.h   |4 +
 include/linux/mmc/mmc.h|   19 +
 6 files changed, 219 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index af2c4d2..28ad74e 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -41,6 +42,12 @@
 #include "sd_ops.h"
 #include "sdio_ops.h"
 
+/*
+ * The Background operation can take a long time, depends on the house keeping
+ * operations the card has to peform
+ */
+#define MMC_BKOPS_MAX_TIMEOUT  (4 * 60 * 1000) /* max time to wait in ms */
+
 static struct workqueue_struct *workqueue;
 static const unsigned freqs[] = { 40, 30, 20, 10 };
 
@@ -245,6 +252,70 @@ mmc_start_request(struct mmc_host *host, struct 
mmc_request *mrq)
host->ops->request(host, mrq);
 }
 
+/**
+ * mmc_start_bkops - start BKOPS for supported cards
+ * @card: MMC card to start BKOPS
+ * @form_exception: A flags to indicate if this function was
+ * called due to an exception raised by the card
+ *
+ * Start background operations whenever requested.
+ * when the urgent BKOPS bit is set in a R1 command response
+ * then background operations should be started immediately.
+*/
+void mmc_start_bkops(struct mmc_card *card, bool from_exception)
+{
+   int err;
+   int timeout;
+   bool use_busy_signal;
+
+   BUG_ON(!card);
+
+   i

Re: [PATCH v12] mmc: support BKOPS feature for eMMC

[Jaehoon Chung]

Dear Chris,

On 09/17/2012 07:30 PM, Chris Ball wrote:
> Hi Jaehoon,
> 
> On Mon, Sep 17 2012, Jaehoon Chung wrote:
>> @@ -2334,7 +2471,13 @@ int mmc_suspend_host(struct mmc_host *host)
>>  mmc_bus_get(host);
>>  if (host->bus_ops && !host->bus_dead) {
>>  
>> -if (host->bus_ops->suspend)
>> +if (host->bus_ops->suspend) {
>> +if (mmc_card_doing_bkops(host->card)) {
>> +err = mmc_stop_bkops(host->card);
>> +if (err)
>> +goto out;
>> +}
>> +}
>>  err = host->bus_ops->suspend(host);
>>  
>>  if (err == -ENOSYS || !host->bus_ops->resume) {
> 
> Something's gone very wrong with the closing brace here.  Maybe you want
> the closing brace to be a line later than it is?
Sorry. you're right. it's my mistake. I will fix this.

Best Regards,
Jaehoon Chung
> 
> Thanks,
> 
> - Chris.
> 

--
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 v12] mmc: support BKOPS feature for eMMC

[Chris Ball]

Hi Jaehoon,

On Mon, Sep 17 2012, Jaehoon Chung wrote:
> @@ -2334,7 +2471,13 @@ int mmc_suspend_host(struct mmc_host *host)
>   mmc_bus_get(host);
>   if (host->bus_ops && !host->bus_dead) {
>  
> - if (host->bus_ops->suspend)
> + if (host->bus_ops->suspend) {
> + if (mmc_card_doing_bkops(host->card)) {
> + err = mmc_stop_bkops(host->card);
> + if (err)
> + goto out;
> + }
> + }
>   err = host->bus_ops->suspend(host);
>  
>   if (err == -ENOSYS || !host->bus_ops->resume) {

Something's gone very wrong with the closing brace here.  Maybe you want
the closing brace to be a line later than it is?

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 4/4] drivers/mmc/host/mxs-mmc.c: fix error return code

[Marek Vasut]

Dear Peter Senna Tschudin,

> From: Peter Senna Tschudin 

The patch description is a bit crap, but otherwise

Acked-by: Marek Vasut 

> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> 
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> // 
> 
> Signed-off-by: Peter Senna Tschudin 
> ---
>  drivers/mmc/host/mxs-mmc.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
> index 80d1e6d..afd8fdd 100644
> --- a/drivers/mmc/host/mxs-mmc.c
> +++ b/drivers/mmc/host/mxs-mmc.c
> @@ -674,6 +674,7 @@ static int mxs_mmc_probe(struct platform_device *pdev)
>   if (!ssp->dmach) {
>   dev_err(mmc_dev(host->mmc),
>   "%s: failed to request dma\n", __func__);
> + ret = -ENODEV;
>   goto out_clk_put;
>   }

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

Re: [PATCH] mmc: sdhci: Test cd-gpio instead of SDHCI presence when probing

[Chris Ball]

Hi,

On Mon, Sep 17 2012, Guennadi Liakhovetski wrote:
> On Mon, 17 Sep 2012, Chris Ball wrote:
>
>> From: Guennadi Liakhovetski 
>> 
>> Previously to this patch, an SDHCI platform that uses a GPIO for
>> card detection instead of the internal SDHCI_CARD_PRESENT bit on
>> the presence register would fail to bring up a new card because
>> logic in sdhci_request() fails the request if that bit is 0.
>> 
>> Some drivers worked around this in various ways: esdhc-imx defines
>> an IO accessor to fake the presence bit being true, s3c turns on
>> polling (which stops the SDHCI driver from checking the bit) after
>> a card's inserted.  But none of this should be necessary; the real
>> fix is to check whether we're using a GPIO and avoid relying on
>> the presence bit if so, as this patch implements.
>> 
>
> Well, ok, thanks for attributing this patch to me:-) I guess then my Sob 
> should go in the first, as you'll be forwarding the patch upstream? But 
> feel free to swap them if you disagree
>
> Signed-off-by: Guennadi Liakhovetski 

Yes, I'll put yours in first.  Pushed to mmc-next for 3.7; 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 1/4] drivers/mmc/host/dw_mmc.c: fix error return code

[Seungwon Jeon]

On Monday, September 17, 2012, Peter Senna Tschudin  
wrote:
> From: Peter Senna Tschudin 
> 
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
> 
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
> 
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> // 
> 
> Signed-off-by: Peter Senna Tschudin 
> ---
>  drivers/mmc/host/dw_mmc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 36f98c0..7ad5176 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2039,8 +2039,10 @@ int dw_mci_probe(struct dw_mci *host)
>   tasklet_init(&host->tasklet, dw_mci_tasklet_func, (unsigned long)host);
>   host->card_workqueue = alloc_workqueue("dw-mci-card",
>   WQ_MEM_RECLAIM | WQ_NON_REENTRANT, 1);
> - if (!host->card_workqueue)
> + if (!host->card_workqueue) {
> + err = -ENOMEM;
ret is expected instead of err.
err isn't defined.

Thanks,
Seungwon Jeon

>   goto err_dmaunmap;
> + }
>   INIT_WORK(&host->card_work, dw_mci_work_routine_card);
>   ret = request_irq(host->irq, dw_mci_interrupt, host->irq_flags, 
> "dw-mci", host);
>   if (ret)
> --
> 1.7.11.4

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

Re: [PATCH 1/4] drivers/mmc/host/dw_mmc.c: fix error return code

[Will Newton]

On Mon, Sep 17, 2012 at 9:15 AM, Peter Senna Tschudin
 wrote:
> From: Peter Senna Tschudin 
>
> Convert a nonnegative error return code to a negative one, as returned
> elsewhere in the function.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // 
> (
> if@p1 (\(ret < 0\|ret != 0\))
>  { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
>   ... when != ret = e2
>   when forall
>  return ret;
> }
> // 
>
> Signed-off-by: Peter Senna Tschudin 

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

Re: [PATCH] mmc: sdhci: Test cd-gpio instead of SDHCI presence when probing

[Guennadi Liakhovetski]

On Mon, 17 Sep 2012, Chris Ball wrote:

> From: Guennadi Liakhovetski 
> 
> Previously to this patch, an SDHCI platform that uses a GPIO for
> card detection instead of the internal SDHCI_CARD_PRESENT bit on
> the presence register would fail to bring up a new card because
> logic in sdhci_request() fails the request if that bit is 0.
> 
> Some drivers worked around this in various ways: esdhc-imx defines
> an IO accessor to fake the presence bit being true, s3c turns on
> polling (which stops the SDHCI driver from checking the bit) after
> a card's inserted.  But none of this should be necessary; the real
> fix is to check whether we're using a GPIO and avoid relying on
> the presence bit if so, as this patch implements.
> 

Well, ok, thanks for attributing this patch to me:-) I guess then my Sob 
should go in the first, as you'll be forwarding the patch upstream? But 
feel free to swap them if you disagree

Signed-off-by: Guennadi Liakhovetski 

Thanks
Guennadi

> Signed-off-by: Chris Ball 
> ---
>  drivers/mmc/host/sdhci.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index d98b199..0e15c79 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "sdhci.h"
>  
> @@ -1293,6 +1294,13 @@ static void sdhci_request(struct mmc_host *mmc, struct 
> mmc_request *mrq)
>   present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
>   SDHCI_CARD_PRESENT;
>  
> + /* If we're using a cd-gpio, testing the presence bit might fail. */
> + if (!present) {
> + int ret = mmc_gpio_get_cd(host->mmc);
> + if (ret > 0)
> + present = true;
> + }
> +
>   if (!present || host->flags & SDHCI_DEVICE_DEAD) {
>   host->mrq->cmd->error = -ENOMEDIUM;
>   tasklet_schedule(&host->finish_tasklet);
> -- 
> 1.7.11.2
> 
> 
> 
> - 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

[PATCH] mmc: sdhci: Test cd-gpio instead of SDHCI presence when probing

[Chris Ball]

From: Guennadi Liakhovetski 

Previously to this patch, an SDHCI platform that uses a GPIO for
card detection instead of the internal SDHCI_CARD_PRESENT bit on
the presence register would fail to bring up a new card because
logic in sdhci_request() fails the request if that bit is 0.

Some drivers worked around this in various ways: esdhc-imx defines
an IO accessor to fake the presence bit being true, s3c turns on
polling (which stops the SDHCI driver from checking the bit) after
a card's inserted.  But none of this should be necessary; the real
fix is to check whether we're using a GPIO and avoid relying on
the presence bit if so, as this patch implements.

Signed-off-by: Chris Ball 
---
 drivers/mmc/host/sdhci.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index d98b199..0e15c79 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sdhci.h"
 
@@ -1293,6 +1294,13 @@ static void sdhci_request(struct mmc_host *mmc, struct 
mmc_request *mrq)
present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
SDHCI_CARD_PRESENT;
 
+   /* If we're using a cd-gpio, testing the presence bit might fail. */
+   if (!present) {
+   int ret = mmc_gpio_get_cd(host->mmc);
+   if (ret > 0)
+   present = true;
+   }
+
if (!present || host->flags & SDHCI_DEVICE_DEAD) {
host->mrq->cmd->error = -ENOMEDIUM;
tasklet_schedule(&host->finish_tasklet);
-- 
1.7.11.2



- 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: cd-gpio and SDHCI presence

[Chris Ball]

Hi Guennadi, thanks for replying so quickly,

On Mon, Sep 17 2012, Guennadi Liakhovetski wrote:
>> "present" is false because SDHCI_PRESENT_STATE doesn't have the presence
>> bit sent (if it did, we wouldn't need a cd-gpio, right?) and the command
>> fails.
>> 
>> And we can't just set SDHCI_QUIRK_BROKEN_CARD_DETECTION, because that
>> would turn on polling, which we don't want.  How's this supposed to work?
>
> Sorry, I'm not very familiar with the SDHCI hardware or the driver, so, 
> I'll be speculating here.
>
> cd-gpio can function in two modes: polling and IRQ. IRQ is enabled if a 
> number of conditions is satisfied: gpio_to_irq() returns a non-negative 
> number, the user doesn't force polling by setting MMC_CAP_NEEDS_POLL and 
> request(_threaded)_irq() is successful. If either of the three conditions 
> fail, GPIO polling will be used.

Right, I'm in IRQ mode.

> Now, concerning SDHCI. cd-gpio doesn't magically make all MMC drivers 
> capable of using GPIO card detection, sorry:-) To use it you should first 
> make sure your driver can take card-present or card-detect information 
> from a GPIO. Then the slot-gpio module shall be used to add this GPIO CD 
> functionality to your driver instead of cooking it up by yourself.
>
> From the above it seems to me, that your SDHCI instance is not yet quite 
> trained to take GPIO input for card-detection:-) Looking through various 
> SDHCI implementations I see several drivers already implementing and using 
> various GPIO slot services internally: tegra, spear, s3c, pci, esdhc-imx. 
> They all seem to work with their own GPIO CD implementations, which are 
> very similar to the slot-gpio one and it shouldn't be too difficult to 
> replace them with the latter.

I'm using sdhci-pxav3, which is a small sdhci-pltfm driver.

I see now, thanks; what I was missing is that the other drivers are either:

* using IO accessors to fake the presence bit being set (esdhc-imx)
* using the ugly hack of just falling back to polling (s3c)
* running on a controller that doesn't have this problem (tegra?)

So the answer to "how's this supposed to work?" was "your driver needs
a workaround for reporting the presence bit", I guess.  Hopefully making
the change below should let us remove this unnecessary code from
esdhc-imx and s3c.

> Concerning how specifically it should work in your case - I'm not sure, 
> sorry. What platform are you working with? Does it already have GPIO 
> support? If it did, it should have been pretty simple to replace it with 
> the generic one from slot-gpio. Looking at the code, it seems to me, that 
> even on SDHCI systems, where a GPIO is used for card detection, the 
> controller is sometimes still able to recognise the card's presence. This 
> seems to be the case on tegra, pci (except cafe),... However, e.g., s3c 
> uses a dirty hack of setting and clearing 
> SDHCI_QUIRK_BROKEN_CARD_DETECTION in their CD routine... In general, I 
> think, it should suffice to do in sdhci_request() (and others) something 
> like
>
>   /* If polling, assume that the card is always present. */
>   if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
>   present = true;
>   else
>   present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
>   SDHCI_CARD_PRESENT;
>
>   if (!present) {
>   int ret = mmc_gpio_get_cd(host->mmc);
>   if (ret > 0)
>   present = true;
>   }

Makes sense, and works fine.  I'll prepare a formal patch and send it
out now -- please could you reply with your Signed-off-by, since I'll
put you in the From field?

> Also, once a card has been detected, shouldn't it be possible to use 
> mmc_card_present() to check its presence?

Sounds right, although that happens too late to help here.

Thanks very much!

- 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 v12] mmc: support BKOPS feature for eMMC

[Jaehoon Chung]

Enable eMMC background operations (BKOPS) feature.

If URGENT_BKOPS is set after a response, note that BKOPS
are required. Immediately run BKOPS if required.
read/write operations should be requested during BKOPS(LEVEL-1),
then issue HPI to interrupt the ongoing BKOPS 
and service the foreground operation.
(This patch is only control the LEVEL2/3.)

When repeating the writing 1GB data, at a certain time, performance is 
decreased.
At that time, card is also triggered the Level-3 or Level-2.
After running bkops, performance is recovered.

Future considerations
 * Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
 * Interrupt ongoing BKOPS before powering off the card.
 * How get BKOPS_STATUS value.(periodically send ext_csd command?)
 * If use periodic bkops, also consider runtime_pm control.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
Signed-off-by: Konstantin Dorfman 
Reviewed-by: Maya Erez 
---
Changelog v12:
- use the kamlloc for allocating the ext_csd.
: If use the periodic bkops, it should be modified.
Changelog v11:
- removed the MMC_CAP2_BKOPS.
: if card support and enable bkops, then use it.
Changelog v10:
- Based on latest mmc-next
- Only control the level-2/3.
: If triggered upper than level2, immediately start bkops.
- Remove the BKOPS_CAP2_INIT_BKOPS (move into mmc-util)
- change use_busy_signal instead of waiting_for_prog_done for 
__mmc_switch
- Remove the useless code.
- Add the from_exception to prepare the periodic bkops.
Changelog V9:
- Rebased on patch-v7.
- Added Konstantin and Maya's patch
: mmc:core: Define synchronous BKOPS timeout
: mmc:core: eMMC4.5 BKOPS fixes
- Removed periodic bkops
: This feature will do in future work
- Add __mmc_switch() for waiting_for_prod_done.

Changelog V8:
- Remove host->lock spin lock reviewed by Adrian
- Support periodic start bkops
- when bkops_status is level-3, if timeout is set to 0, send hpi.
- Move the start-bkops point
Changelog V7:
- Use HPI command when issued URGENT_BKOPS
- Recheck until clearing the bkops-status bit.
Changelog V6:
- Add the flag of check-bkops-status.
  (For fixing async_req problem)
- Add the capability for MMC_CAP2_INIT_BKOPS.
  (When unset the bkops_en bit in ext_csd register)
- modify the wrong condition.
Changelog V5:
- Rebase based on the latest mmc-next.
- modify codes based-on Chris's comment
Changelog V4:
- Add mmc_read_bkops_status
- When URGENT_BKOPS(level2-3), didn't use HPI command.
- In mmc_switch(), use R1B/R1 according to level.
Changelog V3:
- move the bkops setting's location in mmc_blk_issue_rw_rq
- modify condition checking
- bkops_en is assigned ext_csd[EXT_CSD_BKOPS_EN] instead of "1"
- remove the unused code
- change pr_debug instead of pr_warn in mmc_send_hpi_cmd
- Add the Future consideration suggested by Per
Changelog V2:
- Use EXCEPTION_STATUS instead of URGENT_BKOPS
- Add function to check Exception_status(for eMMC4.5)
---
 drivers/mmc/core/core.c|  157 +++-
 drivers/mmc/core/mmc.c |   11 +++
 drivers/mmc/core/mmc_ops.c |   26 ++-
 include/linux/mmc/card.h   |8 ++
 include/linux/mmc/core.h   |4 +
 include/linux/mmc/mmc.h|   19 +
 6 files changed, 219 insertions(+), 6 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index af2c4d2..4749557 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -41,6 +42,12 @@
 #include "sd_ops.h"
 #include "sdio_ops.h"
 
+/*
+ * The Background operation can take a long time, depends on the house keeping
+ * operations the card has to peform
+ */
+#define MMC_BKOPS_MAX_TIMEOUT  (4 * 60 * 1000) /* max time to wait in ms */
+
 static struct workqueue_struct *workqueue;
 static const unsigned freqs[] = { 40, 30, 20, 10 };
 
@@ -245,6 +252,70 @@ mmc_start_request(struct mmc_host *host, struct 
mmc_request *mrq)
host->ops->request(host, mrq);
 }
 
+/**
+ * mmc_start_bkops - start BKOPS for supported cards
+ * @card: MMC card to start BKOPS
+ * @form_exception: A flags to indicate if this function was
+ * called due to an exception raised by the card
+ *
+ * Start background operations whenever requested.
+ * when the urgent BKOPS bit is set in a R1 command response
+ * then background operations should be started immediately.
+*/
+void mmc_start_bkops(struct mmc_card *card, bool from_exception)
+{
+   int err;
+   int timeout;
+   bool use_busy_signal;
+
+   BUG_ON(!card);
+
+   i

[PATCH 3/4] drivers/mmc/host/omap_hsmmc.c: fix error return code

[Peter Senna Tschudin]

From: Peter Senna Tschudin 

Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
  ... when != ret = e2
  when forall
 return ret;
}
// 

Signed-off-by: Peter Senna Tschudin 
---
 drivers/mmc/host/omap_hsmmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e59ac62..c8a2b36 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1893,6 +1893,7 @@ static int __devinit omap_hsmmc_probe(struct 
platform_device *pdev)
if (pdata->init(&pdev->dev) != 0) {
dev_dbg(mmc_dev(host->mmc),
"Unable to configure MMC IRQs\n");
+   ret = -ENXIO;
goto err_irq_cd_init;
}
}
-- 
1.7.11.4

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

[PATCH 4/4] drivers/mmc/host/mxs-mmc.c: fix error return code

[Peter Senna Tschudin]

From: Peter Senna Tschudin 

Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
  ... when != ret = e2
  when forall
 return ret;
}
// 

Signed-off-by: Peter Senna Tschudin 
---
 drivers/mmc/host/mxs-mmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/mxs-mmc.c b/drivers/mmc/host/mxs-mmc.c
index 80d1e6d..afd8fdd 100644
--- a/drivers/mmc/host/mxs-mmc.c
+++ b/drivers/mmc/host/mxs-mmc.c
@@ -674,6 +674,7 @@ static int mxs_mmc_probe(struct platform_device *pdev)
if (!ssp->dmach) {
dev_err(mmc_dev(host->mmc),
"%s: failed to request dma\n", __func__);
+   ret = -ENODEV;
goto out_clk_put;
}
 
-- 
1.7.11.4

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

[PATCH 1/4] drivers/mmc/host/dw_mmc.c: fix error return code

[Peter Senna Tschudin]

From: Peter Senna Tschudin 

Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
  ... when != ret = e2
  when forall
 return ret;
}
// 

Signed-off-by: Peter Senna Tschudin 
---
 drivers/mmc/host/dw_mmc.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 36f98c0..7ad5176 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2039,8 +2039,10 @@ int dw_mci_probe(struct dw_mci *host)
tasklet_init(&host->tasklet, dw_mci_tasklet_func, (unsigned long)host);
host->card_workqueue = alloc_workqueue("dw-mci-card",
WQ_MEM_RECLAIM | WQ_NON_REENTRANT, 1);
-   if (!host->card_workqueue)
+   if (!host->card_workqueue) {
+   err = -ENOMEM;
goto err_dmaunmap;
+   }
INIT_WORK(&host->card_work, dw_mci_work_routine_card);
ret = request_irq(host->irq, dw_mci_interrupt, host->irq_flags, 
"dw-mci", host);
if (ret)
-- 
1.7.11.4

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

[PATCH 2/4] drivers/mmc/host/omap.c: fix error return code

[Peter Senna Tschudin]

From: Peter Senna Tschudin 

Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// 
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
  ... when != ret = e2
  when forall
 return ret;
}
// 

Signed-off-by: Peter Senna Tschudin 
---
 drivers/mmc/host/omap.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap.c b/drivers/mmc/host/omap.c
index 48ad361..d468f51 100644
--- a/drivers/mmc/host/omap.c
+++ b/drivers/mmc/host/omap.c
@@ -1369,8 +1369,10 @@ static int __devinit mmc_omap_probe(struct 
platform_device *pdev)
host->irq = irq;
host->phys_base = host->mem_res->start;
host->virt_base = ioremap(res->start, resource_size(res));
-   if (!host->virt_base)
+   if (!host->virt_base) {
+   ret = -ENOMEM;
goto err_ioremap;
+   }
 
host->iclk = clk_get(&pdev->dev, "ick");
if (IS_ERR(host->iclk)) {
@@ -1438,8 +1440,10 @@ static int __devinit mmc_omap_probe(struct 
platform_device *pdev)
host->reg_shift = (cpu_is_omap7xx() ? 1 : 2);
 
host->mmc_omap_wq = alloc_workqueue("mmc_omap", 0, 0);
-   if (!host->mmc_omap_wq)
+   if (!host->mmc_omap_wq) {
+   err = -ENOMEM;
goto err_plat_cleanup;
+   }
 
for (i = 0; i < pdata->nr_slots; i++) {
ret = mmc_omap_new_slot(host, i);
-- 
1.7.11.4

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

Re: [PATCH 00/34] i.MX multi-platform support

[Sascha Hauer]

Hi Shawn,

On Mon, Sep 17, 2012 at 01:34:29PM +0800, Shawn Guo wrote:
> The series enables multi-platform support for imx.  Since the required
> frameworks (clk, pwm) and spare_irq have already been adopted on imx,
> the series is all about cleaning up mach/* headers.  Along with the
> changes, arch/arm/plat-mxc gets merged into arch/arm/mach-imx.
> 
> It's based on a bunch of branches (works from others), Rob's initial
> multi-platform series, Arnd's platform-data and smp_ops (Marc's) and
> imx 3.7 material (Sascha and myself).
> 
> It's available on branch below.
> 
>   git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform
> 
> It's been tested on imx5 and imx6, and only compile-tested on imx2 and
> imx3, so testing on imx2/3 are appreciated.

Great work! This really pushes the i.MX architecture one step closer to
a clean code base.

I gave it a test on i.MX1, i.MX27, i.MX31 and i.MX35. All run fine, but
the last patch breaks the imx_v4_v5_defconfig: Somehow it now defaults
to ARMv7 based machines. I haven't looked into it, just reenabled
ARMv4/ARMv5 and the boards again -> works. The config should be updated
with the last patch.

I'm fine with the changes to mx2-camera, but Javier should give his ok
to it, he has worked on it quite a lot recently.

One other issue related to imx-dma, see comment to that patch.

Otherwise:

Acked-by: Sascha Hauer 
Tested-by: Sascha Hauer 

Thanks
 Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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 v2 2/3] mmc: davinci_mmc: convert to DMA engine API

[Chris Ball]

Hi,

On Wed, Aug 22 2012, Koen Kooi wrote:
> Op 21-08-12 20:43, Matt Porter schreef:
>> Removes use of the DaVinci EDMA private DMA API and replaces it with use
>> of the DMA engine API.
>> 
>> Signed-off-by: Matt Porter 
>
> Runtime tested on hawkboard with 3.6.0-rc2 with rootfs on SD and running
> bonnie++ on it.
>
> Tested-by: Koen Kooi 

Thanks, pushed to mmc-next for 3.7.

- 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] mmc: sdio: Fix PM_SLEEP related build warnings

[Chris Ball]

Hi,

On Thu, Aug 09 2012, Rafael J. Wysocki wrote:
> On Thursday, August 09, 2012, Thierry Reding wrote:
>> Power management callbacks defined by SIMPLE_DEV_PM_OPS are only used if
>> the PM_SLEEP Kconfig symbol has been defined. If not, the compiler will
>> complain about them being unused. However, since the callback for this
>> driver doesn't do anything it can just as well be dropped.
>> 
>> Signed-off-by: Thierry Reding 
>
> Acked-by: Rafael J. Wysocki 

Thanks, pushed to mmc-next for 3.7.

- 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 v6] mmc: core: Remove bounce buffer in mmc_send_cxd_data()

[Chris Ball]

Hi,

On Thu, Aug 02 2012, Kyungsik Lee wrote:
> It is expected that Extended CSD register(the size of this register
> is larger than CID/CSD) will be referenced more frequently as more
> fields have been added to Extended CSD and it seems that it is not
> a good option to double the memory used.
>
> This patch is intended to avoid the use of bounce buffer for reading
> Extended CSD register in mmc_send_cxd_data(). It will provide a better
> performance gain by removing memcpy() overhead for a half KiB and
> a redundant bounce buffer allocated repeatedly at the cost of providing
> DMA-capable buffer from upper caller(but on-stack buffer is allowed
> with no performance gain).
>
> Signed-off-by: Kyungsik Lee 
> Reviewed-by: Venkatraman S 

Thanks, pushed to mmc-next for 3.7.

- 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: cd-gpio and SDHCI presence

[Guennadi Liakhovetski]

Hi Chris

On Mon, 17 Sep 2012, Chris Ball wrote:

> Hi Guennadi,
> 
> I'm having trouble using a cd-gpio.  After I request it, I get the
> IRQ and mmc_rescan() triggers successfully, but mmc_attach_sd()
> fails because every command returns -123 (ENOMEDIUM), due to:
> 
> sdhci.c:
>   /* If polling, assume that the card is always present. */
>   if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
>   present = true;
>   else
>   present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
>   SDHCI_CARD_PRESENT;
> 
>   if (!present || host->flags & SDHCI_DEVICE_DEAD) {
>   host->mrq->cmd->error = -ENOMEDIUM;
>   tasklet_schedule(&host->finish_tasklet);
>   } else { 
>   ...
> 
> "present" is false because SDHCI_PRESENT_STATE doesn't have the presence
> bit sent (if it did, we wouldn't need a cd-gpio, right?) and the command
> fails.
> 
> And we can't just set SDHCI_QUIRK_BROKEN_CARD_DETECTION, because that
> would turn on polling, which we don't want.  How's this supposed to work?

Sorry, I'm not very familiar with the SDHCI hardware or the driver, so, 
I'll be speculating here.

cd-gpio can function in two modes: polling and IRQ. IRQ is enabled if a 
number of conditions is satisfied: gpio_to_irq() returns a non-negative 
number, the user doesn't force polling by setting MMC_CAP_NEEDS_POLL and 
request(_threaded)_irq() is successful. If either of the three conditions 
fail, GPIO polling will be used.

Now, concerning SDHCI. cd-gpio doesn't magically make all MMC drivers 
capable of using GPIO card detection, sorry:-) To use it you should first 
make sure your driver can take card-present or card-detect information 
from a GPIO. Then the slot-gpio module shall be used to add this GPIO CD 
functionality to your driver instead of cooking it up by yourself.

>From the above it seems to me, that your SDHCI instance is not yet quite 
trained to take GPIO input for card-detection:-) Looking through various 
SDHCI implementations I see several drivers already implementing and using 
various GPIO slot services internally: tegra, spear, s3c, pci, esdhc-imx. 
They all seem to work with their own GPIO CD implementations, which are 
very similar to the slot-gpio one and it shouldn't be too difficult to 
replace them with the latter.

Concerning how specifically it should work in your case - I'm not sure, 
sorry. What platform are you working with? Does it already have GPIO 
support? If it did, it should have been pretty simple to replace it with 
the generic one from slot-gpio. Looking at the code, it seems to me, that 
even on SDHCI systems, where a GPIO is used for card detection, the 
controller is sometimes still able to recognise the card's presence. This 
seems to be the case on tegra, pci (except cafe),... However, e.g., s3c 
uses a dirty hack of setting and clearing 
SDHCI_QUIRK_BROKEN_CARD_DETECTION in their CD routine... In general, I 
think, it should suffice to do in sdhci_request() (and others) something 
like

/* If polling, assume that the card is always present. */
if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
present = true;
else
present = sdhci_readl(host, SDHCI_PRESENT_STATE) &
SDHCI_CARD_PRESENT;

if (!present) {
int ret = mmc_gpio_get_cd(host->mmc);
if (ret > 0)
present = true;
}

Also, once a card has been detected, shouldn't it be possible to use 
mmc_card_present() to check its presence?

Thanks
Guennadi

> Maybe your system was differently broken, and we need some new way to
> communicate that neither the PRESENT bit nor polling should be used?
> 
> 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