[RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Kyle Moffett]

Hello,

I saw Baruch Siach's patch:
  powerpc: 85xx: separate e500 from e500mc

Unfortunately, that patch breaks the dependencies for the P5020DS
platform and does not fix the underlying code which does not
understand what the ambiguous "CONFIG_E500" means.

In order to fix the issue at the fundamental level, I created the
following 17-patch series loosely based on Baruch's patch.

=== High-Level Summary ===

The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
each other, yet they share the same "CONFIG_E500" Kconfig option.

The following patch series splits the 32-bit CPU support into two
separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
Additionally, the 64-bit e5500 support is separated to its own config
option ("CONFIG_FSL_E5500") which is automatically combined with
either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
is enabled.

I based the patches on v3.2-rc1, please let me know if I should
update the patches against a different tree.

The first 4 patches stand on their own merits; they are generic code
cleanups necessary to support the later patches.

I'd like to know what you all think.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Kumar Gala]

On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:

> Hello,
> 
> I saw Baruch Siach's patch:
>  powerpc: 85xx: separate e500 from e500mc
> 
> Unfortunately, that patch breaks the dependencies for the P5020DS
> platform and does not fix the underlying code which does not
> understand what the ambiguous "CONFIG_E500" means.
> 
> In order to fix the issue at the fundamental level, I created the
> following 17-patch series loosely based on Baruch's patch.
> 
> === High-Level Summary ===
> 
> The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
> each other, yet they share the same "CONFIG_E500" Kconfig option.
> 
> The following patch series splits the 32-bit CPU support into two
> separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
> Additionally, the 64-bit e5500 support is separated to its own config
> option ("CONFIG_FSL_E5500") which is automatically combined with
> either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
> is enabled.

So its clear from the community that there is confusion here and we need to clean this up.  I guess my attempt to support an kernel that ran on both E500v2 and E500mc isn't worth it.  However I don't want to completely remove the ability to do this.

Towards the cleanup I'd ask for a proposal on what exactly the CONFIG_ options we'd end up with would be and their meaning.

So today we have:

CONFIG_E500
CONFIG_PPC_E500MC

What do we want to move to?  I want to keep the builds such that we have only 2 classes:  e500V1/V2 and e500mc/e5500/e6500/.../eX500.  I see no reason to hyper-optimize e500mc vs e5500 vs e6500.

- k

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Moffett, Kyle D]

On Nov 10, 2011, at 08:59, Kumar Gala wrote:
> On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:
>> I saw Baruch Siach's patch:
>> powerpc: 85xx: separate e500 from e500mc
>> 
>> Unfortunately, that patch breaks the dependencies for the P5020DS
>> platform and does not fix the underlying code which does not
>> understand what the ambiguous "CONFIG_E500" means.
>> 
>> In order to fix the issue at the fundamental level, I created the
>> following 17-patch series loosely based on Baruch's patch.
>> 
>> === High-Level Summary ===
>> 
>> The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
>> each other, yet they share the same "CONFIG_E500" Kconfig option.
>> 
>> The following patch series splits the 32-bit CPU support into two
>> separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
>> Additionally, the 64-bit e5500 support is separated to its own config
>> option ("CONFIG_FSL_E5500") which is automatically combined with
>> either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
>> is enabled.
> 
> So its clear from the community that there is confusion here and we
> need to clean this up.  I guess my attempt to support an kernel that
> ran on both E500v2 and E500mc isn't worth it.  However I don't want to
> completely remove the ability to do this.

Well, a kernel built with CONFIG_PPC_E500MC today appears to be
fundamentally broken on E500v1/E500v2:

#if defined(CONFIG_8xx) || defined(CONFIG_403GCX)
#define L1_CACHE_SHIFT		4
#define MAX_COPY_PREFETCH	1
#elif defined(CONFIG_PPC_E500MC)
#define L1_CACHE_SHIFT		6
#define MAX_COPY_PREFETCH	4
#elif defined(CONFIG_PPC32)
#define MAX_COPY_PREFETCH	4
#if defined(CONFIG_PPC_47x)
#define L1_CACHE_SHIFT		7
#else
#define L1_CACHE_SHIFT		5
#endif
#else /* CONFIG_PPC64 */
#define L1_CACHE_SHIFT		7
#endif

E500MC will set L1_CACHE_SHIFT to 6, while regular E500 appears to
want it set to 5.  I don't know if that's a mistake or exactly what
code that affects, but it looks very wrong.

Furthermore, it looks like there are a couple issues here I missed
before.  PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
except when you turn on the P5020DS board option which magically
changes it to "6" and breaks lord-knows-what.  I think my patch
series actually "breaks" that and makes e5500 use 7 as well.

Are you sure that a kernel built to support E5500 can also run on
other 64-bit PowerPC/POWER systems?


> Towards the cleanup I'd ask for a proposal on what exactly the
> CONFIG_ options we'd end up with would be and their meaning.
> So today we have:
> 
> CONFIG_E500
> CONFIG_PPC_E500MC

It's actually a bit more complicated than that.  There are 3 ways
that the user can configure an e500 kernel today.  I'm omitting
the "FSL_SOC_BOOKE" menu that wraps around all of the 85xx/e5500
boards today, because that is set for all of these platforms:

  * PPC32 + PPC_85xx + E500 [+ boards]
  * PPC64 + BOOK3E_64 + P5020_DS (which adds E500 and PPC_E500MC)

Note that whether or not "PPC_E500MC" is set on PPC32 depends
only on which boards the user picked.  So if I am trying to
build an e500v2 kernel and I accidentally also turn on support
for one of the e500mc boards, my kernel mysteriously breaks.


> What do we want to move to?  I want to keep the builds such that we
> have only 2 classes:  e500V1/V2 and e500mc/e5500/e6500/.../eX500.
> I see no reason to hyper-optimize e500mc vs e5500 vs e6500.

So after my changes, there are the following user-configurable
option sets:
  * PPC32 + FSL_E500_V1_V2 [+ e500v1/v2 boards]
  * PPC32 + FSL_E500MC     [+ e500mc boards]
  * PPC64 + BOOK3E_64 + P5020_DS (which adds FSL_E5500)

Since most of the "e500mc"-specific code was in 32-bit-only ASM
or inside of #ifdef PPC32, the new FSL_E500MC option is only
set on 32-bit builds, even if it is running in compat mode on
64-bit e5500 hardware)

Internally the P5020_DS option turns on the hidden FSL_E5500
option for both 32-bit and 64-bit; that config option enables
platform drivers and similar stuff.

Depending on how compatible the AMP processors are, you could
rename the option to be "FSL_E5X00" or add a hidden option for
"FSL_E6500" that is also selected by appropriate boards.

Please let me know if you think!

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Kumar Gala]

On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:

> On Nov 10, 2011, at 08:59, Kumar Gala wrote:
>> On Nov 9, 2011, at 6:03 PM, Kyle Moffett wrote:
>>> I saw Baruch Siach's patch:
>>> powerpc: 85xx: separate e500 from e500mc
>>> 
>>> Unfortunately, that patch breaks the dependencies for the P5020DS
>>> platform and does not fix the underlying code which does not
>>> understand what the ambiguous "CONFIG_E500" means.
>>> 
>>> In order to fix the issue at the fundamental level, I created the
>>> following 17-patch series loosely based on Baruch's patch.
>>> 
>>> === High-Level Summary ===
>>> 
>>> The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
>>> each other, yet they share the same "CONFIG_E500" Kconfig option.
>>> 
>>> The following patch series splits the 32-bit CPU support into two
>>> separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
>>> Additionally, the 64-bit e5500 support is separated to its own config
>>> option ("CONFIG_FSL_E5500") which is automatically combined with
>>> either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
>>> is enabled.
>> 
>> So its clear from the community that there is confusion here and we
>> need to clean this up.  I guess my attempt to support an kernel that
>> ran on both E500v2 and E500mc isn't worth it.  However I don't want to
>> completely remove the ability to do this.
> 
> Well, a kernel built with CONFIG_PPC_E500MC today appears to be
> fundamentally broken on E500v1/E500v2:
> 
> #if defined(CONFIG_8xx) || defined(CONFIG_403GCX)
> #define L1_CACHE_SHIFT		4
> #define MAX_COPY_PREFETCH	1
> #elif defined(CONFIG_PPC_E500MC)
> #define L1_CACHE_SHIFT		6
> #define MAX_COPY_PREFETCH	4
> #elif defined(CONFIG_PPC32)
> #define MAX_COPY_PREFETCH	4
> #if defined(CONFIG_PPC_47x)
> #define L1_CACHE_SHIFT		7
> #else
> #define L1_CACHE_SHIFT		5
> #endif
> #else /* CONFIG_PPC64 */
> #define L1_CACHE_SHIFT		7
> #endif
> 
> E500MC will set L1_CACHE_SHIFT to 6, while regular E500 appears to
> want it set to 5.  I don't know if that's a mistake or exactly what
> code that affects, but it looks very wrong.

This is correct for E500 & E500MC.  However we have a HW mode that allows us to handle running in 'e500' mode on e500mc.

> Furthermore, it looks like there are a couple issues here I missed
> before.  PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
> except when you turn on the P5020DS board option which magically
> changes it to "6" and breaks lord-knows-what.  I think my patch
> series actually "breaks" that and makes e5500 use 7 as well.

a value of '6' on E5500 / P5020DS is correct and doesn't break anything.  Setting it to 7 is wrong and thus the code is correct today.

> Are you sure that a kernel built to support E5500 can also run on
> other 64-bit PowerPC/POWER systems?

No it will not.  There is not expectation of that as E5500 is an embedded / Book-E class part and uses that ISA version.  Book-S (server) 64-bit machines are not OS compatible and we are not trying to make them as such (but we do re-use a lot of code).

>> Towards the cleanup I'd ask for a proposal on what exactly the
>> CONFIG_ options we'd end up with would be and their meaning.
>> So today we have:
>> 
>> CONFIG_E500
>> CONFIG_PPC_E500MC
> 
> It's actually a bit more complicated than that.  There are 3 ways
> that the user can configure an e500 kernel today.  I'm omitting
> the "FSL_SOC_BOOKE" menu that wraps around all of the 85xx/e5500
> boards today, because that is set for all of these platforms:
> 
>  * PPC32 + PPC_85xx + E500 [+ boards]
>  * PPC64 + BOOK3E_64 + P5020_DS (which adds E500 and PPC_E500MC)
> 
> Note that whether or not "PPC_E500MC" is set on PPC32 depends
> only on which boards the user picked.  So if I am trying to
> build an e500v2 kernel and I accidentally also turn on support
> for one of the e500mc boards, my kernel mysteriously breaks.

sure, I understand I'm fine with us 'fixing' things such that we treat E500V1/V2 differently from E500MC/E5500 in user Kconfig choices

>> What do we want to move to?  I want to keep the builds such that we
>> have only 2 classes:  e500V1/V2 and e500mc/e5500/e6500/.../eX500.
>> I see no reason to hyper-optimize e500mc vs e5500 vs e6500.
> 
> So after my changes, there are the following user-configurable
> option sets:
>  * PPC32 + FSL_E500_V1_V2 [+ e500v1/v2 boards]
>  * PPC32 + FSL_E500MC     [+ e500mc boards]
>  * PPC64 + BOOK3E_64 + P5020_DS (which adds FSL_E5500)
> 
> Since most of the "e500mc"-specific code was in 32-bit-only ASM
> or inside of #ifdef PPC32, the new FSL_E500MC option is only
> set on 32-bit builds, even if it is running in compat mode on
> 64-bit e5500 hardware)
> 
> Internally the P5020_DS option turns on the hidden FSL_E5500
> option for both 32-bit and 64-bit; that config option enables
> platform drivers and similar stuff.
> 
> Depending on how compatible the AMP processors are, you could
> rename the option to be "FSL_E5X00" or add a hidden option for
> "FSL_E6500" that is also selected by appropriate boards.
> 
> Please let me know if you think!

I'd like to avoid adding FSL_E5500, FSL_E6500, etc CONFIG options getting added.  I'd like to keep things as:

32-bit:
	e500v1/v2
	e500mc/e5500/e6500/...
64-bit:
	e5500/e6500/...

We need to come up with some CONFIG option that covers e500mc/e5500/e6500/...

- k

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Scott Wood]

On Thu, Nov 10, 2011 at 10:30:41AM -0600, Kumar Gala wrote:
> On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:
> > Furthermore, it looks like there are a couple issues here I missed
> > before.  PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
> > except when you turn on the P5020DS board option which magically
> > changes it to "6" and breaks lord-knows-what.  I think my patch
> > series actually "breaks" that and makes e5500 use 7 as well.
> 
> a value of '6' on E5500 / P5020DS is correct and doesn't break anything.  Setting it to 7 is wrong and thus the code is correct today.
> 
> > Are you sure that a kernel built to support E5500 can also run on
> > other 64-bit PowerPC/POWER systems?
> 
> No it will not.  There is not expectation of that as E5500 is an
> embedded / Book-E class part and uses that ISA version.  Book-S
> (server) 64-bit machines are not OS compatible and we are not trying to
> make them as such (but we do re-use a lot of code).

What about other 64-bit book3e chips?  What cache block size does A2 have?

-Scott

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Moffett, Kyle D]

On Nov 10, 2011, at 11:54, Scott Wood wrote:
> On Thu, Nov 10, 2011 at 10:30:41AM -0600, Kumar Gala wrote:
>> On Nov 10, 2011, at 10:17 AM, Moffett, Kyle D wrote:
>>> Furthermore, it looks like there are a couple issues here I missed
>>> before.  PPC64 systems all appear to have an L1_CACHE_SHIFT of 7,
>>> except when you turn on the P5020DS board option which magically
>>> changes it to "6" and breaks lord-knows-what.  I think my patch
>>> series actually "breaks" that and makes e5500 use 7 as well.
>> 
>> a value of '6' on E5500 / P5020DS is correct and doesn't break anything.
>> Setting it to 7 is wrong and thus the code is correct today.
>> 
>>> Are you sure that a kernel built to support E5500 can also run on
>>> other 64-bit PowerPC/POWER systems?
>> 
>> No it will not.  There is not expectation of that as E5500 is an
>> embedded / Book-E class part and uses that ISA version.  Book-S
>> (server) 64-bit machines are not OS compatible and we are not trying to
>> make them as such (but we do re-use a lot of code).
> 
> What about other 64-bit book3e chips?  What cache block size does A2 have?

Ok, so I've been poking around this code a bunch and as far as I can
tell, the cacheline stuff has basically always been subtly wrong in
twelve different ways and it's only largely coincidence that it works
today.

So PowerPC64 systems have their own "ppc64_caches" structure set up
before start_kernel() is called by parsing the OpenFirmware "cpu" nodes.
That structure is then checked in every piece of 64-bit kernel code
(except xmon) that uses the "dcbXX" and "icbXX" opcodes.

There is an entirely separate mechanism built into the "cputable" that
is used on all PowerPC systems to compute cacheline sizes to pass in via
ELF headers for userspace to use in memset()/memcpy(), etc.

Furthermore, the VDSO gets cacheline sizes stored into it, but on 64-bit
they come from the ppc64_caches structure and on 32-bit they come from
dcache_bsize/icache_bsize copied from the cputable.

Then there's the value in arch/powerpc/include/asm/cache.h which is used
throughout the kernel to figure out how far apart to space CPU-specific
datastructures (EG: __cacheline_aligned_on_smp).

Despite the fact that all PPC64 have an "L1_CACHE_SIZE" value of 128,
the PowerPC A2 and e5500 have {d,i}cache_bsize values of 64 in cputable
and presumably also get correct values from OpenFirmware, so the bogus
constant in asm/cache.h does nothing more than waste a bit of memory
for unnecessary padding.

Unfortunately, lots of PPC32 assembly pretends that the value found in
asm/cache.h is a hard truth and uses it for "dcbz", etc, which is why
there are all of those ugly #ifdefs in asm/cache.h

Based on all of that, my proposal is going to be a patch which does the
following:

  (1) Conditionally set L1_CACHE_SHIFT to the maximum value used by any
      platform being compiled in for alignment purposes.

  (2) Make the ppc64_caches struct apply to ppc32 as well, and
      preinitialize it with a minimum value used by any platform being
      compiled in (for "dcbXX"/"icbXX" purposes).  This is safe because
      the pagesize is always a multiple of the cache block size and the
      kernel only uses dcbXX/icbXX on whole pages.  The only impact is a
      temporary small performance hit from flushing or zeroing the same
      block 8 times if too small.

  (3) Try to initialize the ppc_caches struct on ppc32 from the
      OpenFirmware device-tree.  If that fails, then use the values we
      find in the cputable.  After this is initialized any performance
      hit in copy_page()/zero_page() will obviously disappear.

  (4) Fix all of the PPC32 assembly code that is misusing L1_CACHE_SHIFT
      to use the ppc_caches struct instead.

Does that sound like a reasonable approach?

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Benjamin Herrenschmidt]

On Thu, 2011-11-10 at 18:38 -0600, Moffett, Kyle D wrote:

> Ok, so I've been poking around this code a bunch and as far as I can
> tell, the cacheline stuff has basically always been subtly wrong in
> twelve different ways and it's only largely coincidence that it works
> today.

Yay ! Somebody to clean that shit up ! :-)

That's the biggest missing step to being able to have 440 and 476 in a
single binary :-)

> So PowerPC64 systems have their own "ppc64_caches" structure set up
> before start_kernel() is called by parsing the OpenFirmware "cpu" nodes.
> That structure is then checked in every piece of 64-bit kernel code
> (except xmon) that uses the "dcbXX" and "icbXX" opcodes.

Yup. (And we should really fix xmon btw...)

> There is an entirely separate mechanism built into the "cputable" that
> is used on all PowerPC systems to compute cacheline sizes to pass in via
> ELF headers for userspace to use in memset()/memcpy(), etc.

Yeah well, it actually uses global variables which are set from cputable
on ppc32 and from the ppc64_caches structure on ppc64. Yeah it's not
pretty.

> Furthermore, the VDSO gets cacheline sizes stored into it, but on 64-bit
> they come from the ppc64_caches structure and on 32-bit they come from
> dcache_bsize/icache_bsize copied from the cputable.

Yup.

> Then there's the value in arch/powerpc/include/asm/cache.h which is used
> throughout the kernel to figure out how far apart to space CPU-specific
> datastructures (EG: __cacheline_aligned_on_smp).

Not much we can do about that one since it has to be compile time. Maybe
something like calculating the biggest cache line size supported by all
built-in processor types ?

> Despite the fact that all PPC64 have an "L1_CACHE_SIZE" value of 128,
> the PowerPC A2 and e5500 have {d,i}cache_bsize values of 64 in cputable
> and presumably also get correct values from OpenFirmware, so the bogus
> constant in asm/cache.h does nothing more than waste a bit of memory
> for unnecessary padding.

More or less yes, though we haven't totally given up on the idea of
eventually, one day, produce binaries capable of running both 64-bit S
and E :-)

> Unfortunately, lots of PPC32 assembly pretends that the value found in
> asm/cache.h is a hard truth and uses it for "dcbz", etc, which is why
> there are all of those ugly #ifdefs in asm/cache.h

Yes, well... -some- assembly, mostly the copy routines. It's been the
main reason why this hasn't been fixed yet.

> Based on all of that, my proposal is going to be a patch which does the
> following:
> 
>   (1) Conditionally set L1_CACHE_SHIFT to the maximum value used by any
>       platform being compiled in for alignment purposes.

Yay !

>   (2) Make the ppc64_caches struct apply to ppc32 as well, and
>       preinitialize it with a minimum value used by any platform being
>       compiled in (for "dcbXX"/"icbXX" purposes).  This is safe because
>       the pagesize is always a multiple of the cache block size and the
>       kernel only uses dcbXX/icbXX on whole pages.  The only impact is a
>       temporary small performance hit from flushing or zeroing the same
>       block 8 times if too small.

Are you sure about dcbz ? Getting that wrong can be deadly ... I'd
rather get rid of some fancy optims and use a soft value in some cases.
That or we can compile multiple variants for the common case of some of
the copy routines and use patching (alternate sections) to branch to the
right one at runtime, at least for the common cases (32 and 128 for
example for 440 and 476).

