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

On Nov 10, 2011, at 12:03, Scott Wood wrote:

On Thu, Nov 10, 2011 at 10:42:25AM -0600, Kumar Gala wrote:

quoted

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

quoted

On Thu, Nov 10, 2011 at 07:40:04AM -0600, Kumar Gala wrote:

quoted

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.

=20
What "mode" do you mean?  DCBZ32?  We don't support using that currentl=

y,

quoted

quoted

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 lega=

cy

quoted

quoted

software work.

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

=20
For running legacy software, or for multiplatform Linux kernels?
=20
And if you're willing to toss performance away for this goal, why do you
need lwsync? :-)
=20
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.
=20
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