Re: [PATCH v2] mmc: dw-mmc: relocate the position called dw_mci_setup_bus()

[Jaehoon Chung]

Dear Seungwon,

On 10/30/2012 02:27 PM, Seungwon Jeon wrote:
> Monday, October 29, 2012, Jaehoon Chung  wrote:
>> On 10/29/2012 06:08 PM, Seungwon Jeon wrote:
>>> Monday, October 29, 2012, Jaehoon Chung 
 After power-on, must be ensured at least 74~80 clocks before sending any 
 first command.
 To ensure, it's good that dw_mci_setup_bus() is located at dw_mci_set_ios
 instead of __dw_mci_start_request()
>>> After power-up, host driver sets 'DW_MMC_CARD_NEED_INIT' flag, right?
>>> And then, this flag help to add SDMMC_CMD_INIT flag into CMD, when 
>>> __dw_mci_start_request is
>> executed.
>>> 74~80 clocks is ensured with SDMMC_CMD_INIT regardless location change, 
>>> isn't it?
>>> I mentioned this part in previous mail. Could you check it?
>> According to eMMC spec, after power-on, need to wait for 74-clock before 
>> sending first command
>> You can see code that after mmc_set_ios(), waiting for mmc_delay(10) into 
>> mmc_power_up().
>> (You can read the comment at mmc_power_up(), Maybe mmc_delay(10) didn't 
>> ensure the 74-clock).
> There is 'send_initialization' bit in CMD register.
> If this bit set with CMD0, it will guarantee 80 clocks by host controller.
Is it guaranteed 80-clocks by host-controller? So I understood something wrong.
My understanding is that "if flags is set, need to wait for 80-clock."
If host-controller can ensure the 80-clock, location is not important.

My point was just entire sequence with core.c and dw_mmc.c
Anyway, thank you for review.
If i miss other thing. let me know, plz.

Best Regards,
Jaehoon Chung

> Currently this is applied in driver.
> I agree change the location of dw_mci_setup_bus.
> But commit message seem not proper for it.
> Please let me know, if I miss something.
> 
> Thanks,
> Seungwon Jeon
>>
>> Best Regards,
>> Jaehoon Chung
>>>
>>> Thanks,
>>> Seungwon Jeon
>>>

 Signed-off-by: Jaehoon Chung 
 Signed-off-by: Kyungmin Park 
 Acked-by: Seungwon Jeon 
 --
 Changelog V2:
- Modified the commit-message.
 ---
  drivers/mmc/host/dw_mmc.c |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)

 diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
 index 4b2bedc..de79093 100644
 --- a/drivers/mmc/host/dw_mmc.c
 +++ b/drivers/mmc/host/dw_mmc.c
 @@ -682,9 +682,6 @@ static void __dw_mci_start_request(struct dw_mci *host,
if (host->pdata->select_slot)
host->pdata->select_slot(slot->id);

 -  /* Slot specific timing and width adjustment */
 -  dw_mci_setup_bus(slot);
 -
host->cur_slot = slot;
host->mrq = mrq;

 @@ -810,6 +807,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
 struct mmc_ios *ios)
if (slot->host->drv_data->set_ios)
slot->host->drv_data->set_ios(slot->host, ios);

 +  /* Slot specific timing and width adjustment */
 +  dw_mci_setup_bus(slot);
 +
switch (ios->power_mode) {
case MMC_POWER_UP:
set_bit(DW_MMC_CARD_NEED_INIT, &slot->flags);
 --
 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
>>>
>>> --
>>> 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
> 
> --
> 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: [RFC PATCH v3 13/16] ARM: dts: add AM33XX MMC support

[AnilKumar, Chimata]

On Thu, Oct 18, 2012 at 18:56:52, Porter, Matt wrote:
> Adds AM33XX MMC support for am335x-bone and am335x-evm.
> 
> Signed-off-by: Matt Porter 
> ---
>  arch/arm/boot/dts/am335x-bone.dts |6 ++
>  arch/arm/boot/dts/am335x-evm.dts  |6 ++
>  arch/arm/boot/dts/am33xx.dtsi |   27 +++
>  3 files changed, 39 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone.dts 
> b/arch/arm/boot/dts/am335x-bone.dts
> index c634f87..5510979 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -70,6 +70,8 @@
>   };
>  
>   ldo3_reg: regulator@5 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;

I think these min & max limits are regulator limits. Are these fields
required? Add details of these additions. AFAIK fine-tuned (board
specific) min/max limits should be add here(like mpu and core
regulator nodes)

>   regulator-always-on;
>   };
>  
> @@ -78,3 +80,7 @@
>   };
>   };
>  };
> +
> +&mmc1 {
> + vmmc-supply = <&ldo3_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts 
> b/arch/arm/boot/dts/am335x-evm.dts
> index 185d632..d63fce8 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -114,7 +114,13 @@
>   };
>  
>   vmmc_reg: regulator@12 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <330>;

=same=

>   regulator-always-on;
>   };
>   };
>  };
> +
> +&mmc1 {
> + vmmc-supply = <&vmmc_reg>;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index ab9c78f..26a6af7 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -234,6 +234,33 @@
>   status = "disabled";
>   };
>  
> + mmc1: mmc@4806 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc1";
> + ti,dual-volt;
> + ti,needs-special-reset;
> + dmas = <&edma 24
> + &edma 25>;
> + dma-names = "tx", "rx";

Add status = "disabled" here and "okay" in corresponding
.dts file

> + };
> +
> + mmc2: mmc@481d8000 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc2";
> + ti,needs-special-reset;
> + dmas = <&edma 2
> + &edma 3>;
> + dma-names = "tx", "rx";
> + status = "disabled";
> + };
> +
> + mmc3: mmc@4781 {
> + compatible = "ti,omap3-hsmmc";
> + ti,hwmods = "mmc3";
> + ti,needs-special-reset;

What about DMA resources for mmc3?

AnilKumar

> + status = "disabled";
> + };
> +
>   wdt2: wdt@44e35000 {
>   compatible = "ti,omap3-wdt";
>   ti,hwmods = "wd_timer2";
> -- 
> 1.7.9.5
> 
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 

--
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 v2 2/2] mmc: sdhci-s3c: fix the card detection in runtime-pm

[Seungwon Jeon]

If host clock is disabled, host cannot detect a card
in case of using CD internal for detection.

Signed-off-by: Seungwon Jeon 
---
Rebased with mmc-next.

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

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index a79b153..d680c0b 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -747,7 +747,8 @@ static int __devinit sdhci_s3c_probe(struct platform_device 
*pdev)
sdhci_s3c_setup_card_detect_gpio(sc);
 
 #ifdef CONFIG_PM_RUNTIME
-   clk_disable_unprepare(sc->clk_io);
+   if (pdata->cd_type != S3C_SDHCI_CD_INTERNAL)
+   clk_disable_unprepare(sc->clk_io);
 #endif
return 0;
 
@@ -794,7 +795,8 @@ static int __devexit sdhci_s3c_remove(struct 
platform_device *pdev)
gpio_free(sc->ext_cd_gpio);
 
 #ifdef CONFIG_PM_RUNTIME
-   clk_prepare_enable(sc->clk_io);
+   if (pdata->cd_type != S3C_SDHCI_CD_INTERNAL)
+   clk_prepare_enable(sc->clk_io);
 #endif
sdhci_remove_host(host, 1);
 
-- 
1.7.0.4


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

[PATCH v2 1/2] mmc: sdhci-s3c: ensure non-transaction of bus before clk_disable

[Seungwon Jeon]

clock shoud be supplied during bus transaction. This patch defers
clk_disabe in runtime_suspend if cmd/data line is used.

Signed-off-by: Seungwon Jeon 
Acked-by: Heiko Stuebner 
---
Rebased with mmc-next.

 drivers/mmc/host/sdhci-s3c.c |   13 +
 drivers/mmc/host/sdhci.c |   20 
 drivers/mmc/host/sdhci.h |   11 +++
 3 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index a093e2e..a79b153 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -845,12 +845,17 @@ static int sdhci_s3c_runtime_suspend(struct device *dev)
struct sdhci_host *host = dev_get_drvdata(dev);
struct sdhci_s3c *ourhost = to_s3c(host);
struct clk *busclk = ourhost->clk_io;
-   int ret;
+   int ret = 0;
 
-   ret = sdhci_runtime_suspend_host(host);
+   if (!(readl(host->ioaddr + SDHCI_PRESENT_STATE) &
+   (SDHCI_CMD_INHIBIT | SDHCI_DATA_INHIBIT))) {
+   ret = sdhci_runtime_suspend_host(host);
+   clk_disable_unprepare(ourhost->clk_bus[ourhost->cur_clk]);
+   clk_disable_unprepare(busclk);
+   } else {
+   sdhci_runtime_pm_put(host);
+   }
 
-   clk_disable_unprepare(ourhost->clk_bus[ourhost->cur_clk]);
-   clk_disable_unprepare(busclk);
return ret;
 }
 
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f05a377..d62646d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -54,20 +54,6 @@ static void sdhci_finish_command(struct sdhci_host *);
 static int sdhci_execute_tuning(struct mmc_host *mmc, u32 opcode);
 static void sdhci_tuning_timer(unsigned long data);
 
