On Wed, 2013-08-21 at 10:23 +0530, Deepthi Dharwar wrote: > 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? No answer? > >>>> +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. I don't want to "get into" a file that claims to be generic PPC but is loaded with 64-bit dependencies. > 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. The way forward is to give this file a more appropriate name based on the hardware that it actually targets -- and to refactor it so that the answer to that question is not complicated. -Scott