>   (3) Try to initialize the ppc_caches struct on ppc32 from the
>       OpenFirmware device-tree.  If that fails, then use the values we
>       find in the cputable.  After this is initialized any performance
>       hit in copy_page()/zero_page() will obviously disappear.
>
>   (4) Fix all of the PPC32 assembly code that is misusing L1_CACHE_SHIFT
>       to use the ppc_caches struct instead.

Yes. This could be done while keeping the hand-optimized stuff by
compiling several variants of it.

> Does that sound like a reasonable approach?

It absolutely does ! Thanks for looking at that, it's been on my todo
list for ages and I've been always finding good reasons to do something
else instead :-)

Cheers,
Ben.

> Cheers,
> Kyle Moffett
> 
> --
> Curious about my work on the Debian powerpcspe port?
> I'm keeping a blog here: http://pureperl.blogspot.com/

[RFC PATCH 0/2] powerpc: CPU cache op cleanup

[Kyle Moffett]

Ok, so I have a work-in-progress patch for cleaning up the CPU cache
handling, and I'd like some comments on the approach.

It's not really split up, and it's kind of a huge patch because it
tries to tackle a lot of things at once.  Unfortunately, I'm having a
hard time finding good clean places to break things apart.

Furthermore, I know 100% that it is not complete on PPC32 yet, and it
almost certainly does not build on PPC64 yet either.

These are the only files in arch/powerpc/ which have known-incorrect
references to L1_CACHE_* variables:
  arch/powerpc/lib/copy_32.S
  arch/powerpc/kernel/misc_32.S

Unfortunately, I've been staring at PPC asm for long enough that I
have a migraine headache and I'm going to have to stop here for now.
If somebody else wants to tackle fixing up the 32-bit copy_page() and
__copy_tofrom_user() routines it would be highly appreciated.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

Re: [RFC PATCH 0/2] powerpc: CPU cache op cleanup

[Benjamin Herrenschmidt]

On Mon, 2011-11-14 at 21:32 -0500, Kyle Moffett wrote:
> Unfortunately, I've been staring at PPC asm for long enough that I
> have a migraine headache and I'm going to have to stop here for now.
> If somebody else wants to tackle fixing up the 32-bit copy_page() and
> __copy_tofrom_user() routines it would be highly appreciated. 

Yeah that's the one everybody's avoiding :-)

What about my idea of instead compiling it multiple times with a
different size and fixing up the branch to call the right one ?

Cheers,
Ben.

Re: [RFC PATCH 0/2] powerpc: CPU cache op cleanup

[Moffett, Kyle D]

On Nov 15, 2011, at 17:29, Benjamin Herrenschmidt wrote:
> On Mon, 2011-11-14 at 21:32 -0500, Kyle Moffett wrote:
>> Unfortunately, I've been staring at PPC asm for long enough that I
>> have a migraine headache and I'm going to have to stop here for now.
>> If somebody else wants to tackle fixing up the 32-bit copy_page() and
>> __copy_tofrom_user() routines it would be highly appreciated. 
> 
> Yeah that's the one everybody's avoiding :-)
> 
> What about my idea of instead compiling it multiple times with a
> different size and fixing up the branch to call the right one ?

I guess that's doable, although I have to admit that idea almost gives
me more of a headache than trying to fix up the 32-bit ASM.

One thing that bothers me in particular is that both 32/64 versions of
__copy_tofrom_user() are dramatically overcomplicated for what they
ought to be doing.

It would seem that if we get a page fault during an unaligned copy, we
ought to just give up and fall back to a simple byte-by-byte copy loop
from wherever we left off.  That would eliminate 90% of the ugly
special cases without actually hurting performance, right?

For a page-fault during a cacheline-aligned copy, we should be able to
handle the exception and retry from the last cacheline without much
logic, again with good performance.

With that said, I'm curious about the origin of the PPC32 ASM.  In
particular, it looks like it was generated by GCC at some point in the
distant past, and I'm wondering if there's a good way to rewrite that
file in C and trick GCC into generating the relevant exception tables
for it?

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

Re: [RFC PATCH 0/2] powerpc: CPU cache op cleanup

[Benjamin Herrenschmidt]

On Tue, 2011-11-15 at 16:45 -0600, Moffett, Kyle D wrote:

> I guess that's doable, although I have to admit that idea almost gives
> me more of a headache than trying to fix up the 32-bit ASM.
> 
> One thing that bothers me in particular is that both 32/64 versions of
> __copy_tofrom_user() are dramatically overcomplicated for what they
> ought to be doing.
> 
> It would seem that if we get a page fault during an unaligned copy, we
> ought to just give up and fall back to a simple byte-by-byte copy loop
> from wherever we left off.  That would eliminate 90% of the ugly
> special cases without actually hurting performance, right?
> 
> For a page-fault during a cacheline-aligned copy, we should be able to
> handle the exception and retry from the last cacheline without much
> logic, again with good performance.
> 
> With that said, I'm curious about the origin of the PPC32 ASM.  In
> particular, it looks like it was generated by GCC at some point in the
> distant past, and I'm wondering if there's a good way to rewrite that
> file in C and trick GCC into generating the relevant exception tables
> for it?

There is some serious history in there :-)

I would check with Anton, he's been doing some performance work on those
lately (the 64-bit ones).

It's probably worth throwing a proof-of-concept simpler variant for
32-bit at least on the table and have people compare the perfs
(typically network perfs). I can test on a range of ppc32 here (6xx,
7xxx, 4xx).

Cheers,
Ben.

Re: [RFC PATCH 0/2] powerpc: CPU cache op cleanup

[Moffett, Kyle D]

On Nov 15, 2011, at 18:46, Benjamin Herrenschmidt wrote:
> On Tue, 2011-11-15 at 16:45 -0600, Moffett, Kyle D wrote:
>> 
>> With that said, I'm curious about the origin of the PPC32 ASM.  In
>> particular, it looks like it was generated by GCC at some point in the
>> distant past, and I'm wondering if there's a good way to rewrite that
>> file in C and trick GCC into generating the relevant exception tables
>> for it?
> 
> There is some serious history in there :-)
> 
> I would check with Anton, he's been doing some performance work on those
> lately (the 64-bit ones).
> 
> It's probably worth throwing a proof-of-concept simpler variant for
> 32-bit at least on the table and have people compare the perfs
> (typically network perfs). I can test on a range of ppc32 here (6xx,
> 7xxx, 4xx).

Ok, so there's not really a good way to make GCC generate the exception
tables itself.  I've come up with several overly-clever ways to do most
of what we would want using "asm goto" except that (1) "asm goto" cannot
have register outputs, and (2) "asm goto" is only available in GCC 4.5+

I could easily work around the former by putting the code into its own
file and creating a "global" register variable just for that file, but
the GCC 4.5+ dependency is a total nonstarter.

I'm trying to see if I can make it look better than it does now with
some judicious use of inline ASM.  At the very least, it should be
possible to have a wrapper function written in C which calls the ASM
guts with the correct cache params.

More importantly, the ASM code needs to use something other than
totally arbitrary numbers for labels.  :-D

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

Re: [RFC PATCH 0/2] powerpc: CPU cache op cleanup

[Paul Mackerras]

On Tue, Nov 15, 2011 at 04:45:18PM -0600, Moffett, Kyle D wrote:
> On Nov 15, 2011, at 17:29, Benjamin Herrenschmidt wrote:
> > On Mon, 2011-11-14 at 21:32 -0500, Kyle Moffett wrote:
> >> Unfortunately, I've been staring at PPC asm for long enough that I
> >> have a migraine headache and I'm going to have to stop here for now.
> >> If somebody else wants to tackle fixing up the 32-bit copy_page() and
> >> __copy_tofrom_user() routines it would be highly appreciated. 
> > 
> > Yeah that's the one everybody's avoiding :-)
> > 
> > What about my idea of instead compiling it multiple times with a
> > different size and fixing up the branch to call the right one ?
> 
> I guess that's doable, although I have to admit that idea almost gives
> me more of a headache than trying to fix up the 32-bit ASM.
> 
> One thing that bothers me in particular is that both 32/64 versions of
> __copy_tofrom_user() are dramatically overcomplicated for what they
> ought to be doing.
> 
> It would seem that if we get a page fault during an unaligned copy, we
> ought to just give up and fall back to a simple byte-by-byte copy loop
> from wherever we left off.  That would eliminate 90% of the ugly
> special cases without actually hurting performance, right?

That's basically what we do, IIRC, and most of the complexity comes
from working out where we were up to.  We could probably use a simpler
approximation that means we might copy some bytes twice.  In fact the
greatest simplification would probably be to implement range entries
in the exception table so we can just have one entry for all the loads
and stores instead of an entry for each individual load and store.

> For a page-fault during a cacheline-aligned copy, we should be able to
> handle the exception and retry from the last cacheline without much
> logic, again with good performance.
> 
> With that said, I'm curious about the origin of the PPC32 ASM.  In
> particular, it looks like it was generated by GCC at some point in the
> distant past, and I'm wondering if there's a good way to rewrite that
> file in C and trick GCC into generating the relevant exception tables
> for it?

Why do you think it was generated by gcc?  I wrote the original
version, but I think it got extended and macro-ized by others.

Paul.

Re: [RFC PATCH 0/2] powerpc: CPU cache op cleanup

[Moffett, Kyle D]

On Nov 15, 2011, at 23:40, Paul Mackerras wrote:
> On Tue, Nov 15, 2011 at 04:45:18PM -0600, Moffett, Kyle D wrote:
>> 
>> I guess that's doable, although I have to admit that idea almost gives
>> me more of a headache than trying to fix up the 32-bit ASM.
>> 
>> One thing that bothers me in particular is that both 32/64 versions of
>> __copy_tofrom_user() are dramatically overcomplicated for what they
>> ought to be doing.
>> 
>> It would seem that if we get a page fault during an unaligned copy, we
>> ought to just give up and fall back to a simple byte-by-byte copy loop
>> from wherever we left off.  That would eliminate 90% of the ugly
>> special cases without actually hurting performance, right?
> 
> That's basically what we do, IIRC, and most of the complexity comes
> from working out where we were up to.  We could probably use a simpler
> approximation that means we might copy some bytes twice.  In fact the
> greatest simplification would probably be to implement range entries
> in the exception table so we can just have one entry for all the loads
> and stores instead of an entry for each individual load and store.

Well, I spent some time tinkering with the GCC inline-assembly option,
which was probably a waste, but I figured I would post my code here for
other people to chuckle at.  :-D

Here's a basic, relatively easily extended "copy u8" macro that sets up
the exception table using "asm goto":

#define try_copy_u8(DST, SRC, LOAD_FAULT, STORE_FAULT) do {	\
	unsigned long try_copy_tmp__ = (try_copy_tmp__);	\
	asm goto (						\
		"1:	lbz %[tmp], %[src]\n"			\
		"2:	stb %[tmp], %[dst]\n"			\
		"	.pushsection __ex_table, \"a\"\n"	\
		"	.align 2\n"				\
		"	.long 1b, %l["#LOAD_FAULT"]\n"		\
		"	.long 2b, %l["#STORE_FAULT"]\n"		\
		"	.popsection\n"				\
		: /* No outputs allowed for "asm goto" */	\
		: [dst] "m"(*(__user u8 *)(DST)),		\
		  [src] "m"(*(const __user u8 *)(SRC)),		\
		  [tmp] "r"(try_copy_tmp__)			\
		: "memory"					\
		: LOAD_FAULT, STORE_FAULT			\
	);							\
} while(0)

If I put that into a function and compile it, the assembly and the
exception table look perfectly OK, even under register pressure.
With a few macros like that it looks like it should be possible to
write the copy function directly in C and get optimal results.

The only other variants you need would be "try_copy_ulong" and
"try_copy_4ulong"/"try_copy_8ulong" for 32/64-bit.

Unfortunately, as I mentioned before, GCC 4.4 and older don't have
"asm goto" support :-(.

Perhaps I could put __copy_tofrom_user() into its own file and make
the assembled 32/64 output files be ".shipped"?

On the other hand, perhaps this is overly complicated :-D.

I'll poke at it more tomorrow.


>> For a page-fault during a cacheline-aligned copy, we should be able to
>> handle the exception and retry from the last cacheline without much
>> logic, again with good performance.
>> 
>> With that said, I'm curious about the origin of the PPC32 ASM.  In
>> particular, it looks like it was generated by GCC at some point in the
>> distant past, and I'm wondering if there's a good way to rewrite that
>> file in C and trick GCC into generating the relevant exception tables
>> for it?
> 
> Why do you think it was generated by gcc?  I wrote the original
> version, but I think it got extended and macro-ized by others.

Ah, sorry,  when I first looked at it the large collection of numeric
labels and the very sparing comments made it look autogenerated.

Although, given how much of a pain in the neck it is maybe you would
rather people not think you wrote it at all. ;-)

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

[RFC PATCH 1/2] powerpc: Remove duplicate cacheable_memcpy/memzero functions

[Kyle Moffett]

These functions are only used from one place each.  If the cacheable_*
versions really are more efficient, then those changes should be
migrated into the common code instead.

NOTE: The old routines are just flat buggy on kernels that support
      hardware with different cacheline sizes.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/include/asm/system.h    |    2 -
 arch/powerpc/kernel/ppc_ksyms.c      |    2 -
 arch/powerpc/lib/copy_32.S           |  127 ----------------------------------
 arch/powerpc/mm/ppc_mmu_32.c         |    2 +-
 drivers/net/ethernet/ibm/emac/core.c |   12 +---
 5 files changed, 3 insertions(+), 142 deletions(-)

diff --git a/arch/powerpc/include/asm/system.h b/arch/powerpc/include/asm/system.h
index e30a13d..25389d1 100644
--- a/arch/powerpc/include/asm/system.h
+++ b/arch/powerpc/include/asm/system.h
@@ -189,8 +189,6 @@ static inline void flush_spe_to_thread(struct task_struct *t)
 #endif
 
 extern int call_rtas(const char *, int, int, unsigned long *, ...);
-extern void cacheable_memzero(void *p, unsigned int nb);
-extern void *cacheable_memcpy(void *, const void *, unsigned int);
 extern int do_page_fault(struct pt_regs *, unsigned long, unsigned long);
 extern void bad_page_fault(struct pt_regs *, unsigned long, int);
 extern int die(const char *, struct pt_regs *, long);
diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
index d3114a7..acba8ce 100644
--- a/arch/powerpc/kernel/ppc_ksyms.c
+++ b/arch/powerpc/kernel/ppc_ksyms.c
@@ -159,8 +159,6 @@ EXPORT_SYMBOL(screen_info);
 #ifdef CONFIG_PPC32
 EXPORT_SYMBOL(timer_interrupt);
 EXPORT_SYMBOL(tb_ticks_per_jiffy);
-EXPORT_SYMBOL(cacheable_memcpy);
-EXPORT_SYMBOL(cacheable_memzero);
 #endif
 
 #ifdef CONFIG_PPC32
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index 55f19f9..6813f80 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -69,54 +69,6 @@ CACHELINE_BYTES = L1_CACHE_BYTES
 LG_CACHELINE_BYTES = L1_CACHE_SHIFT
 CACHELINE_MASK = (L1_CACHE_BYTES-1)
 
-/*
- * Use dcbz on the complete cache lines in the destination
- * to set them to zero.  This requires that the destination
- * area is cacheable.  -- paulus
- */
-_GLOBAL(cacheable_memzero)
-	mr	r5,r4
-	li	r4,0
-	addi	r6,r3,-4
-	cmplwi	0,r5,4
-	blt	7f
-	stwu	r4,4(r6)
-	beqlr
-	andi.	r0,r6,3
-	add	r5,r0,r5
-	subf	r6,r0,r6
-	clrlwi	r7,r6,32-LG_CACHELINE_BYTES
-	add	r8,r7,r5
-	srwi	r9,r8,LG_CACHELINE_BYTES
-	addic.	r9,r9,-1	/* total number of complete cachelines */
-	ble	2f
-	xori	r0,r7,CACHELINE_MASK & ~3
-	srwi.	r0,r0,2
-	beq	3f
-	mtctr	r0
-4:	stwu	r4,4(r6)
-	bdnz	4b
-3:	mtctr	r9
-	li	r7,4
-10:	dcbz	r7,r6
-	addi	r6,r6,CACHELINE_BYTES
-	bdnz	10b
-	clrlwi	r5,r8,32-LG_CACHELINE_BYTES
-	addi	r5,r5,4
-2:	srwi	r0,r5,2
-	mtctr	r0
-	bdz	6f
-1:	stwu	r4,4(r6)
-	bdnz	1b
-6:	andi.	r5,r5,3
-7:	cmpwi	0,r5,0
-	beqlr
-	mtctr	r5
-	addi	r6,r6,3
-8:	stbu	r4,1(r6)
-	bdnz	8b
-	blr
-
 _GLOBAL(memset)
 	rlwimi	r4,r4,8,16,23
 	rlwimi	r4,r4,16,0,15
@@ -142,85 +94,6 @@ _GLOBAL(memset)
 	bdnz	8b
 	blr
 
-/*
- * This version uses dcbz on the complete cache lines in the
- * destination area to reduce memory traffic.  This requires that
- * the destination area is cacheable.
- * We only use this version if the source and dest don't overlap.
- * -- paulus.
- */
-_GLOBAL(cacheable_memcpy)
-	add	r7,r3,r5		/* test if the src & dst overlap */
-	add	r8,r4,r5
-	cmplw	0,r4,r7
-	cmplw	1,r3,r8
-	crand	0,0,4			/* cr0.lt &= cr1.lt */
-	blt	memcpy			/* if regions overlap */
-
-	addi	r4,r4,-4
-	addi	r6,r3,-4
-	neg	r0,r3
-	andi.	r0,r0,CACHELINE_MASK	/* # bytes to start of cache line */
-	beq	58f
-
-	cmplw	0,r5,r0			/* is this more than total to do? */
-	blt	63f			/* if not much to do */
-	andi.	r8,r0,3			/* get it word-aligned first */
-	subf	r5,r0,r5
-	mtctr	r8
-	beq+	61f
-70:	lbz	r9,4(r4)		/* do some bytes */
-	stb	r9,4(r6)
-	addi	r4,r4,1
-	addi	r6,r6,1
-	bdnz	70b
-61:	srwi.	r0,r0,2
-	mtctr	r0
-	beq	58f
-72:	lwzu	r9,4(r4)		/* do some words */
-	stwu	r9,4(r6)
-	bdnz	72b
-
-58:	srwi.	r0,r5,LG_CACHELINE_BYTES /* # complete cachelines */
-	clrlwi	r5,r5,32-LG_CACHELINE_BYTES
-	li	r11,4
-	mtctr	r0
-	beq	63f
-53:
-	dcbz	r11,r6
-	COPY_16_BYTES
-#if L1_CACHE_BYTES >= 32
-	COPY_16_BYTES
-#if L1_CACHE_BYTES >= 64
-	COPY_16_BYTES
-	COPY_16_BYTES
-#if L1_CACHE_BYTES >= 128
-	COPY_16_BYTES
-	COPY_16_BYTES
-	COPY_16_BYTES
-	COPY_16_BYTES
-#endif
-#endif
-#endif
-	bdnz	53b
-
-63:	srwi.	r0,r5,2
-	mtctr	r0
-	beq	64f
-30:	lwzu	r0,4(r4)
-	stwu	r0,4(r6)
-	bdnz	30b
-
-64:	andi.	r0,r5,3
-	mtctr	r0
-	beq+	65f
-40:	lbz	r0,4(r4)
-	stb	r0,4(r6)
-	addi	r4,r4,1
-	addi	r6,r6,1
-	bdnz	40b
-65:	blr
-
 _GLOBAL(memmove)
 	cmplw	0,r3,r4
 	bgt	backwards_memcpy
diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
index 11571e1..9f16b9f 100644
--- a/arch/powerpc/mm/ppc_mmu_32.c
+++ b/arch/powerpc/mm/ppc_mmu_32.c
@@ -224,7 +224,7 @@ void __init MMU_init_hw(void)
 	 */
 	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
 	Hash = __va(memblock_alloc(Hash_size, Hash_size));
-	cacheable_memzero(Hash, Hash_size);
+	memset(Hash, 0, Hash_size);
 	_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
 
 	Hash_end = (struct hash_pte *) ((unsigned long)Hash + Hash_size);
diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
index ed79b2d..be214ad 100644
--- a/drivers/net/ethernet/ibm/emac/core.c
+++ b/drivers/net/ethernet/ibm/emac/core.c
@@ -77,13 +77,6 @@ MODULE_AUTHOR
     ("Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>");
 MODULE_LICENSE("GPL");
 
-/*
- * PPC64 doesn't (yet) have a cacheable_memcpy
- */
-#ifdef CONFIG_PPC64
-#define cacheable_memcpy(d,s,n) memcpy((d),(s),(n))
-#endif
-
 /* minimum number of free TX descriptors required to wake up TX process */
 #define EMAC_TX_WAKEUP_THRESH		(NUM_TX_BUFF / 4)
 
@@ -1637,7 +1630,7 @@ static inline int emac_rx_sg_append(struct emac_instance *dev, int slot)
 			dev_kfree_skb(dev->rx_sg_skb);
 			dev->rx_sg_skb = NULL;
 		} else {
-			cacheable_memcpy(skb_tail_pointer(dev->rx_sg_skb),
+			memcpy(skb_tail_pointer(dev->rx_sg_skb),
 					 dev->rx_skb[slot]->data, len);
 			skb_put(dev->rx_sg_skb, len);
 			emac_recycle_rx_skb(dev, slot, len);
@@ -1694,8 +1687,7 @@ static int emac_poll_rx(void *param, int budget)
 				goto oom;
 
 			skb_reserve(copy_skb, EMAC_RX_SKB_HEADROOM + 2);
-			cacheable_memcpy(copy_skb->data - 2, skb->data - 2,
-					 len + 2);
+			memcpy(copy_skb->data - 2, skb->data - 2, len + 2);
 			emac_recycle_rx_skb(dev, slot, len);
 			skb = copy_skb;
 		} else if (unlikely(emac_alloc_rx_skb(dev, slot, GFP_ATOMIC)))
-- 
1.7.2.5

Re: [RFC PATCH 1/2] powerpc: Remove duplicate cacheable_memcpy/memzero functions

[Benjamin Herrenschmidt]

On Mon, 2011-11-14 at 21:32 -0500, Kyle Moffett wrote:
> These functions are only used from one place each.  If the cacheable_*
> versions really are more efficient, then those changes should be
> migrated into the common code instead.
> 
> NOTE: The old routines are just flat buggy on kernels that support
>       hardware with different cacheline sizes.
> 
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---

Right, considering where those are used, I think we can safely remove
them. Thanks.

Ben.

>  arch/powerpc/include/asm/system.h    |    2 -
>  arch/powerpc/kernel/ppc_ksyms.c      |    2 -
>  arch/powerpc/lib/copy_32.S           |  127 ----------------------------------
>  arch/powerpc/mm/ppc_mmu_32.c         |    2 +-
>  drivers/net/ethernet/ibm/emac/core.c |   12 +---
>  5 files changed, 3 insertions(+), 142 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/system.h b/arch/powerpc/include/asm/system.h
> index e30a13d..25389d1 100644
> --- a/arch/powerpc/include/asm/system.h
> +++ b/arch/powerpc/include/asm/system.h
> @@ -189,8 +189,6 @@ static inline void flush_spe_to_thread(struct task_struct *t)
>  #endif
>  
>  extern int call_rtas(const char *, int, int, unsigned long *, ...);
> -extern void cacheable_memzero(void *p, unsigned int nb);
> -extern void *cacheable_memcpy(void *, const void *, unsigned int);
>  extern int do_page_fault(struct pt_regs *, unsigned long, unsigned long);
>  extern void bad_page_fault(struct pt_regs *, unsigned long, int);
>  extern int die(const char *, struct pt_regs *, long);
> diff --git a/arch/powerpc/kernel/ppc_ksyms.c b/arch/powerpc/kernel/ppc_ksyms.c
> index d3114a7..acba8ce 100644
> --- a/arch/powerpc/kernel/ppc_ksyms.c
> +++ b/arch/powerpc/kernel/ppc_ksyms.c
> @@ -159,8 +159,6 @@ EXPORT_SYMBOL(screen_info);
>  #ifdef CONFIG_PPC32
>  EXPORT_SYMBOL(timer_interrupt);
>  EXPORT_SYMBOL(tb_ticks_per_jiffy);
> -EXPORT_SYMBOL(cacheable_memcpy);
> -EXPORT_SYMBOL(cacheable_memzero);
>  #endif
>  
>  #ifdef CONFIG_PPC32
> diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
> index 55f19f9..6813f80 100644
> --- a/arch/powerpc/lib/copy_32.S
> +++ b/arch/powerpc/lib/copy_32.S
> @@ -69,54 +69,6 @@ CACHELINE_BYTES = L1_CACHE_BYTES
>  LG_CACHELINE_BYTES = L1_CACHE_SHIFT
>  CACHELINE_MASK = (L1_CACHE_BYTES-1)
>  
> -/*
> - * Use dcbz on the complete cache lines in the destination
> - * to set them to zero.  This requires that the destination
> - * area is cacheable.  -- paulus
> - */
> -_GLOBAL(cacheable_memzero)
> -	mr	r5,r4
> -	li	r4,0
> -	addi	r6,r3,-4
> -	cmplwi	0,r5,4
> -	blt	7f
> -	stwu	r4,4(r6)
> -	beqlr
> -	andi.	r0,r6,3
> -	add	r5,r0,r5
> -	subf	r6,r0,r6
> -	clrlwi	r7,r6,32-LG_CACHELINE_BYTES
> -	add	r8,r7,r5
> -	srwi	r9,r8,LG_CACHELINE_BYTES
> -	addic.	r9,r9,-1	/* total number of complete cachelines */
> -	ble	2f
> -	xori	r0,r7,CACHELINE_MASK & ~3
> -	srwi.	r0,r0,2
> -	beq	3f
> -	mtctr	r0
> -4:	stwu	r4,4(r6)
> -	bdnz	4b
> -3:	mtctr	r9
> -	li	r7,4
> -10:	dcbz	r7,r6
> -	addi	r6,r6,CACHELINE_BYTES
> -	bdnz	10b
> -	clrlwi	r5,r8,32-LG_CACHELINE_BYTES
> -	addi	r5,r5,4
> -2:	srwi	r0,r5,2
> -	mtctr	r0
> -	bdz	6f
> -1:	stwu	r4,4(r6)
> -	bdnz	1b
> -6:	andi.	r5,r5,3
> -7:	cmpwi	0,r5,0
> -	beqlr
> -	mtctr	r5
> -	addi	r6,r6,3
> -8:	stbu	r4,1(r6)
> -	bdnz	8b
> -	blr
> -
>  _GLOBAL(memset)
>  	rlwimi	r4,r4,8,16,23
>  	rlwimi	r4,r4,16,0,15
> @@ -142,85 +94,6 @@ _GLOBAL(memset)
>  	bdnz	8b
>  	blr
>  
> -/*
> - * This version uses dcbz on the complete cache lines in the
> - * destination area to reduce memory traffic.  This requires that
> - * the destination area is cacheable.
> - * We only use this version if the source and dest don't overlap.
> - * -- paulus.
> - */
> -_GLOBAL(cacheable_memcpy)
> -	add	r7,r3,r5		/* test if the src & dst overlap */
> -	add	r8,r4,r5
> -	cmplw	0,r4,r7
> -	cmplw	1,r3,r8
> -	crand	0,0,4			/* cr0.lt &= cr1.lt */
> -	blt	memcpy			/* if regions overlap */
> -
> -	addi	r4,r4,-4
> -	addi	r6,r3,-4
> -	neg	r0,r3
> -	andi.	r0,r0,CACHELINE_MASK	/* # bytes to start of cache line */
> -	beq	58f
> -
> -	cmplw	0,r5,r0			/* is this more than total to do? */
> -	blt	63f			/* if not much to do */
> -	andi.	r8,r0,3			/* get it word-aligned first */
> -	subf	r5,r0,r5
> -	mtctr	r8
> -	beq+	61f
> -70:	lbz	r9,4(r4)		/* do some bytes */
> -	stb	r9,4(r6)
> -	addi	r4,r4,1
> -	addi	r6,r6,1
> -	bdnz	70b
> -61:	srwi.	r0,r0,2
> -	mtctr	r0
> -	beq	58f
> -72:	lwzu	r9,4(r4)		/* do some words */
> -	stwu	r9,4(r6)
> -	bdnz	72b
> -
> -58:	srwi.	r0,r5,LG_CACHELINE_BYTES /* # complete cachelines */
> -	clrlwi	r5,r5,32-LG_CACHELINE_BYTES
> -	li	r11,4
> -	mtctr	r0
> -	beq	63f
> -53:
> -	dcbz	r11,r6
> -	COPY_16_BYTES
> -#if L1_CACHE_BYTES >= 32
> -	COPY_16_BYTES
> -#if L1_CACHE_BYTES >= 64
> -	COPY_16_BYTES
> -	COPY_16_BYTES
> -#if L1_CACHE_BYTES >= 128
> -	COPY_16_BYTES
> -	COPY_16_BYTES
> -	COPY_16_BYTES
> -	COPY_16_BYTES
> -#endif
> -#endif
> -#endif
> -	bdnz	53b
> -
> -63:	srwi.	r0,r5,2
> -	mtctr	r0
> -	beq	64f
> -30:	lwzu	r0,4(r4)
> -	stwu	r0,4(r6)
> -	bdnz	30b
> -
> -64:	andi.	r0,r5,3
> -	mtctr	r0
> -	beq+	65f
> -40:	lbz	r0,4(r4)
> -	stb	r0,4(r6)
> -	addi	r4,r4,1
> -	addi	r6,r6,1
> -	bdnz	40b
> -65:	blr
> -
>  _GLOBAL(memmove)
>  	cmplw	0,r3,r4
>  	bgt	backwards_memcpy
> diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
> index 11571e1..9f16b9f 100644
> --- a/arch/powerpc/mm/ppc_mmu_32.c
> +++ b/arch/powerpc/mm/ppc_mmu_32.c
> @@ -224,7 +224,7 @@ void __init MMU_init_hw(void)
>  	 */
>  	if ( ppc_md.progress ) ppc_md.progress("hash:find piece", 0x322);
>  	Hash = __va(memblock_alloc(Hash_size, Hash_size));
> -	cacheable_memzero(Hash, Hash_size);
> +	memset(Hash, 0, Hash_size);
>  	_SDR1 = __pa(Hash) | SDR1_LOW_BITS;
>  
>  	Hash_end = (struct hash_pte *) ((unsigned long)Hash + Hash_size);
> diff --git a/drivers/net/ethernet/ibm/emac/core.c b/drivers/net/ethernet/ibm/emac/core.c
> index ed79b2d..be214ad 100644
> --- a/drivers/net/ethernet/ibm/emac/core.c
> +++ b/drivers/net/ethernet/ibm/emac/core.c
> @@ -77,13 +77,6 @@ MODULE_AUTHOR
>      ("Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>");
>  MODULE_LICENSE("GPL");
>  
> -/*
> - * PPC64 doesn't (yet) have a cacheable_memcpy
> - */
> -#ifdef CONFIG_PPC64
> -#define cacheable_memcpy(d,s,n) memcpy((d),(s),(n))
> -#endif
> -
>  /* minimum number of free TX descriptors required to wake up TX process */
>  #define EMAC_TX_WAKEUP_THRESH		(NUM_TX_BUFF / 4)
>  
> @@ -1637,7 +1630,7 @@ static inline int emac_rx_sg_append(struct emac_instance *dev, int slot)
>  			dev_kfree_skb(dev->rx_sg_skb);
>  			dev->rx_sg_skb = NULL;
>  		} else {
> -			cacheable_memcpy(skb_tail_pointer(dev->rx_sg_skb),
> +			memcpy(skb_tail_pointer(dev->rx_sg_skb),
>  					 dev->rx_skb[slot]->data, len);
>  			skb_put(dev->rx_sg_skb, len);
>  			emac_recycle_rx_skb(dev, slot, len);
> @@ -1694,8 +1687,7 @@ static int emac_poll_rx(void *param, int budget)
>  				goto oom;
>  
>  			skb_reserve(copy_skb, EMAC_RX_SKB_HEADROOM + 2);
> -			cacheable_memcpy(copy_skb->data - 2, skb->data - 2,
> -					 len + 2);
> +			memcpy(copy_skb->data - 2, skb->data - 2, len + 2);
>  			emac_recycle_rx_skb(dev, slot, len);
>  			skb = copy_skb;
>  		} else if (unlikely(emac_alloc_rx_skb(dev, slot, GFP_ATOMIC)))

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Moffett, Kyle D]

On Nov 10, 2011, at 23:40, Benjamin Herrenschmidt wrote:
> On Thu, 2011-11-10 at 18:38 -0600, Moffett, Kyle D wrote:
>>  (2) Make the ppc64_caches struct apply to ppc32 as well, and
>>      preinitialize it with a minimum value used by any platform being
>>      compiled in (for "dcbXX"/"icbXX" purposes).  This is safe because
>>      the pagesize is always a multiple of the cache block size and the
>>      kernel only uses dcbXX/icbXX on whole pages.  The only impact is a
>>      temporary small performance hit from flushing or zeroing the same
>>      block 8 times if too small.
> 
> Are you sure about dcbz ? Getting that wrong can be deadly ... I'd
> rather get rid of some fancy optims and use a soft value in some cases.
> That or we can compile multiple variants for the common case of some of
> the copy routines and use patching (alternate sections) to branch to the
> right one at runtime, at least for the common cases (32 and 128 for
> example for 440 and 476).

Well, all of the kernel loops that use dcbz are operating on whole pages,
and the PPC Book-E spec documents that the pagesize is an even multiple
of the cacheline size and the cachelines are always page-aligned.

So when you are clearing a whole page, there are only 2 things you can do
wrong with "dcbz":

  (1) Call "dcbz" with an address outside of the page you want to zero.

  (2) Omit calls "dcbz" to dcbz for some physical cachelines in the page.

Now, that's a totally different story from the userspace memset() calls
that caused the problem originally, because they were frequently given
memory much smaller than a page to clear, and if you didn't know exactly
how many bytes a "dcbz" was going to clear you couldn't use it at all.

But the kernel doesn't do that anywhere, it just uses it for page clears.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Tabi Timur-B04825]

Moffett, Kyle D wrote:
>the PPC Book-E spec documents that the pagesize is an even multiple
> of the cacheline size and the cachelines are always page-aligned.

cachelines are page aligned?

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Kyle Moffett]

On Mon, Nov 14, 2011 at 21:41, Tabi Timur-B04825 <B04825@freescale.com> wrote:
> Moffett, Kyle D wrote:
>>the PPC Book-E spec documents that the pagesize is an even multiple
>> of the cacheline size and the cachelines are always page-aligned.
>
> cachelines are page aligned?

Whoops, good catch.  That should have been:

"the PPC Book-E spec documents that the pagesize is an even multiple
of the cacheline size and that the pages are always cacheline-aligned."

Thanks!

Cheers,
Kyle Moffett

-- 
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

Re: [RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Benjamin Herrenschmidt]

On Mon, 2011-11-14 at 20:36 -0600, Moffett, Kyle D wrote:
> So when you are clearing a whole page, there are only 2 things you can do
> wrong with "dcbz":
> 
>   (1) Call "dcbz" with an address outside of the page you want to zero.
> 
>   (2) Omit calls "dcbz" to dcbz for some physical cachelines in the page.
> 
> Now, that's a totally different story from the userspace memset() calls
> that caused the problem originally, because they were frequently given
> memory much smaller than a page to clear, and if you didn't know exactly
> how many bytes a "dcbz" was going to clear you couldn't use it at all.

Right. That's why we pass the cache line sizes to userspace via the elf
AUX table so they don't do stupid things like that :-)

> But the kernel doesn't do that anywhere, it just uses it for page clears. 

Right, so we could easily precalc the count & increment and use a "soft"
loop.

Cheers,
Ben.

[RFC PATCH 00/17] powerpc/e500: separate e500 from e500mc

[Kyle Moffett]

(Sorry for the repost, I accidentally omitted Baruch's email).

Hello,

I saw Baruch Siach's patch:
  powerpc: 85xx: separate e500 from e500mc

Unfortunately, that patch breaks the dependencies for the P5020DS
platform and does not fix the underlying code which does not
understand what the ambiguous "CONFIG_E500" means.

In order to fix the issue at the fundamental level, I created the
following 17-patch series loosely based on Baruch's patch.

=== High-Level Summary ===

The e500v1/v2 and e500mc/e5500 CPU families are not compatible with
each other, yet they share the same "CONFIG_E500" Kconfig option.

The following patch series splits the 32-bit CPU support into two
separate options: "CONFIG_FSL_E500_V1_V2" and "CONFIG_FSL_E500MC".
Additionally, the 64-bit e5500 support is separated to its own config
option ("CONFIG_FSL_E5500") which is automatically combined with
either 32-bit e500MC or 64-bit Book-3E when the P5020DS board support
is enabled.

I based the patches on v3.2-rc1, please let me know if I should
update the patches against a different tree.

The first 4 patches stand on their own merits; they are generic code
cleanups necessary to support the later patches.

I'd like to know what you all think.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

[RFC PATCH 01/17] powerpc/mpic: Fix bogus CONFIG_BOOKE conditional

[Kyle Moffett]

The code inside the conditional is only used by 85xx CoreNet fabric
platforms, so add a new config define and use it where necessary.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/platforms/85xx/Kconfig    |    5 +++++
 arch/powerpc/platforms/85xx/Makefile   |   11 ++++++-----
 arch/powerpc/platforms/Kconfig.cputype |    3 +++
 arch/powerpc/sysdev/mpic.c             |    6 ++----
 4 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 45023e2..9088381 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -181,6 +181,7 @@ config P2041_RDB
 	select GPIO_MPC8XXX
 	select HAS_RAPIDIO
 	select PPC_EPAPR_HV_PIC
+	select FSL_CORENET
 	help
 	  This option enables support for the P2041 RDB board
 
@@ -194,6 +195,7 @@ config P3041_DS
 	select GPIO_MPC8XXX
 	select HAS_RAPIDIO
 	select PPC_EPAPR_HV_PIC
+	select FSL_CORENET
 	help
 	  This option enables support for the P3041 DS board
 
@@ -206,6 +208,7 @@ config P3060_QDS
 	select MPC8xxx_GPIO
 	select HAS_RAPIDIO
 	select PPC_EPAPR_HV_PIC
+	select FSL_CORENET
 	help
 	  This option enables support for the P3060 QDS board
 
@@ -219,6 +222,7 @@ config P4080_DS
 	select GPIO_MPC8XXX
 	select HAS_RAPIDIO
 	select PPC_EPAPR_HV_PIC
+	select FSL_CORENET
 	help
 	  This option enables support for the P4080 DS board
 
@@ -235,6 +239,7 @@ config P5020_DS
 	select GPIO_MPC8XXX
 	select HAS_RAPIDIO
 	select PPC_EPAPR_HV_PIC
+	select FSL_CORENET
 	help
 	  This option enables support for the P5020 DS board
 
diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
index bc5acb9..c6d1334 100644
--- a/arch/powerpc/platforms/85xx/Makefile
+++ b/arch/powerpc/platforms/85xx/Makefile
@@ -13,11 +13,12 @@ obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
 obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
 obj-$(CONFIG_P1022_DS)    += p1022_ds.o
 obj-$(CONFIG_P1023_RDS)   += p1023_rds.o
-obj-$(CONFIG_P2041_RDB)   += p2041_rdb.o corenet_ds.o
-obj-$(CONFIG_P3041_DS)    += p3041_ds.o corenet_ds.o
-obj-$(CONFIG_P3060_QDS)   += p3060_qds.o corenet_ds.o
-obj-$(CONFIG_P4080_DS)    += p4080_ds.o corenet_ds.o
-obj-$(CONFIG_P5020_DS)    += p5020_ds.o corenet_ds.o
+obj-$(CONFIG_P2041_RDB)   += p2041_rdb.o
+obj-$(CONFIG_P3041_DS)    += p3041_ds.o
+obj-$(CONFIG_P3060_QDS)   += p3060_qds.o
+obj-$(CONFIG_P4080_DS)    += p4080_ds.o
+obj-$(CONFIG_P5020_DS)    += p5020_ds.o
+obj-$(CONFIG_FSL_CORENET) += corenet_ds.o
 obj-$(CONFIG_STX_GP3)	  += stx_gp3.o
 obj-$(CONFIG_TQM85xx)	  += tqm85xx.o
 obj-$(CONFIG_SBC8560)     += sbc8560.o
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index fbecae0..9210e94 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -177,6 +177,9 @@ config FSL_BOOKE
 	select SYS_SUPPORTS_HUGETLBFS if PHYS_64BIT
 	default y
 
+config FSL_CORENET
+	bool
+
 # this is for common code between PPC32 & PPC64 FSL BOOKE
 config PPC_FSL_BOOK3E
 	bool
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index 0842c6f..1a3d84a 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1642,9 +1642,9 @@ unsigned int mpic_get_irq(void)
 	return mpic_get_one_irq(mpic);
 }
 