-#ifdef CONFIG_PM_RUNTIME
-static int sdhci_runtime_pm_get(struct sdhci_host *host);
-static int sdhci_runtime_pm_put(struct sdhci_host *host);
-#else
-static inline int sdhci_runtime_pm_get(struct sdhci_host *host)
-{
-   return 0;
-}
-static inline int sdhci_runtime_pm_put(struct sdhci_host *host)
-{
-   return 0;
-}
-#endif
-
 static void sdhci_dumpregs(struct sdhci_host *host)
 {
pr_debug(DRIVER_NAME ": === REGISTER DUMP (%s)===\n",
@@ -2535,16 +2521,18 @@ EXPORT_SYMBOL_GPL(sdhci_enable_irq_wakeups);
 
 #ifdef CONFIG_PM_RUNTIME
 
-static int sdhci_runtime_pm_get(struct sdhci_host *host)
+int sdhci_runtime_pm_get(struct sdhci_host *host)
 {
return pm_runtime_get_sync(host->mmc->parent);
 }
+EXPORT_SYMBOL_GPL(sdhci_runtime_pm_get);
 
-static int sdhci_runtime_pm_put(struct sdhci_host *host)
+int sdhci_runtime_pm_put(struct sdhci_host *host)
 {
pm_runtime_mark_last_busy(host->mmc->parent);
return pm_runtime_put_autosuspend(host->mmc->parent);
 }
+EXPORT_SYMBOL_GPL(sdhci_runtime_pm_put);
 
 int sdhci_runtime_suspend_host(struct sdhci_host *host)
 {
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 71a4a7e..a42a192 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -385,8 +385,19 @@ extern void sdhci_enable_irq_wakeups(struct sdhci_host 
*host);
 #endif
 
 #ifdef CONFIG_PM_RUNTIME
+extern int sdhci_runtime_pm_get(struct sdhci_host *host);
+extern int sdhci_runtime_pm_put(struct sdhci_host *host);
 extern int sdhci_runtime_suspend_host(struct sdhci_host *host);
 extern int sdhci_runtime_resume_host(struct sdhci_host *host);
+#else
+inline int sdhci_runtime_pm_get(struct sdhci_host *host)
+{
+   return 0;
+}
+inline int sdhci_runtime_pm_put(struct sdhci_host *host)
+{
+   return 0;
+}
 #endif
 
 #endif /* __SDHCI_HW_H */
-- 
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 v2] mmc: dw-mmc: relocate the position called dw_mci_setup_bus()

[Seungwon Jeon]

Monday, October 29, 2012, Jaehoon Chung  wrote:
> On 10/29/2012 06:08 PM, Seungwon Jeon wrote:
> > Monday, October 29, 2012, Jaehoon Chung 
> >> After power-on, must be ensured at least 74~80 clocks before sending any 
> >> first command.
> >> To ensure, it's good that dw_mci_setup_bus() is located at dw_mci_set_ios
> >> instead of __dw_mci_start_request()
> > After power-up, host driver sets 'DW_MMC_CARD_NEED_INIT' flag, right?
> > And then, this flag help to add SDMMC_CMD_INIT flag into CMD, when 
> > __dw_mci_start_request is
> executed.
> > 74~80 clocks is ensured with SDMMC_CMD_INIT regardless location change, 
> > isn't it?
> > I mentioned this part in previous mail. Could you check it?
> According to eMMC spec, after power-on, need to wait for 74-clock before 
> sending first command
> You can see code that after mmc_set_ios(), waiting for mmc_delay(10) into 
> mmc_power_up().
> (You can read the comment at mmc_power_up(), Maybe mmc_delay(10) didn't 
> ensure the 74-clock).
There is 'send_initialization' bit in CMD register.
If this bit set with CMD0, it will guarantee 80 clocks by host controller.
Currently this is applied in driver.
I agree change the location of dw_mci_setup_bus.
But commit message seem not proper for it.
Please let me know, if I miss something.

Thanks,
Seungwon Jeon
> 
> Best Regards,
> Jaehoon Chung
> >
> > Thanks,
> > Seungwon Jeon
> >
> >>
> >> Signed-off-by: Jaehoon Chung 
> >> Signed-off-by: Kyungmin Park 
> >> Acked-by: Seungwon Jeon 
> >> --
> >> Changelog V2:
> >>- Modified the commit-message.
> >> ---
> >>  drivers/mmc/host/dw_mmc.c |6 +++---
> >>  1 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> >> index 4b2bedc..de79093 100644
> >> --- a/drivers/mmc/host/dw_mmc.c
> >> +++ b/drivers/mmc/host/dw_mmc.c
> >> @@ -682,9 +682,6 @@ static void __dw_mci_start_request(struct dw_mci *host,
> >>if (host->pdata->select_slot)
> >>host->pdata->select_slot(slot->id);
> >>
> >> -  /* Slot specific timing and width adjustment */
> >> -  dw_mci_setup_bus(slot);
> >> -
> >>host->cur_slot = slot;
> >>host->mrq = mrq;
> >>
> >> @@ -810,6 +807,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, 
> >> struct mmc_ios *ios)
> >>if (slot->host->drv_data->set_ios)
> >>slot->host->drv_data->set_ios(slot->host, ios);
> >>
> >> +  /* Slot specific timing and width adjustment */
> >> +  dw_mci_setup_bus(slot);
> >> +
> >>switch (ios->power_mode) {
> >>case MMC_POWER_UP:
> >>set_bit(DW_MMC_CARD_NEED_INIT, &slot->flags);
> >> --
> >> 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
> >
> > --
> > 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

--
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] mmc: sdhci-s3c: fix the card detection in runtime-pm

[Seungwon Jeon]

Tuesday, October 30, 2012, Heiko Stuebner  wrote:
> Hi Chris,
> 
> Am Montag, 29. Oktober 2012, 22:16:47 schrieb Chris Ball:
> > Hi,
> >
> > On Fri, Oct 19 2012, Heiko Stübner wrote:
> > > Am Freitag, 19. Oktober 2012, 10:04:14 schrieb Seungwon Jeon:
> > >> On Thursday, October 18, 2012, Heiko Stuebner 
> > >>
> > >> > If host clock is disabled, host cannot detect a card
> > >> > in case of using the internal or gpio card-detect for detection.
> > >> >
> > >> > Signed-off-by: Seungwon Jeon 
> > >> > Tested-by: Heiko Stuebner 
> > >> > ---
> > >> > I've added the SDHCI_CD_GPIO to the conditional. With this change it
> > >> > works on my machine. But I'm not sure if this would also be necessary
> > >> > for the external card detect.
> > >>
> > >> Card detection will be asserted out of host in case of using
> > >> SDHCI_CD_GPIO. Adding SDHCI_CD_GPIO to the conditional seems
> > >> unnecessary.
> > >
> > > But it _was_ necessary :-) . Because only then did the problem go away.
> > > You might be right, that there exists a better solution for this, but
> > > something in the original patch is at least still missing to fix the
> > > problem.
> >
> > Seungwon, what would you like to do here?  (I'm unhappy taking a patch
> > with your name on it that's been modified in a way you disagree with.)
> 
> I agree with Seungwon, that the solution in my v2 is not the correct one :-) -
> should've called it RFC or so. The gpio-card-detect code _should_ be able to
> handle the resume of the host itself in the card detect case, but it seems
> it's not able to.
> 
> The patch in its v1 form does not fix the problem commit 2abeb5c5ded2 (mmc:
> sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume) has caused for
> Samsung devices using the gpio card-detect - it's broken in 3.7 currently.
> 
> 
> So for 3.7 the easiest way would of course be to revert the commit above and
> find a correct solution for 3.8.

Hi Chris,

This patch doesn't aim Heiko's problem but guarantee card detection for using 
internal CD.
Clock should be enabled for internal card detection of host.

Thanks,
Seungwon Jeon
> 
> 
> Heiko
> --
> 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 v7 0/3] Add modules to support realtek PCIE card reader

[wwang]

Hi Chris, Samuel and Alex:

Can you help to review this patchset, please?

I have asked Greg to remove rts_pstor from the staging tree. So this
driver have to be merged into 3.8 kernel, or else Realtek'sPCI-E card
reader can not be accessed easily.

BR,
Wei WANG

--
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] mmc: sdhci-s3c: fix the card detection in runtime-pm

[Heiko Stübner]

Hi Chris,

Am Montag, 29. Oktober 2012, 22:16:47 schrieb Chris Ball:
> Hi,
> 
> On Fri, Oct 19 2012, Heiko Stübner wrote:
> > Am Freitag, 19. Oktober 2012, 10:04:14 schrieb Seungwon Jeon:
> >> On Thursday, October 18, 2012, Heiko Stuebner 
> >> 
> >> > If host clock is disabled, host cannot detect a card
> >> > in case of using the internal or gpio card-detect for detection.
> >> > 
> >> > Signed-off-by: Seungwon Jeon 
> >> > Tested-by: Heiko Stuebner 
> >> > ---
> >> > I've added the SDHCI_CD_GPIO to the conditional. With this change it
> >> > works on my machine. But I'm not sure if this would also be necessary
> >> > for the external card detect.
> >> 
> >> Card detection will be asserted out of host in case of using
> >> SDHCI_CD_GPIO. Adding SDHCI_CD_GPIO to the conditional seems
> >> unnecessary.
> > 
> > But it _was_ necessary :-) . Because only then did the problem go away.
> > You might be right, that there exists a better solution for this, but
> > something in the original patch is at least still missing to fix the
> > problem.
> 
> Seungwon, what would you like to do here?  (I'm unhappy taking a patch
> with your name on it that's been modified in a way you disagree with.)

I agree with Seungwon, that the solution in my v2 is not the correct one :-) - 
should've called it RFC or so. The gpio-card-detect code _should_ be able to 
handle the resume of the host itself in the card detect case, but it seems 
it's not able to.

The patch in its v1 form does not fix the problem commit 2abeb5c5ded2 (mmc: 
sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume) has caused for 
Samsung devices using the gpio card-detect - it's broken in 3.7 currently.


So for 3.7 the easiest way would of course be to revert the commit above and 
find a correct solution for 3.8.


Heiko
--
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: fix sdhci-dove removal

[Chris Ball]

Hi,

On Mon, Oct 29 2012, Sebastian Hesselbarth wrote:
> On 10/29/2012 10:49 PM, Chris Ball wrote:
>> On Mon, Oct 29 2012, Russell King - ARM Linux wrote:
>>> Anyway, here's a replacement patch, updated against my cubox tree but
>>> lacking the cubox gpio changes for it.  Un-tested through: (a) I can't
>>> test this on its own on the cubox, (b) I don't have a separate dove
>>> tree to test it against and my disk space is all but out at the moment
>>> for yet another build tree...
>>
>> Compile-tested and pushed to mmc-next, and I'll submit it for 3.7 if
>> I get a Tested-by from someone like Sebastian (CC'd), or for 3.8 if I
>> don't.  (I'll add sdhci-pltfm API rework to my TODO list, too.)
>
> Chris, Russell,
>
> obviously I am not the one to ask for a Tested-by because it was my
> patch that originally caused all the trouble. My apologies for this!
>
> Anyway, I did test the patch on 3.7-rc3 and except that you need a
> 3-way git am because of a one-line offset, sdhci-dove runs just fine.
>
> Tested-by: Sebastian Hesselbarth 

Great, thanks -- will push to 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: fix sdhci-dove removal

[Sebastian Hesselbarth]

On 10/29/2012 10:49 PM, Chris Ball wrote:

On Mon, Oct 29 2012, Russell King - ARM Linux wrote:

Anyway, here's a replacement patch, updated against my cubox tree but
lacking the cubox gpio changes for it.  Un-tested through: (a) I can't
test this on its own on the cubox, (b) I don't have a separate dove
tree to test it against and my disk space is all but out at the moment
for yet another build tree...


Compile-tested and pushed to mmc-next, and I'll submit it for 3.7 if
I get a Tested-by from someone like Sebastian (CC'd), or for 3.8 if I
don't.  (I'll add sdhci-pltfm API rework to my TODO list, too.)


Chris, Russell,

obviously I am not the one to ask for a Tested-by because it was my
patch that originally caused all the trouble. My apologies for this!

Anyway, I did test the patch on 3.7-rc3 and except that you need a
3-way git am because of a one-line offset, sdhci-dove runs just fine.

Tested-by: Sebastian Hesselbarth 
--
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: fix sdhci-dove removal

[Chris Ball]

Hi,

On Mon, Oct 29 2012, Russell King - ARM Linux wrote:
> Anyway, here's a replacement patch, updated against my cubox tree but
> lacking the cubox gpio changes for it.  Un-tested through: (a) I can't
> test this on its own on the cubox, (b) I don't have a separate dove
> tree to test it against and my disk space is all but out at the moment
> for yet another build tree...

Compile-tested and pushed to mmc-next, and I'll submit it for 3.7 if
I get a Tested-by from someone like Sebastian (CC'd), or for 3.8 if I
don't.  (I'll add sdhci-pltfm API rework to my TODO list, too.)

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] MMC: fix sdhci-dove removal

[Russell King - ARM Linux]

On Mon, Oct 29, 2012 at 05:10:37PM -0400, Chris Ball wrote:
> Hi Russell,
> 
> On Mon, Oct 15 2012, Russell King - ARM Linux wrote:
> > Here's an updated patch which just about fixes the sdhci-dove driver.
> > I would not be surprised given the idiotic sdhci-pltfm API if many
> > other drivers suffered the same bug.
> >
> > 8<
> > From: Russell King 
> > Subject: [PATCH] MMC: fix sdhci-dove probe/removal
> >
> > 1. Never ever publish a device in the system before it has been setup
> >to a usable state.
> > 2. Unregister the device _BEFORE_ taking away any resources it may be
> >using.
> > 3. Don't check clks against NULL.
> >
> > Signed-off-by: Russell King 
> 
> This version of the patch doesn't apply cleanly or compile -- maybe you
> have a later revision?

Well, I'm only going to send a patch against 3.6 because that's the
kernel I'm running on the cubox - which is the platform I'm finding
these bugs on.  As it's a platform which I want to keep stable for
other work, it's not getting -rc kernels on it.

It's also been through several revisions across conflict resolutions
which is why the above errors occurred (thanks to having to fix them
up multiple times.)  And to top it off, there's additional patches
below this one too, so separating out just the fix is virtually
impossible to do safely.

Anyway, here's a replacement patch, updated against my cubox tree but
lacking the cubox gpio changes for it.  Un-tested through: (a) I can't
test this on its own on the cubox, (b) I don't have a separate dove
tree to test it against and my disk space is all but out at the moment
for yet another build tree...

It would helpful of course to have _more_ of the cubox stuff in mainline
but unfortunately it's all non-DT so wouldn't be accepted.

 drivers/mmc/host/sdhci-dove.c |   38 --
 1 files changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/host/sdhci-dove.c b/drivers/mmc/host/sdhci-dove.c
index a6e53a1..bb3cefe 100644
--- a/drivers/mmc/host/sdhci-dove.c
+++ b/drivers/mmc/host/sdhci-dove.c
@@ -19,6 +19,7 @@
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -83,30 +84,32 @@ static int __devinit sdhci_dove_probe(struct 
platform_device *pdev)
struct sdhci_dove_priv *priv;
int ret;
 
-   ret = sdhci_pltfm_register(pdev, &sdhci_dove_pdata);
-   if (ret)
-   goto sdhci_dove_register_fail;
-
priv = devm_kzalloc(&pdev->dev, sizeof(struct sdhci_dove_priv),
GFP_KERNEL);
if (!priv) {
dev_err(&pdev->dev, "unable to allocate private data");
-   ret = -ENOMEM;
-   goto sdhci_dove_allocate_fail;
+   return -ENOMEM;
}
 
+   priv->clk = clk_get(&pdev->dev, NULL);
+   if (!IS_ERR(priv->clk))
+   clk_prepare_enable(priv->clk);
+
+   ret = sdhci_pltfm_register(pdev, &sdhci_dove_pdata);
+   if (ret)
+   goto sdhci_dove_register_fail;
+
host = platform_get_drvdata(pdev);
pltfm_host = sdhci_priv(host);
pltfm_host->priv = priv;
 
-   priv->clk = clk_get(&pdev->dev, NULL);
-   if (!IS_ERR(priv->clk))
-   clk_prepare_enable(priv->clk);
return 0;
 
-sdhci_dove_allocate_fail:
-   sdhci_pltfm_unregister(pdev);
 sdhci_dove_register_fail:
+   if (!IS_ERR(priv->clk)) {
+   clk_disable_unprepare(priv->clk);
+   clk_put(priv->clk);
+   }
return ret;
 }
 
@@ -116,14 +119,13 @@ static int __devexit sdhci_dove_remove(struct 
platform_device *pdev)
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
struct sdhci_dove_priv *priv = pltfm_host->priv;
 
-   if (priv->clk) {
-   if (!IS_ERR(priv->clk)) {
-   clk_disable_unprepare(priv->clk);
-   clk_put(priv->clk);
-   }
-   devm_kfree(&pdev->dev, priv->clk);
+   sdhci_pltfm_unregister(pdev);
+
+   if (!IS_ERR(priv->clk)) {
+   clk_disable_unprepare(priv->clk);
+   clk_put(priv->clk);
}
-   return sdhci_pltfm_unregister(pdev);
+   return 0;
 }
 
 static struct platform_driver sdhci_dove_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: [PATCH v1] mmc: fix async request mechanism for sequential read scenarios

[Per Forlin]

Hi,

I would like to move the focus of my concerns from root cause analysis
to the actual patch,
My first reflection is that the patch is relatively complex and some
of the code looks duplicated.
Would it be possible to simplify it and re-use  the current execution flow.

Is the following flow feasible?

in mmc_start_req():
--
if (rqc == NULL && not_resend)
  wait_for_both_mmc_and_arrival_of_new_req
else
  wait_only_for_mmc

if (arrival_of_new_req) {
   set flag to indicate fetch-new_req
  return NULL;
}
-

in queue.c:
if (fetch-new_req)
  don't overwrite previous req.

BR
Per



On Sun, Oct 28, 2012 at 2:12 PM, Konstantin Dorfman
 wrote:
> Hello,
>
> On 10/26/2012 02:07 PM, Venkatraman S wrote:
>
>>
>> Actually there could a lot of reasons why block layer or CFQ would not have
>> inserted the request into the queue. i.e. you can see a lot of exit paths
>> where blk_peek_request returns NULL, even though there could be any request
>> pending in one of the CFQ requests queues.
>>
>> Essentially you need to check what makes blk_fetch_request
>> (cfq_dispatch_requests() ) return NULL when there is an element in
>> queue, if at all.
>>
>
> This is not important why block layer causes to blk_fetch_request() (or
> blk_peek_request()) to return NULL to the MMC layer, but what is really
> important - MMC layer should always be able to fetch the new arrived
> request ASAP, after block layer notification (mmc_request() ) and this
> is what my fix goes to implement.
>
> And the fix is not changing block layer behavior.
>
> Thanks
>
> --
> Konstantin Dorfman,
> QUALCOMM ISRAEL, on behalf of Qualcomm Innovation Center,
> Inc. is a member of Code Aurora Forum,
> hosted by The Linux Foundation
--
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: core: debugfs: Add signal_voltage to ios dump

[Chris Ball]

Hi,

