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. -Scott