+#ifdef CONFIG_FSL_CORENET
 unsigned int mpic_get_coreint_irq(void)
 {
-#ifdef CONFIG_BOOKE
 	struct mpic *mpic = mpic_primary;
 	u32 src;
 
@@ -1664,10 +1664,8 @@ unsigned int mpic_get_coreint_irq(void)
 	}
 
 	return irq_linear_revmap(mpic->irqhost, src);
-#else
-	return NO_IRQ;
-#endif
 }
+#endif
 
 unsigned int mpic_get_mcirq(void)
 {
-- 
1.7.2.5

Re: [RFC PATCH 01/17] powerpc/mpic: Fix bogus CONFIG_BOOKE conditional

[Kumar Gala]

On Nov 9, 2011, at 6:06 PM, Kyle Moffett wrote:

> The code inside the conditional is only used by 85xx CoreNet fabric
> platforms, so add a new config define and use it where necessary.

1. why make the change
2. if you're using FSL_CORENET as a SoC feature CONFIG option than other bits of this patch are wrong

It should NOT be used in platforms/85xx/Makefile those should be left alone and FSL_CORENET should be selected by having E500MC or similar set.

> 
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig    |    5 +++++
> arch/powerpc/platforms/85xx/Makefile   |   11 ++++++-----
> arch/powerpc/platforms/Kconfig.cputype |    3 +++
> arch/powerpc/sysdev/mpic.c             |    6 ++----
> 4 files changed, 16 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 45023e2..9088381 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -181,6 +181,7 @@ config P2041_RDB
> 	select GPIO_MPC8XXX
> 	select HAS_RAPIDIO
> 	select PPC_EPAPR_HV_PIC
> +	select FSL_CORENET
> 	help
> 	  This option enables support for the P2041 RDB board
> 
> @@ -194,6 +195,7 @@ config P3041_DS
> 	select GPIO_MPC8XXX
> 	select HAS_RAPIDIO
> 	select PPC_EPAPR_HV_PIC
> +	select FSL_CORENET
> 	help
> 	  This option enables support for the P3041 DS board
> 
> @@ -206,6 +208,7 @@ config P3060_QDS
> 	select MPC8xxx_GPIO
> 	select HAS_RAPIDIO
> 	select PPC_EPAPR_HV_PIC
> +	select FSL_CORENET
> 	help
> 	  This option enables support for the P3060 QDS board
> 
> @@ -219,6 +222,7 @@ config P4080_DS
> 	select GPIO_MPC8XXX
> 	select HAS_RAPIDIO
> 	select PPC_EPAPR_HV_PIC
> +	select FSL_CORENET
> 	help
> 	  This option enables support for the P4080 DS board
> 
> @@ -235,6 +239,7 @@ config P5020_DS
> 	select GPIO_MPC8XXX
> 	select HAS_RAPIDIO
> 	select PPC_EPAPR_HV_PIC
> +	select FSL_CORENET
> 	help
> 	  This option enables support for the P5020 DS board
> 
> diff --git a/arch/powerpc/platforms/85xx/Makefile b/arch/powerpc/platforms/85xx/Makefile
> index bc5acb9..c6d1334 100644
> --- a/arch/powerpc/platforms/85xx/Makefile
> +++ b/arch/powerpc/platforms/85xx/Makefile
> @@ -13,11 +13,12 @@ obj-$(CONFIG_MPC85xx_RDB) += mpc85xx_rdb.o
> obj-$(CONFIG_P1010_RDB)   += p1010rdb.o
> obj-$(CONFIG_P1022_DS)    += p1022_ds.o
> obj-$(CONFIG_P1023_RDS)   += p1023_rds.o
> -obj-$(CONFIG_P2041_RDB)   += p2041_rdb.o corenet_ds.o
> -obj-$(CONFIG_P3041_DS)    += p3041_ds.o corenet_ds.o
> -obj-$(CONFIG_P3060_QDS)   += p3060_qds.o corenet_ds.o
> -obj-$(CONFIG_P4080_DS)    += p4080_ds.o corenet_ds.o
> -obj-$(CONFIG_P5020_DS)    += p5020_ds.o corenet_ds.o
> +obj-$(CONFIG_P2041_RDB)   += p2041_rdb.o
> +obj-$(CONFIG_P3041_DS)    += p3041_ds.o
> +obj-$(CONFIG_P3060_QDS)   += p3060_qds.o
> +obj-$(CONFIG_P4080_DS)    += p4080_ds.o
> +obj-$(CONFIG_P5020_DS)    += p5020_ds.o
> +obj-$(CONFIG_FSL_CORENET) += corenet_ds.o
> obj-$(CONFIG_STX_GP3)	  += stx_gp3.o
> obj-$(CONFIG_TQM85xx)	  += tqm85xx.o
> obj-$(CONFIG_SBC8560)     += sbc8560.o
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index fbecae0..9210e94 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -177,6 +177,9 @@ config FSL_BOOKE
> 	select SYS_SUPPORTS_HUGETLBFS if PHYS_64BIT
> 	default y
> 
> +config FSL_CORENET
> +	bool
> +
> # this is for common code between PPC32 & PPC64 FSL BOOKE
> config PPC_FSL_BOOK3E
> 	bool
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 0842c6f..1a3d84a 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -1642,9 +1642,9 @@ unsigned int mpic_get_irq(void)
> 	return mpic_get_one_irq(mpic);
> }
> 
> +#ifdef CONFIG_FSL_CORENET
> unsigned int mpic_get_coreint_irq(void)
> {
> -#ifdef CONFIG_BOOKE
> 	struct mpic *mpic = mpic_primary;
> 	u32 src;
> 
> @@ -1664,10 +1664,8 @@ unsigned int mpic_get_coreint_irq(void)
> 	}
> 
> 	return irq_linear_revmap(mpic->irqhost, src);
> -#else
> -	return NO_IRQ;
> -#endif
> }
> +#endif
> 
> unsigned int mpic_get_mcirq(void)
> {
> -- 
> 1.7.2.5

[RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

[Kyle Moffett]

The "CONFIG_PHYS_64BIT" option violates the Kconfig best-practices in
various colorful ways.  It has explicit dependencies, but it is also
"select"ed by various CPUs and platforms.  It is not set on 64-bit
systems, but it is used by a number of pieces of powerpc code to enable
or disable 64-bit physical address support.

To resolve these issues, the option has now been split into 3:

  CONFIG_PHYS_64BIT_SUPPORTED:
    This hidden option should be selected by any CPU type which supports
    64-bit physical addresses.  This will enable the PHYS_64BIT option
    to be selected.  It is (obviously) always set on PPC64.

  CONFIG_PHYS_64BIT_DT_REQUIRED:
    This hidden option should be selected by any board or platform which
    has >32-bit physical devices present in hardware.  If this is set
    then the CONFIG_PHYS_64BIT option will be forcibly enabled and
    hidden from the user.  It is (obviously) always set on PPC64.

  CONFIG_PHYS_64BIT:
    This option is user-controllable, where allowed by CPU and platform
    settings, and should never be pointed at with a "select" statement.
    Due to the values of the above two options, this is never visible on
    PPC64.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/Kconfig                   |    4 ++--
 arch/powerpc/platforms/82xx/Kconfig    |    2 +-
 arch/powerpc/platforms/83xx/Kconfig    |    2 +-
 arch/powerpc/platforms/85xx/Kconfig    |   12 ++++++------
 arch/powerpc/platforms/86xx/Kconfig    |    1 +
 arch/powerpc/platforms/Kconfig.cputype |   25 ++++++++++++++++++-------
 6 files changed, 29 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b177caa..27e31c5 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -18,10 +18,10 @@ config WORD_SIZE
 	default 32 if !PPC64
 
 config ARCH_PHYS_ADDR_T_64BIT
-       def_bool PPC64 || PHYS_64BIT
+	def_bool PHYS_64BIT
 
 config ARCH_DMA_ADDR_T_64BIT
-	def_bool ARCH_PHYS_ADDR_T_64BIT
+	def_bool PHYS_64BIT
 
 config MMU
 	bool
diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
index 7c7df40..849d403 100644
--- a/arch/powerpc/platforms/82xx/Kconfig
+++ b/arch/powerpc/platforms/82xx/Kconfig
@@ -1,6 +1,6 @@
 menuconfig PPC_82xx
 	bool "82xx-based boards (PQ II)"
-	depends on 6xx
+	depends on 6xx && !PHYS_64BIT
 
 if PPC_82xx
 
diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
index 670a033..1ed8877 100644
--- a/arch/powerpc/platforms/83xx/Kconfig
+++ b/arch/powerpc/platforms/83xx/Kconfig
@@ -1,6 +1,6 @@
 menuconfig PPC_83xx
 	bool "83xx-based boards"
-	depends on 6xx
+	depends on 6xx && !PHYS_64BIT
 	select PPC_UDBG_16550
 	select PPC_PCI_CHOICE
 	select FSL_PCI if PCI
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 9088381..37f9de7 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -80,7 +80,7 @@ config P1010_RDB
 config P1022_DS
 	bool "Freescale P1022 DS"
 	select DEFAULT_UIMAGE
-	select PHYS_64BIT	# The DTS has 36-bit addresses
+	select PHYS_64BIT_DT_REQUIRED # The DTS has 36-bit addresses
 	select SWIOTLB
 	help
 	  This option enables support for the Freescale P1022DS reference board.
@@ -175,7 +175,7 @@ config P2041_RDB
 	bool "Freescale P2041 RDB"
 	select DEFAULT_UIMAGE
 	select PPC_E500MC
-	select PHYS_64BIT
+	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
 	select GPIO_MPC8XXX
@@ -189,7 +189,7 @@ config P3041_DS
 	bool "Freescale P3041 DS"
 	select DEFAULT_UIMAGE
 	select PPC_E500MC
-	select PHYS_64BIT
+	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
 	select GPIO_MPC8XXX
@@ -203,7 +203,7 @@ config P3060_QDS
 	bool "Freescale P3060 QDS"
 	select DEFAULT_UIMAGE
 	select PPC_E500MC
-	select PHYS_64BIT
+	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select MPC8xxx_GPIO
 	select HAS_RAPIDIO
@@ -216,7 +216,7 @@ config P4080_DS
 	bool "Freescale P4080 DS"
 	select DEFAULT_UIMAGE
 	select PPC_E500MC
-	select PHYS_64BIT
+	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
 	select GPIO_MPC8XXX
@@ -233,7 +233,7 @@ config P5020_DS
 	select DEFAULT_UIMAGE
 	select E500
 	select PPC_E500MC
-	select PHYS_64BIT
+	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
 	select GPIO_MPC8XXX
diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
index 8d6599d..576eb43 100644
--- a/arch/powerpc/platforms/86xx/Kconfig
+++ b/arch/powerpc/platforms/86xx/Kconfig
@@ -5,6 +5,7 @@ menuconfig PPC_86xx
 	select FSL_SOC
 	select ALTIVEC
 	select ARCH_WANT_OPTIONAL_GPIOLIB
+	select PHYS_64BIT_SUPPORTED
 	help
 	  The Freescale E600 SoCs have 74xx cores.
 
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 9210e94..0ab01b0 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -26,6 +26,7 @@ config PPC_BOOK3S_32
 
 config PPC_85xx
 	bool "Freescale 85xx"
+	select PHYS_64BIT_SUPPORTED
 	select E500
 
 config PPC_8xx
@@ -47,7 +48,8 @@ config 44x
 	select PPC_UDBG_16550
 	select 4xx_SOC
 	select PPC_PCI_CHOICE
-	select PHYS_64BIT
+	select PHYS_64BIT_SUPPORTED
+	select PHYS_64BIT_DT_REQUIRED
 
 config E200
 	bool "Freescale e200"
@@ -187,14 +189,20 @@ config PPC_FSL_BOOK3E
 	select PPC_SMP_MUXED_IPI
 	default y if FSL_BOOKE
 
-config PTE_64BIT
-	bool
-	depends on 44x || E500 || PPC_86xx
-	default y if PHYS_64BIT
+## Only some 32-bit CPUs support 64-bit physical addresses
+config PHYS_64BIT_SUPPORTED
+	def_bool PPC64
+
+## Some 32-bit system device trees have >32-bit physical addresses, and so
+## the kernel won't boot unless those are supported.
+config PHYS_64BIT_DT_REQUIRED
+	def_bool PPC64
 
+## DO NOT "select" this user-visible symbol, select the two above instead!
 config PHYS_64BIT
-	bool 'Large physical address support' if E500 || PPC_86xx
-	depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx
+	def_bool PHYS_64BIT_DT_REQUIRED
+	prompt 'Large physical address support' if !PHYS_64BIT_DT_REQUIRED
+	depends on PHYS_64BIT_SUPPORTED
 	---help---
 	  This option enables kernel support for larger than 32-bit physical
 	  addresses.  This feature may not be available on all cores.
@@ -205,6 +213,9 @@ config PHYS_64BIT
 
 	  If in doubt, say N here.
 
+config PTE_64BIT
+	def_bool PHYS_64BIT
+
 config ALTIVEC
 	bool "AltiVec Support"
 	depends on 6xx || POWER4
-- 
1.7.2.5

Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

[Kumar Gala]

On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:

> The "CONFIG_PHYS_64BIT" option violates the Kconfig best-practices in
> various colorful ways.  It has explicit dependencies, but it is also
> "select"ed by various CPUs and platforms.  It is not set on 64-bit
> systems, but it is used by a number of pieces of powerpc code to enable
> or disable 64-bit physical address support.
> 
> To resolve these issues, the option has now been split into 3:
> 
>  CONFIG_PHYS_64BIT_SUPPORTED:
>    This hidden option should be selected by any CPU type which supports
>    64-bit physical addresses.  This will enable the PHYS_64BIT option
>    to be selected.  It is (obviously) always set on PPC64.
> 
>  CONFIG_PHYS_64BIT_DT_REQUIRED:
>    This hidden option should be selected by any board or platform which
>    has >32-bit physical devices present in hardware.  If this is set
>    then the CONFIG_PHYS_64BIT option will be forcibly enabled and
>    hidden from the user.  It is (obviously) always set on PPC64.
> 
>  CONFIG_PHYS_64BIT:
>    This option is user-controllable, where allowed by CPU and platform
>    settings, and should never be pointed at with a "select" statement.
>    Due to the values of the above two options, this is never visible on
>    PPC64.
> 
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---
> arch/powerpc/Kconfig                   |    4 ++--
> arch/powerpc/platforms/82xx/Kconfig    |    2 +-
> arch/powerpc/platforms/83xx/Kconfig    |    2 +-
> arch/powerpc/platforms/85xx/Kconfig    |   12 ++++++------
> arch/powerpc/platforms/86xx/Kconfig    |    1 +
> arch/powerpc/platforms/Kconfig.cputype |   25 ++++++++++++++++++-------
> 6 files changed, 29 insertions(+), 17 deletions(-)

I don't really see what this gets us and don't think we should make this change.

- k

> 
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index b177caa..27e31c5 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -18,10 +18,10 @@ config WORD_SIZE
> 	default 32 if !PPC64
> 
> config ARCH_PHYS_ADDR_T_64BIT
> -       def_bool PPC64 || PHYS_64BIT
> +	def_bool PHYS_64BIT
> 
> config ARCH_DMA_ADDR_T_64BIT
> -	def_bool ARCH_PHYS_ADDR_T_64BIT
> +	def_bool PHYS_64BIT
> 
> config MMU
> 	bool
> diff --git a/arch/powerpc/platforms/82xx/Kconfig b/arch/powerpc/platforms/82xx/Kconfig
> index 7c7df40..849d403 100644
> --- a/arch/powerpc/platforms/82xx/Kconfig
> +++ b/arch/powerpc/platforms/82xx/Kconfig
> @@ -1,6 +1,6 @@
> menuconfig PPC_82xx
> 	bool "82xx-based boards (PQ II)"
> -	depends on 6xx
> +	depends on 6xx && !PHYS_64BIT
> 
> if PPC_82xx
> 
> diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/platforms/83xx/Kconfig
> index 670a033..1ed8877 100644
> --- a/arch/powerpc/platforms/83xx/Kconfig
> +++ b/arch/powerpc/platforms/83xx/Kconfig
> @@ -1,6 +1,6 @@
> menuconfig PPC_83xx
> 	bool "83xx-based boards"
> -	depends on 6xx
> +	depends on 6xx && !PHYS_64BIT
> 	select PPC_UDBG_16550
> 	select PPC_PCI_CHOICE
> 	select FSL_PCI if PCI
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 9088381..37f9de7 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -80,7 +80,7 @@ config P1010_RDB
> config P1022_DS
> 	bool "Freescale P1022 DS"
> 	select DEFAULT_UIMAGE
> -	select PHYS_64BIT	# The DTS has 36-bit addresses
> +	select PHYS_64BIT_DT_REQUIRED # The DTS has 36-bit addresses
> 	select SWIOTLB
> 	help
> 	  This option enables support for the Freescale P1022DS reference board.
> @@ -175,7 +175,7 @@ config P2041_RDB
> 	bool "Freescale P2041 RDB"
> 	select DEFAULT_UIMAGE
> 	select PPC_E500MC
> -	select PHYS_64BIT
> +	select PHYS_64BIT_DT_REQUIRED
> 	select SWIOTLB
> 	select ARCH_REQUIRE_GPIOLIB
> 	select GPIO_MPC8XXX
> @@ -189,7 +189,7 @@ config P3041_DS
> 	bool "Freescale P3041 DS"
> 	select DEFAULT_UIMAGE
> 	select PPC_E500MC
> -	select PHYS_64BIT
> +	select PHYS_64BIT_DT_REQUIRED
> 	select SWIOTLB
> 	select ARCH_REQUIRE_GPIOLIB
> 	select GPIO_MPC8XXX
> @@ -203,7 +203,7 @@ config P3060_QDS
> 	bool "Freescale P3060 QDS"
> 	select DEFAULT_UIMAGE
> 	select PPC_E500MC
> -	select PHYS_64BIT
> +	select PHYS_64BIT_DT_REQUIRED
> 	select SWIOTLB
> 	select MPC8xxx_GPIO
> 	select HAS_RAPIDIO
> @@ -216,7 +216,7 @@ config P4080_DS
> 	bool "Freescale P4080 DS"
> 	select DEFAULT_UIMAGE
> 	select PPC_E500MC
> -	select PHYS_64BIT
> +	select PHYS_64BIT_DT_REQUIRED
> 	select SWIOTLB
> 	select ARCH_REQUIRE_GPIOLIB
> 	select GPIO_MPC8XXX
> @@ -233,7 +233,7 @@ config P5020_DS
> 	select DEFAULT_UIMAGE
> 	select E500
> 	select PPC_E500MC
> -	select PHYS_64BIT
> +	select PHYS_64BIT_DT_REQUIRED
> 	select SWIOTLB
> 	select ARCH_REQUIRE_GPIOLIB
> 	select GPIO_MPC8XXX
> diff --git a/arch/powerpc/platforms/86xx/Kconfig b/arch/powerpc/platforms/86xx/Kconfig
> index 8d6599d..576eb43 100644
> --- a/arch/powerpc/platforms/86xx/Kconfig
> +++ b/arch/powerpc/platforms/86xx/Kconfig
> @@ -5,6 +5,7 @@ menuconfig PPC_86xx
> 	select FSL_SOC
> 	select ALTIVEC
> 	select ARCH_WANT_OPTIONAL_GPIOLIB
> +	select PHYS_64BIT_SUPPORTED
> 	help
> 	  The Freescale E600 SoCs have 74xx cores.
> 
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index 9210e94..0ab01b0 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -26,6 +26,7 @@ config PPC_BOOK3S_32
> 
> config PPC_85xx
> 	bool "Freescale 85xx"
> +	select PHYS_64BIT_SUPPORTED
> 	select E500
> 
> config PPC_8xx
> @@ -47,7 +48,8 @@ config 44x
> 	select PPC_UDBG_16550
> 	select 4xx_SOC
> 	select PPC_PCI_CHOICE
> -	select PHYS_64BIT
> +	select PHYS_64BIT_SUPPORTED
> +	select PHYS_64BIT_DT_REQUIRED
> 
> config E200
> 	bool "Freescale e200"
> @@ -187,14 +189,20 @@ config PPC_FSL_BOOK3E
> 	select PPC_SMP_MUXED_IPI
> 	default y if FSL_BOOKE
> 
> -config PTE_64BIT
> -	bool
> -	depends on 44x || E500 || PPC_86xx
> -	default y if PHYS_64BIT
> +## Only some 32-bit CPUs support 64-bit physical addresses
> +config PHYS_64BIT_SUPPORTED
> +	def_bool PPC64
> +
> +## Some 32-bit system device trees have >32-bit physical addresses, and so
> +## the kernel won't boot unless those are supported.
> +config PHYS_64BIT_DT_REQUIRED
> +	def_bool PPC64
> 
> +## DO NOT "select" this user-visible symbol, select the two above instead!
> config PHYS_64BIT
> -	bool 'Large physical address support' if E500 || PPC_86xx
> -	depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx
> +	def_bool PHYS_64BIT_DT_REQUIRED
> +	prompt 'Large physical address support' if !PHYS_64BIT_DT_REQUIRED
> +	depends on PHYS_64BIT_SUPPORTED
> 	---help---
> 	  This option enables kernel support for larger than 32-bit physical
> 	  addresses.  This feature may not be available on all cores.
> @@ -205,6 +213,9 @@ config PHYS_64BIT
> 
> 	  If in doubt, say N here.
> 
> +config PTE_64BIT
> +	def_bool PHYS_64BIT
> +
> config ALTIVEC
> 	bool "AltiVec Support"
> 	depends on 6xx || POWER4
> -- 
> 1.7.2.5

Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

[Timur Tabi]

Kyle Moffett wrote:
>   CONFIG_PHYS_64BIT_SUPPORTED:
>     This hidden option should be selected by any CPU type which supports
>     64-bit physical addresses.  This will enable the PHYS_64BIT option
>     to be selected.  It is (obviously) always set on PPC64.
> 
>   CONFIG_PHYS_64BIT_DT_REQUIRED:
>     This hidden option should be selected by any board or platform which
>     has >32-bit physical devices present in hardware.  If this is set
>     then the CONFIG_PHYS_64BIT option will be forcibly enabled and
>     hidden from the user.  It is (obviously) always set on PPC64.
> 
>   CONFIG_PHYS_64BIT:
>     This option is user-controllable, where allowed by CPU and platform
>     settings, and should never be pointed at with a "select" statement.
>     Due to the values of the above two options, this is never visible on
>     PPC64.

I'm with Kumar on this.  I don't see the point of making it so complicated.  No kernel should ever have to care with a DT is 64-bit or 32-bit.  If you build a kernel with 64-bit phys support, then it will work with any DT.

U-Boot already warns you if the DT and the actual physical addresses of the devices don't match.

There are only two reasons to create a 32-bit kernel:

1) A small performance improvement on systems with 2GB or less.
2) Some SOC devices only support 32-bit physical addresses, so the easiest way to ensure a compatible address is to prohibit memory above 4GB.