On Fri, Oct 26 2012, Johan Rudholm wrote:
> 2012/10/26 Philip Rakity :
>>
>> On Oct 26, 2012, at 11:31 AM, Johan Rudholm
>>  wrote:
>>
>>> + default:
>>> + str = "invalid";
>>
>> would "is unknown"  be a better str ?
>
> Maybe... Actually, I just followed the standard in the function, all
> other strings default to "invalid" when the definition is missing. So
> if I change this, then I should also change the rest of the strings in
> the function. I will do this if we think it's worth the effort, but is
> it?

Thanks, pushed to mmc-next for 3.8 -- let's handle string renaming
separately to this patch.

- 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/1] mmc: omap_hsmmc: remove warning message for debounce clock

[Chris Ball]

Hi,

On Thu, Oct 25 2012, Tony Lindgren wrote:
> * Balaji T K  [121025 09:00]:
>> MMC debounce clock is applicable only for omap2430, warning message gets
>> printed when enable fails for debounce clock. Remove the get debounce clock
>> failure message as it is noisy for other platforms.
>> 
>> Signed-off-by: Balaji T K 
>> Reported-by: Russell King 
>
> This would be good to get in during the -rc cycle if possible to remove
> the bogus warnings on non-2430 omaps. But since it's been there for a
> long time, we can wait too if needed.
>
> Acked-by: Tony Lindgren 

Thanks; pushed to mmc-next, I'll send it 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: sh_mmcif: fix use after free

[Chris Ball]

Hi Guennadi,

On Tue, Oct 23 2012, Guennadi Liakhovetski wrote:
> A recent commit "mmc: sh_mmcif: fix clock management" has introduced a use
> after free bug in sh_mmcif.c: in sh_mmcif_remove() the call to
> mmc_free_host() frees private driver data, therefore using it afterwards
> is a bug. Revert that hunk.
>
> Signed-off-by: Guennadi Liakhovetski 
> ---
>
> Chris, the offending patch appeared in 3.6, so, this has to go to 
> 3.6.stable, as well as to 3.7-rc.
>
>  drivers/mmc/host/sh_mmcif.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
> index 11d2bc3..d25bc97 100644
> --- a/drivers/mmc/host/sh_mmcif.c
> +++ b/drivers/mmc/host/sh_mmcif.c
> @@ -1466,9 +1466,9 @@ static int __devexit sh_mmcif_remove(struct 
> platform_device *pdev)
>  
>   platform_set_drvdata(pdev, NULL);
>  
> + clk_disable(host->hclk);
>   mmc_free_host(host->mmc);
>   pm_runtime_put_sync(&pdev->dev);
> - clk_disable(host->hclk);
>   pm_runtime_disable(&pdev->dev);
>  
>   return 0;

Thanks, pushed to mmc-next for 3.7.  In future, feel free to note the
stable@ situation by adding:

   Cc: sta...@vger.kernel.org [3.6]

- 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: To use multiple scatter gather list

[Chris Ball]

Hi,

On Mon, Oct 22 2012, Kyoungil Kim wrote:
> We used only single sg entry for SDIO transfer.
> This chagne is to use multiple sg entry.
> In case of dwmci, it support only up to 4KB size per single sg entry.
> So if we want to transfer more than 4KB, we should send more than 1 command.
> This makes performance degradation for large data transfer.
>
> Signed-off-by: Kyoungil Kim 

Can you share the before/after benchmark on your controller, please?

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 v2] mmc: sdhci-s3c: ensure non-transaction of bus before clk_disable

[Chris Ball]

Hi,

On Thu, Oct 18 2012, Heiko Stübner wrote:
> Clock should be supplied during bus transaction. This patch defers
> clk_disabe in runtime_suspend if CMD/DATA line is used.
>
> Signed-off-by: Seungwon Jeon 
> Acked-by: Heiko Stuebner 
> ---
> It's also necessary to destaticise the forward declarations in the top of
> sdhci.c, which I've done in this v2.

Looks like this doesn't apply to mmc-next anymore -- please could you
rebase/resend?

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 v2] mmc: sdhci-s3c: fix the card detection in runtime-pm

[Chris Ball]

Hi,

On Fri, Oct 19 2012, Heiko Stübner wrote:
> Am Freitag, 19. Oktober 2012, 10:04:14 schrieb Seungwon Jeon:
>> On Thursday, October 18, 2012, Heiko Stuebner 
>> 
>> > If host clock is disabled, host cannot detect a card
>> > in case of using the internal or gpio card-detect for detection.
>> > 
>> > Signed-off-by: Seungwon Jeon 
>> > Tested-by: Heiko Stuebner 
>> > ---
>> > I've added the SDHCI_CD_GPIO to the conditional. With this change it
>> > works on my machine. But I'm not sure if this would also be necessary
>> > for the external card detect.
>> 
>> Card detection will be asserted out of host in case of using SDHCI_CD_GPIO.
>> Adding SDHCI_CD_GPIO to the conditional seems unnecessary.
>
> But it _was_ necessary :-) . Because only then did the problem go away. You 
> might be right, that there exists a better solution for this, but something 
> in 
> the original patch is at least still missing to fix the problem.

Seungwon, what would you like to do here?  (I'm unhappy taking a patch
with your name on it that's been modified in a way you disagree with.)

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] mmc: sdhci-pci: fix 'Invalid iomem size' error message condition

[Chris Ball]

Hi,

On Thu, Oct 18 2012, Adrian Hunter wrote:
> The SDHCI standard defines a 256 byte register set but a device
> that specifies a larger iomem region is not an error.  Alter the
> message condition accordingly.
>
> Signed-off-by: Adrian Hunter 
> ---
>  drivers/mmc/host/sdhci-pci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-pci.c b/drivers/mmc/host/sdhci-pci.c
> index 4bb74b0..04936f3 100644
> --- a/drivers/mmc/host/sdhci-pci.c
> +++ b/drivers/mmc/host/sdhci-pci.c
> @@ -1196,7 +1196,7 @@ static struct sdhci_pci_slot * __devinit 
> sdhci_pci_probe_slot(
>   return ERR_PTR(-ENODEV);
>   }
>  
> - if (pci_resource_len(pdev, bar) != 0x100) {
> + if (pci_resource_len(pdev, bar) < 0x100) {
>   dev_err(&pdev->dev, "Invalid iomem size. You may "
>   "experience problems.\n");
>   }

Thanks, pushed to mmc-next for 3.8.

- 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: fix sdhci-dove removal

[Chris Ball]

Hi Russell,

On Mon, Oct 15 2012, Russell King - ARM Linux wrote:
> Here's an updated patch which just about fixes the sdhci-dove driver.
> I would not be surprised given the idiotic sdhci-pltfm API if many
> other drivers suffered the same bug.
>
> 8<
> From: Russell King 
> Subject: [PATCH] MMC: fix sdhci-dove probe/removal
>
> 1. Never ever publish a device in the system before it has been setup
>to a usable state.
> 2. Unregister the device _BEFORE_ taking away any resources it may be
>using.
> 3. Don't check clks against NULL.
>
> Signed-off-by: Russell King 

This version of the patch doesn't apply cleanly or compile -- maybe you
have a later revision?

/home/cjb/git/mmc/drivers/mmc/host/sdhci-dove.c: In function ‘sdhci_dove_probe’:
/home/cjb/git/mmc/drivers/mmc/host/sdhci-dove.c:109:2: error: implicit 
declaration of function ‘clk_unprepare_disable’ 
[-Werror=implicit-function-declaration]
/home/cjb/git/mmc/drivers/mmc/host/sdhci-dove.c:111:1: warning: label 
‘sdhci_dove_allocate_fail’ defined but not used [-Wunused-label]

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] mmc: mxcmmc: Fix MODULE_ALIAS

[Chris Ball]

Hi,

On Mon, Oct 29 2012, Sascha Hauer wrote:
> On Tue, Oct 09, 2012 at 04:26:05PM -0300, Fabio Estevam wrote:
>> The correct name for the driver is "mxc-mmc".
>> 
>> Signed-off-by: Fabio Estevam 
>
> Acked-by: Sascha Hauer 

Thanks, pushed to mmc-next for 3.8.

- 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 00/26] pstore, mmc: add mmc as backend for pstore

[Chris Ball]

Hi,

On Mon, Oct 29 2012, Kirill A. Shutemov wrote:
> On Tue, Oct 23, 2012 at 04:47:58PM +0300, Irina Tirdea wrote:
>> These patches enable using the mmc card to store panic information.
>> 
>> They include changes for pstore and mmc:
>>  - add block device backend for pstore
>>  - add logic in mmc for writing in panic mode
>
> Chris, any feedback on mmc/sdhci part?

Looks like the patchset hasn't been sent to linux-mmc@vger.kernel.org
yet -- could you send a v2 with that address included, please?

It would also be great to see descriptive commit messages, rather than
just patch subject lines.

Documentation-wise, the patchset mentions that host controller support
is required for this to work, but doesn't explain what kind of support
that is, and the sdhci-pci support seems unconditional on type of host
controller -- why wouldn't every controller work?  Is it (just) because
other controller drivers use msleep?

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] mmc: mxcmmc: Fix MODULE_ALIAS

[Sascha Hauer]

On Tue, Oct 09, 2012 at 04:26:05PM -0300, Fabio Estevam wrote:
> The correct name for the driver is "mxc-mmc".
> 
> Signed-off-by: Fabio Estevam 

Acked-by: Sascha Hauer 

Sascha

> ---
>  drivers/mmc/host/mxcmmc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/mmc/host/mxcmmc.c b/drivers/mmc/host/mxcmmc.c
> index 565c2e4..6290b7f 100644
> --- a/drivers/mmc/host/mxcmmc.c
> +++ b/drivers/mmc/host/mxcmmc.c
> @@ -1134,4 +1134,4 @@ module_platform_driver(mxcmci_driver);
>  MODULE_DESCRIPTION("i.MX Multimedia Card Interface Driver");
>  MODULE_AUTHOR("Sascha Hauer, Pengutronix");
>  MODULE_LICENSE("GPL");
> -MODULE_ALIAS("platform:imx-mmc");
> +MODULE_ALIAS("platform:mxc-mmc");
> -- 
> 1.7.9.5
> 
> 
> 

