Message ID | 1462634508-24961-6-git-send-email-ivo.g.dimitrov.75@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160507 08:24]: > once omap_dm_timer_start() is called, which calls omap_dm_timer_enable() > and thus pm_runtime_get_sync(), it doesn't make sense to call PM runtime > functions again before omap_dm_timer_stop is called(). Otherwise PM runtime > functions called in omap_dm_timer_enable/disable lead to long and unneeded > delays. > > Fix that by implementing an "enabled" counter, so the PM runtime functions > get called only when really needed. > > Without that patch Nokia N900 IR TX driver (ir-rx51) does not function. We should use pm_runtime for the refcounting though and call PM runtime unconditionally. Can you try to follow the standard PM runtime usage like this: init: pm_runtime_use_autosuspend(&timer->pdev->dev); pm_runtime_set_autosuspend_delay(&timer->pdev->dev, 200); pm_runtime_enable(&timer->pdev->dev); ... enable: pm_runtime_get_sync(&timer->pdev->dev); ... disable: pm_runtime_mark_last_busy(&timer->pdev->dev); pm_runtime_put_autosuspend(&timer->pdev->dev); ... exit: pm_runtime_dont_use_autosuspend(&timer->pdev->dev); pm_runtime_put_sync(&timer->pdev->dev); pm_runtime_disable(&timer->pdev->dev); No idea what the timeout should be, maybe less than 200 ms. Also we need to test that off idle still works with timer1, that might need special handling. Regards, Tony
Hi, On 9.05.2016 22:36, Tony Lindgren wrote: > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160507 08:24]: >> once omap_dm_timer_start() is called, which calls omap_dm_timer_enable() >> and thus pm_runtime_get_sync(), it doesn't make sense to call PM runtime >> functions again before omap_dm_timer_stop is called(). Otherwise PM runtime >> functions called in omap_dm_timer_enable/disable lead to long and unneeded >> delays. >> >> Fix that by implementing an "enabled" counter, so the PM runtime functions >> get called only when really needed. >> >> Without that patch Nokia N900 IR TX driver (ir-rx51) does not function. > Well, I just tested again, with the $subject patch reverted and contradictory to my own words, it worked just fine. I believe the reason is that I did hrtimer "migration" after I did the $subject patch. I was thinking the reason for the slow transmission was PWM dmtimer, but now it turns out it has been the "pulse" dmtimer. So, I think the $subject patch should be dropped. > We should use pm_runtime for the refcounting though and call PM runtime > unconditionally. Can you try to follow the standard PM runtime usage > like this: > It works without that, but on the other hand, I finally have some reference on how PM runtime API should be called :). > init: > pm_runtime_use_autosuspend(&timer->pdev->dev); > pm_runtime_set_autosuspend_delay(&timer->pdev->dev, 200); > pm_runtime_enable(&timer->pdev->dev); > ... > enable: > pm_runtime_get_sync(&timer->pdev->dev); > ... > disable: > pm_runtime_mark_last_busy(&timer->pdev->dev); > pm_runtime_put_autosuspend(&timer->pdev->dev); > ... > exit: > pm_runtime_dont_use_autosuspend(&timer->pdev->dev); > pm_runtime_put_sync(&timer->pdev->dev); > pm_runtime_disable(&timer->pdev->dev); > > No idea what the timeout should be, maybe less than 200 ms. Also we need > to test that off idle still works with timer1, that might need special > handling. > Thanks, Ivo
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160509 13:52]: > Hi, > > On 9.05.2016 22:36, Tony Lindgren wrote: > > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160507 08:24]: > > > once omap_dm_timer_start() is called, which calls omap_dm_timer_enable() > > > and thus pm_runtime_get_sync(), it doesn't make sense to call PM runtime > > > functions again before omap_dm_timer_stop is called(). Otherwise PM runtime > > > functions called in omap_dm_timer_enable/disable lead to long and unneeded > > > delays. > > > > > > Fix that by implementing an "enabled" counter, so the PM runtime functions > > > get called only when really needed. > > > > > > Without that patch Nokia N900 IR TX driver (ir-rx51) does not function. > > > > Well, I just tested again, with the $subject patch reverted and > contradictory to my own words, it worked just fine. I believe the reason is > that I did hrtimer "migration" after I did the $subject patch. I was > thinking the reason for the slow transmission was PWM dmtimer, but now it > turns out it has been the "pulse" dmtimer. So, I think the $subject patch > should be dropped. > > > We should use pm_runtime for the refcounting though and call PM runtime > > unconditionally. Can you try to follow the standard PM runtime usage > > like this: > > > > It works without that, but on the other hand, I finally have some reference > on how PM runtime API should be called :). OK. And I just applied the related dts changes. Please repost the driver changes and DT binding doc with Rob's ack to the driver maintainers to apply. Regards, Tony
On 10.06.2016 13:22, Tony Lindgren wrote: > > OK. And I just applied the related dts changes. Please repost the driver > changes and DT binding doc with Rob's ack to the driver maintainers to > apply. > Already did, see https://lkml.org/lkml/2016/5/16/429 Shall I do anything else? Thanks, Ivo
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160610 14:23]: > > On 10.06.2016 13:22, Tony Lindgren wrote: > > > > OK. And I just applied the related dts changes. Please repost the driver > > changes and DT binding doc with Rob's ack to the driver maintainers to > > apply. > > > > Already did, see https://lkml.org/lkml/2016/5/16/429 > > Shall I do anything else? Probably good idea to repost just the driver changes to the subsystem maintainers. With v4.7 out any pre v4.7 patchsets easily get forgotten. Regards, Tony
* Tony Lindgren <tony@atomide.com> [160613 00:10]: > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160610 14:23]: > > > > On 10.06.2016 13:22, Tony Lindgren wrote: > > > > > > OK. And I just applied the related dts changes. Please repost the driver > > > changes and DT binding doc with Rob's ack to the driver maintainers to > > > apply. > > > > > > > Already did, see https://lkml.org/lkml/2016/5/16/429 > > > > Shall I do anything else? > > Probably good idea to repost just the driver changes to the > subsystem maintainers. With v4.7 out any pre v4.7 patchsets > easily get forgotten. Heh s/v4.7/v4.6/ :) Tony
Hi, On 13.06.2016 10:10, Tony Lindgren wrote: > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160610 14:23]: >> >> On 10.06.2016 13:22, Tony Lindgren wrote: >>> >>> OK. And I just applied the related dts changes. Please repost the driver >>> changes and DT binding doc with Rob's ack to the driver maintainers to >>> apply. >>> >> >> Already did, see https://lkml.org/lkml/2016/5/16/429 >> >> Shall I do anything else? > > Probably good idea to repost just the driver changes to the > subsystem maintainers. With v4.7 out any pre v4.7 patchsets > easily get forgotten. > Sorry for the maybe stupid question, but does this mean that I should send separate patches instead of series? Or the series without what you've already applied? Thanks, Ivo
* Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160613 12:01]: > Hi, > > On 13.06.2016 10:10, Tony Lindgren wrote: > > * Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> [160610 14:23]: > > > > > > On 10.06.2016 13:22, Tony Lindgren wrote: > > > > > > > > OK. And I just applied the related dts changes. Please repost the driver > > > > changes and DT binding doc with Rob's ack to the driver maintainers to > > > > apply. > > > > > > > > > > Already did, see https://lkml.org/lkml/2016/5/16/429 > > > > > > Shall I do anything else? > > > > Probably good idea to repost just the driver changes to the > > subsystem maintainers. With v4.7 out any pre v4.7 patchsets > > easily get forgotten. > > > > Sorry for the maybe stupid question, but does this mean that I should send > separate patches instead of series? Or the series without what you've > already applied? Always leave out the patches that have been already applied. Otherwise people will get confused. Just mention it in the cover letter saying "patch xyz has been already applied into foo tree, these patches are safe to apply separately into bar tree" or something similar :) Tony
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 7a327bd..f35a78c 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -365,6 +365,9 @@ void omap_dm_timer_enable(struct omap_dm_timer *timer) { int c; + if (timer->enabled++) + return; + pm_runtime_get_sync(&timer->pdev->dev); if (!(timer->capability & OMAP_TIMER_ALWON)) { @@ -383,7 +386,11 @@ EXPORT_SYMBOL_GPL(omap_dm_timer_enable); void omap_dm_timer_disable(struct omap_dm_timer *timer) { - pm_runtime_put_sync(&timer->pdev->dev); + if (timer->enabled == 1) + pm_runtime_put_sync(&timer->pdev->dev); + + if (timer->enabled) + timer->enabled--; } EXPORT_SYMBOL_GPL(omap_dm_timer_disable); diff --git a/arch/arm/plat-omap/include/plat/dmtimer.h b/arch/arm/plat-omap/include/plat/dmtimer.h index dd79f30..fc984e1 100644 --- a/arch/arm/plat-omap/include/plat/dmtimer.h +++ b/arch/arm/plat-omap/include/plat/dmtimer.h @@ -114,6 +114,7 @@ struct omap_dm_timer { unsigned long rate; unsigned reserved:1; unsigned posted:1; + u32 enabled; struct timer_regs context; int (*get_context_loss_count)(struct device *); int ctx_loss_count;
once omap_dm_timer_start() is called, which calls omap_dm_timer_enable() and thus pm_runtime_get_sync(), it doesn't make sense to call PM runtime functions again before omap_dm_timer_stop is called(). Otherwise PM runtime functions called in omap_dm_timer_enable/disable lead to long and unneeded delays. Fix that by implementing an "enabled" counter, so the PM runtime functions get called only when really needed. Without that patch Nokia N900 IR TX driver (ir-rx51) does not function. Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> --- arch/arm/plat-omap/dmtimer.c | 9 ++++++++- arch/arm/plat-omap/include/plat/dmtimer.h | 1 + 2 files changed, 9 insertions(+), 1 deletion(-)