Item #2 is not something that we really worry about.  It's only a real problem on true 64-bit kernels, and in those cases, we cannot build a kernel with 32-bit phys support, so the driver needs to handle it internally.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

[Moffett, Kyle D]

On Nov 10, 2011, at 09:04, Timur Tabi wrote:
> Kyle Moffett wrote:
>>  CONFIG_PHYS_64BIT_SUPPORTED:
>>    This hidden option should be selected by any CPU type which supports
>>    64-bit physical addresses.  This will enable the PHYS_64BIT option
>>    to be selected.  It is (obviously) always set on PPC64.
>> 
>>  CONFIG_PHYS_64BIT_DT_REQUIRED:
>>    This hidden option should be selected by any board or platform which
>>    has >32-bit physical devices present in hardware.  If this is set
>>    then the CONFIG_PHYS_64BIT option will be forcibly enabled and
>>    hidden from the user.  It is (obviously) always set on PPC64.
>> 
>>  CONFIG_PHYS_64BIT:
>>    This option is user-controllable, where allowed by CPU and platform
>>    settings, and should never be pointed at with a "select" statement.
>>    Due to the values of the above two options, this is never visible on
>>    PPC64.
> 
> I'm with Kumar on this.  I don't see the point of making it so complicated.

Did you look at the existing code?  It's already that complicated:

config ARCH_PHYS_ADDR_T_64BIT
	def_bool PPC64 || PHYS_64BIT

config ARCH_DMA_ADDR_T_64BIT
	def_bool ARCH_PHYS_ADDR_T_64BIT

config {P1022_DS,P2041_RDB,P3041_DS,P3060_QDS,P4080_DS,P5020_DS}
	select PHYS_64BIT

config 44x
	select PHYS_64BIT

config PTE_64BIT
	bool
	depends on 44x || E500 || PPC_86xx
	default y if PHYS_64BIT

config PHYS_64BIT
	bool 'Large physical address support' if E500 || PPC_86xx
	depends on (44x || E500 || PPC_86xx) && !PPC_83xx && !PPC_82xx

Even worse, PHYS_64BIT is not set on 64-bit processors, but there is
a lot of driver code that seems to assume PHYS_64BIT indicates the
size of "phys_addr_t".

> No kernel should ever have to care with a DT is 64-bit or 32-bit.  If
> you build a kernel with 64-bit phys support, then it will work with
> any DT.
> 

> U-Boot already warns you if the DT and the actual physical addresses
> of the devices don't match.

The big issue is that the Kconfig docs are very clear that "select"
should not be used on user-visible options (AKA: PHYS_64BIT), and yet
half the PPC_85xx boards have this tidbit:
	select PHYS_64BIT # The DTS has 36-bit addresses

I'm totally OK with removing that from all those boards, but to preserve
the existing behavior (also used by the entire 44x platform) I added the
new config symbol PHYS_64BIT_DT_REQUIRED, which is used to control
whether or not the "PHYS_64BIT" option is even visible to the user.

I originally called it "PHYS_64BIT_REQUIRED", but since all of the
board comments talked about 36-bit DTS addresses, I added the _DT_.


> There are only two reasons to create a 32-bit kernel:
> 
> 1) A small performance improvement on systems with 2GB or less.
> 2) Some SOC devices only support 32-bit physical addresses, so the
> easiest way to ensure a compatible address is to prohibit memory above
> 4GB.

If this is true, then why does PHYS_64BIT have that big ugly list of
dependencies right now?  I don't know about the other platforms well
enough to tell what would break by enabling PHYS_64BIT, but I assume
that something in the past caused that dependency list.

Cheers,
Kyle Moffett

--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/

Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

[Timur Tabi]

Moffett, Kyle D wrote:

> Did you look at the existing code?  It's already that complicated:
> 
> config ARCH_PHYS_ADDR_T_64BIT
> 	def_bool PPC64 || PHYS_64BIT

I never understood why we have PHYS_64BIT and ARCH_PHYS_ADDR_T_64BIT, since they mean the same thing.  

> config ARCH_DMA_ADDR_T_64BIT
> 	def_bool ARCH_PHYS_ADDR_T_64BIT
> 
> config {P1022_DS,P2041_RDB,P3041_DS,P3060_QDS,P4080_DS,P5020_DS}
> 	select PHYS_64BIT

I posted a patch to remove the P1022_DS version of this.  I'm in favor of removing it from the other boards and letting the defconfig define it, but Kumar nak'd that idea.

> config PTE_64BIT
> 	bool
> 	depends on 44x || E500 || PPC_86xx
> 	default y if PHYS_64BIT

I think this one is about how our TLB registers look, and it's not related to anything else.

> Even worse, PHYS_64BIT is not set on 64-bit processors, but there is
> a lot of driver code that seems to assume PHYS_64BIT indicates the
> size of "phys_addr_t".

There's a Kconfig option somewhere that takes care of this.

> The big issue is that the Kconfig docs are very clear that "select"
> should not be used on user-visible options (AKA: PHYS_64BIT), and yet
> half the PPC_85xx boards have this tidbit:
> 	select PHYS_64BIT # The DTS has 36-bit addresses

I'm not sure that Kconfig rule is enforceable.  We use 'select' all the time to make sure that our boards enable the options that need to be enabled.  I'd rather see this:

config X
	select A

config Y
	select A

config Z
	select A

than this:

config A
	default y if X | Y | Z

The former is more maintainable and does not allow the option of disabling "A" if someone wants "X".

> I'm totally OK with removing that from all those boards, but to preserve
> the existing behavior (also used by the entire 44x platform) I added the
> new config symbol PHYS_64BIT_DT_REQUIRED, which is used to control
> whether or not the "PHYS_64BIT" option is even visible to the user.
> 
> I originally called it "PHYS_64BIT_REQUIRED", but since all of the
> board comments talked about 36-bit DTS addresses, I added the _DT_.

They're really 64-bit DTS addresses.  The 36 bit is just a hardware quirk of our SOCs.  From the kernel's perspective, there's no difference between 36-bit and 64-bit physical address.

>> There are only two reasons to create a 32-bit kernel:
>>
>> 1) A small performance improvement on systems with 2GB or less.
>> 2) Some SOC devices only support 32-bit physical addresses, so the
>> easiest way to ensure a compatible address is to prohibit memory above
>> 4GB.
> 
> If this is true, then why does PHYS_64BIT have that big ugly list of
> dependencies right now? 

Because Kumar doesn't want to allow 32-bit kernels on our high-end parts.  Like I said, I'm not a fan of that decision.

> I don't know about the other platforms well
> enough to tell what would break by enabling PHYS_64BIT, but I assume
> that something in the past caused that dependency list.

It's just an arbitrary decision.  We don't ship 32-bit DTs for the P4080-class parts, and we don't have a U-Boot configuration option for building a 32-bit compatible U-Boot.

-- 
Timur Tabi
Linux kernel developer at Freescale

Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

[Benjamin Herrenschmidt]

On Thu, 2011-11-10 at 10:50 -0600, Timur Tabi wrote:

> I'm not sure that Kconfig rule is enforceable.  We use 'select' all the time to make sure that our boards enable the options that need to be enabled.  I'd rather see this:
> 
> config X
> 	select A
> 
> config Y
> 	select A
> 
> config Z
> 	select A
> 
> than this:
> 
> config A
> 	default y if X | Y | Z
> 
> The former is more maintainable and does not allow the option of disabling "A" if someone wants "X".

This is fine as long as config A is not a user selectable option.

We do the wrong thing in a few places (i2c comes to mind) and we should
most certainly consider fixing it. Some of the solution is to move some
select's to defconfigs, some is to do things the way Kyle proposed.

For PHYS_64BIT, I'm not 100% certain at this point what the best
approach it. It should clearly be fixed and hidden for real 64-bit. As
for the rest, should it be user selectable ? I tend to think it should
be fixed & selected by the board config and keep it that way, avoiding
the user question entirely... but you may have good reasons to want to
keep it around.

Cheers,
Ben.

Re: [RFC PATCH 02/17] powerpc: Split up PHYS_64BIT config option to fix "select" issues

[Tabi Timur-B04825]

Benjamin Herrenschmidt wrote:

> For PHYS_64BIT, I'm not 100% certain at this point what the best
> approach it. It should clearly be fixed and hidden for real 64-bit. As
> for the rest, should it be user selectable ?

I have been unable to convince our BSP teams that the minor performance 
improvement of a 32-bit kernel vs 36-bit is not worth the hassle.  We ship 
a lot of lower-end e500 systems that will never have more than 2GB of memory.

The P1022DS is an example.  We ship 32-bit and 36-bit versions of U-Boot, 
the kernel, and the device tree.  I recently added code to U-boot to 
detect if you have a mismatched U-Boot and device tree, because it is so 
easy to mess that up.  I would like nothing more than to abandon 32-bit 
for all e500, but I don't see Freescale allowing that any time soon.

-- 
Timur Tabi
Linux kernel developer at Freescale

[RFC PATCH 03/17] fsl_rio: Remove FreeScale e500 conditionals

[Kyle Moffett]

The "CONFIG_E500" conditional should be unnecessary.  The fsl_rio
hardware is only present on MPC85xx (e500/e500mc) anyways, although it
should build everywhere for better compile-test coverage.

The conditionally-defined fsl_rio_mcheck_exception() function lost its
two e500-specific constants in commit 82a9a4809f:
  powerpc/e500: fix breakage with fsl_rio_mcheck_exception

Specifically, the references to SPRN_MCSR and MCSR_BUS_RBERR were moved
to an e500-specific file.