-- 
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 00/26] pstore, mmc: add mmc as backend for pstore

[Kirill A. Shutemov]

On Tue, Oct 23, 2012 at 04:47:58PM +0300, Irina Tirdea wrote:
> These patches enable using the mmc card to store panic information.
> 
> They include changes for pstore and mmc:
>  - add block device backend for pstore
>  - add logic in mmc for writing in panic mode

Chris, any feedback on mmc/sdhci part?

-- 
 Kirill A. Shutemov
--
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] mmc: omap_hsmmc: fix host reference after mmc_free_host

[Chris Ball]

Hi,

On Mon, Oct 15 2012, Venkatraman S wrote:
> From: Balaji T K 
>
> struct omap_hsmmc_host *host should not be accessed after mmc_free_host().
> Reorder mmc_free_host() after iounmap(host->base).
>
> Signed-off-by: Balaji T K 
> Signed-off-by: Venkatraman S 
> ---
>  drivers/mmc/host/omap_hsmmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index a33ab74..a3929b7 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -2019,8 +2019,8 @@ static int __devexit omap_hsmmc_remove(struct 
> platform_device *pdev)
>   clk_put(host->dbclk);
>   }
>  
> - mmc_free_host(host->mmc);
>   iounmap(host->base);
> + mmc_free_host(host->mmc);
>   omap_hsmmc_gpio_free(pdev->dev.platform_data);
>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

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 2/4] MMC: omap_hsmmc: add DT property for max bus frequency

[Chris Ball]

Hi,

On Mon, Oct 15 2012, Venkatraman S wrote:
> From: Daniel Mack 
>
> Maximum bus frequency can be limited by external circuitry like level
> shifters etc. Allow passing this value from DT.
>
> Signed-off-by: Daniel Mack 

Thanks, pushed to mmc-next for 3.8.

- 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] MMC: omap_hsmmc: claim pinctrl at probe time

[Chris Ball]

Hi,

On Mon, Oct 15 2012, Venkatraman S wrote:
> From: Daniel Mack 
>
> This allows DT-driven board to set up the pin mux only when the driver
> is in use.
>
> Signed-off-by: Daniel Mack 

Thanks, pushed to mmc-next for 3.8.

- 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] mmc: omap_hsmmc: Fix NULL pointer dereference for dt boot

[Chris Ball]

Hi,

On Mon, Oct 15 2012, Venkatraman S wrote:
> From: Balaji T K 
>
> dev->platform_data is NULL in case of device tree boot,
> instead use the saved version in struct omap_hsmmc_host.
>
> Signed-off-by: Balaji T K 
> Signed-off-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: [RESEND PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards

[Felipe Balbi]

Hi,

On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
> HSMMC IP on AM33xx need a special setting to handle High-speed cards.
> Other platforms like TI81xx, OMAP4 may need this as-well. This depends
> on the HSMMC IP timing closure done for the high speed cards.
> 
> From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
> 
> The MMC/SD/SDIO output signals can be driven on either falling edge or
> rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
> to reach better timing performance, and thus to increase data transfer
> frequency.
> 
> There are few pre-requisites for enabling the HSPE bit
> - Controller should support High-Speed-Enable Bit and
> - Controller should not be using DDR Mode and
> - Controller should advertise that it supports High Speed in
>   capabilities register and
> - MMC/SD clock coming out of controller > 25MHz
> 
> Signed-off-by: Hebbar, Gururaja 
> ---
> Rebased on mmc-next (v3.7.0-rc1)
> Only Build tested since EDMA support for AM335x is not yet added
> 
> :100644 100644 be76a23... ed271fc... M
> Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> :100644 100644 8b4e4f2... 346af5b... M
> arch/arm/plat-omap/include/plat/mmc.h
> :100644 100644 54bfd0c... 3fd95cb... Mdrivers/mmc/host/omap_hsmmc.c
>  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |1 +
>  arch/arm/plat-omap/include/plat/mmc.h  |1 +
>  drivers/mmc/host/omap_hsmmc.c  |   30 
> +++-
>  3 files changed, 31 insertions(+), 1 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> index be76a23..ed271fc 100644
> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
> @@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
>  "supply-name" examples are "vmmc", "vmmc_aux" etc
>  ti,non-removable: non-removable slot (like eMMC)
>  ti,needs-special-reset: Requires a special softreset sequence
> +ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
> High Speed

can't you do runtime revision detection for this ?

>  Example:
>   mmc1: mmc@0x4809c000 {
> diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
> b/arch/arm/plat-omap/include/plat/mmc.h
> index 8b4e4f2..346af5b 100644
> --- a/arch/arm/plat-omap/include/plat/mmc.h
> +++ b/arch/arm/plat-omap/include/plat/mmc.h
> @@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
>   /* we can put the features above into this variable */
>  #define HSMMC_HAS_PBIAS  (1 << 0)
>  #define HSMMC_HAS_UPDATED_RESET  (1 << 1)
> +#define HSMMC_HAS_HSPE_SUPPORT   (1 << 2)
>   unsigned features;
>  
>   int switch_pin; /* gpio (card detect) */
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index 54bfd0c..3fd95cb 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -62,6 +62,7 @@
>  
>  #define VS18 (1 << 26)
>  #define VS30 (1 << 25)
> +#define HSS  (1 << 21)
>  #define SDVS18   (0x5 << 9)
>  #define SDVS30   (0x6 << 9)
>  #define SDVS33   (0x7 << 9)
> @@ -89,6 +90,7 @@
>  #define MSBS (1 << 5)
>  #define BCE  (1 << 1)
>  #define FOUR_BIT (1 << 1)
> +#define HSPE (1 << 2)
>  #define DDR  (1 << 19)
>  #define DW8  (1 << 5)
>  #define CC   0x1
> @@ -489,6 +491,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
> *host)
>   struct mmc_ios *ios = &host->mmc->ios;
>   unsigned long regval;
>   unsigned long timeout;
> + unsigned long clkdiv;
>  
>   dev_vdbg(mmc_dev(host->mmc), "Set clock to %uHz\n", ios->clock);
>  
> @@ -496,7 +499,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
> *host)
>  
>   regval = OMAP_HSMMC_READ(host->base, SYSCTL);
>   regval = regval & ~(CLKD_MASK | DTO_MASK);
> - regval = regval | (calc_divisor(host, ios) << 6) | (DTO << 16);
> + clkdiv = calc_divisor(host, ios);
> + regval = regval | (clkdiv << 6) | (DTO << 16);

not part of $SUBJECT

>   OMAP_HSMMC_WRITE(host->base, SYSCTL, regval);
>   OMAP_HSMMC_WRITE(host->base, SYSCTL,
>   OMAP_HSMMC_READ(host->base, SYSCTL) | ICE);
> @@ -507,6 +511,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
> *host)
>   && time_before(jiffies, timeout))
>   cpu_relax();
>  
> + /*
> +  * Enable High-Speed Support
> +  * Pre-Requisites
> +  *  - Controller should support High-Speed-Enable Bit
> +  *  - Controller should not be using DDR Mode
> +  *  - Controller should advertise that it supports High Speed
> +   

Re: [PATCH] mmc: at91-mci: remove driver

[Chris Ball]

Hi,

On Mon, Oct 29 2012, ludovic.desroc...@atmel.com wrote:
> From: Ludovic Desroches 
>
> The at91-mci driver is no more needed since atmel-mci driver supports
> all Atmel devices.
>
> Signed-off-by: Ludovic Desroches 
> Acked-by: Nicolas Ferre 

Thanks!  Pushed to mmc-next for 3.8.

- 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] mmc: at91-mci: remove driver

[ludovic.desroches]

From: Ludovic Desroches 

The at91-mci driver is no more needed since atmel-mci driver supports
all Atmel devices.

Signed-off-by: Ludovic Desroches 
Acked-by: Nicolas Ferre 
---

Hello,

This patch removes the old at91-mci driver for 3.8 as it has been planned.

Regards

Ludovic

 MAINTAINERS |8 -
 arch/arm/mach-at91/include/mach/board.h |   10 -
 drivers/mmc/host/Kconfig|   22 +-
 drivers/mmc/host/Makefile   |1 -
 drivers/mmc/host/at91_mci.c | 1219 ---
 drivers/mmc/host/at91_mci.h |  115 ---
 6 files changed, 1 insertion(+), 1374 deletions(-)
 delete mode 100644 drivers/mmc/host/at91_mci.c
 delete mode 100644 drivers/mmc/host/at91_mci.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1fa9074..7fde4b1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1360,14 +1360,6 @@ S:   Maintained
 F: drivers/atm/
 F: include/linux/atm*
 
-ATMEL AT91 MCI DRIVER
-M: Ludovic Desroches 
-L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
-W: http://www.atmel.com/products/AT91/
-W: http://www.at91.com/
-S: Maintained
-F: drivers/mmc/host/at91_mci.c
-
 ATMEL AT91 / AT32 MCI DRIVER
 M: Ludovic Desroches 
 S: Maintained
diff --git a/arch/arm/mach-at91/include/mach/board.h 
b/arch/arm/mach-at91/include/mach/board.h
index c55a436..a0d92a9 100644
--- a/arch/arm/mach-at91/include/mach/board.h
+++ b/arch/arm/mach-at91/include/mach/board.h
@@ -70,16 +70,6 @@ struct at91_cf_data {
 extern void __init at91_add_device_cf(struct at91_cf_data *data);
 
  /* MMC / SD */
