[Skiboot] [RFC 1/1] SLW : Add new idle device-tree format

Abhishek huntbag at linux.vnet.ibm.com
Fri Nov 29 16:25:57 AEDT 2019


Hi,


On 11/25/2019 10:38 PM, Stewart Smith wrote:
>> On 25 Nov 2019, at 05:04, Klaus Heinrich Kiwi <klaus at linux.vnet.ibm.com> wrote:
>>
>> On 11/17/2019 10:05 PM, Oliver O'Halloran wrote:
>>>> On Fri, Aug 9, 2019 at 8:55 PM Abhishek Goel <huntbag at linux.vnet.ibm.com> wrote:
>>>> Add stop states under ibm,idle-states in addition to the current array
>>>> based device tree properties.
>> I noted that Abhishek answered that a complete redesign will take place, but I couldn't help to ask...
>>> How does the kernel know if one state node deeper than another? What
>>> I'm really wondering is whether we need a reg for the individual
>>> states e.g.:
>>>
>>> stop at 11 {
>>>   reg= <11>
>>>   compatible="stop11-v1"
>>>   ...
>>> }
>>> stop at 4 {
>>>   reg = <4>;
>>>   compatible="stop4-v1";
>>>   ...
>>> }
>> Your original patch apparently implies that stop states are naturally hierarchical (i.e., can only support stop4 if we support stop1, 2, 3). If that's the case, perhaps we should also have an hierarchical device-tree representation?
> Kind of. The higher the stop number the higher the saving and latency (ie the deeper the stop), but there’s no reason that supported numbers are linear. Supporting only 0lite, 1, and 5 is possible.
> _______________________________________________
> Skiboot mailing list
> Skiboot at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/skiboot
Let's say that only stop0, 1 and 5 are enabled state and other states 
have been disabled
and not supported because they have some bug. In case a cpu request 
stop5 and enters
stop, it is possible that it wakes up from a shallower state such as 
stop 2 which is a buggy
state. To prevent this, we must maintain linearity among the supported 
state.

--Abhishek



More information about the Skiboot mailing list