Subject: Re: [PATCH v2 7/9] powerpc/powernv: Add platform support for stop instruction

From: Shreyas B Prabhu <[email-masked]>
Date: Fri, 20 May 2016 11:46:02 +0530

On 05/20/2016 10:55 AM, Paul Mackerras wrote:
> On Tue, May 03, 2016 at 01:54:36PM +0530, Shreyas B. Prabhu wrote:
>> POWER ISA v3 defines a new idle processor core mechanism. In summary,
>>  a) new instruction named stop is added. This instruction replaces
>> 	instructions like nap, sleep, rvwinkle.
>>  b) new per thread SPR named PSSCR is added which controls the behavior
>> 	of stop instruction.
>>
>> PSSCR has following key fields
>> 	Bits 0:3  - Power-Saving Level Status. This field indicates the lowest
>> 	power-saving state the thread entered since stop instruction was last
>> 	executed.
>>
>> 	Bit 42 - Enable State Loss
>> 	0 - No state is lost irrespective of other fields
>> 	1 - Allows state loss
>>
>> 	Bits 44:47 - Power-Saving Level Limit
>> 	This limits the power-saving level that can be entered into.
>>
>> 	Bits 60:63 - Requested Level
>> 	Used to specify which power-saving level must be entered on executing
>> 	stop instruction
>>
>> This patch adds support for stop instruction and PSSCR handling.
> 
> I notice that you have duplicated a whole lot of assembly code
> relating to synchronizing between threads going into and out of
> power-saving modes, saving/restoring SPRs, resyncing the timebase, and
> so on.
> 
> Two questions arise:
> 
> - Are we really going to have to do all of that in the same way for
>   POWER9 as we did for POWER8?  You even copied over a comment about
>   the fastsleep workaround, which I really hope we won't have to do on
>   POWER9.  Also, on POWER9, the threads are much more independent, so
>   I was not expecting that there would still be shared registers.

Copying of comment regarding fastsleep workaround was an oversight. It
will not be necessary in POWER9. I'll fix that in the next version.

The need for synchronizing between threads going into and out of
power-saving modes still exists. Resyncing timebase and restoring few
registers still have to be done once per core.
> 
> - If we do have to do all that, could we use the same code as on
>   POWER8 rather than having another copy of all that code?
> 

While we could use the same code I felt that handling POWER8 and POWER9
cases in the same file might make the code more complicated.
Gautham suggested we can use the same POWER8 code and use FTR sections
wherever POWER8 and POWER9 deviate. If you feel that is better I can
implement that in the next version.

Thanks,
Shreyas