On Wed, 2013-08-21 at 10:23 +0530, Deepthi Dharwar wrote:

On 08/19/2013 11:47 PM, Scott Wood wrote:

quoted

On Mon, 2013-08-19 at 15:48 +0530, Deepthi Dharwar wrote:

quoted

Hi Dongsheng,

On 08/19/2013 11:22 AM, Wang Dongsheng-B40534 wrote:

quoted

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.

quoted

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?

quoted

quoted

quoted

quoted

+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