[RFC] omap_pm_get_device_context_loss_count() support on OMAP4

[RFC] omap_pm_get_device_context_loss_count() support on OMAP4

[Rajendra Nayak]

Hi,

This is to take the discussion forward which I started here
http://marc.info/?l=linux-omap&m=130812942102354&w=2
on how to support the omap_pm_get_device_context_loss_count()
api on OMAP4.

I started to work on this and thought I almost had patches
which would do the job on OMAP4,(keep a per-module/hwmod
context count by looking at the per-module context registers
that exist on OMAP4, similar to the per-pwrdm count maintained by
looking at the per-pwrdm prepwrst registers on OMAP3)
until I realized my approach had 2 issues

-1- The book keeping (similar to whats done in pwrdm_pre_transition()
and pwrdm_post_transition()) was turning out to be quite expensive
to be done for *every* low power system/cpu transition.
(Btw, some profiling shows me the existing book keeping is quite
expensive already)

-2- Doing this book keeping *only* during low power system/cpu
transitions is'nt enough as there could be modules which can
independently transition while the MPU and L3 are still active
like DSS, ABE, GFX etc.
This was avoided on OMAP3 with 'autodeps' as described in the discussion
thread above which made book keeping in low power system/cpu
transitions work for all.

Issue -1- might be a little easy to solve if the book-keeping
needs to be done only for domains/modules which transition along
with the system/cpu. The book keeping can then only be done for
specific C states (and suspend) instead of doing it for all C states.

What I am unable to fix is Issue -2-.

Me and Santosh discussed a lot on how to handle this and we thought
with all the HW governed transitions, the only foolproof way of
doing this was if the HW itself could log a count instead of just
logging the state of previous transition.
(Which is not the case on OMAP4 :-))

Does anyone else see any other way of handling this (Issue -2-) on OMAP4
in software?

regards,
Rajendra/Santosh

Re: [RFC] omap_pm_get_device_context_loss_count() support on OMAP4

[Paul Walmsley]

Hi Rajendra,

On Wed, 15 Jun 2011, Rajendra Nayak wrote:

> This is to take the discussion forward which I started here
> http://marc.info/?l=linux-omap&m=130812942102354&w=2
> on how to support the omap_pm_get_device_context_loss_count()
> api on OMAP4.
> 
> I started to work on this and thought I almost had patches
> which would do the job on OMAP4,(keep a per-module/hwmod
> context count by looking at the per-module context registers
> that exist on OMAP4, similar to the per-pwrdm count maintained by
> looking at the per-pwrdm prepwrst registers on OMAP3)
> until I realized my approach had 2 issues
> 
> -1- The book keeping (similar to whats done in pwrdm_pre_transition()
> and pwrdm_post_transition()) was turning out to be quite expensive
> to be done for *every* low power system/cpu transition.
> (Btw, some profiling shows me the existing book keeping is quite
> expensive already)

Do you know what the expensive part of the book keeping is?  i.e., is it 
the PRM register access, or waiting for the powerdomain transition, etc.?

> -2- Doing this book keeping *only* during low power system/cpu
> transitions is'nt enough as there could be modules which can
> independently transition while the MPU and L3 are still active
> like DSS, ABE, GFX etc.

This can only happen while the drivers are idle from a runtime PM 
perspective, correct?  In other words, context could only be lost after 
the driver's last pm_runtime_put*().

> This was avoided on OMAP3 with 'autodeps' as described in the discussion
> thread above which made book keeping in low power system/cpu
> transitions work for all.
> 
> Issue -1- might be a little easy to solve if the book-keeping
> needs to be done only for domains/modules which transition along
> with the system/cpu. The book keeping can then only be done for
> specific C states (and suspend) instead of doing it for all C states.
> 
> What I am unable to fix is Issue -2-.
> 
> Me and Santosh discussed a lot on how to handle this and we thought
> with all the HW governed transitions, the only foolproof way of
> doing this was if the HW itself could log a count instead of just
> logging the state of previous transition.
> (Which is not the case on OMAP4 :-))
> 
> Does anyone else see any other way of handling this (Issue -2-) on OMAP4
> in software?

As I understand it, those LOSTCONTEXT bits are only cleared when they are 
written to, correct?  So is it enough to check those bits during the hwmod 
enable, if the hwmod's enclosing powerdomain was programmed to some state 
that might cause it to lose context?

In other words, to take DSS as an example, when DSS is not in use, I don't 
think the exact count of how many times the DSS hardware went off and on 
is important.  (And as you mention, it doesn't seem possible to track this 
with the current hardware without those autodeps, which are undesirable 
for other reasons.)  But what is important to the core code is whether the 
DSS lost context between the last pm_runtime_put*() and a 
pm_runtime_get*().  And those LOSTCONTEXT bits should stay set until Linux 
clears them, right?

Does this sound reasonable, or am I missing something obvious? :-)


- Paul