Date: Mon, 2 Nov 2009 13:33:08 -0600 From: Jason Harmening <jason.harmening@gmail.com> To: gonzo@bluezbox.com, freebsd-hackers@freebsd.org Subject: Re: MIPS: bus_dma(9) and cache problems Message-ID: <2d1264630911021133uf3033deu20b41adfe54f62c2@mail.gmail.com> In-Reply-To: <bc2d970911021024i51357e80w949781454727e8b3@mail.gmail.com> References: <2d1264630910290849k2ca29237ubb25cc3b7313ec26@mail.gmail.com> <bc2d970911021024i51357e80w949781454727e8b3@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 2, 2009 at 12:24 PM, Ryan Stone <rysto32@gmail.com> wrote: >> What sync operation are you doing? =A0At least for PREREAD or PREWRITE, >> I'd expect any dirty cache lines to be flushed to RAM. =A0If this isn't >> happening, then you may want to submit a bug report. > > For a PREREAD, I don't believe that it's correct to flush a dirty > cache line to RAM. =A0That would overwrite whatever had been DMA'ed into > that cache line. > I don't think that should matter--if you're issuing a PREREAD, *before* the start of a DMA transfer, the CPU either doesn't care about what's currently in the part of the line that is to be DMA'ed into (because it's about to be overwritten by the device anyway), or it's finished accessing what's in there from a previous DMA operation (in which case you'd expect it to either be present in the cache or already flushed out by something else anyway). But the basic idea is that the CPU shouldn't access the cache line from the time the PRE-whatever operation is issued to the time the POST-whatever operation is issued, so if you have multiple threads (anywhere on the system) accessing that line, you could be screwed. Heh, I just noticed the copyright at the top of the MIPS busdma implementation--apparently you ARE familiar w/ the MIPS sync implementation :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2d1264630911021133uf3033deu20b41adfe54f62c2>