Hello:
In the run-up to the 2.6.26 series of RCs, commit 351336929ccf222ae38ff0cb7a8dd5fd5c6236a0, [MIPS] Allow setting of the cache attribute at run time, introduced a new kernel parameter, cca, which you can use to specify the cache coherency attribute to be used in the system. This replaces the previous config parameter, CONFIG_MIPS_UNCACHED, to allow finer-grained control over the CCA to be used.
I'm running into a problem with this code, in that when I don't specify the cca parameter on my boot line, it selects a default value that is not the same as was used in 2.6.25 and previous kernel versions. Before, the CCA would be set to a value specified in the constant PAGE_CACHABLE_DEFAULT, defined in include/asm-mips/pgtable-bits.h. The relevant code in 2.6.25 was:
#ifdef CONFIG_MIPS_UNCACHED
#define PAGE_CACHABLE_DEFAULT _CACHE_UNCACHED
#elif defined(CONFIG_DMA_NONCOHERENT)
#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_NONCOHERENT
#elif defined(CONFIG_CPU_RM9000)
#define PAGE_CACHABLE_DEFAULT _CACHE_CWB
#else
#define PAGE_CACHABLE_DEFAULT _CACHE_CACHABLE_COW
#endif
For my system, CONFIG_DMA_NONCOHERENT is defined, so the CCA is set to _CACHE_CACHABLE_NONCOHERENT (value of 3, writeback, on my PMC-Sierra RM7035C-based system).
After the commit, the CCA, if not set on the kernel boot line, is set to the current value of the K0 field of the coprocessor 0 Config register. In my system's case, this code comes from the function coherency_setup() in arch/mips/mm/c-r4k.c:
if (cca < 0 || cca > 7)
cca = read_c0_config() & CONF_CM_CMASK;
_page_cachable_default = cca << _CACHE_SHIFT;
On my system, when this code is executed, the K0 field has a value of 0 (write-through without write-allocate) -- I'm not sure if this has been set previously during the Linux bootup sequence, or if it would have been set from the boot monitor (PMON in my case, for which I have no source code specific to my system), or if it is using the default processor reset values (undefined on my processor). Anyways, the result is that my system uses a CCA setting of 0 rather than 3, and I see much slower performance than I did under 2.6.25. Of course, I can specify "cca=3" on the command line to use the previous setting, but I think it would be much nicer if this was handled in the code.
OK, so I guess what my question is, what would be the best way to fix this, or am I the only one who is seeing this problem? I could whip up a patch for c-r4k.c that restores the previous behaviour as defined in 2.6.25's pgtable-bits.h, or I could set something up in my platform-specific code to use a different value. Suggestions?
For the record, my system is a PMC-Sierra RM2881 "Xiao Hu" evaluation board with a RM7035C processor. It is based on the old ITE 8172G evaluation board, whose support had become subject to bitrot and was finally removed in 2.6.19. Support for the Xiao Hu is not in the l-m.o tree.
Thanks for any guidance that you can provide me!
Shane McDonald
