Re: [PATCH 0/6] mmc: sdhci-s3c: Fix base clock source management
Hi, On Mon, Mar 03 2014, Tomasz Figa wrote: > It's been almost two months since I posted this series, it's been > already ACKed and it would be nice to have it applied for upcoming > release. Sorry about this, Tomasz -- now pushed to mmc-next for 3.15, thanks. - Chris. -- Chris Ball <http://printf.net/> -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: dw_mmc: Does anyone use multiple slots?
Hi, On Fri, Aug 09 2013, Olof Johansson wrote: > On Thu, Aug 8, 2013 at 5:16 PM, Doug Anderson wrote: > >> I guess my overall question is: if there are no actual implementations >> of multislot, shouldn't we kill it and simplify the code a whole lot? >> If someone out there has a real multislot device they can step back in >> and do it more correctly? >> >> Of course we need to find someone to actually go through and do the >> killing of multislot, but finding that person might be easier if there >> was some agreement that it was good to do. > > There clearly seems to be no in-tree users of multislot. If someone > new comes in, we have the code in the history and can revert the > removal (or at least use it as reference for re-introduction). > > I vote for removing it. It adds really annoying complexity for > something that nobody uses. I agree with Olof, for what it's worth. (The maintainers of the driver are Jaehoon and Seungwon, though.) Thanks, - Chris. -- Chris Ball <http://printf.net/> -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dw_mmc: let device core setup the default pin configuration
Hi, On Thu, Apr 11 2013, Thomas Abraham wrote: > With device core now able to setup the default pin configuration, > the pin configuration code based on the deprecated Samsung specific > gpio bindings is removed. > > Signed-off-by: Thomas Abraham > Acked-by: Linus Walleij > Reviewed-by: Doug Anderson > Tested-by: Doug Anderson > Acked-by: Seungwon Jeon > --- > Changes since v4: > - Fixed the incorrecr return path after error in enabling vmmc regulator > as pointed out by Doug. Thanks, pushed to mmc-next for 3.10. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/30] mmc: sdhci-s3c: remove platform dependencies
Hi, On Wed, Apr 10 2013, Arnd Bergmann wrote: > plat/regs-sdhci.h is not used anywhere but in the sdhci-s3c > driver, so it can become a local file there and all other > inclusions removed. > > plat/sdhci.h is used only to define the platform devices, > and with the exception of the platform_data structure not > needed by the driver, so we can split out the platform_data > definition instead and leave the rest to platform code. > > Signed-off-by: Arnd Bergmann > Cc: linux-...@vger.kernel.org > Cc: Chris Ball Acked-by: Chris Ball - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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-s3c: let device core setup the default pin configuration
Hi, On Thu, Mar 07 2013, Linus Walleij wrote: > On Wed, Mar 6, 2013 at 12:36 PM, Thomas Abraham > wrote: > >> With device core now able to setup the default pin configuration, >> the call to devm_pinctrl_get_select_default can be removed. And >> the pin configuration code based on the deprecated Samsung specific >> gpio bindings is also removed. >> >> Signed-off-by: Thomas Abraham > > Acked-by: Linus Walleij Thanks, pushed to mmc-next for 3.10. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] mmc: dw_mmc: Remove DW_MCI_QUIRK_NO_WRITE_PROTECT
Hi Doug, On Mon, Jan 14 2013, Doug Anderson wrote: > The whole bundle of all 5 patches at v4 is here: > http://patchwork.kernel.org/bundle/dianders/mmc_wp/ Thanks, I've pushed all 5 to mmc-next for 3.9 now with the collected ACKs. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/2] mmc: host: sdhci-s3c: Add support for pinctrl
Hi, On Sun, Nov 25 2012, Tomasz Figa wrote: > Hi Chris, > > On Sunday 25 of November 2012 14:22:44 Chris Ball wrote: >> Hi, >> >> On Wed, Nov 21 2012, Thomas Abraham wrote: >> > nit: there could have been one example each for gpio and pinctrl >> > variant instead of putting both into one example node. >> >> Tomasz, do you want to reply to this review comment? > > Well, since Thomas already gave his Acked-by for this patch and the > comment was only about a minor thing in the documentation, I considered it > a thing that could be adjusted with further patch if needed. Okay, that's reasonable -- I'll take it as-is for now. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/2] mmc: host: sdhci-s3c: Add support for pinctrl
Hi, On Wed, Nov 21 2012, Thomas Abraham wrote: > nit: there could have been one example each for gpio and pinctrl > variant instead of putting both into one example node. Tomasz, do you want to reply to this review comment? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dw_mmc: enable controller interrupt before calling mmc_start_host
Hi, On Thu, Oct 25 2012, Yuvaraj CD wrote: > Yes,its legal name."Yuvaraj C D". Thanks for letting me know; pushed to mmc-next for 3.7. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dw_mmc: enable controller interrupt before calling mmc_start_host
Hi, On Mon, Oct 08 2012, Yuvaraj CD wrote: > As mmc_start_host is getting called before enabling the dw_mmc controller > interrupt, there is a problem of missing the SDMMC_INT_CMD_DONE for the > very first command sent by the sdio_reset. > This problem occurs only when we disable MMC debugging i.e, MMC_DEBUG [=n]. > Hence this patch enables the dw_mmc controller interrupt before > mmc_start_host. > > Signed-off-by: Yuvaraj CD Is "Yuvaraj CD" your legal name? We should use your full name so that we can track copyright attribution properly. Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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-s3c: use clk_prepare_enable and clk_disable_unprepare
Hi, On Tue, Oct 02 2012, Thomas Abraham wrote: > Convert clk_enable/clk_disable to clk_prepare_enable/clk_disable_unprepare > calls as required by common clock framework. > > Signed-off-by: Thomas Abraham Thanks, pushed to mmc-next for 3.8. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 8/9] mmc: dw_mmc: add support for implementation specific callbacks
Hi, On Thu, Sep 20 2012, Thomas Abraham wrote: >> In non-Exynos platform, host->drv_data has NULL. > > Yes, sorry, I missed that. > > Chris, should I fix this and send the updated patch or shall I send a > separate fix patch. A separate fix patch would be good, please. (I'd normally take an updated patch but Stephen Rothwell's asked for people to hold off rebasing now that -rc7 is out, which is reasonable.) Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 3/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume
Hi Chander, On Fri, Sep 21 2012, Chander Kashyap wrote: > From: Chander Kashyap > > Perform clock disable/enable in runtime suspend/resume. > > Signed-off-by: Chander Kashyap > Acked-by: Jaehoon Chung > --- > Changelog: > v2: > - Wrapped clk_disable in probe and clk_enable in remove with > #ifdef CONFIG_PM_RUNTIME conditional check. Thanks, pushed to mmc-next for 3.7. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/5] mmc: host: sdhci-s3c: Add broken-voltage DT property for broken voltage quirk
Hi, On Wed, Sep 19 2012, Jaehoon Chung wrote: >> On Wed, Sep 19 2012, Tomasz Figa wrote: >>> We could just check if the regulator provides the capability to change the >>> voltage. >>> >>> I don't see any direct way of querying the regulator for provided >>> capabilities (correct me if I'm just blind), but calling >>> regulator_count_voltages() on the regulator and checking if the returned >>> value is 1 should be enough to assume that the regulator is fixed. >> >> Sounds good, I agree. Are you able to test that the obvious patch below >> works on your fixed-regulator board? >> >> Jaehoon and Adrian, can you think of any reason why we shouldn't replace >> MMC_CAP2_BROKEN_VOLTAGE with the regulator_count_voltages() call below? >> Thanks. > > I think this is better than using MMC_CAP2_BROKEN_VOLTAGE. > I tested with this..and working fine. Great, here's the patch. Jaehoon, once this is merged, maybe you could help remove the uses of MMC_CAP2_BROKEN_VOLTAGE from arch/arm/mach-exynos and arch/arm/mach-s5pv210 now that they're no longer needed? Thanks, - Chris. Subject: [PATCH] mmc: core: Replace MMC_CAP2_BROKEN_VOLTAGE with test for fixed regulator Before this patch, we were using MMC_CAP2_BROKEN_VOLTAGE as a way to avoid calling regulator_set_voltage() on a fixed regulator, but that's just duplicating information that already exists -- we should test whether the regulator is fixed directly, instead of via a capability. This patch implements that test. We can't reclaim the capability bit just yet, since there are still boards in arch/arm/ that reference it; those references can be removed now. Reported-by: Tomasz Figa Signed-off-by: Chris Ball --- drivers/mmc/core/core.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 044cd01..6612163 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1113,7 +1113,8 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc, int tmp; int voltage; - /* REVISIT mmc_vddrange_to_ocrmask() may have set some + /* +* REVISIT mmc_vddrange_to_ocrmask() may have set some * bits this regulator doesn't quite support ... don't * be too picky, most cards and regulators are OK with * a 0.1V range goof (it's a small error percentage). @@ -1127,12 +1128,13 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc, max_uV = min_uV + 100 * 1000; } - /* avoid needless changes to this voltage; the regulator -* might not allow this operation + /* +* If we're using a fixed/static regulator, don't call +* regulator_set_voltage; it would fail. */ voltage = regulator_get_voltage(supply); - if (mmc->caps2 & MMC_CAP2_BROKEN_VOLTAGE) + if (regulator_count_voltages(supply) == 1) min_uV = max_uV = voltage; if (voltage < 0) -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume
Hi, On Wed, Sep 19 2012, Chander Kashyap wrote: > I will resend this patch after fixing the issue. Thanks; please base your new patch against current mmc-next. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/5] mmc: host: sdhci-s3c: Add broken-voltage DT property for broken voltage quirk
Hi,
On Wed, Sep 19 2012, Tomasz Figa wrote:
> We could just check if the regulator provides the capability to change the
> voltage.
>
> I don't see any direct way of querying the regulator for provided
> capabilities (correct me if I'm just blind), but calling
> regulator_count_voltages() on the regulator and checking if the returned
> value is 1 should be enough to assume that the regulator is fixed.
Sounds good, I agree. Are you able to test that the obvious patch below
works on your fixed-regulator board?
Jaehoon and Adrian, can you think of any reason why we shouldn't replace
MMC_CAP2_BROKEN_VOLTAGE with the regulator_count_voltages() call below?
Thanks.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 044cd01..a3cc740 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1132,7 +1132,7 @@ int mmc_regulator_set_ocr(struct mmc_host *mmc,
*/
voltage = regulator_get_voltage(supply);
- if (mmc->caps2 & MMC_CAP2_BROKEN_VOLTAGE)
+ if (regulator_count_voltages(supply) == 1)
min_uV = max_uV = voltage;
if (voltage < 0)
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/5] mmc: host: sdhci-s3c: Add broken-voltage DT property for broken voltage quirk
Hi Tomasz, On Wed, Sep 19 2012, Tomasz Figa wrote: > Hi Chris, > > On Wednesday 19 of September 2012 01:42:01 Chris Ball wrote: >> On Tue, Sep 04 2012, Tomasz Figa wrote: >> > Some boards use fixed voltage regulator for vmmc supply (e.g. for eMMC >> > memories). MMC_CAP2_BROKEN_VOLTAGE must be enabled for them to operate >> > correctly. >>> >> Is there a reason we can't make this a property on the regulator instead? > > Is there a reason we can't make this a property of the mmc subsystem? ;) > > Now, seriously, could you elaborate on this a bit more? Do you mean that a > regulator should provide a dummy set voltage operation that would accept > any voltage? Sorry for the terseness. It seems like we're encoding exactly the same information twice in two different subsystems -- I don't see the point, so I'd like to think about how we could do better. For example, if we're only concerned about fixed regulators, could we just detect a fixed regulator in the driver and avoid the failing call to regulator_set_voltage() directly, without needing to go via this capability? Seems like the capability doesn't tell us anything we couldn't already have known. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume
Hi, On Wed, Sep 19 2012, Jaehoon Chung wrote: > Looks good to me. > > Acked-by: Jaehoon Chung Thanks, pushed to mmc-next for 3.7. (The patch didn't merge cleanly so I applied it by hand; let me know if anything looks wrong.) - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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
Hi Thomas, On Wed, Sep 19 2012, Thomas Abraham wrote: >> 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. > > Hi Chris, > > I have addressed all the comments received for the v5 of the dw-mmc > device tree support patch series. Will Newton has acked this patch > series. Can this series be merged for v3.7 ? Yes, looks good; pushed to mmc-next for 3.7. Jaehoon and Seungwon, if you reply soon with your ACK then I'll add it to this patchset. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/3] mmc: sdhci-s3c: Add clk_(enable/disable) in runtime suspend/resume
Hi Jaehoon, Girish,
On Fri, Sep 14 2012, Chander Kashyap wrote:
> Perform clock disable/enable in runtime suspend/resume.
>
> Signed-off-by: Chander Kashyap
> ---
> drivers/mmc/host/sdhci-s3c.c | 25 +++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 3f4518d..d51 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -513,7 +513,9 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> goto err_no_busclks;
> }
>
> +#ifndef CONFIG_PM_RUNTIME
> clk_enable(sc->clk_bus[sc->cur_clk]);
> +#endif
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> host->ioaddr = devm_request_and_ioremap(&pdev->dev, res);
> @@ -620,10 +622,13 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> gpio_is_valid(pdata->ext_cd_gpio))
> sdhci_s3c_setup_card_detect_gpio(sc);
>
> + clk_disable(sc->clk_io);
> return 0;
>
> err_req_regs:
> +#ifndef CONFIG_PM_RUNTIME
> clk_disable(sc->clk_bus[sc->cur_clk]);
> +#endif
> for (ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
> if (sc->clk_bus[ptr]) {
> clk_put(sc->clk_bus[ptr]);
> @@ -656,12 +661,15 @@ static int __devexit sdhci_s3c_remove(struct
> platform_device *pdev)
> if (gpio_is_valid(sc->ext_cd_gpio))
> gpio_free(sc->ext_cd_gpio);
>
> + clk_enable(sc->clk_io);
> sdhci_remove_host(host, 1);
>
> pm_runtime_dont_use_autosuspend(&pdev->dev);
> pm_runtime_disable(&pdev->dev);
>
> +#ifndef CONFIG_PM_RUNTIME
> clk_disable(sc->clk_bus[sc->cur_clk]);
> +#endif
> for (ptr = 0; ptr < 3; ptr++) {
> if (sc->clk_bus[ptr]) {
> clk_put(sc->clk_bus[ptr]);
> @@ -696,15 +704,28 @@ static int sdhci_s3c_resume(struct device *dev)
> 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;
> +
> + ret = sdhci_runtime_suspend_host(host);
>
> - return sdhci_runtime_suspend_host(host);
> + clk_disable(ourhost->clk_bus[ourhost->cur_clk]);
> + clk_disable(busclk);
> + return ret;
> }
>
> static int sdhci_s3c_runtime_resume(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;
>
> - return sdhci_runtime_resume_host(host);
> + clk_enable(busclk);
> + clk_enable(ourhost->clk_bus[ourhost->cur_clk]);
> + ret = sdhci_runtime_resume_host(host);
> + return ret;
> }
> #endif
Could I get an ACK on this patch from one of you, please?
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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] mmc: sdhci-s3c: Fix crash on module insertion for second time
Hi, On Fri, Sep 14 2012, Chander Kashyap wrote: > If sdhci-s3c driver is built as module, it gives following error if inserted > again after removing. This was happening as pm_runtime_use_autosuspend() is > called in sdhci_s3c_probe() function but in sdhci_s3c_remove() its > complementry > pm_runtime_dont_use_autosuspend() is not called. > > BUG: spinlock bad magic on CPU#1, insmod/955 > lock: 0xee771368, .magic: , .owner: insmod/955, .owner_cpu: 1 > [] (unwind_backtrace+0x0/0xf8) from [] > (do_raw_spin_unlock+0xa4/0xe4) > [] (do_raw_spin_unlock+0xa4/0xe4) from [] > (_raw_spin_unlock_irqrestore+0xc/0x38) > [] (_raw_spin_unlock_irqrestore+0xc/0x38) from [] > (sdhci_runtime_suspend_host+0x54/0x80) > [] (sdhci_runtime_suspend_host+0x54/0x80) from [] > (sdhci_s3c_runtime_suspend+0x14/0x38 [sdhci_s3c]) > [] (sdhci_s3c_runtime_suspend+0x14/0x38 [sdhci_s3c]) from > [] (pm_generic_runtime_suspend+0x2c/0x40) > [] (pm_generic_runtime_suspend+0x2c/0x40) from [] > (__rpm_callback+0x70/0x98) > [] (__rpm_callback+0x70/0x98) from [] > (rpm_suspend+0xf0/0x534) > [] (rpm_suspend+0xf0/0x534) from [] > (__pm_runtime_suspend+0x5c/0x74) > [] (__pm_runtime_suspend+0x5c/0x74) from [] > (pm_generic_runtime_idle+0x44/0x4c) > [] (pm_generic_runtime_idle+0x44/0x4c) from [] > (__rpm_callback+0x70/0x98) > [] (__rpm_callback+0x70/0x98) from [] > (rpm_idle+0xdc/0x18c) > [] (rpm_idle+0xdc/0x18c) from [] > (pm_runtime_set_autosuspend_delay+0x30/0x3c) > [] (pm_runtime_set_autosuspend_delay+0x30/0x3c) from [] > (sdhci_s3c_probe+0x35c/0x52c [sdhci_s3c]) > [] (sdhci_s3c_probe+0x35c/0x52c [sdhci_s3c]) from [] > (platform_drv_probe+0x18/0x1c) > > Signed-off-by: Chander Kashyap > --- > drivers/mmc/host/sdhci-s3c.c |1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c > index 0cbb4c2..3f4518d 100644 > --- a/drivers/mmc/host/sdhci-s3c.c > +++ b/drivers/mmc/host/sdhci-s3c.c > @@ -658,6 +658,7 @@ static int __devexit sdhci_s3c_remove(struct > platform_device *pdev) > > sdhci_remove_host(host, 1); > > + pm_runtime_dont_use_autosuspend(&pdev->dev); > pm_runtime_disable(&pdev->dev); > > clk_disable(sc->clk_bus[sc->cur_clk]); Thanks, pushed to mmc-next for 3.7. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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/3] mmc: sdhci-s3c: Enable only required bus clock
Hi, On Fri, Sep 14 2012, Chander Kashyap wrote: > In case of multiple bus clock sources, all the clock sources were > getting enabled. As only one clock source is needed at the time hence > enable only the required bus clock. > > This patch does as follows: > 1.In sdhci_s3c_probe enable only required bus clock source. > > 2.Handle the disabling of old bus clock and enables the > best clock selected in sdhci_s3c_set_clock(). > > Signed-off-by: Chander Kashyap Thanks, pushed to mmc-next for 3.7. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/5] mmc: host: sdhci-s3c: Add broken-voltage DT property for broken voltage quirk
Hi,
On Tue, Sep 04 2012, Tomasz Figa wrote:
> Some boards use fixed voltage regulator for vmmc supply (e.g. for eMMC
> memories). MMC_CAP2_BROKEN_VOLTAGE must be enabled for them to operate
> correctly.
>
> Cc: Ben Dooks
> Cc: Chris Ball
> CC: linux-...@vger.kernel.org
> Signed-off-by: Tomasz Figa
> Signed-off-by: Kyungmin Park
> ---
> Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
> drivers/mmc/host/sdhci-s3c.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
> b/Documentation/devicetree/bindings/mmc/mmc.txt
> index 8a6811f..ecbde68 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> @@ -16,6 +16,7 @@ Optional properties:
> - wp-inverted: when present, polarity on the wp gpio line is inverted
> - non-removable: non-removable slot (like eMMC)
> - max-frequency: maximum operating clock frequency
> +- broken-voltage: vmmc regulator does not allow voltage control
>
> Example:
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 445910e..39715b8 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -443,6 +443,9 @@ static int __devinit sdhci_s3c_parse_dt(struct device
> *dev,
> if (!ourhost->gpios)
> return -ENOMEM;
>
> + if (of_get_property(node, "broken-voltage", 0))
> + pdata->host_caps2 |= MMC_CAP2_BROKEN_VOLTAGE;
> +
> /* get the card detection method */
> if (of_get_property(node, "broken-cd", 0)) {
> pdata->cd_type = S3C_SDHCI_CD_NONE;
Is there a reason we can't make this a property on the regulator instead?
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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
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 <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: dt: Add card-detection properties to core binding.
Signed-off-by: Chris Ball --- Documentation/devicetree/bindings/mmc/mmc.txt | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a6811f..8e2e0ba 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -9,12 +9,17 @@ Interpreted by the OF core: Required properties: - bus-width: Number of data lines, can be <1>, <4>, or <8> +Card detection: +If no property below is supplied, standard SDHCI card detect is used. +Only one of the properties in this section should be supplied: + - broken-cd: There is no card detection available; polling must be used. + - cd-gpios: Specify GPIOs for card detection, see gpio binding + - non-removable: non-removable slot (like eMMC); assume always present. + Optional properties: -- cd-gpios: Specify GPIOs for card detection, see gpio binding - wp-gpios: Specify GPIOs for write protection, see gpio binding - cd-inverted: when present, polarity on the cd gpio line is inverted - wp-inverted: when present, polarity on the wp gpio line is inverted -- non-removable: non-removable slot (like eMMC) - max-frequency: maximum operating clock frequency Example: -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Add 'broken-cd' DT binding
Hi Stephen, On Wed, Aug 22 2012, Stephen Warren wrote: > On 08/22/2012 04:17 AM, Chris Ball wrote: >> Hi, >> >> On Wed, Aug 22 2012, Shawn Guo wrote: >>> The following is what I have on my mind. >>> >>> broken-cd cd-gpiosimplication >>> --- >>> no no SDHCI CD >>> no yes GPIO CD >>> yes no NO CD / Broken CD >>> yes yes Invalid >>> >>> yes: property presents >>> no: property does not present >> >> This matches Mitch's last suggestion exactly -- I think we're all agreed >> on these properties now. The only remaining question is how to handle >> the pinctrl for CD in Thomas's case. > > Sorry if this has already been mentioned, but I assume the standard > non-removable property overrides any of those, or is invalid in > combination with any of those? Yes, absolutely. I'll make sure to explain that in the new version of the document. (I think the reason it hasn't been mentioned much in this thread is that it's already part of the core bindings.) Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Add 'broken-cd' DT binding
Hi Thomas, On Wed, Aug 22 2012, Thomas Abraham wrote: >> none -> currently "samsung,sdhci-cd-internal" >> broken-cd -> currently "samsung,sdhci-cd-none" >> cd-gpios -> currently "samsung,sdhci-cd-gpios" >> non-removable -> currently "samsung,sdhci-cd-permanent" >> cd-gpios + samsung,sdhci-cd-external -> currently "samsung,sdhci-cd-external" >> >> How does that sound? > > Not quite there yet. It is not possible to leave out cd-gpios for > "samsung,sdhci-cd-internal" since the current Samsung pinmux > configuration piggybacks on gpio dt binding. Can we use the following > instead. > > none -> currently "samsung,sdhci-cd-none" > broken-cd-> currently "samsung,sdhci-cd-none" > cd-gpios -> currently "samsung,sdhci-cd-gpios" > non-removable -> currently "samsung,sdhci-cd-permanent" > cd-gpios + samsung,sdhci-cd-internal -> currently "samsung,sdhci-cd-internal" I see. Okay; unless anyone has better ideas, it sounds like you should go ahead and do that -- with something like this in your binding docs: "This binding differs from the core MMC binding by requiring a cd-gpios property to be present to use internal card-detection. If no cd-gpios are present (and "non-removable" is missing) the driver will poll for card-detection as if a "broken-cd" property was provided." I'll send out the new core bindings doc shortly. Finishing off another thread -- the "samsung-sdhci.txt" name is okay. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Add 'broken-cd' DT binding
Hi Shawn, On Wed, Aug 22 2012, Shawn Guo wrote: > mmc: sdhci: Always pass clock request value zero to set_clock host op > > To allow the set_clock host op to disable the SDCLK source when not > needed, always call the host op when the requested clock speed is > zero. Do this even if host->clock already equals zero, because > the SDHCI driver may set that value (without calling the host op) > to force an update at the next (non-zero-speed) call. > > Signed-off-by: Todd Poynor > Acked-by: Adrian Hunter > Signed-off-by: Chris Ball > > Reverting the commit will get "controller" mode back to work. Weird; I wonder how that's related to card detection. I'm afraid it's ultimately a driver bug -- esdhc should be able to handle having set_clock called with a value of 0. It seems to have a case in esdhc_set_clock() for 0, so I'm surprised it's not working. What's the symptom of the failure? Can you debug some more? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Add 'broken-cd' DT binding
Hi Thomas, On Wed, Aug 22 2012, Thomas Abraham wrote: >> This matches Mitch's last suggestion exactly -- I think we're all agreed >> on these properties now. The only remaining question is how to handle >> the pinctrl for CD in Thomas's case. > > Hi Chris, > > For sdhci-s3c driver, the 'broken-cd' and 'cd-gpios' bindings are > sufficient. But, are drivers free to use implementation specific > behavior when using these bindings. Or do we strictly adhere to the > table which Shawn has listed. For sdhci-s3c driver, I would like to > deviate from the "implication" column listed above. I'd rather you use the implications described above for the names described above; there's not much point in defining named behaviors across the subsystem if they're actually different in each driver. But I think you can still use driver-internal properties that change the interpretation of those names in a documented way. If the meaning of cd-gpios is modified when coupled with your "samsung,sdhci-cd-external", that's okay with me. That should cover all the cases you need until you migrate to using pinctrl, right? So, you could immediately support: none -> currently "samsung,sdhci-cd-internal" broken-cd -> currently "samsung,sdhci-cd-none" cd-gpios -> currently "samsung,sdhci-cd-gpios" non-removable -> currently "samsung,sdhci-cd-permanent" cd-gpios + samsung,sdhci-cd-external -> currently "samsung,sdhci-cd-external" How does that sound? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Add 'broken-cd' DT binding
Hi, On Wed, Aug 22 2012, Shawn Guo wrote: > The following is what I have on my mind. > > broken-cd cd-gpiosimplication > --- > nono SDHCI CD > noyes GPIO CD > yes no NO CD / Broken CD > yes yes Invalid > > yes: property presents > no: property does not present This matches Mitch's last suggestion exactly -- I think we're all agreed on these properties now. The only remaining question is how to handle the pinctrl for CD in Thomas's case. Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Add 'broken-cd' DT binding
Hi, On Tue, Aug 21 2012, Rob Herring wrote: >> cd-gpios and cd-external can be present on the same node. if broken-cd >> is present, it must be the only one of these nodes used. > > I don't see the point of cd-external. Either you just use the CD > interrupt defined within the SDHCI or you have a gpio line independent > of the SDHCI and use cd-gpios. You've described two of the possible cases, but not the third. In the third case, you have a gpio line that is not independent of the SDHCI, because it is the SDHCI's CD pin brought out to be directly accessible via a GPIO. The difference is in the handling of the interrupt -- if you don't have "cd-external" then you're just using the SDHCI's interrupt, but if you have an independent line then you're going to need to register your own IRQ handler on it, and "cd-external" signifies that. Thomas wrote this explanation earlier in the thread: > "samsung,sdhci-cd-gpio" means that the cd-gpio line is not connected > to the card-detect pad of the sdhci controller. Instead, it identifies > cd-gpio as a gpio pin, connected to the card-detect pin of the "card > slot" and it can used as a source of external interrupt. The driver > can register card insert/remove handler for this interrupt and get > notified about the changes in card state. > > "sdhci-cd-internal" means that the "cd-gpio" line is used to connect > the card-detect pin of the card slot and the card-detect pad of the > sdhci controller. The controller is then aware of any changes in card > state and the controller generates appropriate interrupts to notify > changes in card-state. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Add 'broken-cd' DT binding
Hi, adding Shawn and Wolfram,
On Tue, Aug 21 2012, Arnd Bergmann wrote:
> On Tuesday 21 August 2012, Chris Ball wrote:
>> How about this?
>>
>> broken-cd: No CD available, use polling.
>>
>> cd-gpios: The CD pin on the host is working and brought out to a GPIO.
>>
>> external-cd-gpios: The CD pin on the host is broken, but there's an
>>independent external GPIO available.
>>
>>
>> (Each host should only have one of these properties.)
>
> The fsl-imx-esdhc.txt binding already has all three cases, but
> describes them differently:
>
> fsl,cd-internal: when present, the CD pin on the host is working
> cd-gpios: when present, contains the gpio line that CD is connected to
> If both are absent, it has to use polling.
Aside: the bindings do not match the code. The bindings document says
to use "fsl,cd-internal", and imx51-babbage.dts does so -- but the code
doesn't check for "fsl,cd-internal", it checks for "fsl,cd-controller":
if (of_get_property(np, "fsl,cd-controller", NULL))
boarddata->cd_type = ESDHC_CD_CONTROLLER;
The same confusion is present for fsl,wp-{controller,internal}.
Ignoring that, these bindings are similar, but not the same -- imx-esdhc
only allows one of the cd_type cases to be true, so you either have
cd-internal or you have cd-gpios:
if (of_get_property(np, "fsl,cd-controller", NULL))
boarddata->cd_type = ESDHC_CD_CONTROLLER;
boarddata->cd_gpio = of_get_named_gpio(np, "cd-gpios", 0);
if (gpio_is_valid(boarddata->cd_gpio))
boarddata->cd_type = ESDHC_CD_GPIO;
This differs from Thomas's binding -- he wants a way to say "the cd-gpio
mentioned in cd-gpios is [internal/external] to the card's CD pin".
Rob Herring said:
> This makes the most sense to me. However, I prefer broken-cd over
> cd-internal. The binding should add properties for exceptions, not SDHCI
> spec compliant implementations.
Agreed, I was going to say the same thing. Putting it all together, it
sounds like we want:
no extra properties: the CD pin on the host just works.
broken-cd:the CD pin on the host is broken; use polling.
cd-gpios: the GPIO listed is the CD pin on the host being
brought out directly to a GPIO.
cd-external: when used with cd-gpios, specifies that the GPIO
in cd-gpios is external to the CD pin on the host.
cd-gpios and cd-external can be present on the same node. if broken-cd
is present, it must be the only one of these nodes used.
Shawn, I guess I'll leave it up to you on whether/when you'd like to
move away from the "fsl," properties to the new common ones?
If this looks okay to everyone, I'll send a patch soon.
Thanks!
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Add 'broken-cd' DT binding
Hi, On Tue, Aug 21 2012, Thomas Abraham wrote: > I am trying to have a way to represent a gpio line as card detect line > that is not connected to the card-detect pad of the mmc controller but > instead used as a gpio interrupt line or polled gpio line. > > 'broken-cd' would imply that the card-detect pad of the mmc controller > is not connected to the card-detect pin at the slot. The 'cd-gpios' > property in that case would let the driver code to use the 'cd-gpios' > line as the external gpio interrupt or poll it. How about this? broken-cd: No CD available, use polling. cd-gpios: The CD pin on the host is working and brought out to a GPIO. external-cd-gpios: The CD pin on the host is broken, but there's an independent external GPIO available. (Each host should only have one of these properties.) Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Add 'broken-cd' DT binding
Hi, On Tue, Aug 21 2012, Arnd Bergmann wrote: > On Tuesday 21 August 2012, Thomas Abraham wrote: >> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt >> b/Documentation/devicetree/bindings/mmc/mmc.txt >> index 8a6811f..1aa527a 100644 >> --- a/Documentation/devicetree/bindings/mmc/mmc.txt >> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt >> @@ -16,6 +16,8 @@ Optional properties: >> - wp-inverted: when present, polarity on the wp gpio line is inverted >> - non-removable: non-removable slot (like eMMC) >> - max-frequency: maximum operating clock frequency >> +- broken-cd: when present, indicates that the cd-gpios line is not >> + connected to the card-detect pad of the MMC host controller. > > What is the difference between listing the cd line as broken and > listing no cd line at all? I think the documentation's incorrect here -- "broken-cd" should be used without a cd-gpios node, and tells the driver that there is no working WP and we'll need to poll the host (SDHCI_QUIRK_BROKEN_CARD_DETECTION): diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c index 25733ef..23ebdbb 100644 --- a/drivers/mmc/host/sdhci-pxav3.c +++ b/drivers/mmc/host/sdhci-pxav3.c @@ -198,6 +198,9 @@ static struct sdhci_pxa_platdata *pxav3_get_mmc_pdata(struct device *dev) if (clk_delay_cycles > 0) pdata->clk_delay_cycles = clk_delay_cycles; + if (of_find_property(np, "broken-cd", NULL)) + pdata->quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION; + return pdata; } #else So, I'd say: "- broken-cd: when present, indicates that there is no card-detect line available on the host; polling should be used instead." Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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-s3c: Add device tree support
Hi Thomas, On Thu, Aug 16 2012, Thomas Abraham wrote: > +Optional Board Specific Properties: > +- One of the following properties for card detect type. > + - samsung,sdhci-cd-internal: Card detect line from the card slot is > +connected to the card detect pad of the sdhci controller. A gpio is > +used for this connection (with possible pin function settings). > + - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings) > +is used a card detect line. This gpio line is not connected to card > detect > +pad of the sdhci controller. > + - samsung,sdhci-cd-none: There is no card detect line. Polling is used to > +detect the presence of the card. (DEFAULT, if no card detect property > +is specified). > + - samsung,sdhci-cd-permanent: There is no card detect line. The card is > +permanently connected to the sdhci controller. sdhci-s3c isn't the only driver that's going to have options for different cd configurations -- maybe now is the right time to move these options into the core bindings? At OLPC we've just started using: * "broken-cd" to mean "samsung,sdhci-cd-none", * the presence of a "cd-gpios" property to imply "samsung,sdhci-cd-gpio". * "non-removable" to mean "samsung,sdhci-cd-permanent" (this is already specified in mmc.txt) Would these work for you? We don't have a distinction between sdhci-cd-internal and sdhci-cd-gpio, and I'm having trouble working out why one is necessary. Why does the driver need to know where the gpio came from, aside from knowing which gpio it is and whether it needs to be inverted (with cd-inverted)? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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-s3c: Add device tree support
Hi,
On Thu, Aug 16 2012, 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 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 | 51 +++
> drivers/mmc/host/sdhci-s3c.c | 146
> +++-
> 2 files changed, 191 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> new file mode 100644
> index 000..398540b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
> @@ -0,0 +1,51 @@
> +* 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.
> +
> +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:
> +- One of the following properties for card detect type.
> + - samsung,sdhci-cd-internal: Card detect line from the card slot is
> +connected to the card detect pad of the sdhci controller. A gpio is
> +used for this connection (with possible pin function settings).
> + - samsung,sdhci-cd-gpio: A gpio line (with possible pin function settings)
> +is used a card detect line. This gpio line is not connected to card
> detect
> +pad of the sdhci controller.
> + - samsung,sdhci-cd-none: There is no card detect line. Polling is used to
> +detect the presence of the card. (DEFAULT, if no card detect property
> +is specified).
> + - samsung,sdhci-cd-permanent: There is no card detect line. The card is
> +permanently connected to the sdhci controller.
> +
> +Example:
> + sdhci@1253 {
> + compatible = "samsung,exynos4210-sdhci";
> + reg = <0x1253 0x100>;
> + interrupts = <<0 75 0>;
> + bus-width = <4>;
> + samsung,sdhci-cd-internal;
> + 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.
Looks good, except the text file doesn't mention anywhere that it describes
the bindings used by sdhci-s3c.c -- that could be useful information to
someone reading the binding and trying to discover which driver uses it.
Maybe we can call the text file "sdhci-s3c.txt"? Or "samsung,sdhci-s3c.txt"
if you prefer.
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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-s3c: Add device tree support
Hi Thomas, On Thu, Aug 16 2012, 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 > --- > drivers/mmc/host/sdhci-s3c.c | 146 > -- > 1 files changed, 140 insertions(+), 6 deletions(-) I know your initial version was submitted before we adopted a set of standard MMC DT bindings, but now that those bindings exist this code should be using them -- there should be a new file: Documentation/devicetree/bindings/mmc/sdhci-s3c.txt describing differences between the mmc.txt bindings and this driver's. Also, you didn't include a patch changelog, so I can't tell whether this contains changes against your v3 of this patch; please do that. Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 5/6] mmc: dw_mmc: add device tree support
Hi, On Thu, Jul 12 2012, Thomas Abraham wrote: > 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..3acd6c9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt > @@ -0,0 +1,108 @@ > +* 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. > + > +Required Properties: > + > +* compatible: should be one of the following > + - snps,dw-mshc: for controllers compliant with synopsis dw-mshc. > + > +* reg: physical base address of the dw-mshc controller and size of its memory > + region. > + > +* interrupts: interrupt specifier for the controller. The format and value of > + the interrupt specifier depends on the interrupt parent for the controller. Please instead add: This file documents differences between the core properties described by mmc.txt and the properties used by the dw_mmc driver. mmc.txt already describes compatible, reg, interrupts, bus-width, cd-gpios, and wp-gpios, so you don't need to describe those again. > + cnt = sizeof(of_quriks) / sizeof(struct dw_mci_of_quirks); > + for (idx = 0; idx < cnt; idx++) > + if (of_get_property(np, of_quriks[idx].quirk, NULL)) > + pdata->quirks |= of_quriks[idx].id; of_quirks, not of_quriks. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Convert s3cmci driver to gpiolib API
Hi,
On Sat, Jun 30 2012, Sylwester Nawrocki wrote:
> The s3c2410_gpio* calls are obsolete and have been scheduled for
> removal since several kernel releases. Remove them and use common
> gpiolib API.
>
> This patch is a prerequisite for removal of the S3C24XX SoC specific
> arch/arm/plat-samsung/include/gpio-fns.h header.
>
> Tested on Micro2440-SDK.
>
> Cc: Ben Dooks
> Signed-off-by: Sylwester Nawrocki
> ---
> drivers/mmc/host/s3cmci.c | 10 +++---
> 1 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/host/s3cmci.c b/drivers/mmc/host/s3cmci.c
> index c3622a6..bd5a5cc 100644
> --- a/drivers/mmc/host/s3cmci.c
> +++ b/drivers/mmc/host/s3cmci.c
> @@ -26,7 +26,6 @@
> #include
>
> #include
> -#include
>
> #include
>
> @@ -1237,12 +1236,9 @@ static void s3cmci_set_ios(struct mmc_host *mmc,
> struct mmc_ios *ios)
> switch (ios->power_mode) {
> case MMC_POWER_ON:
> case MMC_POWER_UP:
> - s3c2410_gpio_cfgpin(S3C2410_GPE(5), S3C2410_GPE5_SDCLK);
> - s3c2410_gpio_cfgpin(S3C2410_GPE(6), S3C2410_GPE6_SDCMD);
> - s3c2410_gpio_cfgpin(S3C2410_GPE(7), S3C2410_GPE7_SDDAT0);
> - s3c2410_gpio_cfgpin(S3C2410_GPE(8), S3C2410_GPE8_SDDAT1);
> - s3c2410_gpio_cfgpin(S3C2410_GPE(9), S3C2410_GPE9_SDDAT2);
> - s3c2410_gpio_cfgpin(S3C2410_GPE(10), S3C2410_GPE10_SDDAT3);
> + /* Configure GPE5...GPE10 pins in SD mode */
> + s3c_gpio_cfgall_range(S3C2410_GPE(5), 6, S3C_GPIO_SFN(2),
> + S3C_GPIO_PULL_NONE);
>
> if (host->pdata->set_power)
> host->pdata->set_power(ios->power_mode, ios->vdd);
Thanks, pushed to mmc-next for 3.6.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dw_mmc: Fixed sdio interrupt mask bit setting bug
Hi, On Mon, May 14 2012, Will Newton wrote: > On Mon, May 14, 2012 at 9:38 AM, Kyoungil Kim wrote: >> The sdio interrupt mask bits are arranged in [31:16]. >> (1 << SDMMC_INT_SDIO(slot->id))) does 16 bits left shift twice. >> So this patch changes to do 16 bits left shift only one time. >> >> Signed-off-by: Kyoungil Kim >> --- >> drivers/mmc/host/dw_mmc.c | 4 ++-- >> 1 files changed, 2 insertions(+), 2 deletions(-) > > Yes, looks correct. > > Acked-by: Will Newton Thanks, pushed to mmc-next for 3.5. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dt: Consolidate DT bindings
Hi Arnd, On Sun, May 13 2012, Arnd Bergmann wrote: > I've verified that there are no conflicts with anything we have in > arm-soc right now, so I think it should just go through your > tree. Ah, I based the patch on latest linux-next. That's why there aren't conflicts against arm-soc, but there are conflicts (in the omap and tegra dts changes) between the patch and Linus master/mmc-next: Applying: mmc: dt: Consolidate DT bindings error: patch failed: arch/arm/boot/dts/omap3-beagle.dts:57 error: patch failed: arch/arm/boot/dts/omap4-panda.dts:55 error: patch failed: arch/arm/boot/dts/omap4-sdp.dts:94 error: patch failed: arch/arm/boot/dts/tegra-cardhu.dts:141 error: patch failed: arch/arm/boot/dts/tegra-harmony.dts:335 error: patch failed: arch/arm/boot/dts/tegra-ventana.dts:338 Patch failed at 0001 mmc: dt: Consolidate DT bindings So I think merging via arm-soc is the only way to get it to Linus without conflicts. (Alternatively I can take it in mmc-next and Linus can handle the conflicts.) Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mmc: dt: Consolidate DT bindings
Hi Arnd, On Fri, Mar 30 2012, Stephen Warren wrote: >> No progress so far. I would suggest we apply the patch below to unify >> the bindings we have. I tried to minimize the impact by picking the most >> common version for each property, but if we know about devices that would >> get broken by this, we may have to be more careful. >> >> Signed-off-by: Arnd Bergmann Here's a version of your MMC DT bindings patch that responds to Stephen Warren's review comments, refreshed against latest linux-next -- I'd like to get this merged for v3.5. Since it touches many .dts files, should it go via arm-soc? Thanks. From: Arnd Bergmann Subject: [PATCH] mmc: dt: Consolidate DT bindings This patch unifies the current DT MMC bindings documentation and code, adds generic MMC DT bindings documentation, and updates .dts files for consistency. Signed-off-by: Arnd Bergmann [cjb: typo fixes, addition of max-frequency property] Signed-off-by: Chris Ball --- Changes since Arnd's v1: * Typo fix from Stephen Warren: s/interrupt/interrupts/ * Typo fix: s/non-removable/ti,non-removable/. This one's being preserved for backwards compatibility. * Add max-frequency property. .../devicetree/bindings/mmc/fsl-esdhc.txt |6 +++-- .../devicetree/bindings/mmc/fsl-imx-esdhc.txt |2 +- .../devicetree/bindings/mmc/mmc-spi-slot.txt |3 ++- Documentation/devicetree/bindings/mmc/mmc.txt | 27 .../devicetree/bindings/mmc/nvidia-sdhci.txt |4 +-- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |4 +-- arch/arm/boot/dts/imx53-smd.dts|4 +-- arch/arm/boot/dts/imx6q-arm2.dts |2 +- arch/arm/boot/dts/omap3-beagle.dts |2 +- arch/arm/boot/dts/omap4-panda.dts |4 +-- arch/arm/boot/dts/omap4-sdp.dts|6 ++--- arch/arm/boot/dts/tegra-cardhu.dts |2 ++ arch/arm/boot/dts/tegra-harmony.dts|2 ++ arch/arm/boot/dts/tegra-paz00.dts |2 ++ arch/arm/boot/dts/tegra-seaboard.dts |2 ++ arch/arm/boot/dts/tegra-ventana.dts|2 ++ arch/powerpc/boot/dts/mpc8569mds.dts |1 + drivers/mmc/host/omap_hsmmc.c |2 +- drivers/mmc/host/sdhci-esdhc-imx.c |2 +- drivers/mmc/host/sdhci-pltfm.c |8 -- 20 files changed, 66 insertions(+), 21 deletions(-) create mode 100644 Documentation/devicetree/bindings/mmc/mmc.txt diff --git a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt index 64bcb8b..0d93b4b 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt +++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt @@ -11,9 +11,11 @@ Required properties: - interrupt-parent : interrupt source phandle. - clock-frequency : specifies eSDHC base clock frequency. - sdhci,wp-inverted : (optional) specifies that eSDHC controller -reports inverted write-protect state; +reports inverted write-protect state; New devices should use +the generic "wp-inverted" property. - sdhci,1-bit-only : (optional) specifies that a controller can -only handle 1-bit data transfers. +only handle 1-bit data transfers. New devices should use the +generic "bus-width = <1>" property. - sdhci,auto-cmd12: (optional) specifies that a controller can only handle auto CMD12. diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt index ab22fe6..c7e404b 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt @@ -9,7 +9,7 @@ Required properties: - interrupts : Should contain eSDHC interrupt Optional properties: -- fsl,card-wired : Indicate the card is wired to host permanently +- non-removable : Indicate the card is wired to host permanently - fsl,cd-internal : Indicate to use controller internal card detection - fsl,wp-internal : Indicate to use controller internal write protection - cd-gpios : Specify GPIOs for card detection diff --git a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt index 89a0084..d64aea5 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt +++ b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt @@ -10,7 +10,8 @@ Required properties: Optional properties: - gpios : may specify GPIOs in this order: Card-Detect GPIO, - Write-Protect GPIO. + Write-Protect GPIO. Note that this does not follow the + binding from mmc.txt, for historic reasons. - interrupts : the interrupt of a card detect interrupt. - interrupt-parent : the phandle for the interrupt controller that services in
Re: [PATCH v3 6/6] mmc: sdhci-s3c: Add device tree support
Hi Arnd, (Diff truncated to show relevant hunks.) On Fri, Mar 30 2012, Arnd Bergmann wrote: > diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > index dbd4368..90b86e5 100644 > --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt > @@ -15,10 +15,10 @@ Optional properties: > ti,dual-volt: boolean, supports dual voltage cards > -supply: phandle to the regulator device tree node > "supply-name" examples are "vmmc", "vmmc_aux" etc > -ti,bus-width: Number of data lines, default assumed is 1 if the property is > missing. > +bus-width: Number of data lines, default assumed is 1 if the property is > missing. > cd-gpios: GPIOs for card detection > wp-gpios: GPIOs for write protection > -ti,non-removable: non-removable slot (like eMMC) > +non-removable: non-removable slot (like eMMC) > ti,needs-special-reset: Requires a special softreset sequence > > Example: > @@ -27,7 +27,7 @@ Example: > reg = <0x4809c000 0x400>; > ti,hwmods = "mmc1"; > ti,dual-volt; > - ti,bus-width = <4>; > + bus-width = <4>; > vmmc-supply = <&vmmc>; /* phandle to regulator node */ > ti,non-removable; > }; > diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c > index 47adb16..ae48fc7 100644 > --- a/drivers/mmc/host/omap_hsmmc.c > +++ b/drivers/mmc/host/omap_hsmmc.c > @@ -1766,7 +1766,7 @@ static struct omap_mmc_platform_data > *of_get_hsmmc_pdata(struct device *dev) > pdata->slots[0].nonremovable = true; > pdata->slots[0].no_regulator_off_init = true; > } > - of_property_read_u32(np, "ti,bus-width", &bus_width); > + of_property_read_u32(np, "bus-width", &bus_width); > if (bus_width == 4) > pdata->slots[0].caps |= MMC_CAP_4_BIT_DATA; > else if (bus_width == 8) Here you change "ti,non-removable" to "non-removable" in the properties section of ti-omap-hsmmc.txt without changing it in the example section of that document, or in the code or shipped .dts files. (Presumably you decided to preserve it for backwards compatibility, so the bindings documentation shouldn't be changed.) Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/6] mmc: sdhci-s3c: Add device tree support
Hi Arnd, On Fri, Mar 30 2012, Arnd Bergmann wrote: > On Friday 30 March 2012, Viresh Kumar wrote: >> On 3/27/2012 9:49 PM, Arnd Bergmann wrote: >> > These bindings came up in a discussion IRC today. I think it's rather bad >> > that >> > we can't agree on a common way to name the properties for mmc. We have >> > bindings being proposed or already included from Anton, Stephen, Shawn, >> > Rajendra, Viresh, Lee and Thomas. Almost all of them define GPIO pins >> > for card detect and write protect, as well properties to define the bus >> > width and high-speed modes, but we seem to have almost as many different >> > definitions of these as we have drivers. >> > >> > Can we please come up with a common binding for these? >> >> Is there any progress on this? Sorry i wasn't following all mails. >> How should i progress for sdhci-spear? > > No progress so far. I would suggest we apply the patch below to unify > the bindings we have. I tried to minimize the impact by picking the most > common version for each property, but if we know about devices that would > get broken by this, we may have to be more careful. > > Signed-off-by: Arnd Bergmann Thanks very much for doing this -- I'll be happy to take the patch in mmc-next once you get time to post a v2 covering Stephen Warren's review comments (and adding "max-frequency" to the document, I guess). - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi Kukjin, On Wed, Mar 28 2012, Kukjin Kim wrote: >>> As a result I'm dropping this tree -- and all of the patches that I >>> have on top of it -- from mmc-next so that I can get a pull request >>> out. This means that I'm dropping: >> > Hmm, I think, if you're ok, you can send a second pull request to > Linus for it and actually, it is in linux-next for a long time via mmc > and samsung tree. > > Note, please don't rebase it because its resolution for conflicts is > in linux-next and I think Linus will use it when happens > conflicts...Or I can provide new tree on top of latest mainline. But > I'm not sure about latter. I can't send the tree as it is to Linus now, because Arnd has asked us to hold off on these device tree bindings and work with the unified bindings he's proposing instead. (Rebasing to drop that patch will introduce new conflicts.) I'm going to send Mark Brown's two patches to Linus now, even though it will cause a conflict in -next. The rest (other than the device tree bindings) are mergable after -rc1, because they're fixes, so we'll eventually get everything except DT in to 3.4. I think you should just drop this patchset from your tree in linux-next entirely now. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi Kukjin, On Tue, Feb 21 2012, Chris Ball wrote: > On Tue, Feb 21 2012, Kukjin Kim wrote: >> I created topic branch for this we talked. You can pull that following: >> git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git >> v3.4-for-cjb >> >> If any problems, please kindly let me know. > > Pushed to mmc-next, thanks. (I'm expecting that you'll do the merge > to Linus.) I was expecting you to merge these patches, but they aren't in the arm-soc tree and haven't been sent to Linus, and we're in the last few days of the merge window. As a result I'm dropping this tree -- and all of the patches that I have on top of it -- from mmc-next so that I can get a pull request out. This means that I'm dropping: mmc: sdhci-s3c: Add device tree support mmc: sdhci-s3c: Keep a copy of platform data and use it mmc: sdhci-s3c: derive transfer width host capability from max_width in ARM: SAMSUNG: remove all uses of clk_type member in sdhci platform data ARM: EXYNOS: use 'exynos4-sdhci' as device name for sdhci controllers mmc: sdhci-s3c: Remove usage of clk_type member in platform data .. which I was expecting you to merge, and also: mmc: sdhci-s3c: fix broken compilation for non-Exynos SoCs mmc: sdhci-s3c: Enable runtime power management mmc: sdhci-s3c: Use CONFIG_PM_SLEEP to ifdef system suspend mmc: sdhci-s3c: use devm_ functions .. which were merged on top of the above patches. We'll have to try again with 3.5 for the new features, and post-rc1 for the fixes. Please let me know what happened with this merge. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: mmc: sdhci-s3c: fix broken compilation for non-Exynos SoCs
Hi Marek,
On Fri, Mar 09 2012, Marek Szyprowski wrote:
> exynos4_sdhci_drv_data structure is not available on non-Exynos builds,
> that's why EXYNOS4_SDHCI_DRV_DATA macro has been introduced. This patch
> fixes commit 67819656 'mmc: sdhci-s3c: Add device tree support' to use
> that macro. This fixes broken build for pre-Exynos SoCs.
>
> Signed-off-by: Marek Szyprowski
> ---
> 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 ea0767e..984601e 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -859,7 +859,7 @@ MODULE_DEVICE_TABLE(platform, sdhci_s3c_driver_ids);
> static const struct of_device_id sdhci_s3c_dt_match[] = {
> { .compatible = "samsung,s3c6410-sdhci", },
> { .compatible = "samsung,exynos4210-sdhci",
> - .data = &exynos4_sdhci_drv_data },
> + .data = EXYNOS4_SDHCI_DRV_DATA },
> {},
> };
> MODULE_DEVICE_TABLE(of, sdhci_s3c_dt_match);
Thanks, pushed to mmc-next for 3.4 with Jaehoon's ACK.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mmc: sdhci-s3c: Enable runtime power management
Hi,
On Fri, Mar 02 2012, Mark Brown wrote:
> Since most of the work is already done by the core we just need to add
> runtime suspend methods and tell the PM core that runtime PM is enabled
> for this device.
>
> Signed-off-by: Mark Brown
> ---
> drivers/mmc/host/sdhci-s3c.c | 28
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 46152d6..6926ac9 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -721,6 +722,11 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> if (pdata->host_caps2)
> host->mmc->caps2 |= pdata->host_caps2;
>
> + pm_runtime_enable(&pdev->dev);
> + pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> + pm_runtime_use_autosuspend(&pdev->dev);
> + pm_suspend_ignore_children(&pdev->dev, 1);
> +
> ret = sdhci_add_host(host);
> if (ret) {
> dev_err(dev, "sdhci_add_host() failed\n");
> @@ -740,6 +746,8 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
>
> err_add_host:
> release_resource(sc->ioarea);
> + pm_runtime_forbid(&pdev->dev);
> + pm_runtime_get_noresume(&pdev->dev);
> kfree(sc->ioarea);
>
> err_req_regs:
> @@ -784,6 +792,8 @@ static int __devexit sdhci_s3c_remove(struct
> platform_device *pdev)
>
> sdhci_remove_host(host, 1);
>
> + pm_runtime_disable(&pdev->dev);
> +
> for (ptr = 0; ptr < 3; ptr++) {
> if (sc->clk_bus[ptr]) {
> clk_disable(sc->clk_bus[ptr]);
> @@ -824,9 +834,27 @@ static int sdhci_s3c_resume(struct device *dev)
> }
> #endif
>
> +#ifdef CONFIG_PM_RUNTIME
> +static int sdhci_s3c_runtime_suspend(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> +
> + return sdhci_runtime_suspend_host(host);
> +}
> +
> +static int sdhci_s3c_runtime_resume(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> +
> + return sdhci_runtime_resume_host(host);
> +}
> +#endif
> +
> #ifdef CONFIG_PM
> static const struct dev_pm_ops sdhci_s3c_pmops = {
> SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
> + SET_RUNTIME_PM_OPS(sdhci_s3c_runtime_suspend, sdhci_s3c_runtime_resume,
> +NULL)
> };
>
> #define SDHCI_S3C_PMOPS (&sdhci_s3c_pmops)
I had to rework this patch to avoid a conflict with Julia Lawall's patch
"mmc: sdhci-s3c: use devm_ functions": https://lkml.org/lkml/2012/2/18/76
The reworked patch is below, please let me know if it looks incorrect:
From: Mark Brown
Subject: [PATCH] mmc: sdhci-s3c: Enable runtime power management
Since most of the work is already done by the core we just need to add
runtime suspend methods and tell the PM core that runtime PM is enabled
for this device.
Signed-off-by: Mark Brown
Acked-by: Jaehoon Chung
Signed-off-by: Chris Ball
---
drivers/mmc/host/sdhci-s3c.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 9683322..312aaf4 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
@@ -705,9 +706,16 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
if (pdata->host_caps)
host->mmc->caps |= pdata->host_caps;
+ pm_runtime_enable(&pdev->dev);
+ pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
+ pm_runtime_use_autosuspend(&pdev->dev);
+ pm_suspend_ignore_children(&pdev->dev, 1);
+
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, "sdhci_add_host() failed\n");
+ pm_runtime_forbid(&pdev->dev);
+ pm_runtime_get_noresume(&pdev->dev);
goto err_req_regs;
}
@@ -764,6 +772,8 @@ static int __devexit sdhci_s3c_remove(struct
platform_device *pdev)
sdhci_remove_host(host, 1);
+ pm_runtime_disable(&pdev->dev);
+
for (ptr = 0; ptr < 3; ptr++) {
if (sc->clk_bus[ptr]) {
clk_disable(sc->clk_bus[ptr]);
@@ -800,9 +810,27 @@ static int sdhci_s3c_resume(struct device *dev)
}
#endif
+#ifdef CONFIG_PM_RUNTIME
+static int sdhci_s3c_runtime_suspend(st
Re: [PATCH 2/2] mmc: sdhci-s3c: Enable runtime power management
Hi Mark,
On Fri, Mar 02 2012, Mark Brown wrote:
> Since most of the work is already done by the core we just need to add
> runtime suspend methods and tell the PM core that runtime PM is enabled
> for this device.
>
> Signed-off-by: Mark Brown
> ---
> drivers/mmc/host/sdhci-s3c.c | 28
> 1 files changed, 28 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 46152d6..6926ac9 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -721,6 +722,11 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> if (pdata->host_caps2)
> host->mmc->caps2 |= pdata->host_caps2;
>
> + pm_runtime_enable(&pdev->dev);
> + pm_runtime_set_autosuspend_delay(&pdev->dev, 50);
> + pm_runtime_use_autosuspend(&pdev->dev);
> + pm_suspend_ignore_children(&pdev->dev, 1);
> +
> ret = sdhci_add_host(host);
> if (ret) {
> dev_err(dev, "sdhci_add_host() failed\n");
> @@ -740,6 +746,8 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
>
> err_add_host:
> release_resource(sc->ioarea);
> + pm_runtime_forbid(&pdev->dev);
> + pm_runtime_get_noresume(&pdev->dev);
> kfree(sc->ioarea);
>
> err_req_regs:
> @@ -784,6 +792,8 @@ static int __devexit sdhci_s3c_remove(struct
> platform_device *pdev)
>
> sdhci_remove_host(host, 1);
>
> + pm_runtime_disable(&pdev->dev);
> +
> for (ptr = 0; ptr < 3; ptr++) {
> if (sc->clk_bus[ptr]) {
> clk_disable(sc->clk_bus[ptr]);
> @@ -824,9 +834,27 @@ static int sdhci_s3c_resume(struct device *dev)
> }
> #endif
>
> +#ifdef CONFIG_PM_RUNTIME
> +static int sdhci_s3c_runtime_suspend(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> +
> + return sdhci_runtime_suspend_host(host);
> +}
> +
> +static int sdhci_s3c_runtime_resume(struct device *dev)
> +{
> + struct sdhci_host *host = dev_get_drvdata(dev);
> +
> + return sdhci_runtime_resume_host(host);
> +}
> +#endif
> +
> #ifdef CONFIG_PM
> static const struct dev_pm_ops sdhci_s3c_pmops = {
> SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
> + SET_RUNTIME_PM_OPS(sdhci_s3c_runtime_suspend, sdhci_s3c_runtime_resume,
> +NULL)
> };
>
> #define SDHCI_S3C_PMOPS (&sdhci_s3c_pmops)
Thanks, pushed to mmc-next for 3.4 with Jaehoon's ACK.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mmc: sdhci-s3c: Use CONFIG_PM_SLEEP to ifdef system suspend
Hi Mark,
On Fri, Mar 02 2012, Mark Brown wrote:
> This matches current best practice as one can have runtime PM enabled
> without system sleep and CONFIG_PM is defined for both.
>
> Signed-off-by: Mark Brown
> ---
> drivers/mmc/host/sdhci-s3c.c |9 +
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index ea0767e..46152d6 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -807,8 +808,7 @@ static int __devexit sdhci_s3c_remove(struct
> platform_device *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM
> -
> +#ifdef CONFIG_PM_SLEEP
> static int sdhci_s3c_suspend(struct device *dev)
> {
> struct sdhci_host *host = dev_get_drvdata(dev);
> @@ -822,10 +822,11 @@ static int sdhci_s3c_resume(struct device *dev)
>
> return sdhci_resume_host(host);
> }
> +#endif
>
> +#ifdef CONFIG_PM
> static const struct dev_pm_ops sdhci_s3c_pmops = {
> - .suspend= sdhci_s3c_suspend,
> - .resume = sdhci_s3c_resume,
> + SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
> };
>
> #define SDHCI_S3C_PMOPS (&sdhci_s3c_pmops)
Thanks, pushed to mmc-next for 3.4 with Jaehoon's ACK.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi, On Wed, Feb 22 2012, Mark Brown wrote: > On Tue, Feb 21, 2012 at 08:17:41AM -0500, Chris Ball wrote: > >> Pushed to mmc-next, thanks. (I'm expecting that you'll do the merge >> to Linus.) > > I've been sending patches adding runtime PM support to this driver for a > while with no response - are there any issues with those? I don't have s3c hardware, so I've been waiting for a Tested-by or ACK from someone who does -- Kukjin, any objection if I take this into mmc-next with a plan to merge it, to provoke some testing? Is it possible for you to test/review the patch? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi, On Tue, Feb 21 2012, Kukjin Kim wrote: > I created topic branch for this we talked. You can pull that following: > git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git > v3.4-for-cjb > > If any problems, please kindly let me know. Pushed to mmc-next, thanks. (I'm expecting that you'll do the merge to Linus.) - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi, On Thu, Feb 16 2012, Kukjin Kim wrote: > I mean if I or you create topic branch for this whole series, can be > merged into both tree for avoiding conflicts with further working. Of > course, the topic branch don't have to rebase after merging into each > tree. > > If you're ok on this and my opinion, let me create the topic branch. Okay, sure. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support
Hi, On Thu, Feb 09 2012, Kukjin Kim wrote: > Looks ok to me and I'd like to pick this series in samsung tree with Chris' > ack. > > Chris, is it ok? If you need to merge this in your tree, please let me know. > I will provide topic branch for it. > > If any problems, please let me know. I don't have a very strong opinion, but I think it's probably better to go via the mmc tree since the patch is so large and hence the chance of conflict before merging is high. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/2] mmc: sdhci-s3c: add platform data for the second capability
Hi,
On Mon, Feb 06 2012, Jaehoon Chung wrote:
> This patch is added host_caps2 in sdhci-s3c.c
> It's necessary that use the second capabilities.
> And removed the duplicated host_caps.
>
> Signed-off-by: Jaehoon Chung
> Signed-off-by: Kyungmin Park
> ---
> Changelog v3:
> - based-on latest mmc-next tree
> Changelog v2:
> - remove the duplicated host_caps.
>
> drivers/mmc/host/sdhci-s3c.c |6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index d065e37..46b9782 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -521,9 +521,6 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> if (pdata->cd_type == S3C_SDHCI_CD_PERMANENT)
> host->mmc->caps = MMC_CAP_NONREMOVABLE;
>
> - if (pdata->host_caps)
> - host->mmc->caps |= pdata->host_caps;
> -
> if (pdata->pm_caps)
> host->mmc->pm_caps |= pdata->pm_caps;
>
> @@ -547,6 +544,9 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
> if (pdata->host_caps)
> host->mmc->caps |= pdata->host_caps;
>
> + if (pdata->host_caps2)
> + host->mmc->caps2 |= pdata->host_caps2;
> +
> ret = sdhci_add_host(host);
> if (ret) {
> dev_err(dev, "sdhci_add_host() failed\n");
In case you'd rather merge both of these via the samsung-soc tree:
Acked-by: Chris Ball
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Fix PowerOff Notify suspend/resume
Hi, On Tue, Jan 31 2012, Girish K S wrote: > Modified the mmc_poweroff to resume before sending the > poweroff notification command. In sleep mode only AWAKE > and RESET commands are allowed, so before sending the > poweroff notification command resume from sleep mode and > then send the notification command. > > POwerOff Notify is tested on a Synopsis Designware Host > Controller(eMMC 4.5). The suspend to RAM and resume works fine. > > This patch is successfully applied on the Chris's mmc-next > branch > > cc: Chris Ball > Signed-off-by: Girish K S > Tested-by: Girish K S Thanks, pushed to mmc-next for 3.3 with Saugata's Reviewed-by. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Fix Low speed mmc card detection failure
Hi,
On Wed, Jan 18 2012, Girish K S wrote:
> This patch fixes the failure of low speed mmc card detection
>
> Signed-off-by: Girish K S
> ---
> drivers/mmc/core/mmc.c |5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index dc03291..2bc586b 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -1020,7 +1020,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> err = mmc_select_hs200(card);
> else if (host->caps & MMC_CAP_MMC_HIGHSPEED)
> err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> - EXT_CSD_HS_TIMING, 1, 0);
> + EXT_CSD_HS_TIMING, 1,
> + card->ext_csd.generic_cmd6_time);
>
> if (err && err != -EBADMSG)
> goto free_card;
> @@ -1130,7 +1131,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
>* Activate wide bus and DDR (if supported).
>*/
> if (!mmc_card_hs200(card) &&
> - (card->csd.mmca_vsn >= CSD_SPEC_VER_3) &&
> + (card->csd.mmca_vsn >= CSD_SPEC_VER_4) &&
> (host->caps & (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA))) {
> static unsigned ext_csd_bits[][2] = {
> { EXT_CSD_BUS_WIDTH_8, EXT_CSD_DDR_BUS_WIDTH_8 },
Thanks, pushed to mmc-next for 3.3.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V9 2/2] mmc: host: Adds support for eMMC 4.5 HS200 mode
Hi,
On Thu, Jan 05 2012, Girish K S wrote:
> @@ -1703,10 +1707,13 @@ static int sdhci_execute_tuning(struct mmc_host *mmc)
>* Host Controller needs tuning only in case of SDR104 mode
>* and for SDR50 mode when Use Tuning for SDR50 is set in
>* Capabilities register.
> + * If the Host Controller supports the HS200 mode then tuning
> + * function has to be executed.
>*/
> if (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR104) ||
> (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR50) &&
> - (host->flags & SDHCI_SDR50_NEEDS_TUNING)))
> + (host->flags & SDHCI_SDR50_NEEDS_TUNING)) ||
> + (host->flags & SDHCI_HS200_NEEDS_TUNING))
> ctrl |= SDHCI_CTRL_EXEC_TUNING;
> else {
> spin_unlock(&host->lock);
Actually, this generates a warning:
/home/cjb/git/mmc/drivers/mmc/host/sdhci.c: In function ‘sdhci_execute_tuning’:
/home/cjb/git/mmc/drivers/mmc/host/sdhci.c:1716:7: warning: suggest parentheses
around ‘&&’ within ‘||’ [-Wparentheses]
.. as well as being hard to follow. Shall we split it up as below instead?
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 64febf2..5627354 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1694,6 +1694,7 @@ static int sdhci_execute_tuning(struct mmc_host *mmc, u32
opcode)
int tuning_loop_counter = MAX_TUNING_LOOP;
unsigned long timeout;
int err = 0;
+ bool requires_tuning_nonuhs;
host = mmc_priv(mmc);
@@ -1704,16 +1705,19 @@ static int sdhci_execute_tuning(struct mmc_host *mmc,
u32 opcode)
ctrl = sdhci_readw(host, SDHCI_HOST_CONTROL2);
/*
-* Host Controller needs tuning only in case of SDR104 mode
-* and for SDR50 mode when Use Tuning for SDR50 is set in
+* The Host Controller needs tuning only in case of SDR104 mode
+* and for SDR50 mode when Use Tuning for SDR50 is set in the
* Capabilities register.
-* If the Host Controller supports the HS200 mode then tuning
-* function has to be executed.
+* If the Host Controller supports the HS200 mode then the
+* tuning function has to be executed.
*/
- if ((ctrl & SDHCI_CTRL_UHS_MASK == SDHCI_CTRL_UHS_SDR104) ||
- ((ctrl & SDHCI_CTRL_UHS_MASK == SDHCI_CTRL_UHS_SDR50) &&
-host->flags & SDHCI_SDR50_NEEDS_TUNING ||
+ if (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR50) &&
+ (host->flags & SDHCI_SDR50_NEEDS_TUNING ||
host->flags & SDHCI_HS200_NEEDS_TUNING))
+ requires_tuning_nonuhs = true;
+
+ if (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR104) ||
+ requires_tuning_nonuhs)
ctrl |= SDHCI_CTRL_EXEC_TUNING;
else {
spin_unlock(&host->lock);
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V9 0/2] HS200 Mode support for device and host
Hi Girish,
On Thu, Jan 05 2012, Girish K S wrote:
> Girish K S (2):
> mmc: core: HS200 mode support for eMMC 4.5
> mmc: host: Adds support for eMMC 4.5 HS200 mode
Thanks, pushed to mmc-next with the following corrections to 2/2:
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 4be50ea..64febf2 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1014,8 +1014,8 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
flags |= SDHCI_CMD_INDEX;
/* CMD19 is special in that the Data Present Select should be set */
- if (cmd->data || (cmd->opcode == MMC_SEND_TUNING_BLOCK) ||
- (cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200))
+ if (cmd->data || cmd->opcode == MMC_SEND_TUNING_BLOCK ||
+ cmd->opcode == MMC_SEND_TUNING_BLOCK_HS200)
flags |= SDHCI_CMD_DATA;
sdhci_writew(host, SDHCI_MAKE_CMD(cmd->opcode, flags), SDHCI_COMMAND);
@@ -1710,10 +1710,10 @@ static int sdhci_execute_tuning(struct mmc_host *mmc,
u32 opcode)
* If the Host Controller supports the HS200 mode then tuning
* function has to be executed.
*/
- if (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR104) ||
- (((ctrl & SDHCI_CTRL_UHS_MASK) == SDHCI_CTRL_UHS_SDR50) &&
- (host->flags & SDHCI_SDR50_NEEDS_TUNING)) ||
- (host->flags & SDHCI_HS200_NEEDS_TUNING))
+ if ((ctrl & SDHCI_CTRL_UHS_MASK == SDHCI_CTRL_UHS_SDR104) ||
+ ((ctrl & SDHCI_CTRL_UHS_MASK == SDHCI_CTRL_UHS_SDR50) &&
+host->flags & SDHCI_SDR50_NEEDS_TUNING ||
+host->flags & SDHCI_HS200_NEEDS_TUNING))
ctrl |= SDHCI_CTRL_EXEC_TUNING;
else {
spin_unlock(&host->lock);
@@ -2163,8 +2163,8 @@ static void sdhci_data_irq(struct sdhci_host *host, u32
intmask)
/* CMD19 generates _only_ Buffer Read Ready interrupt */
if (intmask & SDHCI_INT_DATA_AVAIL) {
command = SDHCI_GET_CMD(sdhci_readw(host, SDHCI_COMMAND));
- if ((command == MMC_SEND_TUNING_BLOCK) ||
- (command == MMC_SEND_TUNING_BLOCK_HS200)) {
+ if (command == MMC_SEND_TUNING_BLOCK) ||
+ command == MMC_SEND_TUNING_BLOCK_HS200) {
host->tuning_done = 1;
wake_up(&host->buf_ready_int);
return;
@@ -2765,11 +2765,11 @@ int sdhci_add_host(struct sdhci_host *host)
if (caps[1] & SDHCI_SUPPORT_DDR50)
mmc->caps |= MMC_CAP_UHS_DDR50;
- /* Does the host needs tuning for SDR50? */
+ /* Does the host need tuning for SDR50? */
if (caps[1] & SDHCI_USE_SDR50_TUNING)
host->flags |= SDHCI_SDR50_NEEDS_TUNING;
- /* Does the host needs tuning for HS200? */
+ /* Does the host need tuning for HS200? */
if (mmc->caps2 & MMC_CAP2_HS200)
host->flags |= SDHCI_HS200_NEEDS_TUNING;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 46fd2ac..ad265b9 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -158,7 +158,7 @@
#define SDHCI_CTRL_UHS_SDR50 0x0002
#define SDHCI_CTRL_UHS_SDR1040x0003
#define SDHCI_CTRL_UHS_DDR50 0x0004
-#define SDHCI_CTRL_HS_SDR200 0x0005 /*reserved value in SDIO spec */
+#define SDHCI_CTRL_HS_SDR200 0x0005 /* reserved value in SDIO spec */
#define SDHCI_CTRL_VDD_180 0x0008
#define SDHCI_CTRL_DRV_TYPE_MASK 0x0030
#define SDHCI_CTRL_DRV_TYPE_B0x
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dw_mmc: Clear the DDR mode for non-DDR
Hi, On Tue, Jan 03 2012, Will Newton wrote: > On Mon, Jan 2, 2012 at 7:00 AM, Seungwon Jeon wrote: >> UHS_REG should be cleared for non-DDR mode. But currently there is >> no way to clear DDR mode, if it is already set once. This patch adds >> clearing DDR mode for non-DDD mode. >> >> Signed-off-by: Seungwon Jeon >> --- >> drivers/mmc/host/dw_mmc.c | 11 +++ >> 1 files changed, 7 insertions(+), 4 deletions(-) > > Looks ok to me, although I don't have any DDR capable hardware to test. > > Acked-by: Will Newton Thanks, pushed to mmc-next for 3.3. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 RESEND 0/2] mmc: core: Fix cache control for eMMC4.5
Hi, On Mon, Dec 26 2011, Seungwon Jeon wrote: > This patch-set fixed the cache control for eMMC4.5 > > Seungwon Jeon (2): > mmc: core: Separate the timeout value for cache-ctrl > mmc: core: Add claiming a host during mmc_cache_ctrl > > drivers/mmc/core/core.c | 29 +++-- > drivers/mmc/core/mmc.c | 13 +++-- > 2 files changed, 30 insertions(+), 12 deletions(-) Thanks, pushed to mmc-next for 3.3. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8 1/2] mmc: core: HS200 mode support for eMMC 4.5
Hi Girish, small style comments,
On Fri, Dec 23 2011, Girish K S wrote:
> This patch adds the support of the HS200 bus speed for eMMC 4.5 devices.
> The eMMC 4.5 devices have support for 200MHz bus speed. The function
> prototype of the tuning function is modified to handle the tuning command
> number which is different in sd and mmc case.
>
> cc: Chris Ball
> Signed-off-by: Girish K S
> Signed-off-by: Philip Rakity
> ---
> drivers/mmc/core/bus.c |3 +-
> drivers/mmc/core/debugfs.c |3 +
> drivers/mmc/core/mmc.c | 163
> +---
> drivers/mmc/core/sd.c |3 +-
> drivers/mmc/core/sdio.c|4 +-
> include/linux/mmc/card.h |3 +
> include/linux/mmc/host.h | 11 +++-
> include/linux/mmc/mmc.h| 66 +-
> 8 files changed, 242 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> index f8a228a..5d011a3 100644
> --- a/drivers/mmc/core/bus.c
> +++ b/drivers/mmc/core/bus.c
> @@ -303,10 +303,11 @@ int mmc_add_card(struct mmc_card *card)
> mmc_card_ddr_mode(card) ? "DDR " : "",
> type);
> } else {
> - printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
> + pr_info("%s: new %s%s%s%s card at address %04x\n",
> mmc_hostname(card->host),
> mmc_card_uhs(card) ? "ultra high speed " :
> (mmc_card_highspeed(card) ? "high speed " : ""),
> + (mmc_card_hs200(card) ? "HS200 " : ""),
> mmc_card_ddr_mode(card) ? "DDR " : "",
> type, card->rca);
> }
> diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
> index 027615d..9ab5b17 100644
> --- a/drivers/mmc/core/debugfs.c
> +++ b/drivers/mmc/core/debugfs.c
> @@ -135,6 +135,9 @@ static int mmc_ios_show(struct seq_file *s, void *data)
> case MMC_TIMING_UHS_DDR50:
> str = "sd uhs DDR50";
> break;
> + case MMC_TIMING_MMC_HS200:
> + str = "mmc high-speed SDR200";
> + break;
> default:
> str = "invalid";
> break;
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index f0a9f1f..583cb42 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -286,6 +286,27 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
> *ext_csd)
> }
> card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
> switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
> + case EXT_CSD_CARD_TYPE_SDR_ALL:
> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_8V:
> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_1_2V:
> + case EXT_CSD_CARD_TYPE_SDR_ALL_DDR_52:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> + break;
> + case EXT_CSD_CARD_TYPE_SDR_1_2V_ALL:
> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_8V:
> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_1_2V:
> + case EXT_CSD_CARD_TYPE_SDR_1_2V_DDR_52:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_2V;
> + break;
> + case EXT_CSD_CARD_TYPE_SDR_1_8V_ALL:
> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_8V:
> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_1_2V:
> + case EXT_CSD_CARD_TYPE_SDR_1_8V_DDR_52:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_1_8V;
> + break;
> case EXT_CSD_CARD_TYPE_DDR_52 | EXT_CSD_CARD_TYPE_52 |
>EXT_CSD_CARD_TYPE_26:
> card->ext_csd.hs_max_dtr = 5200;
> @@ -700,6 +721,79 @@ static int mmc_select_powerclass(struct mmc_card *card,
> }
>
> /*
> + * Selects the desired buswidth and switch to the HS200 mode
> + * if bus width set without error
> + */
> +static int mmc_select_hs200(struct mmc_card *card)
> +{
> + int idx, err = 0;
> + struct mmc_host *host;
> + static unsigned ext_csd_bits[] = {
> + EXT_CSD_BUS_WIDTH_4,
> + EXT_CSD_BUS_WIDTH_8,
> + };
> + static unsigned bus_widths[] = {
> + MMC_BUS_WIDTH_4,
> + MMC_BUS_WIDTH_8,
> + };
> +
> + BUG_ON(!card);
> +
> + host = card->host;
> +
> + if ((card-
Re: [PATCH v2] mmc: dw_mmc: Add second capability field
Hi,
On Thu, Dec 22 2011, Seungwon Jeon wrote:
> This patch adds caps2 filed for second capability in dw_mmc.
> It corresponds with MMC_CAPS2_XXX. And this patch removes the
> unnecessary condition statement for assigning caps.
>
> Signed-off-by: Seungwon Jeon
> ---
> drivers/mmc/host/dw_mmc.c |6 ++
> include/linux/mmc/dw_mmc.h |1 +
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 3aaeb08..3f5a77a 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1676,10 +1676,8 @@ static int __init dw_mci_init_slot(struct dw_mci
> *host, unsigned int id)
> if (host->pdata->setpower)
> host->pdata->setpower(id, 0);
>
> - if (host->pdata->caps)
> - mmc->caps = host->pdata->caps;
> - else
> - mmc->caps = 0;
> + mmc->caps |= host->pdata->caps;
> + mmc->caps2 |= host->pdata->caps2;
Ah, I replied earlier without having seen this patch. I still prefer
the version I proposed, which doesn't dereference host->pdata->caps{,2}
without testing it first.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Fix voltage select in DDR mode
Hi Girish, On Thu, Dec 15 2011, Girish K S wrote: > This patch fixes the wrong comparison before setting the interface > voltage in DDR mode. > > The assignment to the variable ddr before comaprison is either > ddr = MMC_1_2V_DDR_MODE; or ddr == MMC_1_8V_DDR_MODE. But the comparison > is done wth the extended csd value if (ddr == EXT_CSD_CARD_TYPE_DDR_1_2V) > > cc: Philip Rakity > cc: Arindam Nath > cc: Chris Ball > Signed-off-by: Girish K S Pushed to mmc-next for 3.3 with ACKs from Philip and Subhash and a stable@ tag, thanks. (It's too late for 3.2.) - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] mmc: dw_mmc: Support predefined mutiple block transfers
Hi,
On Thu, Dec 22 2011, Will Newton wrote:
> On Thu, Dec 22, 2011 at 9:01 AM, Seungwon Jeon wrote:
>> This patch adds the support for predefined multiple block r/w.
>> dw_mmc can support MMC_CAP_CMD23 capability.
>>
>> Signed-off-by: Seungwon Jeon
>> ---
>> drivers/mmc/host/dw_mmc.c | 34 --
>> 1 files changed, 28 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
>> index 3aaeb08..04653e8 100644
>> --- a/drivers/mmc/host/dw_mmc.c
>> +++ b/drivers/mmc/host/dw_mmc.c
>> @@ -588,11 +588,11 @@ static void dw_mci_setup_bus(struct dw_mci_slot *slot)
>> mci_writel(host, CTYPE, (slot->ctype << slot->id));
>> }
>>
>> -static void dw_mci_start_request(struct dw_mci *host,
>> - struct dw_mci_slot *slot)
>> +static void __dw_mci_start_request(struct dw_mci *host,
>> + struct dw_mci_slot *slot,
>> + struct mmc_command *cmd)
>> {
>> struct mmc_request *mrq;
>> - struct mmc_command *cmd;
>> struct mmc_data *data;
>> u32 cmdflags;
>>
>> @@ -610,14 +610,13 @@ static void dw_mci_start_request(struct dw_mci *host,
>> host->completed_events = 0;
>> host->data_status = 0;
>>
>> - data = mrq->data;
>> + data = cmd->data;
>> if (data) {
>> dw_mci_set_timeout(host);
>> mci_writel(host, BYTCNT, data->blksz*data->blocks);
>> mci_writel(host, BLKSIZ, data->blksz);
>> }
>>
>> - cmd = mrq->cmd;
>> cmdflags = dw_mci_prepare_command(slot->mmc, cmd);
>>
>> /* this is the first command, send the initialization clock */
>> @@ -635,6 +634,16 @@ static void dw_mci_start_request(struct dw_mci *host,
>> host->stop_cmdr = dw_mci_prepare_command(slot->mmc,
>> mrq->stop);
>> }
>>
>> +static void dw_mci_start_request(struct dw_mci *host,
>> + struct dw_mci_slot *slot)
>> +{
>> + struct mmc_request *mrq = slot->mrq;
>> + struct mmc_command *cmd;
>> +
>> + cmd = mrq->sbc ? mrq->sbc : mrq->cmd;
>> + __dw_mci_start_request(host, slot, cmd);
>> +}
>> +
>> /* must be called with host->lock held */
>> static void dw_mci_queue_request(struct dw_mci *host, struct
>> dw_mci_slot *slot,
>> struct mmc_request *mrq)
>> @@ -889,7 +898,14 @@ static void dw_mci_tasklet_func(unsigned long priv)
>> cmd = host->cmd;
>> host->cmd = NULL;
>> set_bit(EVENT_CMD_COMPLETE, &host->completed_events);
>> - dw_mci_command_complete(host, host->mrq->cmd);
>> + dw_mci_command_complete(host, cmd);
>> + if ((cmd == host->mrq->sbc) && !cmd->error) {
>
> The inner set of parentheses here is not strictly required.
>
>> + prev_state = state = STATE_SENDING_CMD;
>> + __dw_mci_start_request(host, host->cur_slot,
>> + host->mrq->cmd);
>> + goto unlock;
>> + }
>> +
>> if (!host->mrq->data || cmd->error) {
>> dw_mci_request_end(host, host->mrq);
>> goto unlock;
>> @@ -967,6 +983,12 @@ static void dw_mci_tasklet_func(unsigned long priv)
>> goto unlock;
>> }
>>
>> + if (host->mrq->sbc && !data->error) {
>> + data->stop->error = 0;
>> + dw_mci_request_end(host, host->mrq);
>> + goto unlock;
>> + }
>> +
>> prev_state = state = STATE_SENDING_STOP;
>> if (!data->error)
>> send_stop_cmd(host, data);
>> --
>> 1.7.0.4
>
> Otherwise looks ok.
>
> Acked-by: Will Newton
Thanks, pushed to mmc-next for 3.3 with Will's ACK and suggested change.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dw_mmc: Add more capabilities field
Hi, On Fri, Dec 09 2011, Seungwon Jeon wrote: > This patch adds another capabilities field for MMC_CAPS2_XXX. > > Signed-off-by: Seungwon Jeon > --- > drivers/mmc/host/dw_mmc.c |6 ++ > include/linux/mmc/dw_mmc.h |1 + > 2 files changed, 7 insertions(+), 0 deletions(-) > > diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c > index 3aaeb08..366df6b 100644 > --- a/drivers/mmc/host/dw_mmc.c > +++ b/drivers/mmc/host/dw_mmc.c > @@ -1681,6 +1681,12 @@ static int __init dw_mci_init_slot(struct dw_mci > *host, unsigned int id) > else > mmc->caps = 0; > > + if (host->pdata->caps2) > + mmc->caps2 = host->pdata->caps2; > + else > + mmc->caps2 = 0; > + > + I think the else clause is unnecessary here (and above), so I'll suggest merging this patch to mmc-next for 3.3 and also adding: From: Chris Ball Subject: [PATCH] mmc: dw_mmc: Remove unnecessary else clauses. Signed-off-by: Chris Ball diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 69e5889..9b839fa 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -1678,14 +1678,9 @@ static int __init dw_mci_init_slot(struct dw_mci *host, unsigned int id) if (host->pdata->caps) mmc->caps = host->pdata->caps; - else - mmc->caps = 0; if (host->pdata->caps2) mmc->caps2 = host->pdata->caps2; - else - mmc->caps2 = 0; - if (host->pdata->get_bus_wd) if (host->pdata->get_bus_wd(slot->id) >= 4) Thanks, -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Fix power_off_notify during suspend
Hi, On Tue, Nov 15 2011, Girish K S wrote: > The eMMC 4.5 devices respond to only RESET and AWAKE command in the sleep > state. Hence the mmc switch command to notify power off state should be sent > before the device enters sleep state. > > This patch fixes the same. > > Signed-off-by: Girish K S Thanks, pushed to mmc-next for 3.2. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Fix setting power notify state variable for non eMMC
Hi, On Fri, Nov 11 2011, Ulf Hansson wrote: > Girish K S wrote: >> This patch skips the setting of the power notify state variable >> for non eMMC 4.5 devices. Also fixes the problem of omap_hsmmc >> noisy/broken for suspend resume reported by kevin Hilman. >> >> cc: Chris Ball >> Signed-off-by: Girish K S >> --- >> drivers/mmc/core/mmc.c | 10 +++--- >> 1 files changed, 7 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c >> index 3627044..4db73a9 100644 >> --- a/drivers/mmc/core/mmc.c >> +++ b/drivers/mmc/core/mmc.c >> @@ -882,10 +882,14 @@ static int mmc_init_card(struct mmc_host *host, u32 >> ocr, >> card->ext_csd.generic_cmd6_time); >> if (err && err != -EBADMSG) >> goto free_card; >> -} >> - if (!err) >> -card->poweroff_notify_state = MMC_POWERED_ON; >> +/* >> + * The err can be -EBADMSG or 0, >> + * so check for success and update the flag >> + */ >> +if (!err) >> +card->poweroff_notify_state = MMC_POWERED_ON; >> +} >> /* >> * Activate high speed (if supported) > > > I encountered similar problems as for omap_hsmmc for the mmci driver > (although with some ST-Ericsson internal pm_runtime patches). This > patch fixed the problem. Great! > > Acked-by: Ulf Hansson Thanks, pushed to mmc-next for 3.2. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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] SDHCI: S3C: Use generic clock names for sdhci bus clock options
Hi Kukjin, On Wed, Nov 02 2011, Kukjin Kim wrote: >> This patch modifies the driver to stop depending on the clock names >> being passed from the platform and switch over to bus clock lookup >> using generic clock names. >> >> V6 Changes: >> Changed sprintf to snprintf as suggested by Chris Ball. >> >> Signed-off-by: Rajeshwari Shinde > > Acked-by: Kukjin Kim > > Hi Chirs, > > Could you please pick this up in your tree for this merge window? Might be easier to have you send this, if you don't mind, since I'm still traveling and have already sent my main pull request. Thanks! Acked-by: Chris Ball - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/3] SDHCI: S3C: Use generic clock names for sdhci bus clock options
Hi Rajeshwari, Kukjin,
On Fri, Oct 14 2011, Rajeshwari Shinde wrote:
> This patch modifies the driver to stop depending on the clock names
> being passed from the platform and switch over to bus clock lookup
> using generic clock names.
>
> Signed-off-by: Rajeshwari Shinde
> ---
> drivers/mmc/host/sdhci-s3c.c |6 ++
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 82709b6..a5fde87 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -435,14 +435,12 @@ static int __devinit sdhci_s3c_probe(struct
> platform_device *pdev)
>
> for (clks = 0, ptr = 0; ptr < MAX_BUS_CLK; ptr++) {
> struct clk *clk;
> - char *name = pdata->clocks[ptr];
> + char name[14];
>
> - if (name == NULL)
> - continue;
> + sprintf(name, "mmc_busclk.%d", ptr);
Let's use snprintf() here instead -- it's better to have fewer uses of
sprintf() to audit.
> clk = clk_get(dev, name);
> if (IS_ERR(clk)) {
> - dev_err(dev, "failed to get clock %s\n", name);
> continue;
> }
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 V4] mmc: core: HS200 mode support for eMMC 4.5
Hi Girish, On Wed, Oct 26 2011, Girish K S wrote: > This patch adds the support of the HS200 bus speed for eMMC 4.5 devices. > The eMMC 4.5 devices have support for 200MHz bus speed.The mmc core and > host modules have been touched to add support for this module. > > It is necessary to know the card type in the sdhci.c file to add support > for eMMC tuning function. So card.h file is included to import the card > data structure. > > cc: Chris Ball > Signed-off-by: Girish K S The long case statements and conditionals in this patch make it pretty dense/ugly -- can you think of a way to avoid doing this to the code? Also, it would be good to hear if anyone else has tested/is using this patch. Is having a new mmc_card_hs200() test desirable, compared to just reusing mmc_card_highspeed() and checking the ext_csd.card_type? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] mmc: core: Assemble the codes of related to eMMC4.5
Hi, On Mon, Oct 24 2011, Seungwon Jeon wrote: > Code cleanup. The codes of related to eMMC4.5 are scattered. > This patch removes one if-statement and assembles all. And it also > removes variable initialization below else-statement. It is obvious > for previous version but seems unnecessary. All members of card structure > are already set to zero at card-init. > > Signed-off-by: Seungwon Jeon Thanks, pushed to mmc-next for 3.2. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Assemble the codes of related to eMMC4.5
Hi Seungwon,
On Mon, Oct 24 2011, Seungwon Jeon wrote:
> Code cleanup. The codes of related to eMMC4.5 are scattered.
> This patch removes a duplicate if-statement and assembles all.
>
> Signed-off-by: Seungwon Jeon
> ---
> drivers/mmc/core/mmc.c | 20 +---
> 1 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index fb5bf01..3627044 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -467,29 +467,27 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
> *ext_csd)
> card->ext_csd.rst_n_function = ext_csd[EXT_CSD_RST_N_FUNCTION];
> }
>
> - /* eMMC v4.5 or later */
> - if (card->ext_csd.rev >= 6)
> - card->ext_csd.feature_support |= MMC_DISCARD_FEATURE;
> -
> card->ext_csd.raw_erased_mem_count = ext_csd[EXT_CSD_ERASED_MEM_CONT];
> if (ext_csd[EXT_CSD_ERASED_MEM_CONT])
> card->erased_byte = 0xFF;
> else
> card->erased_byte = 0x0;
>
> + /* eMMC v4.5 or later */
> if (card->ext_csd.rev >= 6) {
> + card->ext_csd.feature_support |= MMC_DISCARD_FEATURE;
> +
> card->ext_csd.generic_cmd6_time = 10 *
> ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
> card->ext_csd.power_off_longtime = 10 *
> ext_csd[EXT_CSD_POWER_OFF_LONG_TIME];
> - } else
> - card->ext_csd.generic_cmd6_time = 0;
Your patch removes this line completely. Why is that? You should
explain it in the commit message.
>
> - card->ext_csd.cache_size =
> - ext_csd[EXT_CSD_CACHE_SIZE + 0] << 0 |
> - ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
> - ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
> - ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
> + card->ext_csd.cache_size =
> + ext_csd[EXT_CSD_CACHE_SIZE + 0] << 0 |
> + ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
> + ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
> + ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
> + }
>
> out:
> return err;
The rest looks good, thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V9] mmc: core: Add Power Off Notify Feature eMMC 4.5
Hi, On Tue, Oct 18 2011, Girish K S wrote: >> missing one thing.unsigned intpower_notify_type; in >> include/linux/mmc/host.h > is not alligned to the above member, which was done in my latest patch Fixed. Thanks! - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V9] mmc: core: Add Power Off Notify Feature eMMC 4.5
Hi, On Tue, Oct 18 2011, Jaehoon Chung wrote: > Hi Girish. > > This patch is merged on mmc-next..did you know that? > And if deleted commit id bd3151f6c55c553bed2c0df72792841457b75bb5, > I will re-work for eMMC feature4.5. > git://git.infradead.org/users/kmpark/linux-2.6-samsung emmc4.5 > > To Chris. > If you re-commit this patch, i also change "git pull request". > there are duplicated code in Notify patch, so i didn't add to cache patch. I think I've fixed everything up -- I merged your pull request, included Girish's new patch, and moved the #defines for the CACHE_CTRL patch over to that patch instead of the power class patch. Would be great if you can double-check that the merge all looks okay to you. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Modify the timeout value for writing power class
Hi, On Tue, Oct 18 2011, Seungwon Jeon wrote: > This patch will apply the generic CMD6 timeout to switch command > for power class. > > Signed-off-by: Seungwon Jeon Thanks, applied to mmc-next for 3.2. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8] mmc: core: Add Power Off Notify Feature eMMC 4.5
Hi, On Mon, Oct 17 2011, Girish K S wrote: > After fetching your mmc-next branch. i can see that this patch is > already applied. How about the changes that have been pointed here? Thanks, it's in mmc-next for testing -- please do resend the patch and I'll fold in your changes. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8] mmc: core: Add Power Off Notify Feature eMMC 4.5
Hi Girish, On Mon, Oct 17 2011, Girish K S wrote: >>> + if (card != NULL && mmc_card_mmc(card) && >> >> != NULL is unnecessary. > > This is required. Let me explain the scenario where i felt it is necessary. I'm not saying that you shouldn't test whether card is NULL -- I'm saying that "if (card && mmc_card_mmc(card) && " would perform this test with fewer characters, and be idiomatic for the kernel. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V8] mmc: core: Add Power Off Notify Feature eMMC 4.5
Hi Girish, just trivial changes below.
Does anyone have a Tested-by: to add to the patch?
On Thu, Oct 13 2011, Girish K S wrote:
> This patch adds the support for power off notify feature, available in
> eMMC 4.5 devices. If the the host has support for this feature, then the
> mmc core will notify it to the device by setting the POWER_OFF_NOTIFICATION
> byte in the extended csd register with a value 1(POWER_ON).
>
> For suspend mode short timeout is used, whereas for the normal poweroff long
> timeout is used.
> cc: Chris Ball
> Signed-off-by: Girish K S
> Signed-off-by: Jaehoon Chung
> ---
> Changes in V8:
> Updated with review comments of Chris Ball and rebased to
> chris-mmc/mmc-next branch.
> Changes in V7:
> Rebased to chris-mmc/mmc-next branch. merged to patches
> to single patch.
> Changes in V6:
> Fixes checkpatch errors. The patches are generated after
> rebasing to chris's mmc-next branch.
> Changes in V5:
> This patch version fixes the problem with power off
> notify function, when called for the first time and
> card is not yet initialised.
> Changes in V4:
> Updated with review comments of Jeon
> Changes in V2:
> Adds poweroff notification handling in suspend/normal.
>
> drivers/mmc/core/core.c | 36
> drivers/mmc/core/mmc.c | 23 +--
> drivers/mmc/host/sdhci.c |9 +
> include/linux/mmc/card.h |6 ++
> include/linux/mmc/host.h |6 ++
> include/linux/mmc/mmc.h |8
> 6 files changed, 86 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
> index 61d7730..db368b2 100644
> --- a/drivers/mmc/core/core.c
> +++ b/drivers/mmc/core/core.c
> @@ -1212,11 +1212,45 @@ static void mmc_power_up(struct mmc_host *host)
>
> void mmc_power_off(struct mmc_host *host)
> {
> + struct mmc_card *card;
struct mmc_card *card = host->card;
> + unsigned int notify_type;
> + unsigned int timeout;
> + int err;
> +
> + BUG_ON(!host);
Not necessary.
> +
> mmc_host_clk_hold(host);
>
> + card = host->card;
> host->ios.clock = 0;
> host->ios.vdd = 0;
>
> + if (card != NULL && mmc_card_mmc(card) &&
!= NULL is unnecessary.
> + (card->poweroff_notify_state == MMC_POWERED_ON)) {
Extra set of parens unnecessary.
> +
> + if (host->power_notify_type == MMC_HOST_PW_NOTIFY_SHORT) {
> + notify_type = EXT_CSD_POWER_OFF_SHORT;
> + timeout = card->ext_csd.generic_cmd6_time;
> + card->poweroff_notify_state = MMC_POWEROFF_SHORT;
> + } else {
> + notify_type = EXT_CSD_POWER_OFF_LONG;
> + timeout = card->ext_csd.power_off_longtime;
> + card->poweroff_notify_state = MMC_POWEROFF_LONG;
> + }
> +
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_POWER_OFF_NOTIFICATION,
> + notify_type, timeout);
> +
> + if (err && err != -EBADMSG)
> + pr_err("Device failed to respond within %d poweroff "
> +"time. Forcefully powering down the device\n",
> +timeout);
> +
> + /* Set the card state to no notification after the poweroff */
> + card->poweroff_notify_state = MMC_NO_POWER_NOTIFICATION;
> + }
> +
> /*
>* Reset ocr mask to be the highest possible voltage supported for
>* this mmc host. This value will be used at next power up.
> @@ -2208,6 +2242,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
>
> spin_lock_irqsave(&host->lock, flags);
> host->rescan_disable = 1;
> + host->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
> spin_unlock_irqrestore(&host->lock, flags);
> cancel_delayed_work_sync(&host->detect);
>
> @@ -2231,6 +2266,7 @@ int mmc_pm_notify(struct notifier_block *notify_block,
>
> spin_lock_irqsave(&host->lock, flags);
> host->rescan_disable = 0;
> + host->power_notify_type = MMC_HOST_PW_NOTIFY_LONG;
> spin_unlock_irqrestore(&host->lock, flags);
> mmc_detect_change(host, 0);
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 4e869d3..f8ea938 100644
> --- a/drivers/mmc
Re: [PATCH RESEND V1] mmc: replace printk with appropriate display macro
Hi, On Tue, Oct 11 2011, Girish K S wrote: > All the files using printk function for displaying kernel messages > in the mmc driver have been replaced with corresponding macro. Thanks, applied! I haven't been sure how to handle this patch; in general cosmetic patches that touch many parts of many files are a bad idea, because they break the ability to merge patches. Since we're getting near the end of merging the 3.2 merge window patches, though, maybe now is a good time. If this patch starts causing merge conflicts, I might pull it out later or remove the modifications for the most common files (core.c/sd.c/sdhci.c). Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 RESEND 2/2] mmc: core: Add Poweroff Notify handling eMMC 4.5
Hi Girish, On Tue, Oct 11 2011, Girish K S wrote: > This is a very old version of the patch. My latest patch has been > merged with Mr Chung's branch (the one with PULL REQUEST). > These comments have been already taken care. No, that's not the case. Here is the version of the patch on the emmc4.5 branch that the pull request is for: http://git.infradead.org/users/kmpark/linux-2.6-samsung/commitdiff/dac139c9591545a40ea0058d9305514130762682 and it has the same problems I'm replying to here. Maybe the wrong version got merged? Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 RESEND 2/2] mmc: core: Add Poweroff Notify handling eMMC 4.5
wline needed here, as there was before you added these two lines.
> /*
>* Activate high speed (if supported)
>*/
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index 0e02cc1..92ea734 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -2566,6 +2566,16 @@ int sdhci_add_host(struct sdhci_host *host)
> if (caps[1] & SDHCI_DRIVER_TYPE_D)
> mmc->caps |= MMC_CAP_DRIVER_TYPE_D;
>
> + /*
> + * If Notify capability is enabled and
> + * notify type is not initialised by host, set default to
> + * long power off notify timeout value
> + */
> + if (mmc->caps & MMC_CAP_POWER_OFF_NOTIFY)
> + mmc->power_notify_type = MMC_HOST_PW_NOTIFY_SHORT;
> + else
> + mmc->power_notify_type = MMC_HOST_PW_NOTIFY_NONE;
> +
The comment says it sets the default to long power off if power_notify_type
is unset, but the code sets power_notify_type to short power off regardless
of whether power_notify_type was set. The comment and code should agree.
> /* Initial value for re-tuning timer count */
> host->tuning_count = (caps[1] & SDHCI_RETUNING_TIMER_COUNT_MASK) >>
> SDHCI_RETUNING_TIMER_COUNT_SHIFT;
> diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
> index 2bf2843..1d6a832 100644
> --- a/include/linux/mmc/card.h
> +++ b/include/linux/mmc/card.h
> @@ -190,6 +190,11 @@ struct mmc_card {
> #define MMC_QUIRK_DISABLE_CD (1<<5) /* disconnect CD/DAT[3]
> resistor */
> #define MMC_QUIRK_INAND_CMD38(1<<6) /* iNAND devices have
> broken CMD38 */
> #define MMC_QUIRK_BLK_NO_CMD23 (1<<7) /* Avoid CMD23 for
> regular multiblock */
> + unsigned intpoweroff_notify_state;/*eMMC4.5 notify feature */
> +#define MMC_NO_POWER_NOTIFICATION 0
> +#define MMC_POWERED_ON 1
> +#define MMC_POWEROFF_SHORT 2
> +#define MMC_POWEROFF_LONG 3
>
> unsigned interase_size; /* erase size in sectors */
> unsigned interase_shift;/* if erase unit is power 2 */
> @@ -325,6 +330,20 @@ static inline void __maybe_unused remove_quirk(struct
> mmc_card *card, int data)
> #define mmc_sd_card_set_uhs(c) ((c)->state |= MMC_STATE_ULTRAHIGHSPEED)
> #define mmc_card_set_ext_capacity(c) ((c)->state |= MMC_CARD_SDXC)
>
> +#define mmc_card_powernotify_on(c) \
> + ((c)->poweroff_notify_state == MMC_POWERED_ON)
> +#define mmc_card_powernotify_off(c)\
> + ((c)->poweroff_notify_state == MMC_NO_POWER_NOTIFICATION)
> +
> +#define mmc_card_set_powernotify_off(c)\
> + ((c)->poweroff_notify_state = MMC_NO_POWER_NOTIFICATION)
> +#define mmc_card_set_powernotify_on(c) \
> + ((c)->poweroff_notify_state = MMC_POWERED_ON)
> +#define mmc_card_set_powernotify_short(c) \
> + ((c)->poweroff_notify_state = MMC_POWEROFF_SHORT)
> +#define mmc_card_set_powernotify_long(c) \
> + ((c)->poweroff_notify_state = MMC_POWEROFF_LONG)
> +
I don't think these macros need to exist. You can already do the same
thing in one line of code, and it would be clearer to be modifying/testing
poweroff_notify_state directly. The only case where it might save enough
column space to allow fitting everything on one line is for
MMC_NO_POWER_NOTIFICATION, but maybe that's just a sign that this
#define should be made shorter somehow.
Thanks! Please could you rebase against mmc-next, fix, and resend?
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: card: modify mmc_getgeo function
Hi, On Mon, Sep 26 2011, Uwe Kleine-König wrote: >> Thanks, pushed to mmc-next for 3.2 with a reworded commit message: > This (i.e. ee9e0e0 (mmc: card: Remove duplicated constants) in next) > makes gcc emit a reference to __aeabi_uldivmod in one of my nightly > builds which isn't defined. > > The final linking stage fails with: > > LD .tmp_vmlinux1 > drivers/built-in.o: In function `mmc_blk_getgeo': > clkdev.c:(.text+0xd1528): undefined reference to `__aeabi_uldivmod' > make[2]: *** [.tmp_vmlinux1] Error 1 > make[1]: *** [sub-make] Error 2 > make: *** [all] Error 2 Interesting, thanks. It builds fine here on my (gcc-4.6) ARM toolchains. Looking online, I think you're hitting an old gcc-4.3 bug? - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: core: eMMC 4.5 Power Class Selection Feature
Hi Girish, On Fri, Sep 23 2011, Girish K S wrote: > This patch adds the power class selection feature available > for mmc versions 4.0 and above. > During the enumeration stage before switching to the lower > data bus, check if the power class is supported for the > current bus width. If the power class is available then > switch to the power class and use the higher data bus. If > power class is not supported then switch to the lower data > bus in a worst case. > > Signed-off-by: Girish K S Thanks, pushed to mmc-next for 3.2 now. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] mmc: core: eMMC 4.5 Power Class Selection Feature
Hi Girish, On Fri, Sep 23 2011, Girish K S wrote: >> I suggested replacing your BUG(); here with a return, but you just have >> a break here. Is having the function continue in this case intentional? > > sorry for that. > will update with a return -EBADMSG Thanks; let's go with -EINVAL, though. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4] mmc: core: eMMC 4.5 Power Class Selection Feature
Hi Girish,
On Fri, Sep 23 2011, Girish K S wrote:
> + default:
> + pr_warning("%s: Voltage range not supported "
> +"for power class.\n", mmc_hostname(host));
> + break;
> + }
I suggested replacing your BUG(); here with a return, but you just have
a break here. Is having the function continue in this case intentional?
> +
> + pwrclass_val = ext_csd[index];
> +
> + if (bus_width & (EXT_CSD_BUS_WIDTH_8 | EXT_CSD_DDR_BUS_WIDTH_8))
> + pwrclass_val = (pwrclass_val & EXT_CSD_PWR_CL_8BIT_MASK) >>
> + EXT_CSD_PWR_CL_8BIT_SHIFT;
> + else
> + pwrclass_val = (pwrclass_val & EXT_CSD_PWR_CL_4BIT_MASK) >>
> + EXT_CSD_PWR_CL_4BIT_SHIFT;
> +
> + /* If the power class is different from the default value */
> + if (pwrclass_val > 0) {
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_POWER_CLASS,
> + pwrclass_val,
> + 0);
> + }
> +
> + return err;
> +}
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3] mmc: core: eMMC 4.5 Power Class Selection Feature
Hi Girish,
On Thu, Sep 22 2011, Girish K S wrote:
> This patch adds the power class selection feature available
> for mmc versions 4.0 and above.
> During the enumeration stage before switching to the lower
> data bus, check if the power class is supported for the
> current bus width. If the power class is available then
> switch to the power class and use the higher data bus. If
> power class is not supported then switch to the lower data
> bus in a worst case.
>
> Signed-off-by: Girish K S
> ---
> v1:
> This patch version modifies the power_class_select function prototype.
> During device enumeration, when the host tries to read the extended
> csd register after switching to higher bus width, the read fails at
> higher bus width. So the power_class_select function is modified to
> reuse the extended csd register values read with 1 bit bus width.
> v2:
> This patch version removes some checkpatch error
> v3:
> updated with review comments made by chris ball. patch generated
> by rebasing to chris balls mmc-next branch.
The mmc.h patch doesn't apply against today's mmc-next branch -- maybe
due to a patch I pushed yesterday, also make sure that you're on the
mmc-next branch, not master. Mind rebasing once more, please? And:
> drivers/mmc/core/mmc.c | 91
> +++
> include/linux/mmc/mmc.h | 13 +++
> 2 files changed, 104 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index e3695a0..9dd6c82 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -536,6 +536,81 @@ static struct device_type mmc_type = {
> };
>
> /*
> + * Select the PowerClass for the current bus width
> + * If power class is defined for 4/8 bit bus in the
> + * extended CSD register, select it by executing the
> + * mmc_switch command.
> + */
> +static int mmc_select_powerclass(struct mmc_card *card,
> + unsigned int bus_width, u8 *ext_csd)
> +{
> + int err = 0;
> + unsigned int pwrclass_val;
> + unsigned int index = 0;
> + struct mmc_host *host = card->host;
> +
> + BUG_ON(!card);
If you're going to test the validity of card, do it before dereferencing
card->host above.
> + BUG_ON(!host);
> +
> + if (ext_csd == NULL)
> + return 0;
> + /* Power class selection is supported for versions >= 4.0 */
> + if (card->csd.mmca_vsn < CSD_SPEC_VER_4)
> + return 0;
> + /* Power class values are defined only for 4/8 bit bus */
> + if (bus_width == EXT_CSD_BUS_WIDTH_1)
> + return 0;
Let's add newlines before each comment line here.
> +
> + switch (1 << host->ios.vdd) {
> + case MMC_VDD_165_195:
> + if (host->ios.clock <= 2600)
> + index = EXT_CSD_PWR_CL_26_195;
> + else if (host->ios.clock <= 5200)
> + index = (bus_width <= EXT_CSD_BUS_WIDTH_8) ?
> + EXT_CSD_PWR_CL_52_195 :
> + EXT_CSD_PWR_CL_DDR_52_195;
> + else if (host->ios.clock <= 2)
> + index = EXT_CSD_PWR_CL_200_195;
> + break;
> + case MMC_VDD_32_33:
> + case MMC_VDD_33_34:
> + case MMC_VDD_34_35:
> + case MMC_VDD_35_36:
> + if (host->ios.clock <= 2600)
> + index = EXT_CSD_PWR_CL_26_360;
> + else if (host->ios.clock <= 5200)
> + index = (bus_width <= EXT_CSD_BUS_WIDTH_8) ?
> + EXT_CSD_PWR_CL_52_360 :
> + EXT_CSD_PWR_CL_DDR_52_360;
> + else if (host->ios.clock <= 2)
> + index = EXT_CSD_PWR_CL_200_360;
> + break;
> + default:
> + printk(KERN_ERR "votage range not supported\n");
(voltage, not votage)
This isn't good, because someone reading dmesg will have no idea that
this message came from MMC, and even if they know that it came from MMC,
they won't know which controller/card it came from.
I suggest:
pr_warning("%s: Voltage range not supported for power class.\n",
mmc_hostname(host));
> + break;
> + }
> +
> + pwrclass_val = ext_csd[index];
> +
> + if (bus_width & (EXT_CSD_BUS_WIDTH_8 | EXT_CSD_DDR_BUS_WIDTH_8))
> + pwrclass_val = (pwrclass_val & EXT_CSD_PWR_CL_8BIT_MASK) >>
> + EXT_CSD_PWR_CL_8BIT_SHI
Re: [PATCH] mmc: card: modify mmc_getgeo function
Hi,
On Tue, Sep 20 2011, Girish K S wrote:
> In the earlier code the cylinder, sector and head are assigned
> independently. Current patch generates the cylinder number
> with the values of sector and head.
> This patch only makes they cylinder value to be dependent on
> the sector and head.
>
> Signed-off-by: Girish K S
> ---
> drivers/mmc/card/block.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 1ff5486..bebb13b 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -226,9 +226,10 @@ static int mmc_blk_release(struct gendisk *disk, fmode_t
> mode)
> static int
> mmc_blk_getgeo(struct block_device *bdev, struct hd_geometry *geo)
> {
> - geo->cylinders = get_capacity(bdev->bd_disk) / (4 * 16);
> geo->heads = 4;
> geo->sectors = 16;
> + geo->cylinders = get_capacity(bdev->bd_disk) /
> + (geo->heads * geo->sectors);
> return 0;
> }
Thanks, pushed to mmc-next for 3.2 with a reworded commit message:
Author: Girish K S
Date: Tue Sep 20 16:38:49 2011 +0530
mmc: card: Remove duplicated constants
Reuse heads/sectors instead of duplicating them in the cylinders
calculation.
Signed-off-by: Girish K S
Signed-off-by: Chris Ball
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: HS200 mode support for eMMC 4.5
Hi Girish,
On Fri, Sep 16 2011, Girish K S wrote:
> This patch adds the support of the HS200 bus speed for
> eMMC 4.5 devices.
> The eMMC 4.5 devices have support for 200MHz bus speed.
> The mmc core and host modules have been touched to add support
> for this module.
> It is necessary to know the card type in the sdhci.c file to
> add support for eMMC tuning function. So card.h file is included
> to import the card data structure.
>
> Signed-off-by: Girish K S
> ---
> drivers/mmc/core/bus.c |3 +-
> drivers/mmc/core/mmc.c | 116
> ++
> drivers/mmc/host/sdhci.c | 18 ++-
> include/linux/mmc/card.h |3 +
> include/linux/mmc/host.h |8 +++
> include/linux/mmc/mmc.h |9 +++-
> 6 files changed, 143 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
> index 393d817..a0aa7ab 100644
> --- a/drivers/mmc/core/bus.c
> +++ b/drivers/mmc/core/bus.c
> @@ -301,10 +301,11 @@ int mmc_add_card(struct mmc_card *card)
> mmc_card_ddr_mode(card) ? "DDR " : "",
> type);
> } else {
> - printk(KERN_INFO "%s: new %s%s%s card at address %04x\n",
> + printk(KERN_INFO "%s: new %s%s%s%s card at address %04x\n",
> mmc_hostname(card->host),
> mmc_sd_card_uhs(card) ? "ultra high speed " :
> (mmc_card_highspeed(card) ? "high speed " : ""),
> + (mmc_card_hs200(card) ? "HS200 " : ""),
> mmc_card_ddr_mode(card) ? "DDR " : "",
> type, card->rca);
> }
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 9cbc113..c50ca42 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -283,6 +283,66 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
> *ext_csd)
> }
> card->ext_csd.raw_card_type = ext_csd[EXT_CSD_CARD_TYPE];
> switch (ext_csd[EXT_CSD_CARD_TYPE] & EXT_CSD_CARD_TYPE_MASK) {
> + case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_52 |
> + EXT_CSD_CARD_TYPE_26:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> + break;
> + case EXT_CSD_CARD_TYPE_SDR_200 | EXT_CSD_CARD_TYPE_DDR_1_8V |
> + EXT_CSD_CARD_TYPE_52 | EXT_CSD_CARD_TYPE_26:
> + card->ext_csd.hs_max_dtr = 2;
> + card->ext_csd.card_type = EXT_CSD_CARD_TYPE_SDR_200;
> + break;
Please try shortening this switch-case by avoiding duplicating sections
that repeat the same action, and having the case fall-through instead.
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: eMMC 4.5 Power Class Selection Feature
Hi Girish,
On Tue, Sep 13 2011, Girish K S wrote:
> This patch adds the power class selection feature available
> for mmc versions 4.0 and above.
> During the enumeration stage before switching to the lower
> data bus, check if the power class is supported for the
> current bus width. If the power class is available then
> switch to the power class and use the higher data bus. If
> power class is not supported then switch to the lower data
> bus in a worst case.
>
> Signed-off-by: Girish K S
> ---
> drivers/mmc/core/mmc.c | 77
> +++
> include/linux/mmc/mmc.h | 13
> 2 files changed, 90 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index 63cc77b..a4004da 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -536,6 +536,81 @@ static struct device_type mmc_type = {
> };
>
> /*
> + * Select the PowerClass for the current bus width
> + * If power class is defined for 4/8 bit bus in the
> + * extended CSD register, select it by executing the
> + * mmc_switch command.
> + */
> +static int mmc_select_powerclass(struct mmc_card *card, unsigned int
> bus_width)
> +{
> + u8 *ext_csd;
> + int err;
> + unsigned int pwrclass_val;
> + unsigned int index = 0;
> + struct mmc_host *host = card->host;
> +
> + BUG_ON(!card);
> + BUG_ON(!host);
> +
> + /* Power class selection is supported for versions >= 4.0 */
> + if (card->csd.mmca_vsn < CSD_SPEC_VER_4)
> + return 0;
> + /*Power class values are defined only for 4/8 bit bus*/
Spaces between /* */ and the comment itself, please.
> + if (bus_width == EXT_CSD_BUS_WIDTH_1)
> + return 0;
> +
> + switch ((1 << host->ios.vdd)) {
Extra parens unnecessary.
> + case MMC_VDD_165_195:
> + if (host->ios.clock <= 2600)
> + index = EXT_CSD_PWR_CL_26_195;
> + else if (host->ios.clock <= 5200)
> + index = (bus_width <= EXT_CSD_BUS_WIDTH_8) ?
> + EXT_CSD_PWR_CL_52_195 :
> + EXT_CSD_PWR_CL_DDR_52_195;
> + else if (host->ios.clock <= 2)
> + index = EXT_CSD_PWR_CL_200_195;
> + break;
> + case MMC_VDD_32_33:
> + case MMC_VDD_33_34:
> + case MMC_VDD_34_35:
> + case MMC_VDD_35_36:
> + if (host->ios.clock <= 2600)
> + index = EXT_CSD_PWR_CL_26_360;
> + else if (host->ios.clock <= 5200)
> + index = (bus_width <= EXT_CSD_BUS_WIDTH_8) ?
> + EXT_CSD_PWR_CL_52_360 :
> + EXT_CSD_PWR_CL_DDR_52_360;
> + else if (host->ios.clock <= 2)
> + index = EXT_CSD_PWR_CL_200_360;
> + break;
> + default:
> + BUG();
BUG() is a huge deal -- it will take out the entire MMC stack, so it's
not appropriate here. How about just a pr_error() that notes an
unexpected VDD and then returns an error value?
> + break;
> + }
> +
> + err = mmc_get_ext_csd(card, &ext_csd);
> + if (err)
> + goto ret;
> +
> + pwrclass_val = ext_csd[index];
> +
> + if (bus_width & (EXT_CSD_BUS_WIDTH_8 | EXT_CSD_DDR_BUS_WIDTH_8))
> + pwrclass_val = (pwrclass_val & EXT_CSD_PWR_CL_8BIT_MASK) >>
> + EXT_CSD_PWR_CL_8BIT_SHIFT;
> + else
> + pwrclass_val = (pwrclass_val & EXT_CSD_PWR_CL_4BIT_MASK) >>
> + EXT_CSD_PWR_CL_4BIT_SHIFT;
> +
> + err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
> + EXT_CSD_POWER_CLASS,
> + pwrclass_val,
> + 0);
> +ret:
> + mmc_free_ext_csd(ext_csd);
> + return err;
> +}
> +
> +/*
> * Handle the detection and initialisation of a card.
> *
> * In the case of a resume, "oldcard" will contain the card
> @@ -802,6 +877,7 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
> bus_width = bus_widths[idx];
> if (bus_width == MMC_BUS_WIDTH_1)
> ddr = 0; /* no DDR for 1-bit width */
> + mmc_select_powerclass(card, ext_csd_bits[idx][0]);
Since you're returning a meaningful error value above, we should do
something with it here -- if you don't expect the error cases to be
hit, you could pr_warning() the return value here so that we can
investigate.
Thanks,
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mmc: core: Add default timeout value for CMD6.
Hi, On Thu, Sep 08 2011, Seungwon Jeon wrote: > EXT_CSD[248] includes the default maximum timeout for CMD6. > This field is added at eMMC4.5 Spec. And it can be used for default > timeout except for some operations which don't define the timeout(i.e. > background operation, sanitize, flush cache) in eMMC4.5 Spec. > > Signed-off-by: Seungwon Jeon > --- > drivers/mmc/core/mmc.c | 19 +++ > include/linux/mmc/card.h |1 + > include/linux/mmc/mmc.h |1 + > 3 files changed, 17 insertions(+), 4 deletions(-) > > diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c > index 5700b1c..a72d879 100644 > --- a/drivers/mmc/core/mmc.c > +++ b/drivers/mmc/core/mmc.c > @@ -410,6 +410,15 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 > *ext_csd) > else > card->erased_byte = 0x0; > > + if (card->ext_csd.rev >= 6) > + card->ext_csd.generic_cmd6_time = 10 * > + ext_csd[EXT_CSD_GENERIC_CMD6_TIME]; > + else > + card->ext_csd.generic_cmd6_time = 0; > + > out: > return err; > } > @@ -668,7 +677,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, >*/ The patch is corrupt at this point: patching file drivers/mmc/core/mmc.c patch: malformed patch at line 39: @@ -668,7 +677,8 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 1/2] mmc: sdhci-s3c: add default controller configuration
Hi, On Wed, Sep 21 2011, Kukjin Kim wrote: > Acked-by: Kukjin Kim > > Hi Chris, > > This is ok to me. Could you please pick this up in your tree so that I can > pick 2nd patch up in my tree. > > As you know, this patch has no dependency with patch2/2 so that you can > handle without any conflicts. Thanks, pushed to mmc-next for 3.2. I've been waiting for kernel.org to come back up, but I think later today I'll just move mmc-next to git://dev.laptop.org/users/cjb/mmc, so this will be available in linux-next soon. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Fix the incorrect calculation for erase unit size.
Hi, On Tue, Sep 13 2011, Seungwon Jeon wrote: >> On Thu, Sep 08 2011, Seungwon Jeon wrote: >> > Erase unit size of high capacity is multiple of 512KiB not 1024KiB. >> >> Could we have some more info, please? What are the visible symptoms >> of the erase unit size being incorrect, how did you realize this was >> a problem, should this patch be applied to stable@, etc. > > It is mentioned from eMMC Spec. > Erase unit size is defined in 512Kbyte * HC_ERASE_GRP_SIZE(EXT_CSD[224]). You haven't answered any of the other questions I asked, though. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: Fix the incorrect calculation for erase unit size.
Hi, On Thu, Sep 08 2011, Seungwon Jeon wrote: > Erase unit size of high capacity is multiple of 512KiB not 1024KiB. Could we have some more info, please? What are the visible symptoms of the erase unit size being incorrect, how did you realize this was a problem, should this patch be applied to stable@, etc. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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-s3c: Fix mmc card I/O problem
Hi, On Fri, Aug 26 2011, Girish K S wrote: > This patch fixes the problem in sdhci-s3c host driver for > Samsung Soc's. During the card identification stage the > mmc core driver enumerates for the best bus width in combination > with the highest available data rate. It starts enumerating from > the highest bus width (8) to lowest bus width (1). > > In case of few MMC cards the 4-bit bus enumeration fails and tries > the 1-bit bus enumeration. When switched to 1-bit bus mode the host driver > has to clear the previous bus width setting and apply the new setting. > > The current patch will clear the previous bus mode and apply the new > mode setting. > > Signed-off-by: Girish K S Thanks, pushed to mmc-next for 3.1 with a stable@ tag. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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-s3c: Fix return value in sdhci_s3c_suspend/resume()
Hi Kukjin,
On Tue, Jun 28 2011, Kukjin Kim wrote:
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 69e3ee3..460ffaf 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -612,16 +612,14 @@ static int sdhci_s3c_suspend(struct platform_device
> *dev, pm_message_t pm)
> {
> struct sdhci_host *host = platform_get_drvdata(dev);
>
> - sdhci_suspend_host(host, pm);
> - return 0;
> + return sdhci_suspend_host(host, pm);
> }
>
> static int sdhci_s3c_resume(struct platform_device *dev)
> {
> struct sdhci_host *host = platform_get_drvdata(dev);
>
> - sdhci_resume_host(host);
> - return 0;
> + return sdhci_resume_host(host);
> }
>
> #else
Thanks, pushed to mmc-next for 3.1.
- Chris.
--
Chris Ball <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dw_mmc: protect a sequence of request and request-done.
Hi, On Mon, Jun 20 2011, Will Newton wrote: > On Mon, Jun 20, 2011 at 9:24 AM, Seungwon Jeon wrote: >> Response timeout(RTO), Response crc error(RCRC) and Response error(RE) >> signals come with command done(CD) and can be raised preceding command >> done(CD). That is these error interrupts and CD can be handled in >> separate dw_mci_interrupt(). If mmc_request_done() is called because of >> response timeout before command done is occured, next request can be >> sent, but CD of current request is not finished. This can bring about >> a broken sequence of request and request-done. >> >> And Data error interrupt(DRTO, DCRC, SBE, EBE) and data transfer >> over(DTO) are same reanson. >> >> Signed-off-by: Seungwon Jeon > > Acked-by: Will Newton Pushed to mmc-next for 3.1, thanks. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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: dw_mmc: set the card_width bit per card.
Hi, On Mon, Jun 20 2011, Will Newton wrote: > On Mon, Jun 20, 2011 at 9:23 AM, Seungwon Jeon wrote: >> This patch sets the card_width bit of CTYPE for the corresponding card. >> >> CTYPE[31] and CTYPE[16] correspond respectively to card[15] and card[0] >> for 8-bit mode. And CTYPE[15] and CTYPE[0] correspond respectively to >> card[15] and CTYPE[0] for 1-bit or 4-bit mode. >> >> Signed-off-by: Seungwon Jeon > > Acked-by: Will Newton Pushed to mmc-next for 3.1, thanks. - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/2] sdhci-s3c: Add support no internal clock divider in host controller
Hi Kyungmin, Ben, On Mon, Dec 20, 2010 at 11:08:00AM +0900, Kyungmin Park wrote: > Hi Chris, > > Unfortunately it's not merged your tree. > It's required for s5pc210 board. can you merge it for 37-rc6 or later? I'm not comfortable slipping this into .37 (-rc6 has already been released) without an ACK from Ben, but I will accept it into mmc-next for the .38 merge window, and Ben can yell sometime before the merge if he doesn't agree. Does that work okay for you? Thanks, -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 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 2/2] sdhci-s3c: Add support no internal clock divider in host controller
Hi Kyungmin, On Tue, Oct 12, 2010 at 11:53:35AM +0900, Kyungmin Park wrote: > Hi Chris, > > we make a conclusion use this patch. Can you merge it for 2.6.37? > > Acked-by: Kyungmin Park I don't feel that I can, because Ben Dooks is listed as the maintainer for this driver and the patch does not have his ACK. I don't know what to do about this; I've already tried asking Ben whether he intends to continue maintaining sdhci-s3c, with no reply. Thanks, - Chris. -- Chris Ball <http://printf.net/> One Laptop Per Child -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
