On Mar 16, 2009, at 5:44 AM, David Jander wrote:
On Friday 13 March 2009 16:23:15 Kumar Gala wrote:
[...]
This errata impacts a number of cores and so we should make this a
CPU
feature fixup rather than #ifdef code.
It should impact only MPC5121e and probably MPC5123, but according
to
Freescale no other processors that use this core...
Not sure about that.. But the errata impacts all e300c2/c3/c4 parts.
Can someone please check if this is true? There should be errata's
for all
other parts that use one of these cores then.
Anyway, I'll try to investigate about how to write a "CPU feature
fixup",
I've never done that before (If you could give me a hint?)
I've posted a patch that should add the CPU feature support. This is
only compile tested. You'll need to try it out on real HW :)
That's a problem right now: The only useable kernel for the MPC5121e
is the
one on the 'ads5121' head from denx, and that is version 2.6.24.6.
Your patch
(v3) does not apply to that kernel, so I would have to change a few
things
before I can actually try it out:
#define CPU_FTR_NEED_DTLB_SW_LRU ASM_CONST(0x0000000000010000)
In 2.6.24.6 this constant is used for something else. Would it be
possible to
pick anotherone, in order to make dual-kernel patches easier to
maintain for
now?
+ mfspr r3,SPRN_DMISS
+ rlwinm r3,r3,19,25,29 /* Get Address bits 19:15 */
+ lis r2,l...@ha /* Search index in lrw[] */
+ addi r2,r2,l...@l
+ tophys(r2,r2)
+ lwzx r1,r3,r2 /* Get item from lrw[] */
+ cmpwi 0,r1,0 /* Was it way 0 last time? */
Why not use a bit vector since we only need one bit of information.
Additionally we can use a single SPRG at that point instead to keep
track of the LRU information.
Sounds interesting. I am just learning my first steps in powerpc-
assembly, so
please forgive if this is a little inefficient still. I'll try again
next week.
Not at all. This has been on my todo list just not high priority so
I'm happy to get someone to work on it and have setup already that
can
show perf differences.
On your Todo list? Does that mean you know about another processor
that has
the same problem?
Yes, I work at Freescale and am aware that the errata impacts all c2/
c3/c4 class chips.
I might work up a newer version w/the SPRG idea if I'm feeling up
to it.
Do you mean it is possible to just pick an SPRG that will be used
only by this
handler and make sure no other piece of software will touch it?
Would be
great. Is there a way of knowing which SPRG's are used by linux? I
read in
the e300 core-RM, that SPRG4...7 are unique to this iteration of the
G2
anyway, so one of those might be a good candidate?
I was thinking one from SPRG4..7 should be fine since Linux doesn't
use them for anything.
We should try this w/SPRG & w/memory to see if we notice any perf
difference.
I have quite a lot of work pressure right now, and unfortunately
very little
time I can dedicate to this. Given the fact that I also cannot test
patches
for mainline, because MPC5121e support is just not complete enough
yet, do
you agree if I modify my own patch (with ifdef's instead of
CPU_FTR...) to
give you feedback on performance impacts, while you implement it as
CPU_FTR
afterwards for mainline? That way I can avoid doing double work, and
spend
more time on testing it actually....
If you agree, I'll start hacking away on the SPRG version
immediately :-)
I think that's fine. The CPU feature bit is minor to deal with and
Ben has stated he wants it to be a MMU feature which is something new
as well. It should be easy to convert the CPU_FTR wrapping into
#ifdefs instead.
I have a few other patches related to this that I am not sure if they
will apply to the 2.6.24.6 tree you are based on.
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
