[RFC] Patch for proper Cortex-A8 cache configuration output

[RFC] Patch for proper Cortex-A8 cache configuration output

[Dirk Behme]

Recent ARM kernel doesn't detect and output Cortex-A8 cache 
configuration correctly. Result is something like this in kernel's 
boot messages:

-- cut --
...
CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f
...
CPU0: D VIPT write-through cache
CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets
...
-- cut --

Catalin sent a patch for this to linux-arm-kernel list:

http://lists.arm.linux.org.uk/lurker/message/20080704.150532.983f01ca.en.html

Result:

-- cut --
...
CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3
CPU0: Level 1 cache is separate instruction and data
CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,
       supports RA
CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,
       supports RA WB WT
CPU0: Level 2 cache is unified
CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512 
sets,
       supports WA RA WB WT
...
-- cut --

Some people really like this and this patch is used in some private 
trees, e.g. for BeagleBoard.

Unfortunately, RMK doesn't like the patch. He prefers to completely 
remove 'broken' configuration output completely.

What's about applying this patch locally to OMAP git until upstream 
ARM kernel has a fix/remove solution for this?

Many thanks

Dirk

Re: [RFC] Patch for proper Cortex-A8 cache configuration output

[Tony Lindgren]

* Dirk Behme <dirk.behme@googlemail.com> [080807 19:38]:
>
> Recent ARM kernel doesn't detect and output Cortex-A8 cache  
> configuration correctly. Result is something like this in kernel's boot 
> messages:
>
> -- cut --
> ...
> CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f
> ...
> CPU0: D VIPT write-through cache
> CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets
> ...
> -- cut --
>
> Catalin sent a patch for this to linux-arm-kernel list:
>
> http://lists.arm.linux.org.uk/lurker/message/20080704.150532.983f01ca.en.html
>
> Result:
>
> -- cut --
> ...
> CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3
> CPU0: Level 1 cache is separate instruction and data
> CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,
>       supports RA
> CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,
>       supports RA WB WT
> CPU0: Level 2 cache is unified
> CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512  
> sets,
>       supports WA RA WB WT
> ...
> -- cut --
>
> Some people really like this and this patch is used in some private  
> trees, e.g. for BeagleBoard.
>
> Unfortunately, RMK doesn't like the patch. He prefers to completely  
> remove 'broken' configuration output completely.
>
> What's about applying this patch locally to OMAP git until upstream ARM 
> kernel has a fix/remove solution for this?

Yeah, let's try it out next week after updating to rc2. There will be
also move of the headers to go under plat-omap, so let's get all that
done first.

Tony


>
> Many thanks
>
> Dirk
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Patch for proper Cortex-A8 cache configuration output

[Tony Lindgren]

* Tony Lindgren <tony@atomide.com> [080808 03:41]:
> * Dirk Behme <dirk.behme@googlemail.com> [080807 19:38]:
> >
> > Recent ARM kernel doesn't detect and output Cortex-A8 cache  
> > configuration correctly. Result is something like this in kernel's boot 
> > messages:
> >
> > -- cut --
> > ...
> > CPU: ARMv7 Processor [411fc082] revision 2 (ARMv7), cr=00c5387f
> > ...
> > CPU0: D VIPT write-through cache
> > CPU0: cache: 768 bytes, associativity 1, 8 byte lines, 64 sets
> > ...
> > -- cut --
> >
> > Catalin sent a patch for this to linux-arm-kernel list:
> >
> > http://lists.arm.linux.org.uk/lurker/message/20080704.150532.983f01ca.en.html
> >
> > Result:
> >
> > -- cut --
> > ...
> > CPU0: L1 I VIPT cache. Caches unified at level 2, coherent at level 3
> > CPU0: Level 1 cache is separate instruction and data
> > CPU0: I cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,
> >       supports RA
> > CPU0: D cache: 16384 bytes, associativity 4, 64 byte lines, 64 sets,
> >       supports RA WB WT
> > CPU0: Level 2 cache is unified
> > CPU0: unified cache: 262144 bytes, associativity 8, 64 byte lines, 512  
> > sets,
> >       supports WA RA WB WT
> > ...
> > -- cut --
> >
> > Some people really like this and this patch is used in some private  
> > trees, e.g. for BeagleBoard.
> >
> > Unfortunately, RMK doesn't like the patch. He prefers to completely  
> > remove 'broken' configuration output completely.
> >
> > What's about applying this patch locally to OMAP git until upstream ARM 
> > kernel has a fix/remove solution for this?
> 
> Yeah, let's try it out next week after updating to rc2. There will be
> also move of the headers to go under plat-omap, so let's get all that
> done first.

I guess Catalin will submit his patch at some point after 2.6.28 opens.
I'll apply it l-o tree, and remove the L2 debug info we had in id.c
to clean up id.c in the future patches.

Tony

Re: [RFC] Patch for proper Cortex-A8 cache configuration output

[Russell King - ARM Linux]

On Wed, Sep 10, 2008 at 04:28:07PM -0700, Tony Lindgren wrote:
> I guess Catalin will submit his patch at some point after 2.6.28 opens.
> I'll apply it l-o tree, and remove the L2 debug info we had in id.c
> to clean up id.c in the future patches.

As I've said on the main ARM lists where I've given reasons, I'm against
extending this stuff, and it is my intention to remove it completely.
It was only added because it was relatively simple and easy to print the
information.

However, with ARMs attitude of breaking configuration register formats
willy nilly, it's just not worth having the additional complexity to
try to work out which format we have, and decode that format.

For all we know, come the next ARM architecture revision, these registers
will have completely changed their format again.  So much for providing
software with an easy way to determine the parameters of the core.

It's just not worth the complexity and effort to try and decode this
information for no other purpose than a few printk's.

Re: [RFC] Patch for proper Cortex-A8 cache configuration output

[Tony Lindgren]

* Russell King - ARM Linux <linux@arm.linux.org.uk> [080911 01:46]:
> On Wed, Sep 10, 2008 at 04:28:07PM -0700, Tony Lindgren wrote:
> > I guess Catalin will submit his patch at some point after 2.6.28 opens.
> > I'll apply it l-o tree, and remove the L2 debug info we had in id.c
> > to clean up id.c in the future patches.
> 
> As I've said on the main ARM lists where I've given reasons, I'm against
> extending this stuff, and it is my intention to remove it completely.
> It was only added because it was relatively simple and easy to print the
> information.
> 
> However, with ARMs attitude of breaking configuration register formats
> willy nilly, it's just not worth having the additional complexity to
> try to work out which format we have, and decode that format.
> 
> For all we know, come the next ARM architecture revision, these registers
> will have completely changed their format again.  So much for providing
> software with an easy way to determine the parameters of the core.
> 
> It's just not worth the complexity and effort to try and decode this
> information for no other purpose than a few printk's.

Hmm, people need to see what's enabled though.

For later ARMs, would it make sense to have some arm_l2_init() function
that would get called from mach specific init to set the timings and enable
L2? That function could then dump the cache configuration too.

Tony