Re: [RFC][PATCH 2/2] PM / Domains: Add preliminary cpuidle support

[Shilimkar, Santosh]

On Sun, May 13, 2012 at 1:03 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
> On Saturday, May 12, 2012, Shilimkar, Santosh wrote:
>> On Sat, May 12, 2012 at 12:29 AM, Rafael J. Wysocki <rjw@xxxxxxx> wrote:
>> > On Friday, May 11, 2012, Santosh Shilimkar wrote:
>> >> On Friday 11 May 2012 12:11 AM, Rafael J. Wysocki wrote:
>> >> > On Thursday, May 10, 2012, Santosh Shilimkar wrote:
> [...]
>> Your case is bit special because CPU is also part of the same power
>> domain as IO's. Since CPU is part of the root power domain along
>> with peripherals, you want CPU to be the device to cut the power in
>> the end(idle) and all the notifiers prepares the IO's for the 'cut
>> power' which CPU can do in the cpuidle.
>
> No, no notifiers, please, they are clearly suboptimal.
>
>> And then on the reverse chain, notifier will help devices to restore
>> the context so that can resume without any issues.
>
> The idea here is to avoid using notifiers.
>
Thanks for clarifying that. Somehow I miss-understood this
part in first place.

>> Well if CPU is added as one more device along with other
>> peripherals, you can still make it work at power domain framework
>> level.
>
> What exactly do you mean by "power domain framework level"?  My patch
> is at the power domain framework level as far as I can say.
>
>> This can be debated further but I think, we need an agreement
>> on CPUIDLE exclusivity.
>
> What do you mean by cpuidle exclusivity?  And what agreement?
>
>> Based on your hardware, say the USB is doing a huge DMA transfer
>> and CPU is not doing anything so it will hit idle thread and can idle.
>
> Sure, it will.
>
>> At least your CPU sub-domain can idle because it is quite independent
>> even if you can't cut the power for whole domain.
>
> That's correct.  The CPU sub-domain is beyond the scope of my patch.
>
>> Even with your patchset its not possible to cut the power because one of the
>> device in the domain is busy. There can be scenario, where say
>> SPI is not used for thousands of CPU idle entry/exit so there
>> is no need to worry about its context save/restore for every
>> idle entry/exit.
>
> The CPU idle state I'm referring to is not the only CPU idle state.
> It is an extra state allowing the CPU to go to even deeper idle that usually
> if all of the devices in its domain happen to be idle.
>
> Quite obviously there are other idle states along this one that will be used
> if this extra state is not enabled.
>
That make sense.

>> The way I am looking at your issue is, every device in a power domain
>> including CPU will decrement the powerdomain usecount.
>
> The CPU will not do that, only devices.
>
>> This can be handled through runtime PM.
>
> But this patchset is a part of runtime PM!  What exactly do you mean?
>
As I said for some reason I thought you were proposing the idle notifiers
which is not the case.

>> When they idle, they can save the context
>> and the context can be restored only when next time they needs to be
>> used. CPU can also decrements the usecount in the idle entry and then check
>> whether the usecound of the common PD is zero.
>
> This is not how it is supposed to work.
>
> It doesn't make sense for cpuidle to even try to use the "domain" state if
> it is known that some I/O devices in the domain aren't idle.  That's why
> that state is disabled in my code whenever one (the first) of the I/O devices
> is resumed.  It is then enabled when the last I/O device in the domain goes
> idle (the states of all devices are saved at this point, to allow cpuidle to
> use the "domain" state without worrying of the devices).
>
Now since the idle notifier confusion ( at least for me) is out, what you
proposed seems to be reasonable considering the power domain is
shared between multiple devices including CPU.

Regards
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/