Re: [PATCH V2 03/12] PM / Domains: Add on-off notifiers

[Rickard Andersson <rickard.andersson@stericsson.com>]

On 04/29/2013 02:14 PM, Linus Walleij wrote:
> On Tue, Apr 23, 2013 at 2:26 PM, Rickard Andersson
> <rickard.andersson@stericsson.com>  wrote:
>> On 03/31/2013 12:17 AM, Rafael J. Wysocki wrote:
>>> On Thursday, March 28, 2013 05:11:29 PM Rickard Andersson wrote:
>>>> I believe notifiers are the best solution to the problem of
>>>> restoring context early when waking up after sleep.
>>> I don't.
>> Some motivation would be good.
> (...)
>>> Well, quite frankly, it is hard to say what problem this is supposed to
>>> address from your description.  Care to give some more details?
>> The problem is that some hardware blocks needs to be restored as early as
>> possible after leaving the U8500 CPU coupled sleep state ApSleep (APE power
>> domain being off).
> (APE = Application Processor Environment, on embedded)
>
> I just have this vague feeling that this is one of those embedded SoC
> vs desktop things where worlds collide.
>
> Isn't it so that on common x86 (desktop, server, laptop) the context of
> the system is saved by some BIOS/ACPI call, and then the ROM
> takes you back up with all devices put back into context?
>
> On embedded SoC's we don't have this, all states in the hardware
> has to be saved and restored with kernel code.
>
> Then there is a question about whether this shall be done centrally
> (there is one piece of code that knows all volatile registers of all
> hardware blocks in the system) which is close to what the desktop
> BIOS may do, or whether you want to do this in a distributed manner,
> so that each driver saves and restores the context of it's particular
> hardware.
>
The advantage with using the distributed approach is that all knowledge 
of a certain hardware block can be handled in one place, the driver. 
Having all knowledge in one place is a standard software design pattern.

Most drivers in the APE domain will be fine using runtime pm, but a few 
needs their context (i.e. registers) to be restored directly when 
leaving a sleep state where the APE power domain has been off. For 
example the following hardware blocks: APE clocks, ICN (main 
interconnect bus) and TPIU (Trace Port Interface Unit).
Using the TPIU block as an example: tracing with debugger (using TPIU 
block) needs to be active (context restored) directly after sleep in 
order to be able to record the execution also after waking up from 
sleep. If the TPIU context is not restored after waking up from sleep 
then the debuggers recording of the execution will also stop after 
waking up from sleep which is not a good thing when looking for 
difficult errors using a debugger.

Rafael: Can you please share your view?

Thanks in advance!
/Rickard