Patch for proper Cortex-A8 cache configuration output

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

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 41 lines · 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.

Quoted 2 lines

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.

Quoted 3 lines · Tony Lindgren

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.