-  /* at91_mci platform config */
-struct at91_mmc_data {
-   int det_pin;/* card detect IRQ */
-   unsignedslot_b:1;   /* uses Slot B */
-   unsignedwire4:1;/* (SD) supports DAT0..DAT3 */
-   int wp_pin; /* (SD) writeprotect detect */
-   int vcc_pin;/* power switching (high == on) */
-};
-extern void __init at91_add_device_mmc(short mmc_id, struct at91_mmc_data 
*data);
-
   /* atmel-mci platform config */
 extern void __init at91_add_device_mci(short mmc_id, struct mci_platform_data 
*data);
 
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 9bf10e7..5c7c846 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -270,26 +270,8 @@ config MMC_AU1X
 
  If unsure, say N.
 
-choice
-   prompt "Atmel SD/MMC Driver"
-   depends on AVR32 || ARCH_AT91
-   default MMC_ATMELMCI if AVR32
-   help
- Choose which driver to use for the Atmel MCI Silicon
-
-config MMC_AT91
-   tristate "AT91 SD/MMC Card Interface support (DEPRECATED)"
-   depends on ARCH_AT91
-   help
- This selects the AT91 MCI controller. This driver will
- be removed soon (for more information have a look to
- Documentation/feature-removal-schedule.txt). Please use
- MMC_ATMEL_MCI.
-
- If unsure, say N.
-
 config MMC_ATMELMCI
-   tristate "Atmel Multimedia Card Interface support"
+   tristate "Atmel SD/MMC Driver (Multimedia Card Interface)"
depends on AVR32 || ARCH_AT91
help
  This selects the Atmel Multimedia Card Interface driver. If
@@ -298,8 +280,6 @@ config MMC_ATMELMCI
 
  If unsure, say N.
 
-endchoice
-
 config MMC_ATMELMCI_DMA
bool "Atmel MCI DMA support"
depends on MMC_ATMELMCI && (AVR32 || ARCH_AT91SAM9G45) && DMA_ENGINE
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index 17ad0a7..cd64b5d 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -17,7 +17,6 @@ obj-$(CONFIG_MMC_WBSD)+= wbsd.o
 obj-$(CONFIG_MMC_AU1X) += au1xmmc.o
 obj-$(CONFIG_MMC_OMAP) += omap.o
 obj-$(CONFIG_MMC_OMAP_HS)  += omap_hsmmc.o
-obj-$(CONFIG_MMC_AT91) += at91_mci.o
 obj-$(CONFIG_MMC_ATMELMCI) += atmel-mci.o
 obj-$(CONFIG_MMC_TIFM_SD)  += tifm_sd.o
 obj-$(CONFIG_MMC_MSM)  += msm_sdcc.o
diff --git a/drivers/mmc/host/at91_mci.c b/drivers/mmc/host/at91_mci.c
deleted file mode 100644
index 74bed0f..000
--- a/drivers/mmc/host/at91_mci.c
+++ /dev/null
@@ -1,1219 +0,0 @@
-/*
- *  linux/drivers/mmc/host/at91_mci.c - ATMEL AT91 MCI Driver
- *
- *  Copyright (C) 2005 Cougar Creek Computing Devices Ltd, All Rights Reserved
- *
- *  Copyright (C) 2006 Malcolm Noyes
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-/*
-   This is the AT91 MCI driver that has been tested with both MMC cards
-   and SD-cards.  Boards that support write protect are now supported.
-   The CCAT91SBC001 board does not support SD cards.
-
-   The three entry points are at91_mci_request, at91_mci_set_ios
-   and at91_mci_get_ro.
-
-   SET IOS
- This configur

[PATCH] MMCI: fetch pinctrl handle and set default state

[Linus Walleij]

This fetches the pinctrl resource for the MMCI driver, and if
a "default" state is found, it is activated.

Acked-by: Ulf Hansson 
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Change dev_err() to dev_warn() when grabbing the default pins
  since being unable to obtain the default state is not in any
  way fatal.
---
 drivers/mmc/host/mmci.c |   18 ++
 drivers/mmc/host/mmci.h |4 
 2 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index edc3e9b..9a36226 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1360,6 +1361,23 @@ static int __devinit mmci_probe(struct amba_device *dev,
mmc->f_max = min(host->mclk, fmax);
dev_dbg(mmc_dev(mmc), "clocking block at %u Hz\n", mmc->f_max);
 
+   host->pinctrl = devm_pinctrl_get(&dev->dev);
+   if (IS_ERR(host->pinctrl)) {
+   ret = PTR_ERR(host->pinctrl);
+   goto clk_disable;
+   }
+
+   host->pins_default = pinctrl_lookup_state(host->pinctrl,
+   PINCTRL_STATE_DEFAULT);
+
+   /* enable pins to be muxed in and configured */
+   if (!IS_ERR(host->pins_default)) {
+   ret = pinctrl_select_state(host->pinctrl, host->pins_default);
+   if (ret)
+   dev_warn(&dev->dev, "could not set default pins\n");
+   } else
+   dev_warn(&dev->dev, "could not get default pinstate\n");
+
 #ifdef CONFIG_REGULATOR
/* If we're using the regulator framework, try to fetch a regulator */
host->vcc = regulator_get(&dev->dev, "vmmc");
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index d437ccf..d34d8c0 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -195,6 +195,10 @@ struct mmci_host {
unsigned intsize;
struct regulator*vcc;
 
+   /* pinctrl handles */
+   struct pinctrl  *pinctrl;
+   struct pinctrl_state*pins_default;
+
 #ifdef CONFIG_DMA_ENGINE
/* DMA stuff */
struct dma_chan *dma_current;
-- 
1.7.7.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] dw_mmc: fix multiple drv_data NULL dereferences

[Chris Ball]

Hi,

On Mon, Oct 29 2012, James Hogan wrote:
> On 17/10/12 10:11, Will Newton wrote:
>> Looks good to me too.
>> 
>> Acked-by: Will Newton 
>> 
>> On Wed, Oct 17, 2012 at 3:06 AM, Jaehoon Chung  
>> wrote:
>>> Looks good to me.
>>>
>>> Acked-by: Jaehoon Chung 
>
> Thanks for the acks Thomas, Seungwon, Jaehoon and Will.
>
> Chris: Any chance of queueing this patch for v3.7?

Yes, certainly -- 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

[RESEND PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards

[Hebbar, Gururaja]

HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.

>From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)

The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.

There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
  capabilities register and
- MMC/SD clock coming out of controller > 25MHz

Signed-off-by: Hebbar, Gururaja 
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added

:100644 100644 be76a23... ed271fc... M  
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 8b4e4f2... 346af5b... M  arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 54bfd0c... 3fd95cb... M  drivers/mmc/host/omap_hsmmc.c
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |1 +
 arch/arm/plat-omap/include/plat/mmc.h  |1 +
 drivers/mmc/host/omap_hsmmc.c  |   30 +++-
 3 files changed, 31 insertions(+), 1 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
 "supply-name" examples are "vmmc", "vmmc_aux" etc
 ti,non-removable: non-removable slot (like eMMC)
 ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High 
Speed
 
 Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h 
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
 #define HSMMC_HAS_PBIAS(1 << 0)
 #define HSMMC_HAS_UPDATED_RESET(1 << 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 << 2)
unsigned features;
 
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..3fd95cb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -62,6 +62,7 @@
 
 #define VS18   (1 << 26)
 #define VS30   (1 << 25)
+#define HSS(1 << 21)
 #define SDVS18 (0x5 << 9)
 #define SDVS30 (0x6 << 9)
 #define SDVS33 (0x7 << 9)
@@ -89,6 +90,7 @@
 #define MSBS   (1 << 5)
 #define BCE(1 << 1)
 #define FOUR_BIT   (1 << 1)
+#define HSPE   (1 << 2)
 #define DDR(1 << 19)
 #define DW8(1 << 5)
 #define CC 0x1
@@ -489,6 +491,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
*host)
struct mmc_ios *ios = &host->mmc->ios;
unsigned long regval;
unsigned long timeout;
+   unsigned long clkdiv;
 
dev_vdbg(mmc_dev(host->mmc), "Set clock to %uHz\n", ios->clock);
 
@@ -496,7 +499,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
*host)
 
regval = OMAP_HSMMC_READ(host->base, SYSCTL);
regval = regval & ~(CLKD_MASK | DTO_MASK);
-   regval = regval | (calc_divisor(host, ios) << 6) | (DTO << 16);
+   clkdiv = calc_divisor(host, ios);
+   regval = regval | (clkdiv << 6) | (DTO << 16);
OMAP_HSMMC_WRITE(host->base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host->base, SYSCTL,
OMAP_HSMMC_READ(host->base, SYSCTL) | ICE);
@@ -507,6 +511,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host 
*host)
&& time_before(jiffies, timeout))
cpu_relax();
 
