linux-mips
[Top] [All Lists]

Re: Au1500 hardware cache coherency

To: Hartvig Ekner <hartvig@ekner.info>
Subject: Re: Au1500 hardware cache coherency
From: Pete Popov <ppopov@mvista.com>
Date: 31 Mar 2003 12:33:38 -0800
Cc: Eric DeVolder <eric.devolder@amd.com>, Linux MIPS mailing list <linux-mips@linux-mips.org>
In-reply-to: <3E889602.62B7AB6B@ekner.info>
Organization: MontaVista Software
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <3E882FB8.BBFDACE2@ekner.info> <3E8853B3.9080902@amd.com> <3E885B68.6927451E@ekner.info> <3E8883B8.1000000@amd.com> <3E889602.62B7AB6B@ekner.info>
Sender: linux-mips-bounce@linux-mips.org
On Mon, 2003-03-31 at 11:24, Hartvig Ekner wrote:
> Hi Eric, 
> 
> I did a quick check of a complete kernel disassembly, and there are
> tons of direct or indirect RMW's to config, which do not explicitly
> insure that Config[0D] is set. 
> Pete - are you aware of this? 

Config[OD] is set in setup.c and should not be cleared afterward.

> Thus, there seems to be a potential problem lurking here for anybody
> who is using USB. 
> 
> However, I am not using USB at all, and it is configured out of the
> kernel. So I assume this is not errata #3 we're seeing here? 
> 
> So, to summarize: The first set of problems in my email below seem to
> be fully explained by errata #14. Note that any kernel compiled from
> the current CVS exhibits this problem: 
> Because although NONCOHEHENT_IO is set, the NC bit in PCI_CFG is not
> set. 

Hmm, ok, I'll check that out.

> I have verified that the problem occurs when NC is cleared, regardless
> of the .config option. So some code needs to be changed in
> au1000/xxx/setup.c... (set NC if NONCOHERENT_IO 
> is enabled). 

> But - much wore worrisome: I did this modification, and with the NC
> bit set, and NONCOHERENT_IO set, I get the second set of errors,
> although it takes much longer time. The wback_inv calls are made
> through the generic code  in the subroutine 
> pci_alloc_consistent() (in arch/mips/kernel/pci-dma.c). 

> So something is wrong.... Anybody at AMD who would care to continue
> the debug? 

Can you send me your test and exact instructions on how you're
duplicating the error? I won't have time to look at it until after 4/20
though.

Pete


<Prev in Thread] Current Thread [Next in Thread>