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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
