| Message ID | 00b901ccf08d$2fc18b50$8f44a1f0$%kim@samsung.com |
|---|---|
| State | New |
| Headers | show |
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.
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?
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.
On 03/03/12 05:40, Chris Ball wrote: > 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? > Hi Chris, Maybe I lost Mark's runtime PM supporting patches. I couldn't find it in my mail box. Sorry for that :( Mark, could you please send it to me again? Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
Acked-by: Jaehoon Chung <jh80.chung@samsung.com> On 03/03/2012 09:46 AM, 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 <broonie@opensource.wolfsonmicro.com> > --- > 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 <linux/module.h> > #include <linux/of.h> > #include <linux/of_gpio.h> > +#include <linux/pm.h> > > #include <linux/mmc/host.h> > > @@ -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)
Hi Mark, On 03/03/2012 09:46 AM, 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 <broonie@opensource.wolfsonmicro.com> > --- > 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 <linux/of.h> > #include <linux/of_gpio.h> > #include <linux/pm.h> > +#include <linux/pm_runtime.h> > > #include <linux/mmc/host.h> > > @@ -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); Could you explain why use 50ms? > + pm_runtime_use_autosuspend(&pdev->dev); > + pm_suspend_ignore_children(&pdev->dev, 1); Is there reason that ignore_children use to set the true? > + > 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)
On Mon, Mar 05, 2012 at 07:48:42PM +0900, Jaehoon Chung wrote: > On 03/03/2012 09:46 AM, Mark Brown wrote: > > + pm_runtime_set_autosuspend_delay(&pdev->dev, 50); > Could you explain why use 50ms? It's essentially a random number, some other devices use the same one. We're just trying to avoid suspending between back to back requests. > > + pm_runtime_use_autosuspend(&pdev->dev); > > + pm_suspend_ignore_children(&pdev->dev, 1); > Is there reason that ignore_children use to set the true? So that we can suspend the host without having to have the MMC card suspended (the host suspend is not visible to the card).
Acked-by: Jaehoon Chung <jh80.chung@samsung.com> On 03/05/2012 08:52 PM, Mark Brown wrote: > On Mon, Mar 05, 2012 at 07:48:42PM +0900, Jaehoon Chung wrote: >> On 03/03/2012 09:46 AM, Mark Brown wrote: > >>> + pm_runtime_set_autosuspend_delay(&pdev->dev, 50); > >> Could you explain why use 50ms? > > It's essentially a random number, some other devices use the same one. > We're just trying to avoid suspending between back to back requests. > >>> + pm_runtime_use_autosuspend(&pdev->dev); >>> + pm_suspend_ignore_children(&pdev->dev, 1); > >> Is there reason that ignore_children use to set the true? > > So that we can suspend the host without having to have the MMC card > suspended (the host suspend is not visible to the card). > > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 <broonie@opensource.wolfsonmicro.com> > --- > 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 <linux/module.h> > #include <linux/of.h> > #include <linux/of_gpio.h> > +#include <linux/pm.h> > > #include <linux/mmc/host.h> > > @@ -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.
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 <broonie@opensource.wolfsonmicro.com> > --- > 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 <linux/of.h> > #include <linux/of_gpio.h> > #include <linux/pm.h> > +#include <linux/pm_runtime.h> > > #include <linux/mmc/host.h> > > @@ -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.
On Fri, Mar 09, 2012 at 12:08:58AM -0500, Chris Ball wrote:
> The reworked patch is below, please let me know if it looks incorrect:
That looks about right, I'll find out soon enough if it doesn't work in
-next as my main development system has the rootfs on this device :)
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.
On Tue, Mar 27, 2012 at 11:50:24AM -0400, Chris Ball wrote: > 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: If they're already in your tree why not just send them to Linus? Given that everything's in git I don't understand why you'd need Kukjin to push them separately or what the benefit of that would be? This is all extremely frustrating fromm the contributor point of view.
On 03/28/12 02:54, Mark Brown wrote: > On Tue, Mar 27, 2012 at 11:50:24AM -0400, Chris Ball wrote: >> 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, (Cc'ed Olof and Arnd) Chris, Yeah, it is not in arm-soc tree now. Because I sent a pull request of samsung-mmc which is including this v3.4-for-cjb but Olof wanted to merge only arch/arm/ part for samsung mmc because they are not unrelated to the branch, v3.4-for-cjb sent to you. Since I thought the branch would be sent to upstream via your tree and you were included in the mailing loop, I agreed. So there is no it in arm-soc. >> and we're in the last few >> days of the merge window. > Yeah...it means not closed yet ;) >> 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. > If they're already in your tree why not just send them to Linus? Given > that everything's in git I don't understand why you'd need Kukjin to > push them separately or what the benefit of that would be? > Yes, I already agreed its merging in the mmc tree :) > This is all extremely frustrating fromm the contributor point of view. If any my effort is required, feel free to contact me. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.
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 wrote: > Hi Kukjin, > Hi, Sorry for late response. [...] > > 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.) > OK, I see. > 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. > Yep, I dropped it in my -next. Thanks. Best regards, Kgene. -- Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd.