[Top] [All Lists]

Question about the new "cca" kernel parameter

Subject: Question about the new "cca" kernel parameter
From: "Shane McDonald" <>
Date: Sun, 22 Jun 2008 09:48:23 -0600
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=95v2UbGhGdLHmOJIRAzehUaYM8I6s4YKVT+pFCtGZLc=; b=MHcRuCwN9DsrnBsAwffYIW6PF7mCL9P8bDSk5tsucgXL110B2gxxTictEgVVHwP7d+ i8n8pt+0WqV+3ynT3PMMUw6KJsSq5WjGvPaoTDtdkItVgA8J5H51cz2Qiw58Xei69vUU Vmemp60QTi8HRTZt6vuTA5+gKf53Wq89pwe24=
Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=w9CP1VszUZnduxUOQacy82i6FoTavW527uhNb4nlk6GYlP4v4WkP+QNt1fPNsvcn74 ZZG+214xby+1tr+NsyznZFzerfqP8HT3dB6XWYHPYDsmXp3ncJed1Y/7EQFfTLuJDDnc dTTfgXT+3BrRQkooS956GKuN7wyuDEY0/wG9E=
Original-recipient: rfc822;

  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:

#elif defined(CONFIG_CPU_RM9000)

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
<Prev in Thread] Current Thread [Next in Thread>
  • Question about the new "cca" kernel parameter, Shane McDonald <=