+   /*
+* Enable High-Speed Support
+* Pre-Requisites
+*  - Controller should support High-Speed-Enable Bit
+*  - Controller should not be using DDR Mode
+*  - Controller should advertise that it supports High Speed
+*in capabilities register
+*  - MMC/SD clock coming out of controller > 25MHz
+*/
+   if ((mmc_slot(host).features & HSMMC_HAS_HSPE_SUPPORT) &&
+   (ios->timing != MMC_TIMING_UHS_DDR50) &&
+   ((OMAP_HSMMC_READ(host->base, CAPA) & HSS) == HSS)) {
+   regval = OMAP_HSMMC_RE

Re: [PATCH] MMCI: fetch pinctrl handle and set default state

[Russell King - ARM Linux]

On Mon, Oct 22, 2012 at 09:52:06AM +0200, Linus Walleij wrote:
> + /* enable pins to be muxed in and configured */
> + if (!IS_ERR(host->pins_default)) {
> + ret = pinctrl_select_state(host->pinctrl, host->pins_default);
> + if (ret)
> + dev_err(&dev->dev, "could not set default pins\n");
> + } else
> + dev_err(&dev->dev, "could not get default pinstate\n");

Umm, are these errors or warnings?  Arguably, because we continue,
these seem to me to be warnings.

In my mind, a warning message is one which is reporting a condition which
we can continue from, whereas an error message is a condition which causes
immediate failure.  (Think about GCC... with warnings you still get code,
but the code may not be correct, but if you see an error message you don't
get any code.)
--
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] mmc: dw-mmc: relocate the position called dw_mci_setup_bus()

[Jaehoon Chung]

On 10/29/2012 06:08 PM, Seungwon Jeon wrote:
> Monday, October 29, 2012, Jaehoon Chung 
>> After power-on, must be ensured at least 74~80 clocks before sending any 
>> first command.
>> To ensure, it's good that dw_mci_setup_bus() is located at dw_mci_set_ios
>> instead of __dw_mci_start_request()
> After power-up, host driver sets 'DW_MMC_CARD_NEED_INIT' flag, right?
> And then, this flag help to add SDMMC_CMD_INIT flag into CMD, when 
> __dw_mci_start_request is executed.
> 74~80 clocks is ensured with SDMMC_CMD_INIT regardless location change, isn't 
> it?
> I mentioned this part in previous mail. Could you check it?
According to eMMC spec, after power-on, need to wait for 74-clock before 
sending first command
You can see code that after mmc_set_ios(), waiting for mmc_delay(10) into 
mmc_power_up().
(You can read the comment at mmc_power_up(), Maybe mmc_delay(10) didn't ensure 
the 74-clock).

Best Regards,
Jaehoon Chung
> 
> Thanks,
> Seungwon Jeon
> 
>>
>> Signed-off-by: Jaehoon Chung 
>> Signed-off-by: Kyungmin Park 
>> Acked-by: Seungwon Jeon 
>> --
>> Changelog V2:
>>  - Modified the commit-message.
>> ---
>>  drivers/mmc/host/dw_mmc.c |6 +++---
>>  1 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 4b2bedc..de79093 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -682,9 +682,6 @@ static void __dw_mci_start_request(struct dw_mci *host,
>>  if (host->pdata->select_slot)
>>  host->pdata->select_slot(slot->id);
>>
>> -/* Slot specific timing and width adjustment */
>> -dw_mci_setup_bus(slot);
>> -
>>  host->cur_slot = slot;
>>  host->mrq = mrq;
>>
>> @@ -810,6 +807,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
>> mmc_ios *ios)
>>  if (slot->host->drv_data->set_ios)
>>  slot->host->drv_data->set_ios(slot->host, ios);
>>
>> +/* Slot specific timing and width adjustment */
>> +dw_mci_setup_bus(slot);
>> +
>>  switch (ios->power_mode) {
>>  case MMC_POWER_UP:
>>  set_bit(DW_MMC_CARD_NEED_INIT, &slot->flags);
>> --
>> 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
> 
> --
> 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] dw_mmc: fix multiple drv_data NULL dereferences

[James Hogan]

On 17/10/12 10:11, Will Newton wrote:
> Looks good to me too.
> 
> Acked-by: Will Newton 
> 
> On Wed, Oct 17, 2012 at 3:06 AM, Jaehoon Chung  wrote:
>> Looks good to me.
>>
>> Acked-by: Jaehoon Chung 

Thanks for the acks Thomas, Seungwon, Jaehoon and Will.

Chris: Any chance of queueing this patch for v3.7?

Thanks
James

>>
>> On 10/16/2012 05:43 PM, James Hogan wrote:
>>> Commit 800d78bfccb3d38116abfda2a5b9c8afdbd5ea21 ("mmc: dw_mmc: add
>>> support for implementation specific callbacks") merged in v3.7-rc1.
>>>
>>> The above commit introduced multiple NULL pointer dereferences when
>>> the default dw_mci_pltfm_probe() is used, as it sets host->drv_data to
>>> NULL, and that's only checked against NULL in 1 out of the 7 cases where
>>> it is dereferenced.
>>>
>>> Signed-off-by: James Hogan 
>>> ---
>>>  drivers/mmc/host/dw_mmc-pltfm.c |4 ++--
>>>  drivers/mmc/host/dw_mmc.c   |   29 +
>>>  2 files changed, 19 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/drivers/mmc/host/dw_mmc-pltfm.c 
>>> b/drivers/mmc/host/dw_mmc-pltfm.c
>>> index c960ca7..e595721 100644
>>> --- a/drivers/mmc/host/dw_mmc-pltfm.c
>>> +++ b/drivers/mmc/host/dw_mmc-pltfm.c
>>> @@ -50,8 +50,8 @@ 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 (drv_data && drv_data->init) {
>>> + ret = drv_data->init(host);
>>>   if (ret)
>>>   return ret;
>>>   }
>>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>>> index c2828f3..0dc6e33 100644
>>> --- a/drivers/mmc/host/dw_mmc.c
>>> +++ b/drivers/mmc/host/dw_mmc.c
>>> @@ -232,6 +232,7 @@ 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);
>>> + struct dw_mci_drv_data *drv_data = slot->host->drv_data;
>>>   u32 cmdr;
>>>   cmd->error = -EINPROGRESS;
>>>
>>> @@ -261,8 +262,8 @@ 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);
>>> + if (drv_data && drv_data->prepare_command)
>>> + drv_data->prepare_command(slot->host, &cmdr);
>>>
>>>   return cmdr;
>>>  }
>>> @@ -772,6 +773,7 @@ static void dw_mci_request(struct mmc_host *mmc, struct 
>>> mmc_request *mrq)
>>>  static void dw_mci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
>>>  {
>>>   struct dw_mci_slot *slot = mmc_priv(mmc);
>>> + struct dw_mci_drv_data *drv_data = slot->host->drv_data;
>>>   u32 regs;
>>>
>>>   /* set default 1 bit mode */
>>> @@ -807,8 +809,8 @@ 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);
>>> + if (drv_data && drv_data->set_ios)
>>> + drv_data->set_ios(slot->host, ios);
>>>
>>>   switch (ios->power_mode) {
>>>   case MMC_POWER_UP:
>>> @@ -1815,6 +1817,7 @@ static int dw_mci_init_slot(struct dw_mci *host, 
>>> unsigned int id)
>>>  {
>>>   struct mmc_host *mmc;
>>>   struct dw_mci_slot *slot;
>>> + struct dw_mci_drv_data *drv_data = host->drv_data;
>>>   int ctrl_id, ret;
>>>   u8 bus_width;
>>>
>>> @@ -1854,8 +1857,8 @@ static int dw_mci_init_slot(struct dw_mci *host, 
>>> unsigned int id)
>>>   } 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 (drv_data && drv_data->caps)
>>> + mmc->caps |= drv_data->caps[ctrl_id];
>>>
>>>   if (host->pdata->caps2)
>>>   mmc->caps2 = host->pdata->caps2;
>>> @@ -1867,10 +1870,10 @@ static int dw_mci_init_slot(struct dw_mci *host, 
>>> unsigned int id)
>>>   else
>>>   bus_width = 1;
>>>
>>> - if (host->drv_data->setup_bus) {
>>> + if (drv_data && drv_data->setup_bus) {
>>>   struct device_node *slot_np;
>>>   slot_np = dw_mci_of_find_slot_node(host->dev, slot->id);
>>> - ret = host->drv_data->setup_bus(host, slot_np, bus_width);
>>> + ret = drv_data->setup_bus(host, slot_np, bus_width);
>>>   if (ret)
>>>   goto err_setup_bus;
>>>   }
>>> @@ -2035,6 +2038,7 @@ static struct dw_mci_board *dw_mci_parse_dt(struct 
>>> dw_mci *host)
>>>   struct dw_mci_board *pdata;
>>>   struct device *dev = host->dev;
>>>   struct device_node *np = dev->of_node;
>>> + struct dw

RE: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support

[Philip, Avinash]

On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
> Adds AM33XX SPI support for am335x-bone and am335x-evm.
> 
> Signed-off-by: Matt Porter 
> ---
>  arch/arm/boot/dts/am335x-bone.dts |   17 +++
>  arch/arm/boot/dts/am335x-evm.dts  |9 
>  arch/arm/boot/dts/am33xx.dtsi |   43 
> +
>  3 files changed, 69 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am335x-bone.dts 
> b/arch/arm/boot/dts/am335x-bone.dts
> index 5510979..23edfd8 100644
> --- a/arch/arm/boot/dts/am335x-bone.dts
> +++ b/arch/arm/boot/dts/am335x-bone.dts
> @@ -18,6 +18,17 @@
>   reg = <0x8000 0x1000>; /* 256 MB */
>   };
>  
> + am3358_pinmux: pinmux@44e10800 {
> + spi1_pins: pinmux_spi1_pins {
> + pinctrl-single,pins = <
> + 0x190 0x13  /* mcasp0_aclkx.spi1_sclk, 
> OUTPUT_PULLUP | MODE3 */
> + 0x194 0x33  /* mcasp0_fsx.spi1_d0, 
> INPUT_PULLUP | MODE3 */
> + 0x198 0x13  /* mcasp0_axr0.spi1_d1, 
> OUTPUT_PULLUP | MODE3 */
> + 0x19c 0x13  /* mcasp0_ahclkr.spi1_cs0, 
> OUTPUT_PULLUP | MODE3 */
> + >;
> + };
> + };
> +

Change to am33xx_pinmux.

>   ocp {
>   uart1: serial@44e09000 {
>   status = "okay";
> @@ -84,3 +95,9 @@
>  &mmc1 {
>   vmmc-supply = <&ldo3_reg>;
>  };
> +
> +&spi1 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&spi1_pins>;
> +};
> diff --git a/arch/arm/boot/dts/am335x-evm.dts 
> b/arch/arm/boot/dts/am335x-evm.dts
> index d63fce8..8d5f660 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -124,3 +124,12 @@
>  &mmc1 {
>   vmmc-supply = <&vmmc_reg>;
>  };
> +
> +&spi0 {
> + status = "okay";
> + spi-flash@0 {
> + compatible = "spansion,s25fl064k", "m25p80";
> + spi-max-frequency = <2400>;
> + reg = <0>;
> + };
> +};

In AM335x-evm, SPI flash available in profile #2 (am335x evm specific profiles).
So can you drop this changes as if I understood correctly, am335x-evm.dts will 
be
populated for devices present only on profile #0.

> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 26a6af7..063ecea 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -40,6 +40,15 @@
>   };
>   };
>  
> + am3358_pinmux: pinmux@44e10800 {
> + compatible = "pinctrl-single";
> + reg = <0x44e10800 0x0238>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x7f>;
> + };
> +

Pin ctrl support already submitted
http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448

Thanks
Avinash

>   /*
>* XXX: Use a flat representation of the AM33XX interconnect.
>* The real AM33XX interconnect network is quite complex.Since
> @@ -261,6 +270,40 @@
>   status = "disabled";
>   };
>  
> + spi0: spi@4803 {
> + compatible = "ti,omap4-mcspi";
> + ti,hwmods = "spi0";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x4803 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <65>;
> + dmas = <&edma 16
> + &edma 17
> + &edma 18
> + &edma 19>;
> + dma-names = "tx0", "rx0", "tx1", "rx1";
> + ti,spi-num-cs = <2>;
> + status = "disabled";
> + };
> +
> + spi1: spi@481a {
> + compatible = "ti,omap4-mcspi";
> + ti,hwmods = "spi1";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reg = <0x481a 0x400>;
> + interrupt-parent = <&intc>;
> + interrupt = <125>;
> + dmas = <&edma 42
> + &edma 43
> + &edma 44
> + &edma 45>;
> + dma-names = "tx0", "rx0", "tx1", "rx1";
> + ti,spi-num-cs = <2>;
> + status = "disabled";
> + };
> +
>   wdt2: wdt@44e35000 {
>   compatible = "ti,omap3-wdt";
>   ti,hwmods = "wd_timer2";
> -- 
> 1.7.9.5
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.or

RE: [PATCH v2] mmc: dw-mmc: relocate the position called dw_mci_setup_bus()

[Seungwon Jeon]

Monday, October 29, 2012, Jaehoon Chung 
> After power-on, must be ensured at least 74~80 clocks before sending any 
> first command.
> To ensure, it's good that dw_mci_setup_bus() is located at dw_mci_set_ios
> instead of __dw_mci_start_request()
After power-up, host driver sets 'DW_MMC_CARD_NEED_INIT' flag, right?
And then, this flag help to add SDMMC_CMD_INIT flag into CMD, when 
__dw_mci_start_request is executed.
74~80 clocks is ensured with SDMMC_CMD_INIT regardless location change, isn't 
it?
I mentioned this part in previous mail. Could you check it?

Thanks,
Seungwon Jeon

> 
> Signed-off-by: Jaehoon Chung 
> Signed-off-by: Kyungmin Park 
> Acked-by: Seungwon Jeon 
> --
> Changelog V2:
>   - Modified the commit-message.
> ---
>  drivers/mmc/host/dw_mmc.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 4b2bedc..de79093 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -682,9 +682,6 @@ static void __dw_mci_start_request(struct dw_mci *host,
>   if (host->pdata->select_slot)
>   host->pdata->select_slot(slot->id);
> 
> - /* Slot specific timing and width adjustment */
> - dw_mci_setup_bus(slot);
> -
>   host->cur_slot = slot;
>   host->mrq = mrq;
> 
> @@ -810,6 +807,9 @@ static void dw_mci_set_ios(struct mmc_host *mmc, struct 
> mmc_ios *ios)
>   if (slot->host->drv_data->set_ios)
>   slot->host->drv_data->set_ios(slot->host, ios);
> 
> + /* Slot specific timing and width adjustment */
> + dw_mci_setup_bus(slot);
> +
>   switch (ios->power_mode) {
>   case MMC_POWER_UP:
>   set_bit(DW_MMC_CARD_NEED_INIT, &slot->flags);
> --
> 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

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

Re: [RFC PATCH v3 11/16] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC

[Sekhar Nori]

On 10/18/2012 6:56 PM, Matt Porter wrote:
> The EDMA DMAC has a hardware limitation that prevents supporting
> scatter gather lists with any number of segments. Since the EDMA
> DMA Engine driver sets the maximum segments to 16, we do the
> same.
> 
> TODO: this will be replaced once the DMA Engine API supports an
> API to query the DMAC's segment size limit.
> 
> Signed-off-by: Matt Porter 
> ---
>  drivers/mmc/host/omap_hsmmc.c |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
> index b327cd0..52bab01 100644
> --- a/drivers/mmc/host/omap_hsmmc.c
> +++ b/drivers/mmc/host/omap_hsmmc.c
> @@ -1828,6 +1828,16 @@ static int __devinit omap_hsmmc_probe(struct 
> platform_device *pdev)
>* as we want. */
>   mmc->max_segs = 1024;
>  
> + /* Eventually we should get our max_segs limitation for EDMA by
> +  * querying the dmaengine API */

Nit picking: This is not as per multi-line comment style in
Documentation/CodingStyle.

Thanks,
Sekhar
--
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: dw-mmc: check whether card is busy or not, before disabling clock

[Jaehoon Chung]

Before disabling clock, need to check whether card is busy on not.

Signed-off-by: Jaehoon Chung 
Signed-off-by: Kyungmin Park 
---
 drivers/mmc/host/dw_mmc.c |   53 +++-
 drivers/mmc/host/dw_mmc.h |1 +
 2 files changed, 33 insertions(+), 21 deletions(-)

diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 4b2bedc..5707bb6 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -228,6 +228,27 @@ static void dw_mci_set_timeout(struct dw_mci *host)
mci_writel(host, TMOUT, 0x);
 }
 
+static bool mci_wait_reset(struct device *dev, struct dw_mci *host)
+{
+   unsigned long timeout = jiffies + msecs_to_jiffies(500);
+   unsigned int ctrl;
+
+   mci_writel(host, CTRL, (SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET |
+   SDMMC_CTRL_DMA_RESET));
+
+   /* wait till resets clear */
+   do {
+   ctrl = mci_readl(host, CTRL);
+   if (!(ctrl & (SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET |
+ SDMMC_CTRL_DMA_RESET)))
+   return true;
+   } while (time_before(jiffies, timeout));
+
+   dev_err(dev, "Timeout resetting block (ctrl %#x)\n", ctrl);
+
+   return false;
+}
+
 static u32 dw_mci_prepare_command(struct mmc_host *mmc, struct mmc_command 
*cmd)
 {
struct mmc_data *data;
@@ -621,6 +642,7 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot)
struct dw_mci *host = slot->host;
u32 div;
u32 clk_en_a;
+   int timeout = 1000;
 
if (slot->clock != host->current_speed) {
div = host->bus_hz / slot->clock;
@@ -637,6 +659,16 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot)
 "Bus speed (slot %d) = %dHz (slot req %dHz, actual 
%dHZ"
 " div = %d)\n", slot->id, host->bus_hz, slot->clock,
 div ? ((host->bus_hz / div) >> 1) : host->bus_hz, div);
+   do {
+   if (!(mci_readl(host, STATUS) & SDMMC_DATA_BUSY))
+   break;
+   if (timeout-- < 0) {
+   dev_err(host->dev, "Can't disable clock"
+   "because Card is busy!!\n");
+   return;
+   }
+   mci_wait_reset(host->dev, host);
+   } while (1);
 
/* disable clock */
mci_writel(host, CLKENA, 0);
@@ -1995,27 +2027,6 @@ no_dma:
return;
 }
 
-static bool mci_wait_reset(struct device *dev, struct dw_mci *host)
-{
-   unsigned long timeout = jiffies + msecs_to_jiffies(500);
-   unsigned int ctrl;
-
-   mci_writel(host, CTRL, (SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET |
-   SDMMC_CTRL_DMA_RESET));
-
-   /* wait till resets clear */
-   do {
-   ctrl = mci_readl(host, CTRL);
-   if (!(ctrl & (SDMMC_CTRL_RESET | SDMMC_CTRL_FIFO_RESET |
- SDMMC_CTRL_DMA_RESET)))
-   return true;
-   } while (time_before(jiffies, timeout));
-
-   dev_err(dev, "Timeout resetting block (ctrl %#x)\n", ctrl);
-
-   return false;
-}
-
 #ifdef CONFIG_OF
 static struct dw_mci_of_quirks {
char *quirk;
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 53b8fd9..4f27357 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -127,6 +127,7 @@
 #define SDMMC_CMD_INDX(n)  ((n) & 0x1F)
 /* Status register defines */
 #define SDMMC_GET_FCNT(x)  (((x)>>17) & 0x1FFF)
+#define SDMMC_DATA_BUSYBIT(9)
 /* Internal DMAC interrupt defines */
 #define SDMMC_IDMAC_INT_AI BIT(9)
 #define SDMMC_IDMAC_INT_NI BIT(8)
-- 
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