From: Sergei Shtylylov <sshtylyov@ru.mvista.com>
To: Linux MIPS <linux-mips@linux-mips.org>
Cc: Manish Lachwani <mlachwani@mvista.com>,
Jordan Crouse <jordan.crouse@amd.com>,
ralf@linux-mips.org
Subject: Re: [PATCH] Retain the write-only OD from being clobbered
Date: Thu, 29 Dec 2005 01:25:57 +0300 [thread overview]
Message-ID: <43B310F5.4090507@ru.mvista.com> (raw)
In-Reply-To: <43838957.2020106@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]
Hello
Sergei Shtylylov wrote:
> Jordan Crouse wrote:
>> First of several patches forwarded to me by Sergei Shtylyov. Ralf,
>> these should be good to go for the tree.
>>
>> Retain the write-only OD bit from being clobbered by coherency_setup()
>>
>> Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
>> Acked-by: Jordan Crouse <jordan.crouse@amd.com>
> A long story of a long standing bug follows...
> AMD Au1x00 board setup code in au1x00_setup() sets CONFIG.OD bit for
> the early steppings of the Au1x00 SOCs, consulting the PRID table in
> arch/mips/au1000/common/cputable.c. This bit disables the bus
> transaction overlapping which causes a number of errata in those early
> SOC steppings (including the one that I think we've run into with USB
> host--at least setting the bit back to 1 fixed it, although disabling
> USB host DMA coherency also seemd to help). The problem is that this bit
> is write-only and reads
> as 0 on almost all SOCs that need it set. So, when the arch/mm/c-r4k.c code
> does RMW to the CONFIG reg. in coherency_setup(), its value is lost, and
> the
> chip again becomes prone to all the nasty errata that it has just been
> saved
> from... :-)
> There's couple more places in the assembly code where the CP0
> CONFIG reg. is written without care of OD bit:
> 1) In the cache parity error handler (arch/mips/mm/cex-gen.S) -- as
> the panic() call follows shortly, probably CACHE.OD=0 doesn't matter
> much at this point;
> 2) In arch/mips/au1000/common/sleeper.S, when the CPU regs are being
> restored on wakeup; Au1x00 PM code in 2.6 seem to have fallen out of
> maintenance, and the stack frame set up there seemed just erratic (2.4
> situation in this module is much better).
> I didn't touch both those places. And of course, this CONFIG.OD bug is
> present in 2.4 kernels as well...
Posting the reworked patch at last -- this variant doesn't include
machine-specific header into arch/mips/c-r4k.c...
WBR, Sergei
Signed-off-by: Konstantin Baidarov <kbaidarov@ru.mvista.com>
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
[-- Attachment #2: Au1x00-retain-OD-bit.patch --]
[-- Type: text/plain, Size: 1588 bytes --]
diff --git a/arch/mips/au1000/common/setup.c b/arch/mips/au1000/common/setup.c
index 08c8c85..e36289b 100644
--- a/arch/mips/au1000/common/setup.c
+++ b/arch/mips/au1000/common/setup.c
@@ -143,6 +143,17 @@ void __init plat_setup(void)
au_writel(0, SYS_TOYTRIM);
}
+/*
+ * Fix up write-only Config[OD] bit after a write to that register. Since the
+ * bit always reads as 0 on those SOC revs that require it to be set to fight
+ * the various errata, we need to set it back to 1...
+ */
+void au1x00_fixup_config_od(void)
+{
+ if (cur_cpu_spec[0]->cpu_od)
+ set_c0_config(1<<19);
+}
+
#if defined(CONFIG_64BIT_PHYS_ADDR)
/* This routine should be valid for all Au1x based boards */
phys_t __fixup_bigphys_addr(phys_t phys_addr, phys_t size)
diff --git a/arch/mips/mm/c-r4k.c b/arch/mips/mm/c-r4k.c
index 422b55f..8447699 100644
--- a/arch/mips/mm/c-r4k.c
+++ b/arch/mips/mm/c-r4k.c
@@ -1201,8 +1201,20 @@ static void __init setup_scache(void)
static inline void coherency_setup(void)
{
+ extern void au1x00_fixup_config_od(void);
+
change_c0_config(CONF_CM_CMASK, CONF_CM_DEFAULT);
+#ifdef CONFIG_SOC_AU1X00
+ /*
+ * c0_config.od (bit 19) is write only (and reads as 0) on many early
+ * revs of AMD Au1x00 SOCs. It disables the bus transaction overlapping
+ * and needs to be set to correct the various errata. So if it has been
+ * set by the board setup code we must leave it set...
+ */
+ au1x00_fixup_config_od();
+#endif
+
/*
* c0_status.cu=0 specifies that updates by the sc instruction use
* the coherency mode specified by the TLB; 1 means cachable
next prev parent reply other threads:[~2005-12-28 22:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-22 20:59 [PATCH] Retain the write-only OD from being clobbered Jordan Crouse
2005-11-22 21:10 ` Sergei Shtylylov
2005-12-28 22:25 ` Sergei Shtylylov [this message]
2006-03-24 20:33 ` Sergei Shtylyov
2006-05-26 3:43 ` [PATCH] Save write-only Config.OD " Sergei Shtylyov
2006-05-26 15:44 ` [PATCH] Save write-only Config.OD from being clobbered (take 4) Sergei Shtylyov
2006-05-26 15:55 ` Martin Michlmayr
2006-05-26 16:02 ` Sergei Shtylyov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43B310F5.4090507@ru.mvista.com \
--to=sshtylyov@ru.mvista.com \
--cc=jordan.crouse@amd.com \
--cc=linux-mips@linux-mips.org \
--cc=mlachwani@mvista.com \
--cc=ralf@linux-mips.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox