[RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver.

[Deepthi Dharwar]

On 08/19/2013 11:47 PM, Scott Wood wrote:
> On Mon, 2013-08-19 at 15:48 +0530, Deepthi Dharwar wrote:
>> Hi Dongsheng,
>>
>> On 08/19/2013 11:22 AM, Wang Dongsheng-B40534 wrote:
>>> I think we should move the states and handle function to arch/power/platform*
>>> The states and handle function is belong to backend driver, not for this, different platform have different state.
>>> Different platforms to make their own deal with these states.
>>>
>>> I think we cannot put all the status of different platforms and handler in this driver.
>>
>> The idea here is a single powerpc back-end driver, which does a runtime
>> detection of the platform it is running and choose the right
>> idle states table. This was one of outcome of V2 discussion.
> 
> I see a lot more in there than just detecting a platform and choosing a
> driver.
> 
>> I feel there is no harm in keeping the state information in the same
>> file. We do have x86, which has all its variants information in one
>> file. One place will have all the idle consolidated information of
>> all the platform variants. If community does feel, we need to
>> have just the states information in arch specific file, we can do so.
> 
> What actual functionality is common to all powerpc but not common to
> other arches?
> 
>>>> diff --git a/drivers/cpuidle/Kconfig b/drivers/cpuidle/Kconfig
>>>> index 0e2cd5c..99ee5d4 100644
>>>> --- a/drivers/cpuidle/Kconfig
>>>> +++ b/drivers/cpuidle/Kconfig
>>>> @@ -42,6 +42,13 @@ config CPU_IDLE_ZYNQ
>>>>  	help
>>>>  	  Select this to enable cpuidle on Xilinx Zynq processors.
>>>>
>>>> +config CPU_IDLE_POWERPC
>>>> +	bool "CPU Idle driver for POWERPC platforms"
>>>> +	depends on PPC64
>>>
>>> Why not PPC?
>>
>> PPC64 seems to a good place to began the consolidation work. This
>> patch-set has not been tested for PPC32 currently.
> 
> PPC64 is a bad place to start if you want it to be generic, because it
> means you'll end up growing dependencies on other things that are PPC64
> only.  There are too many arbitrary 32/64 differences as is.

Hi Scott,

>From my understanding, PPC64 includes BOOK3E and BOOK3S archs.
PPC includes PPC32 and PPC64.

It seemed logical to start consolidating at PPC64 as
one does not want to get into 32/64 bit differences.

>From your comments above,  I just wanted to clarify if PPC or PPC64 is
bad place to start. If PPC64 is bad place to start, then whats the way
forward ?  Can you please throw some more light on it.

Thanks!
Deepthi



> -Scott
> 
> 
> 
>