From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.global.frontbridge.com", Issuer "MSIT Machine Auth CA 2" (not verified)) by ozlabs.org (Postfix) with ESMTPS id DE7F32C00D2 for ; Thu, 22 Aug 2013 06:08:36 +1000 (EST) Message-ID: <1377115703.5029.14.camel@snotra.buserror.net> Subject: Re: [RFC PATCH V3 3/5] powerpc/cpuidle: Generic powerpc backend cpuidle driver. From: Scott Wood To: Deepthi Dharwar Date: Wed, 21 Aug 2013 15:08:23 -0500 In-Reply-To: <521447E7.5000302@linux.vnet.ibm.com> References: <20130819042736.8609.17890.stgit@deepthi.in.ibm.com> <20130819042818.8609.77060.stgit@deepthi.in.ibm.com> <5211F0E0.7080507@linux.vnet.ibm.com> <1376936241.31636.352.camel@snotra.buserror.net> <521447E7.5000302@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Cc: Wood Scott-B07421 , "daniel.lezcano@linaro.org" , Wang Dongsheng-B40534 , "preeti@linux.vnet.ibm.com" , "linux-pm@lists.linux-foundation.org" , "linuxppc-dev@lists.ozlabs.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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