diff mbox

[5/7] ARM: OMAP: dmtimer: Do not call PM runtime functions when not needed.

Message ID 1462634508-24961-6-git-send-email-ivo.g.dimitrov.75@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Ivaylo Dimitrov May 7, 2016, 3:21 p.m. UTC
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(-)

Comments

Tony Lindgren May 9, 2016, 7:36 p.m. UTC | #1
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivaylo Dimitrov May 9, 2016, 8:51 p.m. UTC | #2
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren June 10, 2016, 10:22 a.m. UTC | #3
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivaylo Dimitrov June 10, 2016, 9:21 p.m. UTC | #4
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren June 13, 2016, 7:10 a.m. UTC | #5
* 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


--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren June 13, 2016, 7:39 a.m. UTC | #6
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ivaylo Dimitrov June 13, 2016, 6:58 p.m. UTC | #7
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren June 14, 2016, 7:53 a.m. UTC | #8
* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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;