This patch just removes the unnecessary #ifdef, as the entire file is
effectively dead code on non-e500 platforms anyways.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/sysdev/fsl_rio.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/sysdev/fsl_rio.c b/arch/powerpc/sysdev/fsl_rio.c
index de170fd..783e25c 100644
--- a/arch/powerpc/sysdev/fsl_rio.c
+++ b/arch/powerpc/sysdev/fsl_rio.c
@@ -281,7 +281,6 @@ struct rio_priv {
 
 static void __iomem *rio_regs_win;
 
-#ifdef CONFIG_E500
 int fsl_rio_mcheck_exception(struct pt_regs *regs)
 {
 	const struct exception_table_entry *entry;
@@ -308,7 +307,6 @@ int fsl_rio_mcheck_exception(struct pt_regs *regs)
 	return 0;
 }
 EXPORT_SYMBOL_GPL(fsl_rio_mcheck_exception);
-#endif
 
 /**
  * fsl_rio_doorbell_send - Send a MPC85xx doorbell message
-- 
1.7.2.5

[RFC PATCH 04/17] powerpc: Allow multiple machine-check handlers

[Kyle Moffett]

Certain processor types are co-supportable, and their machine-check
handlers will be referenced if the entries in cputable.c are actually
generated, so allow more than one machine-check handler to be built in.

This fixes a bug where configuring FreeScale E5500 support (P5020DS)
into the kernel would break machine-check handling on PPC64 A2 systems
by using a bogus machine_check_generic() handler that does nothing.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/kernel/traps.c |   18 ++++++++----------
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 4e59082..e3113341 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -418,7 +418,8 @@ int machine_check_47x(struct pt_regs *regs)
 
 	return 0;
 }
-#elif defined(CONFIG_E500)
+#endif
+#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
 int machine_check_e500mc(struct pt_regs *regs)
 {
 	unsigned long mcsr = mfspr(SPRN_MCSR);
@@ -517,7 +518,8 @@ silent_out:
 	mtspr(SPRN_MCSR, mcsr);
 	return mfspr(SPRN_MCSR) == 0 && recoverable;
 }
-
+#endif
+#ifdef CONFIG_FSL_E500_V1_V2
 int machine_check_e500(struct pt_regs *regs)
 {
 	unsigned long reason = get_mc_reason(regs);
@@ -557,12 +559,8 @@ int machine_check_e500(struct pt_regs *regs)
 
 	return 0;
 }
-
-int machine_check_generic(struct pt_regs *regs)
-{
-	return 0;
-}
-#elif defined(CONFIG_E200)
+#endif
+#ifdef CONFIG_E200
 int machine_check_e200(struct pt_regs *regs)
 {
 	unsigned long reason = get_mc_reason(regs);
@@ -587,7 +585,8 @@ int machine_check_e200(struct pt_regs *regs)
 
 	return 0;
 }
-#else
+#endif
+
 int machine_check_generic(struct pt_regs *regs)
 {
 	unsigned long reason = get_mc_reason(regs);
@@ -623,7 +622,6 @@ int machine_check_generic(struct pt_regs *regs)
 	}
 	return 0;
 }
-#endif /* everything else */
 
 void machine_check_exception(struct pt_regs *regs)
 {
-- 
1.7.2.5

Re: [RFC PATCH 04/17] powerpc: Allow multiple machine-check handlers

[Kumar Gala]

On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:

> Certain processor types are co-supportable, and their machine-check
> handlers will be referenced if the entries in cputable.c are actually
> generated, so allow more than one machine-check handler to be built in.
> 
> This fixes a bug where configuring FreeScale E5500 support (P5020DS)
> into the kernel would break machine-check handling on PPC64 A2 systems
> by using a bogus machine_check_generic() handler that does nothing.
> 
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---
> arch/powerpc/kernel/traps.c |   18 ++++++++----------
> 1 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
> index 4e59082..e3113341 100644
> --- a/arch/powerpc/kernel/traps.c
> +++ b/arch/powerpc/kernel/traps.c
> @@ -418,7 +418,8 @@ int machine_check_47x(struct pt_regs *regs)
> 
> 	return 0;
> }
> -#elif defined(CONFIG_E500)
> +#endif
> +#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
> int machine_check_e500mc(struct pt_regs *regs)
> {
> 	unsigned long mcsr = mfspr(SPRN_MCSR);
> @@ -517,7 +518,8 @@ silent_out:
> 	mtspr(SPRN_MCSR, mcsr);
> 	return mfspr(SPRN_MCSR) == 0 && recoverable;
> }
> -
> +#endif
> +#ifdef CONFIG_FSL_E500_V1_V2

doesn't exist yet, so patch is wrong sequence order.

> int machine_check_e500(struct pt_regs *regs)
> {
> 	unsigned long reason = get_mc_reason(regs);
> @@ -557,12 +559,8 @@ int machine_check_e500(struct pt_regs *regs)
> 
> 	return 0;
> }
> -
> -int machine_check_generic(struct pt_regs *regs)
> -{
> -	return 0;
> -}
> -#elif defined(CONFIG_E200)
> +#endif
> +#ifdef CONFIG_E200
> int machine_check_e200(struct pt_regs *regs)
> {
> 	unsigned long reason = get_mc_reason(regs);
> @@ -587,7 +585,8 @@ int machine_check_e200(struct pt_regs *regs)
> 
> 	return 0;
> }
> -#else
> +#endif
> +
> int machine_check_generic(struct pt_regs *regs)
> {
> 	unsigned long reason = get_mc_reason(regs);
> @@ -623,7 +622,6 @@ int machine_check_generic(struct pt_regs *regs)
> 	}
> 	return 0;
> }
> -#endif /* everything else */
> 
> void machine_check_exception(struct pt_regs *regs)
> {
> -- 
> 1.7.2.5

Re: [RFC PATCH 04/17] powerpc: Allow multiple machine-check handlers

[Moffett, Kyle D]

On Nov 10, 2011, at 08:37, Kumar Gala wrote:
> On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
>> 
>> +#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
>> +#ifdef CONFIG_FSL_E500_V1_V2
> 
> doesn't exist yet, so patch is wrong sequence order.

Oops, d'oh.

You are completely correct, thanks for noticing!

I'll fix this for my next submission.

Cheers,
Kyle Moffett

[RFC PATCH 05/17] powerpc/e500: Remove unused "default e500" from CPU table

[Kyle Moffett]

As the 3 "e500" variants are generally incompatible with each other,
(32bit-spe, 32bit-classic-fpu, 64bit-classic-fpu), there is no such
thing as a "default e500" processor.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/kernel/cputable.c |   16 ----------------
 1 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index edae5bb..e35f4fb 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1992,22 +1992,6 @@ static struct cpu_spec __initdata cpu_specs[] = {
 		.machine_check		= machine_check_e500mc,
 		.platform		= "ppce5500",
 	},
-#ifdef CONFIG_PPC32
-	{	/* default match */
-		.pvr_mask		= 0x00000000,
-		.pvr_value		= 0x00000000,
-		.cpu_name		= "(generic E500 PPC)",
-		.cpu_features		= CPU_FTRS_E500,
-		.cpu_user_features	= COMMON_USER_BOOKE |
-			PPC_FEATURE_HAS_SPE_COMP |
-			PPC_FEATURE_HAS_EFP_SINGLE_COMP,
-		.mmu_features		= MMU_FTR_TYPE_FSL_E,
-		.icache_bsize		= 32,
-		.dcache_bsize		= 32,
-		.machine_check		= machine_check_e500,
-		.platform		= "powerpc",
-	}
-#endif /* CONFIG_PPC32 */
 #endif /* CONFIG_E500 */
 
 #ifdef CONFIG_PPC_A2
-- 
1.7.2.5

[RFC PATCH 06/17] powerpc/e500: Split FreeScale e500v1/v2 and e500mc config options

[Kyle Moffett]

Kernels built for e500 and e500mc are fundamentally incompatible with
each other due to different cacheline sizes, support for SPE
instructions, etc.

Unfortuantely, there is a lot of support code with a morass of config
options which mostly mean the same things (E500/E500MC/PPC_85xx/etc).

As preparation for fixing up all the support code, split the config
options into two separate parts.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/platforms/Kconfig.cputype |   34 +++++++++++++++++++++++--------
 1 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 0ab01b0..1108586 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -10,13 +10,15 @@ choice
 	prompt "Processor Type"
 	depends on PPC32
 	help
-	  There are five families of 32 bit PowerPC chips supported.
+	  There are six families of 32 bit PowerPC chips supported.
+
 	  The most common ones are the desktop and server CPUs (601, 603,
 	  604, 740, 750, 74xx) CPUs from Freescale and IBM, with their
 	  embedded 512x/52xx/82xx/83xx/86xx counterparts.
-	  The other embeeded parts, namely 4xx, 8xx, e200 (55xx) and e500
-	  (85xx) each form a family of their own that is not compatible
-	  with the others.
+
+	  The other embedded parts, namely 4xx, 8xx, e200, e500, and e500mc
+	  each form a family of their own that is not compatible with the
+	  others.
 
 	  If unsure, select 52xx/6xx/7xx/74xx/82xx/83xx/86xx.
 
@@ -24,10 +26,21 @@ config PPC_BOOK3S_32
 	bool "512x/52xx/6xx/7xx/74xx/82xx/83xx/86xx"
 	select PPC_FPU
 
-config PPC_85xx
-	bool "Freescale 85xx"
+config FSL_E200
+	bool "Freescale e200 (also known as MPC5xx/MPC55xx)"
+	select E200
+
+config FSL_E500_V1_V2
+	bool "Freescale e500v1/e500v2 (also known as MPC85xx)"
 	select PHYS_64BIT_SUPPORTED
 	select E500
+	select PPC_85xx
+
+config FSL_E500MC
+	bool "Freescale e500mc (also e5500 in 32-bit mode)"
+	select PHYS_64BIT_SUPPORTED
+	select E500
+	select PPC_85xx
 
 config PPC_8xx
 	bool "Freescale 8xx"
@@ -51,9 +64,6 @@ config 44x
 	select PHYS_64BIT_SUPPORTED
 	select PHYS_64BIT_DT_REQUIRED
 
-config E200
-	bool "Freescale e200"
-
 endchoice
 
 choice
@@ -131,6 +141,12 @@ config TUNE_CELL
 config 8xx
 	bool
 
+config E200
+	bool
+
+config PPC_85xx
+	bool
+
 config E500
 	select FSL_EMB_PERFMON
 	select PPC_FSL_BOOK3E
-- 
1.7.2.5

[RFC PATCH 07/17] powerpc/e200: Rename CONFIG_E200 => CONFIG_FSL_E200

[Kyle Moffett]

Match the config symbols for FreeScale e500/e5500 chips by using "FSL"
in the name of the config symbol.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/Kconfig                   |    2 +-
 arch/powerpc/Makefile                  |    2 +-
 arch/powerpc/include/asm/cputable.h    |    2 +-
 arch/powerpc/include/asm/reg.h         |    2 +-
 arch/powerpc/include/asm/reg_booke.h   |    2 +-
 arch/powerpc/kernel/cputable.c         |    4 ++--
 arch/powerpc/kernel/head_fsl_booke.S   |   10 +++++-----
 arch/powerpc/kernel/traps.c            |    2 +-
 arch/powerpc/platforms/Kconfig.cputype |   12 ++++--------
 9 files changed, 17 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 27e31c5..e3412a1 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -288,7 +288,7 @@ config HUGETLB_PAGE_SIZE_VARIABLE
 
 config MATH_EMULATION
 	bool "Math emulation"
-	depends on 4xx || 8xx || E200 || PPC_MPC832x || E500
+	depends on 4xx || 8xx || FSL_E200 || PPC_MPC832x || E500
 	---help---
 	  Some PowerPC chips designed for embedded applications do not have
 	  a floating-point unit and therefore do not implement the
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 57af16e..c17bc29 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -134,7 +134,7 @@ cpu-as-$(CONFIG_4xx)		+= -Wa,-m405
 cpu-as-$(CONFIG_6xx)		+= -Wa,-maltivec
 cpu-as-$(CONFIG_POWER4)		+= -Wa,-maltivec
 cpu-as-$(CONFIG_E500)		+= -Wa,-me500
-cpu-as-$(CONFIG_E200)		+= -Wa,-me200
+cpu-as-$(CONFIG_FSL_E200)	+= -Wa,-me200
 
 KBUILD_AFLAGS += $(cpu-as-y)
 KBUILD_CFLAGS += $(cpu-as-y)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index e30442c..b69f255 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -522,7 +522,7 @@ enum {
 #ifdef CONFIG_44x
 	    CPU_FTRS_44X & CPU_FTRS_440x6 &
 #endif
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
 	    CPU_FTRS_E200 &
 #endif
 #ifdef CONFIG_E500
diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index 559da19..f5b4f457 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -893,7 +893,7 @@
 #define SPRN_SPRG_WSCRATCH_MC	SPRN_SPRG1
 #define SPRN_SPRG_RSCRATCH4	SPRN_SPRG7R
 #define SPRN_SPRG_WSCRATCH4	SPRN_SPRG7W
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
 #define SPRN_SPRG_RSCRATCH_DBG	SPRN_SPRG6R
 #define SPRN_SPRG_WSCRATCH_DBG	SPRN_SPRG6W
 #else
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 28cdbd9..81cd987 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -237,7 +237,7 @@
 #define MCSR_BSL2_ERR	0x00000001UL /* Backside L2 cache error */
 #endif
 
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
 #define MCSR_MCP 	0x80000000UL /* Machine Check Input Pin */
 #define MCSR_CP_PERR 	0x20000000UL /* Cache Push Parity Error */
 #define MCSR_CPERR 	0x10000000UL /* Cache Parity Error */
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e35f4fb..e5b142c 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1871,7 +1871,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
 		.platform		= "ppc440",
 	}
 #endif /* CONFIG_44x */
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
 	{	/* e200z5 */
 		.pvr_mask		= 0xfff00000,
 		.pvr_value		= 0x81000000,
@@ -1915,7 +1915,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
 		.machine_check		= machine_check_e200,
 		.platform		= "ppc5554",
 	}
-#endif /* CONFIG_E200 */
+#endif /* CONFIG_FSL_E200 */
 #endif /* CONFIG_PPC32 */
 #ifdef CONFIG_E500
 #ifdef CONFIG_PPC32
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 9f5d210..134b2b8 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -137,7 +137,7 @@ _ENTRY(__early_start)
 
 	/* Setup the defaults for TLB entries */
 	li	r2,(MAS4_TSIZED(BOOK3E_PAGESZ_4K))@l
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
 	oris	r2,r2,MAS4_TLBSELD(1)@h
 #endif
 	mtspr	SPRN_MAS4, r2
@@ -304,7 +304,7 @@ interrupt_base:
 	CRITICAL_EXCEPTION(0x0100, CriticalInput, unknown_exception)
 
 	/* Machine Check Interrupt */
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
 	/* no RFMCI, MCSRRs on E200 */
 	CRITICAL_EXCEPTION(0x0200, MachineCheck, machine_check_exception)
 #else
@@ -340,7 +340,7 @@ interrupt_base:
 #ifdef CONFIG_PPC_FPU
 	FP_UNAVAILABLE_EXCEPTION
 #else
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
 	/* E200 treats 'normal' floating point instructions as FP Unavail exception */
 	EXCEPTION(0x0800, FloatingPointUnavailable, program_check_exception, EXC_XFER_EE)
 #else
@@ -694,7 +694,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
 #endif
 3:	mtspr	SPRN_MAS2, r12
 
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
 	/* Round robin TLB1 entries assignment */
 	mfspr	r12, SPRN_MAS0
 
@@ -717,7 +717,7 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_BIG_PHYS)
 	rlwimi	r12, r13, 0, 20, 31
 7:
 	mtspr	SPRN_MAS0,r12
-#endif /* CONFIG_E200 */
+#endif /* CONFIG_FSL_E200 */
 
 tlb_write_entry:
 	tlbwe
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index e3113341..81b6afd 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -560,7 +560,7 @@ int machine_check_e500(struct pt_regs *regs)
 	return 0;
 }
 #endif
-#ifdef CONFIG_E200
+#ifdef CONFIG_FSL_E200
 int machine_check_e200(struct pt_regs *regs)
 {
 	unsigned long reason = get_mc_reason(regs);
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 1108586..9770564 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -28,7 +28,6 @@ config PPC_BOOK3S_32
 
 config FSL_E200
 	bool "Freescale e200 (also known as MPC5xx/MPC55xx)"
-	select E200
 
 config FSL_E500_V1_V2
 	bool "Freescale e500v1/e500v2 (also known as MPC85xx)"
@@ -141,9 +140,6 @@ config TUNE_CELL
 config 8xx
 	bool
 
-config E200
-	bool
-
 config PPC_85xx
 	bool
 
@@ -186,12 +182,12 @@ config 4xx
 
 config BOOKE
 	bool
-	depends on E200 || E500 || 44x || PPC_BOOK3E
+	depends on FSL_E200 || E500 || 44x || PPC_BOOK3E
 	default y
 
 config FSL_BOOKE
 	bool
-	depends on (E200 || E500) && PPC32
+	depends on FSL_E200 || (E500 && PPC32)
 	select SYS_SUPPORTS_HUGETLBFS if PHYS_64BIT
 	default y
 
@@ -284,7 +280,7 @@ config PPC_ICSWX
 
 config SPE
 	bool "SPE Support"
-	depends on E200 || (E500 && !PPC_E500MC)
+	depends on FSL_E200 || (E500 && !PPC_E500MC)
 	default y
 	---help---
 	  This option enables kernel support for the Signal Processing
@@ -375,7 +371,7 @@ config NR_CPUS
 
 config NOT_COHERENT_CACHE
 	bool
-	depends on 4xx || 8xx || E200 || PPC_MPC512x || GAMECUBE_COMMON
+	depends on 4xx || 8xx || FSL_E200 || PPC_MPC512x || GAMECUBE_COMMON
 	default n if PPC_47x
 	default y
 
-- 
1.7.2.5

[RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

[Kyle Moffett]

As FreeScale e500 systems have different cacheline sizes from e500mc, it
is basically impossible for the kernel to support both in a single
system image at present.

Given that one is SPE-float and the other is classic-float, they are not
generally userspace-compatible either.

This patch updates the conditional to depend on whether the system is
actually targetting an "e500" or "e500mc" core and entirely removes the
unused sync-to-lwsync-replacement on e500v1/e500v2 systems.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/include/asm/synch.h |   16 ++++------------
 1 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/include/asm/synch.h b/arch/powerpc/include/asm/synch.h
index d7cab44..3d518b6 100644
--- a/arch/powerpc/include/asm/synch.h
+++ b/arch/powerpc/include/asm/synch.h
@@ -5,8 +5,11 @@
 #include <linux/stringify.h>
 #include <asm/feature-fixups.h>
 
-#if defined(__powerpc64__) || defined(CONFIG_PPC_E500MC)
+#if defined(__powerpc64__) || defined(CONFIG_FSL_E500MC)
 #define __SUBARCH_HAS_LWSYNC
+#define LWSYNC lwsync
+#else
+#define LWSYNC sync
 #endif
 
 #ifndef __ASSEMBLY__
@@ -25,17 +28,6 @@ static inline void isync(void)
 }
 #endif /* __ASSEMBLY__ */
 
-#if defined(__powerpc64__)
-#    define LWSYNC	lwsync
-#elif defined(CONFIG_E500)
-#    define LWSYNC					\
-	START_LWSYNC_SECTION(96);			\
-	sync;						\
-	MAKE_LWSYNC_SECTION_ENTRY(96, __lwsync_fixup);
-#else
-#    define LWSYNC	sync
-#endif
-
 #ifdef CONFIG_SMP
 #define __PPC_ACQUIRE_BARRIER				\
 	START_LWSYNC_SECTION(97);			\
-- 
1.7.2.5

Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

[Kumar Gala]

On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:

> As FreeScale e500 systems have different cacheline sizes from e500mc, it
> is basically impossible for the kernel to support both in a single
> system image at present.
> 
> Given that one is SPE-float and the other is classic-float, they are not
> generally userspace-compatible either.
> 
> This patch updates the conditional to depend on whether the system is
> actually targetting an "e500" or "e500mc" core and entirely removes the
> unused sync-to-lwsync-replacement on e500v1/e500v2 systems.
> 
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---
> arch/powerpc/include/asm/synch.h |   16 ++++------------
> 1 files changed, 4 insertions(+), 12 deletions(-)

Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.  I see no reason to change the support we have there.

- k

Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

[Scott Wood]

On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
> 
> On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
> 
> > As FreeScale e500 systems have different cacheline sizes from e500mc, it
> > is basically impossible for the kernel to support both in a single
> > system image at present.
> > 
> > Given that one is SPE-float and the other is classic-float, they are not
> > generally userspace-compatible either.
> > 
> > This patch updates the conditional to depend on whether the system is
> > actually targetting an "e500" or "e500mc" core and entirely removes the
> > unused sync-to-lwsync-replacement on e500v1/e500v2 systems.
> > 
> > Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> > ---
> > arch/powerpc/include/asm/synch.h |   16 ++++------------
> > 1 files changed, 4 insertions(+), 12 deletions(-)
> 
> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.  I see no reason to change the support we have there.

What "mode" do you mean?  DCBZ32?  We don't support using that currently,
and I'd imagine the performance implication would be such that you'd
never want to do it unless it's the only way to make some piece of legacy
software work.

>  I see no reason to change the support we have there.

No reason to remove complexity that is not needed, and is not planned to
be needed?

-Scott

Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

[Kumar Gala]

On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:

> On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
>> 
>> On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:
>> 
>>> As FreeScale e500 systems have different cacheline sizes from e500mc, it
>>> is basically impossible for the kernel to support both in a single
>>> system image at present.
>>> 
>>> Given that one is SPE-float and the other is classic-float, they are not
>>> generally userspace-compatible either.
>>> 
>>> This patch updates the conditional to depend on whether the system is
>>> actually targetting an "e500" or "e500mc" core and entirely removes the
>>> unused sync-to-lwsync-replacement on e500v1/e500v2 systems.
>>> 
>>> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
>>> ---
>>> arch/powerpc/include/asm/synch.h |   16 ++++------------
>>> 1 files changed, 4 insertions(+), 12 deletions(-)
>> 
>> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.  I see no reason to change the support we have there.
> 
> What "mode" do you mean?  DCBZ32?  We don't support using that currently,
> and I'd imagine the performance implication would be such that you'd
> never want to do it unless it's the only way to make some piece of legacy
> software work.

Correct, DCBZ32, we've had customers that go down this path.

>> I see no reason to change the support we have there.
> 
> No reason to remove complexity that is not needed, and is not planned to
> be needed?


I'd rather wait for at least 2 years for e500mc devices to have further deployment before we'd remove this.

- k

Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

[Scott Wood]

On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
> 
> On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
> 
> > On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
> >> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.  I see no reason to change the support we have there.
> > 
> > What "mode" do you mean?  DCBZ32?  We don't support using that currently,
> > and I'd imagine the performance implication would be such that you'd
> > never want to do it unless it's the only way to make some piece of legacy
> > software work.
> 
> Correct, DCBZ32, we've had customers that go down this path.

For running legacy software, or for multiplatform Linux kernels?

And if you're willing to toss performance away for this goal, why do you
need lwsync? :-)

DCBZ32 is not a "mode that is compatible with v1/v2", BTW.  It only
affects cache block size (for dcbz/dcba only), not SPE versus FP, not
changes in power management, not changes in machine check handling, etc.

Using DCBZ32 for the kernel would also complicate switching the kernel to
dcbzl, to support enabling DCBZ32 for certain userspace apps (a more
likely use case) without making it systemwide.

-Scott

Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

[Moffett, Kyle D]

On Nov 10, 2011, at 12:03, Scott Wood wrote:
> On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
>> 
>> On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
>> 
>>> On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
>>>> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.
>>>> I see no reason to change the support we have there.
>>> 
>>> What "mode" do you mean?  DCBZ32?  We don't support using that currently,
>>> and I'd imagine the performance implication would be such that you'd
>>> never want to do it unless it's the only way to make some piece of legacy
>>> software work.
>> 
>> Correct, DCBZ32, we've had customers that go down this path.
> 
> For running legacy software, or for multiplatform Linux kernels?
> 
> And if you're willing to toss performance away for this goal, why do you
> need lwsync? :-)
> 
> DCBZ32 is not a "mode that is compatible with v1/v2", BTW.  It only
> affects cache block size (for dcbz/dcba only), not SPE versus FP, not
> changes in power management, not changes in machine check handling, etc.
> 
> Using DCBZ32 for the kernel would also complicate switching the kernel to
> dcbzl, to support enabling DCBZ32 for certain userspace apps (a more
> likely use case) without making it systemwide.

So, as far as I can tell the kernel doesn't even try to touch DCBZ32.

Even if it did, if you are building a new kernel that includes this patch,
surely you can actually build a proper e500mc kernel instead of trying to
build a new kernel to run on hardware it wasn't designed to run on, right?

I think the bigger issue is the fact that building a PPC_BOOK3E_64 kernel
with both e5500 and PowerPC A2 support turned on will not actually run on
both.  Before my v1-patch-series, machine-check handling is messed up for
PowerPC A2, and afterwards cacheline sizes are messed up for e5500.

Does this mean that PPC_BOOK3E_64 needs to be split into two separate
Book 3-III families the same way that 32-bit has been split?  Is there
another way around it?

Cheers,
Kyle Moffett

Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

[Kumar Gala]

On Nov 10, 2011, at 2:27 PM, Moffett, Kyle D wrote:

> On Nov 10, 2011, at 12:03, Scott Wood wrote:
>> On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:
>>> 
>>> On Nov 10, 2011, at 10:31 AM, Scott Wood wrote:
>>> 
>>>> On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:
>>>>> Nak, we can run an e500mc in a mode that is compatible with e500v1/v2.
>>>>> I see no reason to change the support we have there.
>>>> 
>>>> What "mode" do you mean?  DCBZ32?  We don't support using that currently,
>>>> and I'd imagine the performance implication would be such that you'd
>>>> never want to do it unless it's the only way to make some piece of legacy
>>>> software work.
>>> 
>>> Correct, DCBZ32, we've had customers that go down this path.
>> 
>> For running legacy software, or for multiplatform Linux kernels?
>> 
>> And if you're willing to toss performance away for this goal, why do you
>> need lwsync? :-)
>> 
>> DCBZ32 is not a "mode that is compatible with v1/v2", BTW.  It only
>> affects cache block size (for dcbz/dcba only), not SPE versus FP, not
>> changes in power management, not changes in machine check handling, etc.
>> 
>> Using DCBZ32 for the kernel would also complicate switching the kernel to
>> dcbzl, to support enabling DCBZ32 for certain userspace apps (a more
>> likely use case) without making it systemwide.
> 
> So, as far as I can tell the kernel doesn't even try to touch DCBZ32.

Correct, it was my thinking I'd get there an add this one day, that day never came.

> Even if it did, if you are building a new kernel that includes this patch,
> surely you can actually build a proper e500mc kernel instead of trying to
> build a new kernel to run on hardware it wasn't designed to run on, right?
> 
> I think the bigger issue is the fact that building a PPC_BOOK3E_64 kernel
> with both e5500 and PowerPC A2 support turned on will not actually run on
> both.  Before my v1-patch-series, machine-check handling is messed up for
> PowerPC A2, and afterwards cacheline sizes are messed up for e5500.

That might be, but who is asking or wanting to run a BOOK3E_64 kernel on both.  I'm guessing there are a number of issues with this.

> Does this mean that PPC_BOOK3E_64 needs to be split into two separate
> Book 3-III families the same way that 32-bit has been split?  Is there
> another way around it?

No idea, we have to ask Ben how much he cares.  I don't see any FSL customers pushing us to run the same kernel on A2 and P5020 (or future FSL devices).

- k

Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

[Benjamin Herrenschmidt]

On Thu, 2011-11-10 at 14:34 -0600, Kumar Gala wrote:

> No idea, we have to ask Ben how much he cares.  I don't see any FSL
> customers pushing us to run the same kernel on A2 and P5020 (or future
> FSL devices).

I do care. For example, imagine somebody wanting to support an
enterprise distro on both BG/Q and some FSL based HW ...

Besides, this has generally forced us to do things more cleanly and I
don't want to go back into #ifdef land. These cores are both arch 2.06 E
compilant, there is no good reason to prevent or forbid having them
build into a single binary image.

Look at the mess ARM got into and the pain they are having getting out
of with that stuff ... No way I'm going backward with split configs. If
anything, I'd like to reconcile things even more.

Cheers,
Ben.

Re: [RFC PATCH 08/17] powerpc/e500: Remove conditional "lwsync" substitution

[Benjamin Herrenschmidt]

On Thu, 2011-11-10 at 14:27 -0600, Moffett, Kyle D wrote:
> 
> Does this mean that PPC_BOOK3E_64 needs to be split into two separate
> Book 3-III families the same way that 32-bit has been split?  Is there
> another way around it? 

No, I don't want more split, on the contrary.

Cheers,
Ben.

[RFC PATCH 09/17] powerpc/e500: Split idle handlers for e500v1/v2 and e500mc

[Kyle Moffett]

These are totally different (more so in fact than 6xx vs. e500v1/v2), so
there isn't really a good reason to keep them in the same file.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/include/asm/machdep.h      |    1 +
 arch/powerpc/kernel/Makefile            |    3 +-
 arch/powerpc/kernel/idle_e500.S         |   12 -------
 arch/powerpc/kernel/idle_e500mc.S       |   56 +++++++++++++++++++++++++++++++
 arch/powerpc/kernel/setup_32.c          |    2 +-
 arch/powerpc/platforms/85xx/p2041_rdb.c |    2 +-
 arch/powerpc/platforms/85xx/p3041_ds.c  |    2 +-
 arch/powerpc/platforms/85xx/p3060_qds.c |    2 +-
 arch/powerpc/platforms/85xx/p4080_ds.c  |    2 +-
 arch/powerpc/platforms/85xx/p5020_ds.c  |    2 +-
 10 files changed, 65 insertions(+), 19 deletions(-)
 create mode 100644 arch/powerpc/kernel/idle_e500mc.S

diff --git a/arch/powerpc/include/asm/machdep.h b/arch/powerpc/include/asm/machdep.h
index b540d6f..995a2ec 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -253,6 +253,7 @@ struct machdep_calls {
 };
 
 extern void e500_idle(void);
+extern void e500mc_idle(void);
 extern void power4_idle(void);
 extern void power7_idle(void);
 extern void ppc6xx_idle(void);
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index ce4f7f1..8627dda 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -61,7 +61,8 @@ obj-$(CONFIG_IBMEBUS)           += ibmebus.o
 obj-$(CONFIG_GENERIC_TBSYNC)	+= smp-tbsync.o
 obj-$(CONFIG_CRASH_DUMP)	+= crash_dump.o
 ifeq ($(CONFIG_PPC32),y)
-obj-$(CONFIG_E500)		+= idle_e500.o
+obj-$(CONFIG_FSL_E500_V1_V2)	+= idle_e500.o
+obj-$(CONFIG_FSL_E500MC)	+= idle_e500mc.o
 endif
 obj-$(CONFIG_6xx)		+= idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
 obj-$(CONFIG_TAU)		+= tau_6xx.o
diff --git a/arch/powerpc/kernel/idle_e500.S b/arch/powerpc/kernel/idle_e500.S
index 4f0ab85..47a1a98 100644
--- a/arch/powerpc/kernel/idle_e500.S
+++ b/arch/powerpc/kernel/idle_e500.S
@@ -26,17 +26,6 @@ _GLOBAL(e500_idle)
 	ori	r4,r4,_TLF_NAPPING	/* so when we take an exception */
 	stw	r4,TI_LOCAL_FLAGS(r3)	/* it will return to our caller */
 
-#ifdef CONFIG_PPC_E500MC
-	wrteei	1
-1:	wait
-
-	/*
-	 * Guard against spurious wakeups (e.g. from a hypervisor) --
-	 * any real interrupt will cause us to return to LR due to
-	 * _TLF_NAPPING.
-	 */
-	b	1b
-#else
 	/* Check if we can nap or doze, put HID0 mask in r3 */
 	lis	r3,0
 BEGIN_FTR_SECTION
@@ -83,7 +72,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_L2CSR|CPU_FTR_CAN_NAP)
 	mtmsr	r7
 	isync
 2:	b	2b
-#endif /* !E500MC */
 
 /*
  * Return from NAP/DOZE mode, restore some CPU specific registers,
diff --git a/arch/powerpc/kernel/idle_e500mc.S b/arch/powerpc/kernel/idle_e500mc.S
new file mode 100644
index 0000000..4806942
--- /dev/null
+++ b/arch/powerpc/kernel/idle_e500mc.S
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2008 Freescale Semiconductor, Inc. All rights reserved.
+ * Dave Liu <daveliu@freescale.com>
+ * copy from idle_6xx.S and modify for e500 based processor,
+ * implement the power_save function in idle.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include <linux/threads.h>
+#include <asm/reg.h>
+#include <asm/page.h>
+#include <asm/cputable.h>
+#include <asm/thread_info.h>
+#include <asm/ppc_asm.h>
+#include <asm/asm-offsets.h>
+
+	.text
+
+_GLOBAL(e500mc_idle)
+	rlwinm	r3,r1,0,0,31-THREAD_SHIFT	/* current thread_info */
+	lwz	r4,TI_LOCAL_FLAGS(r3)	/* set napping bit */
+	ori	r4,r4,_TLF_NAPPING	/* so when we take an exception */
+	stw	r4,TI_LOCAL_FLAGS(r3)	/* it will return to our caller */
+	wrteei	1
+1:	wait
+
+	/*
+	 * Guard against spurious wakeups (e.g. from a hypervisor) --
+	 * any real interrupt will cause us to return to LR due to
+	 * _TLF_NAPPING.
+	 */
+	b	1b
+
+/*
+ * Return from NAP/DOZE mode, restore some CPU specific registers,
+ * r2 containing physical address of current.
+ * r11 points to the exception frame (physical address).
+ * We have to preserve r10.
+ */
+_GLOBAL(power_save_ppc32_restore)
+	lwz	r9,_LINK(r11)		/* interrupted in e500mc_idle */
+	stw	r9,_NIP(r11)		/* make it do a blr */
+
+#ifdef CONFIG_SMP
+	rlwinm	r12,r1,0,0,31-THREAD_SHIFT
+	lwz	r11,TI_CPU(r12)		/* get cpu number * 4 */
+	slwi	r11,r11,2
+#else
+	li	r11,0
+#endif
+
+	b	transfer_to_handler_cont
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index c1ce863..b14aabd 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -139,7 +139,7 @@ notrace void __init machine_init(u64 dt_ptr)
 		ppc_md.power_save = ppc6xx_idle;
 #endif
 
-#ifdef CONFIG_E500
+#ifdef CONFIG_FSL_E500_V1_V2
 	if (cpu_has_feature(CPU_FTR_CAN_DOZE) ||
 	    cpu_has_feature(CPU_FTR_CAN_NAP))
 		ppc_md.power_save = e500_idle;
diff --git a/arch/powerpc/platforms/85xx/p2041_rdb.c b/arch/powerpc/platforms/85xx/p2041_rdb.c
index eda6ed5..43ca79d 100644
--- a/arch/powerpc/platforms/85xx/p2041_rdb.c
+++ b/arch/powerpc/platforms/85xx/p2041_rdb.c
@@ -78,7 +78,7 @@ define_machine(p2041_rdb) {
 	.restart		= fsl_rstcr_restart,
 	.calibrate_decr		= generic_calibrate_decr,
 	.progress		= udbg_progress,
-	.power_save		= e500_idle,
+	.power_save		= e500mc_idle,
 };
 
 machine_device_initcall(p2041_rdb, corenet_ds_publish_devices);
diff --git a/arch/powerpc/platforms/85xx/p3041_ds.c b/arch/powerpc/platforms/85xx/p3041_ds.c
index 96d99a3..4abf6ef 100644
--- a/arch/powerpc/platforms/85xx/p3041_ds.c
+++ b/arch/powerpc/platforms/85xx/p3041_ds.c
@@ -80,7 +80,7 @@ define_machine(p3041_ds) {
 	.restart		= fsl_rstcr_restart,
 	.calibrate_decr		= generic_calibrate_decr,
 	.progress		= udbg_progress,
-	.power_save		= e500_idle,
+	.power_save		= e500mc_idle,
 };
 
 machine_device_initcall(p3041_ds, corenet_ds_publish_devices);
diff --git a/arch/powerpc/platforms/85xx/p3060_qds.c b/arch/powerpc/platforms/85xx/p3060_qds.c
index 01dcf44..6f66776 100644
--- a/arch/powerpc/platforms/85xx/p3060_qds.c
+++ b/arch/powerpc/platforms/85xx/p3060_qds.c
@@ -67,7 +67,7 @@ define_machine(p3060_qds) {
 	.restart		= fsl_rstcr_restart,
 	.calibrate_decr		= generic_calibrate_decr,
 	.progress		= udbg_progress,
-	.power_save		= e500_idle,
+	.power_save		= e500mc_idle,
 };
 
 machine_device_initcall(p3060_qds, declare_of_platform_devices);
diff --git a/arch/powerpc/platforms/85xx/p4080_ds.c b/arch/powerpc/platforms/85xx/p4080_ds.c
index d1b21d7..3589961 100644
--- a/arch/powerpc/platforms/85xx/p4080_ds.c
+++ b/arch/powerpc/platforms/85xx/p4080_ds.c
@@ -79,7 +79,7 @@ define_machine(p4080_ds) {
 	.restart		= fsl_rstcr_restart,
 	.calibrate_decr		= generic_calibrate_decr,
 	.progress		= udbg_progress,
-	.power_save		= e500_idle,
+	.power_save		= e500mc_idle,
 };
 
 machine_device_initcall(p4080_ds, corenet_ds_publish_devices);
diff --git a/arch/powerpc/platforms/85xx/p5020_ds.c b/arch/powerpc/platforms/85xx/p5020_ds.c
index e8cba50..2e38748 100644
--- a/arch/powerpc/platforms/85xx/p5020_ds.c
+++ b/arch/powerpc/platforms/85xx/p5020_ds.c
@@ -88,7 +88,7 @@ define_machine(p5020_ds) {
 #ifdef CONFIG_PPC64
 	.power_save		= book3e_idle,
 #else
-	.power_save		= e500_idle,
+	.power_save		= e500mc_idle,
 #endif
 };
 
-- 
1.7.2.5

[RFC PATCH 10/17] powerpc/e500: Fix up the last references to CONFIG_PPC_E500MC

[Kyle Moffett]

This moves the "select PPC_FPU" from PPC_E500MC to the new FSL_E500MC
processor selection, where it belongs.

The only actual difference that this patch introduces is the P5020DS
board (FreeScale e5500 CPU) will not set FSL_E500MC when building in
64-bit mode.

This is OK as all of the existing code that the 64-bit P5020DS needs is
still conditional on CONFIG_E500 or CONFIG_PPC_FPU, which are both set
properly on the P5020DS (PPC_FPU is always enabled on 64-bit).

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/include/asm/cache.h       |    2 +-
 arch/powerpc/platforms/85xx/Kconfig    |   10 +++++-----
 arch/powerpc/platforms/Kconfig.cputype |    8 ++------
 3 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index 4b50941..10988a2 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -8,7 +8,7 @@
 #if defined(CONFIG_8xx) || defined(CONFIG_403GCX)
 #define L1_CACHE_SHIFT		4
 #define MAX_COPY_PREFETCH	1
-#elif defined(CONFIG_PPC_E500MC)
+#elif defined(CONFIG_FSL_E500MC)
 #define L1_CACHE_SHIFT		6
 #define MAX_COPY_PREFETCH	4
 #elif defined(CONFIG_PPC32)
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 37f9de7..248f87c 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -173,8 +173,8 @@ config SBC8560
 
 config P2041_RDB
 	bool "Freescale P2041 RDB"
+	depends on FSL_E500MC
 	select DEFAULT_UIMAGE
-	select PPC_E500MC
 	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
@@ -187,8 +187,8 @@ config P2041_RDB
 
 config P3041_DS
 	bool "Freescale P3041 DS"
+	depends on FSL_E500MC
 	select DEFAULT_UIMAGE
-	select PPC_E500MC
 	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
@@ -201,8 +201,8 @@ config P3041_DS
 
 config P3060_QDS
 	bool "Freescale P3060 QDS"
+	depends on FSL_E500MC
 	select DEFAULT_UIMAGE
-	select PPC_E500MC
 	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select MPC8xxx_GPIO
@@ -214,8 +214,8 @@ config P3060_QDS
 
 config P4080_DS
 	bool "Freescale P4080 DS"
+	depends on FSL_E500MC
 	select DEFAULT_UIMAGE
-	select PPC_E500MC
 	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
@@ -230,9 +230,9 @@ endif # PPC32
 
 config P5020_DS
 	bool "Freescale P5020 DS"
+	depends on FSL_E500MC || PPC_BOOK3E_64
 	select DEFAULT_UIMAGE
 	select E500
-	select PPC_E500MC
 	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 9770564..fd37bb2 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -38,6 +38,7 @@ config FSL_E500_V1_V2
 config FSL_E500MC
 	bool "Freescale e500mc (also e5500 in 32-bit mode)"
 	select PHYS_64BIT_SUPPORTED
+	select PPC_FPU
 	select E500
 	select PPC_85xx
 
@@ -148,11 +149,6 @@ config E500
 	select PPC_FSL_BOOK3E
 	bool
 
-config PPC_E500MC
-	bool "e500mc Support"
-	select PPC_FPU
-	depends on E500
-
 config PPC_FPU
 	bool
 	default y if PPC64
@@ -280,7 +276,7 @@ config PPC_ICSWX
 
 config SPE
 	bool "SPE Support"
-	depends on FSL_E200 || (E500 && !PPC_E500MC)
+	depends on FSL_E200 || FSL_E500_V1_V2
 	default y
 	---help---
 	  This option enables kernel support for the Signal Processing
-- 
1.7.2.5

[RFC PATCH 11/17] powerpc/e500: Use the correct assembler flags for e500mc and e5500

[Kyle Moffett]

The "-me500" assembler option is intended only for use on e500v1 or
e500v2 systems.  On modern binutils it will refuse to assemble standard
floating point opcodes, and it will translate "lwsync" into "sync".

This fixes the e500mc/e5500 kernel build on recent binutils.

For e500mc/e5500 with standard PowerPC floating point, the assembler
options "-me500mc" or "-me500mc64" should be used, although they are not
strictly necessary depending on which opcodes are in use.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/Makefile |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index c17bc29..bd443ee2 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -133,7 +133,8 @@ endif
 cpu-as-$(CONFIG_4xx)		+= -Wa,-m405
 cpu-as-$(CONFIG_6xx)		+= -Wa,-maltivec
 cpu-as-$(CONFIG_POWER4)		+= -Wa,-maltivec
-cpu-as-$(CONFIG_E500)		+= -Wa,-me500
+cpu-as-$(CONFIG_FSL_E500_V1_V2)	+= -Wa,-me500
+cpu-as-$(CONFIG_FSL_E500MC)	+= -Wa,-me500mc
 cpu-as-$(CONFIG_FSL_E200)	+= -Wa,-me200
 
 KBUILD_AFLAGS += $(cpu-as-y)
-- 
1.7.2.5

[RFC PATCH 12/17] powerpc/e500: Separate e500mc CPU table entries from e500v1/e500v2

[Kyle Moffett]

The e500mc CPUs have a classic FPU and are not compatible with e500v1 or
e500v2.  This patch fixes the 32-bit CPU feature tables so that e500mc
entries are not present on e500v1/e500v2 systems and vice versa.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/include/asm/cputable.h |   16 ++++++++++------
 arch/powerpc/kernel/cputable.c      |    8 +++++---
 2 files changed, 15 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index b69f255..c7c2582 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -480,9 +480,11 @@ enum {
 #ifdef CONFIG_E200
 	    CPU_FTRS_E200 |
 #endif
-#ifdef CONFIG_E500
-	    CPU_FTRS_E500 | CPU_FTRS_E500_2 | CPU_FTRS_E500MC |
-	    CPU_FTRS_E5500 |
+#ifdef CONFIG_FSL_E500_V1_V2
+	    CPU_FTRS_E500 | CPU_FTRS_E500_2 |
+#endif
+#ifdef CONFIG_FSL_E500MC
+	    CPU_FTRS_E500MC | CPU_FTRS_E5500 |
 #endif
 	    0,
 };
@@ -525,9 +527,11 @@ enum {
 #ifdef CONFIG_FSL_E200
 	    CPU_FTRS_E200 &
 #endif
-#ifdef CONFIG_E500
-	    CPU_FTRS_E500 & CPU_FTRS_E500_2 & CPU_FTRS_E500MC &
-	    CPU_FTRS_E5500 &
+#ifdef CONFIG_FSL_E500_V1_V2
+	    CPU_FTRS_E500 & CPU_FTRS_E500_2 &
+#endif
+#ifdef CONFIG_FSL_E500MC
+	    CPU_FTRS_E500MC & CPU_FTRS_E5500 &
 #endif
 	    CPU_FTRS_POSSIBLE,
 };
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index e5b142c..a6f2544 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1917,8 +1917,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
 	}
 #endif /* CONFIG_FSL_E200 */
 #endif /* CONFIG_PPC32 */
-#ifdef CONFIG_E500
-#ifdef CONFIG_PPC32
+#ifdef CONFIG_FSL_E500_V1_V2
 	{	/* e500 */
 		.pvr_mask		= 0xffff0000,
 		.pvr_value		= 0x80200000,
@@ -1956,6 +1955,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
 		.machine_check		= machine_check_e500,
 		.platform		= "ppc8548",
 	},
+#endif /* CONFIG_FSL_E500_V1_V2 */
+#ifdef CONFIG_FSL_E500MC
 	{	/* e500mc */
 		.pvr_mask		= 0xffff0000,
 		.pvr_value		= 0x80230000,
@@ -1973,7 +1974,8 @@ static struct cpu_spec __initdata cpu_specs[] = {
 		.machine_check		= machine_check_e500mc,
 		.platform		= "ppce500mc",
 	},
-#endif /* CONFIG_PPC32 */
+#endif /* CONFIG_FSL_E500MC */
+#ifdef CONFIG_E500 /* FIXME */
 	{	/* e5500 */
 		.pvr_mask		= 0xffff0000,
 		.pvr_value		= 0x80240000,
-- 
1.7.2.5

[RFC PATCH 13/17] powerpc/e500: Add a new CONFIG_FSL_E5500 option for the e5500

[Kyle Moffett]

As part of splitting CONFIG_E500 into separate options for e500v1/v2 and
e500mc/e5500, some code only needs to be built when e5500 support is
required.

This adds a new internal-use config option for both 32-bit and 64-bit
builds that enables only the e5500 support code.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/platforms/85xx/Kconfig    |    2 +-
 arch/powerpc/platforms/Kconfig.cputype |    4 ++++
 2 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
index 248f87c..72488d4 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -231,8 +231,8 @@ endif # PPC32
 config P5020_DS
 	bool "Freescale P5020 DS"
 	depends on FSL_E500MC || PPC_BOOK3E_64
+	select FSL_E5500
 	select DEFAULT_UIMAGE
-	select E500
 	select PHYS_64BIT_DT_REQUIRED
 	select SWIOTLB
 	select ARCH_REQUIRE_GPIOLIB
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index fd37bb2..cff45e3 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -144,6 +144,10 @@ config 8xx
 config PPC_85xx
 	bool
 
+config FSL_E5500
+	bool
+	select E500
+
 config E500
 	select FSL_EMB_PERFMON
 	select PPC_FSL_BOOK3E
-- 
1.7.2.5

Re: [RFC PATCH 13/17] powerpc/e500: Add a new CONFIG_FSL_E5500 option for the e5500

[Kumar Gala]

On Nov 9, 2011, at 6:07 PM, Kyle Moffett wrote:

> As part of splitting CONFIG_E500 into separate options for e500v1/v2 and
> e500mc/e5500, some code only needs to be built when e5500 support is
> required.
> 
> This adds a new internal-use config option for both 32-bit and 64-bit
> builds that enables only the e5500 support code.
> 
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---
> arch/powerpc/platforms/85xx/Kconfig    |    2 +-
> arch/powerpc/platforms/Kconfig.cputype |    4 ++++
> 2 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/platforms/85xx/Kconfig
> index 248f87c..72488d4 100644
> --- a/arch/powerpc/platforms/85xx/Kconfig
> +++ b/arch/powerpc/platforms/85xx/Kconfig
> @@ -231,8 +231,8 @@ endif # PPC32
> config P5020_DS
> 	bool "Freescale P5020 DS"
> 	depends on FSL_E500MC || PPC_BOOK3E_64
> +	select FSL_E5500
> 	select DEFAULT_UIMAGE
> -	select E500
> 	select PHYS_64BIT_DT_REQUIRED
> 	select SWIOTLB
> 	select ARCH_REQUIRE_GPIOLIB
> diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
> index fd37bb2..cff45e3 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -144,6 +144,10 @@ config 8xx
> config PPC_85xx
> 	bool
> 
> +config FSL_E5500
> +	bool
> +	select E500
> +
> config E500
> 	select FSL_EMB_PERFMON
> 	select PPC_FSL_BOOK3E
> -- 
> 1.7.2.5

Nak, I don't want to add a unique build option for 64-bit E5500 vs E500MC.  We have E6500 coming and I don't want to introduce CONFIG_FSL_E6500 at that point.

- k

Re: [RFC PATCH 13/17] powerpc/e500: Add a new CONFIG_FSL_E5500 option for the e5500

[Scott Wood]

On Wed, Nov 09, 2011 at 07:07:11PM -0500, Kyle Moffett wrote:
> As part of splitting CONFIG_E500 into separate options for e500v1/v2 and
> e500mc/e5500, some code only needs to be built when e5500 support is
> required.

How much code is this?  e5500 is basically just a 64-bit version of
e500mc.  When running a 32-bit kernel the extra code should be minimal.

-Scott

[RFC PATCH 14/17] powerpc/e500: Don't make kgdb use e500v1/e500v2 registers on e500mc

[Kyle Moffett]

The only systems which need the sparse PowerPC register map are the
e500v1/e500v2.

NOTE: The kgdb code does not otherwise use CONFIG_E500, so this support
is probably still buggy on e500v1/e500v2, but I don't know kgdb enough
to fix it.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/include/asm/kgdb.h |   17 ++++++++++-------
 1 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/kgdb.h b/arch/powerpc/include/asm/kgdb.h
index 9db24e7..4dea066 100644
--- a/arch/powerpc/include/asm/kgdb.h
+++ b/arch/powerpc/include/asm/kgdb.h
@@ -46,14 +46,17 @@ static inline void arch_kgdb_breakpoint(void)
 #define NUMREGBYTES		((68 * 8) + (3 * 4))
 #define NUMCRITREGBYTES		184
 #else /* CONFIG_PPC32 */
-/* On non-E500 family PPC32 we determine the size by picking the last
- * register we need, but on E500 we skip sections so we list what we
- * need to store, and add it up. */
-#ifndef CONFIG_E500
-#define MAXREG			(PT_FPSCR+1)
-#else
+/*
+ * On FreeScale e500v1 or e500v2 processors we need to skip some register
+ * sections, so just add up a list of what we need to store.
+ *
+ * On all other 32-bit PowerPC we can just pick the last needed register.
+ */
+#ifdef CONFIG_FSL_E500_V1_V2
 /* 32 GPRs (8 bytes), nip, msr, ccr, link, ctr, xer, acc (8 bytes), spefscr*/
-#define MAXREG                 ((32*2)+6+2+1)
+#define MAXREG			((32*2)+6+2+1)
+#else
+#define MAXREG			(PT_FPSCR+1)
 #endif
 #define NUMREGBYTES		(MAXREG * sizeof(int))
 /* CR/LR, R1, R2, R13-R31 inclusive. */
-- 
1.7.2.5

Re: [RFC PATCH 14/17] powerpc/e500: Don't make kgdb use e500v1/e500v2 registers on e500mc

[Scott Wood]

BOn Wed, Nov 09, 2011 at 07:07:12PM -0500, Kyle Moffett wrote:
> The only systems which need the sparse PowerPC register map are the
> e500v1/e500v2.

Is this due to SPE?

> +/*
> + * On FreeScale e500v1 or e500v2 processors we need to skip some register
> + * sections, so just add up a list of what we need to store.
> + *
> + * On all other 32-bit PowerPC we can just pick the last needed register.
> + */

The "s" in "Freescale" is not capitalized, BTW.

-Scott

[RFC PATCH 15/17] powerpc/e500: Fix up all remaining code uses of CONFIG_E500

[Kyle Moffett]

The CONFIG_E500 config option is ambiguous and used incorrectly in many
places to refer to some combination of e500v1/v2, e500mc, and e5500.

Fix up each reference to use the correct combinations of the following
config options:
  CONFIG_FSL_E500_V1_V2
  CONFIG_FSL_E500MC
  CONFIG_FSL_E5500

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/Kconfig                   |    2 +-
 arch/powerpc/include/asm/reg_booke.h   |   17 ++++++++++-------
 arch/powerpc/kernel/cputable.c         |    8 ++++----
 arch/powerpc/kernel/entry_32.S         |    8 +++++---
 arch/powerpc/kvm/Kconfig               |    3 ++-
 arch/powerpc/platforms/Kconfig.cputype |   22 ++++++++++------------
 6 files changed, 32 insertions(+), 28 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e3412a1..53c5acf 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -288,7 +288,7 @@ config HUGETLB_PAGE_SIZE_VARIABLE
 
 config MATH_EMULATION
 	bool "Math emulation"
-	depends on 4xx || 8xx || FSL_E200 || PPC_MPC832x || E500
+	depends on 4xx || 8xx || FSL_E200 || PPC_MPC832x || FSL_E500_V1_V2
 	---help---
 	  Some PowerPC chips designed for embedded applications do not have
 	  a floating-point unit and therefore do not implement the
diff --git a/arch/powerpc/include/asm/reg_booke.h b/arch/powerpc/include/asm/reg_booke.h
index 81cd987..845a069 100644
--- a/arch/powerpc/include/asm/reg_booke.h
+++ b/arch/powerpc/include/asm/reg_booke.h
@@ -206,12 +206,10 @@
 #define PPC47x_MCSR_FPR	0x00800000 /* FPR parity error */
 #define PPC47x_MCSR_IPR	0x00400000 /* Imprecise Machine Check Exception */
 
-#ifdef CONFIG_E500
-/* All e500 */
-#define MCSR_MCP 	0x80000000UL /* Machine Check Input Pin */
-#define MCSR_ICPERR 	0x40000000UL /* I-Cache Parity Error */
-
 /* e500v1/v2 */
+#ifdef CONFIG_FSL_E500_V1_V2
+#define MCSR_MCP	0x80000000UL /* Machine Check Input Pin */
+#define MCSR_ICPERR	0x40000000UL /* I-Cache Parity Error */
 #define MCSR_DCP_PERR 	0x20000000UL /* D-Cache Push Parity Error */
 #define MCSR_DCPERR 	0x10000000UL /* D-Cache Parity Error */
 #define MCSR_BUS_IAERR 	0x00000080UL /* Instruction Address Error */
@@ -222,8 +220,12 @@
 #define MCSR_BUS_WBERR 	0x00000004UL /* Write Data Bus Error */
 #define MCSR_BUS_IPERR 	0x00000002UL /* Instruction parity Error */
 #define MCSR_BUS_RPERR 	0x00000001UL /* Read parity Error */
+#endif
 
-/* e500mc */
+/* e500mc/e5500 */
+#if defined(CONFIG_FSL_E500MC) || defined(CONFIG_FSL_E5500)
+#define MCSR_MCP	0x80000000UL /* Machine Check Input Pin */
+#define MCSR_ICPERR	0x40000000UL /* I-Cache Parity Error */
 #define MCSR_DCPERR_MC	0x20000000UL /* D-Cache Parity Error */
 #define MCSR_L2MMU_MHIT	0x04000000UL /* Hit on multiple TLB entries */
 #define MCSR_NMI	0x00100000UL /* Non-Maskable Interrupt */
@@ -250,7 +252,8 @@
 #endif
 
 /* Bit definitions for the HID1 */
-#ifdef CONFIG_E500
+#if defined(CONFIG_FSL_E500_V1_V2) || defined(CONFIG_FSL_E500MC) \
+		|| defined(CONFIG_FSL_E5500)
 /* e500v1/v2 */
 #define HID1_PLL_CFG_MASK 0xfc000000	/* PLL_CFG input pins */
 #define HID1_RFXE	0x00020000	/* Read fault exception enable */
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index a6f2544..3fd01ca 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -69,10 +69,10 @@ extern void __setup_cpu_power7(unsigned long offset, struct cpu_spec* spec);
 extern void __restore_cpu_power7(void);
 extern void __restore_cpu_a2(void);
 #endif /* CONFIG_PPC64 */
-#if defined(CONFIG_E500)
+#ifdef CONFIG_FSL_E5500
 extern void __setup_cpu_e5500(unsigned long offset, struct cpu_spec* spec);
 extern void __restore_cpu_e5500(void);
-#endif /* CONFIG_E500 */
+#endif /* CONFIG_FSL_E5500 */
 
 /* This table only contains "desktop" CPUs, it need to be filled with embedded
  * ones as well...
@@ -1975,7 +1975,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
 		.platform		= "ppce500mc",
 	},
 #endif /* CONFIG_FSL_E500MC */
-#ifdef CONFIG_E500 /* FIXME */
+#ifdef CONFIG_FSL_E5500
 	{	/* e5500 */
 		.pvr_mask		= 0xffff0000,
 		.pvr_value		= 0x80240000,
@@ -1994,7 +1994,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
 		.machine_check		= machine_check_e500mc,
 		.platform		= "ppce5500",
 	},
-#endif /* CONFIG_E500 */
+#endif /* CONFIG_FSL_E5500 */
 
 #ifdef CONFIG_PPC_A2
 	{	/* Standard A2 (>= DD2) + FPU core */
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 56212bc..373cdc4 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -178,14 +178,15 @@ transfer_to_handler:
 	cmplw	r1,r9			/* if r1 <= ksp_limit */
 	ble-	stack_ovf		/* then the kernel stack overflowed */
 5:
-#if defined(CONFIG_6xx) || defined(CONFIG_E500)
+#if defined(CONFIG_6xx) || defined(CONFIG_FSL_E500_V1_V2) \
+		|| defined(CONFIG_FSL_E500MC)
 	rlwinm	r9,r1,0,0,31-THREAD_SHIFT
 	tophys(r9,r9)			/* check local flags */
 	lwz	r12,TI_LOCAL_FLAGS(r9)
 	mtcrf	0x01,r12
 	bt-	31-TLF_NAPPING,4f
 	bt-	31-TLF_SLEEPING,7f
-#endif /* CONFIG_6xx || CONFIG_E500 */
+#endif
 	.globl transfer_to_handler_cont
 transfer_to_handler_cont:
 3:
@@ -236,7 +237,8 @@ reenable_mmu:				/* re-enable mmu so we can */
 	RFI				/* jump to handler, enable MMU */
 #endif /* CONFIG_TRACE_IRQFLAGS */
 
-#if defined (CONFIG_6xx) || defined(CONFIG_E500)
+#if defined (CONFIG_6xx) || defined(CONFIG_FSL_E500_V1_V2) \
+		|| defined(CONFIG_FSL_E500MC)
 4:	rlwinm	r12,r12,0,~_TLF_NAPPING
 	stw	r12,TI_LOCAL_FLAGS(r9)
 	b	power_save_ppc32_restore
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 78133de..3f608bf 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -116,7 +116,8 @@ config KVM_EXIT_TIMING
 
 config KVM_E500
 	bool "KVM support for PowerPC E500 processors"
-	depends on EXPERIMENTAL && E500
+	depends on EXPERIMENTAL
+	depends on FSL_E500_V1_V2 || FSL_E500MC || FSL_E5500
 	select KVM
 	select KVM_MMIO
 	---help---
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index cff45e3..22df19d 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -159,7 +159,7 @@ config PPC_FPU
 
 config FSL_EMB_PERFMON
 	bool "Freescale Embedded Perfmon"
-	depends on E500 || PPC_83xx
+	depends on PPC_83xx || FSL_E500_V1_V2 || FSL_E500MC || FSL_E5500
 	help
 	  This is the Performance Monitor support found on the e500 core
 	  and some e300 cores (c3 and c4).  Select this only if your
@@ -171,25 +171,23 @@ config FSL_EMB_PERF_EVENT
 	default y
 
 config FSL_EMB_PERF_EVENT_E500
-	bool
-	depends on FSL_EMB_PERF_EVENT && E500
-	default y
+	def_bool y
+	depends on FSL_EMB_PERF_EVENT
+	depends on FSL_E500_V1_V2 || FSL_E500MC || FSL_E5500
 
 config 4xx
 	bool
 	depends on 40x || 44x
 	default y
 
-config BOOKE
-	bool
-	depends on FSL_E200 || E500 || 44x || PPC_BOOK3E
-	default y
-
 config FSL_BOOKE
-	bool
-	depends on FSL_E200 || (E500 && PPC32)
+	def_bool y
+	depends on FSL_E200 || FSL_E500_V1_V2 || FSL_E500MC
 	select SYS_SUPPORTS_HUGETLBFS if PHYS_64BIT
-	default y
+
+config BOOKE
+	def_bool y
+	depends on FSL_BOOKE || 44x || PPC_BOOK3E
 
 config FSL_CORENET
 	bool
-- 
1.7.2.5

[RFC PATCH 16/17] powerpc/e500: Make __setup_cpu_{e200,e500,e500mc,e5500} optional

[Kyle Moffett]

Only build the setup functions when the corresponding entries are
included in the CPU table.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/kernel/cpu_setup_fsl_booke.S |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
index 8053db0..77721b2 100644
--- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
+++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
@@ -17,6 +17,8 @@
 #include <asm/cputable.h>
 #include <asm/ppc_asm.h>
 
+#if defined(CONFIG_FSL_E500_V1_V2) || defined(CONFIG_FSL_E500MC) \
+		|| defined(CONFIG_FSL_E5500)
 _GLOBAL(__e500_icache_setup)
 	mfspr	r0, SPRN_L1CSR1
 	andi.	r3, r0, L1CSR1_ICE
@@ -50,14 +52,18 @@ _GLOBAL(__e500_dcache_setup)
 	mtspr	SPRN_L1CSR0, r0		/* Enable */
 	isync
 	blr
+#endif /* CONFIG_FSL_E500_V1_V2 || CONFIG_FSL_E500MC || CONFIG_FSL_E5500 */
 
-#ifdef CONFIG_PPC32
+#ifdef CONFIG_FSL_E200
 _GLOBAL(__setup_cpu_e200)
 	/* enable dedicated debug exception handling resources (Debug APU) */
 	mfspr	r3,SPRN_HID0
 	ori	r3,r3,HID0_DAPUEN@l
 	mtspr	SPRN_HID0,r3
 	b	__setup_e200_ivors
+#endif
+
+#ifdef CONFIG_FSL_E500_V1_V2
 _GLOBAL(__setup_cpu_e500v1)
 _GLOBAL(__setup_cpu_e500v2)
 	mflr	r4
@@ -72,6 +78,9 @@ _GLOBAL(__setup_cpu_e500v2)
 #endif
 	mtlr	r4
 	blr
+#endif
+
+#ifdef CONFIG_FSL_E500MC
 _GLOBAL(__setup_cpu_e500mc)
 	mflr	r4
 	bl	__e500_icache_setup
@@ -80,7 +89,9 @@ _GLOBAL(__setup_cpu_e500mc)
 	mtlr	r4
 	blr
 #endif
+
 /* Right now, restore and setup are the same thing */
+#ifdef CONFIG_FSL_E5500
 _GLOBAL(__restore_cpu_e5500)
 _GLOBAL(__setup_cpu_e5500)
 	mflr	r4
@@ -96,3 +107,4 @@ _GLOBAL(__setup_cpu_e5500)
 #endif
 	mtlr	r4
 	blr
+#endif
-- 
1.7.2.5

Re: [RFC PATCH 16/17] powerpc/e500: Make __setup_cpu_{e200,e500,e500mc,e5500} optional

[Scott Wood]

On Wed, Nov 09, 2011 at 07:07:14PM -0500, Kyle Moffett wrote:
> Only build the setup functions when the corresponding entries are
> included in the CPU table.
> 
> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
> ---
>  arch/powerpc/kernel/cpu_setup_fsl_booke.S |   14 +++++++++++++-
>  1 files changed, 13 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> index 8053db0..77721b2 100644
> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
> @@ -17,6 +17,8 @@
>  #include <asm/cputable.h>
>  #include <asm/ppc_asm.h>
>  
> +#if defined(CONFIG_FSL_E500_V1_V2) || defined(CONFIG_FSL_E500MC) \
> +		|| defined(CONFIG_FSL_E5500)

This seems like the kind of thing that CONFIG_E500 should be retained
for.

-Scott

Re: [RFC PATCH 16/17] powerpc/e500: Make __setup_cpu_{e200,e500,e500mc,e5500} optional

[Kumar Gala]

On Nov 10, 2011, at 10:47 AM, Scott Wood wrote:

> On Wed, Nov 09, 2011 at 07:07:14PM -0500, Kyle Moffett wrote:
>> Only build the setup functions when the corresponding entries are
>> included in the CPU table.
>> 
>> Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
>> ---
>> arch/powerpc/kernel/cpu_setup_fsl_booke.S |   14 +++++++++++++-
>> 1 files changed, 13 insertions(+), 1 deletions(-)
>> 
>> diff --git a/arch/powerpc/kernel/cpu_setup_fsl_booke.S b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
>> index 8053db0..77721b2 100644
>> --- a/arch/powerpc/kernel/cpu_setup_fsl_booke.S
>> +++ b/arch/powerpc/kernel/cpu_setup_fsl_booke.S
>> @@ -17,6 +17,8 @@
>> #include <asm/cputable.h>
>> #include <asm/ppc_asm.h>
>> 
>> +#if defined(CONFIG_FSL_E500_V1_V2) || defined(CONFIG_FSL_E500MC) \
>> +		|| defined(CONFIG_FSL_E5500)
> 
> This seems like the kind of thing that CONFIG_E500 should be retained
> for.
> 
> -Scott

Agreed, we should define CONFIG_E500 as internal and used for common functionality between E500, E500MC, E5500, E6500.

- k

[RFC PATCH 17/17] powerpc/e500: Finally remove "CONFIG_E500"

[Kyle Moffett]

This ambiguous config option is now only present as a Kconfig stub.
Remove it and fix up the users.

Signed-off-by: Kyle Moffett <Kyle.D.Moffett@boeing.com>
---
 arch/powerpc/platforms/Kconfig.cputype |   10 ++++------
 1 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/platforms/Kconfig.cputype
index 22df19d..d4faa6f 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/powerpc/platforms/Kconfig.cputype
@@ -32,14 +32,16 @@ config FSL_E200
 config FSL_E500_V1_V2
 	bool "Freescale e500v1/e500v2 (also known as MPC85xx)"
 	select PHYS_64BIT_SUPPORTED
-	select E500
+	select FSL_EMB_PERFMON
+	select PPC_FSL_BOOK3E
 	select PPC_85xx
 
 config FSL_E500MC
 	bool "Freescale e500mc (also e5500 in 32-bit mode)"
 	select PHYS_64BIT_SUPPORTED
 	select PPC_FPU
-	select E500
+	select FSL_EMB_PERFMON
+	select PPC_FSL_BOOK3E
 	select PPC_85xx
 
 config PPC_8xx
@@ -146,12 +148,8 @@ config PPC_85xx
 
 config FSL_E5500
 	bool
-	select E500
-
-config E500
 	select FSL_EMB_PERFMON
 	select PPC_FSL_BOOK3E
-	bool
 
 config PPC_FPU
 	bool
-- 
1.7.2.5