Date: Sun, 26 Aug 2012 18:26:08 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: freebsd-arm@freebsd.org, "arch@" <freebsd-arch@freebsd.org>, freebsd-mips@freebsd.org, Tim Kientzle <tim@kientzle.com> Subject: Re: Partial cacheline flush problems on ARM and MIPS Message-ID: <CAJ-Vmom=nfqNQQNVW6ED0CQ9cFS45GTFzKGLpzkC2TGpc4JC5w@mail.gmail.com> In-Reply-To: <26F65164-EC99-483E-9FA8-916AD99CBCBC@bsdimp.com> References: <1345757300.27688.535.camel@revolution.hippie.lan> <3A08EB08-2BBF-4B0F-97F2-A3264754C4B7@bsdimp.com> <1345763393.27688.578.camel@revolution.hippie.lan> <FD8DC82C-AD3B-4EBC-A625-62A37B9ECBF1@bsdimp.com> <1345765503.27688.602.camel@revolution.hippie.lan> <CAJ-VmonOwgR7TNuYGtTOhAbgz-opti_MRJgc8G%2BB9xB3NvPFJQ@mail.gmail.com> <1345766109.27688.606.camel@revolution.hippie.lan> <CAJ-VmomFhqV5rTDf-kKQfbSuW7SSiSnqPEjGPtxWjaHFA046kQ@mail.gmail.com> <F8C9E811-8597-4ED0-9F9D-786EB2301D6F@bsdimp.com> <1346002922.1140.56.camel@revolution.hippie.lan> <CAP%2BM-_HZ4yARwZA2koPJDeJWHT-1LORupjymuVnMtLBzeXe=DA@mail.gmail.com> <DD23C97F-E90D-48A8-9F12-9BADBDDF3D1C@kientzle.com> <1346011312.1140.107.camel@revolution.hippie.lan> <26F65164-EC99-483E-9FA8-916AD99CBCBC@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hm. So perhaps we should document the busdma assumptions with respect to alignment and coherency? So this doesnt happen again? Adrian On Aug 26, 2012 4:19 PM, "Warner Losh" <imp@bsdimp.com> wrote: > > On Aug 26, 2012, at 2:01 PM, Ian Lepore wrote: > > > On Sun, 2012-08-26 at 11:53 -0700, Tim Kientzle wrote: > >> These rules sound reasonable. Good documentation might > >> also give examples of what the PRE/POST operations might entail > >> (e.g., from the preceding discussion, it sounds like PREREAD > >> and PREWRITE require at least a partial cache flush on ARM). > >> That helps folks who are coming to the docs with some hardware > >> background. > >> > > > > I agree, I think it would be good to have something like a RATIONALE > > section in the manpage that summarizes the issues faced by various > > categories of platform (hardware coherency, software-assisted coherency, > > etc) and how they handle it. You don't want people coding to the > > implementation (some of which is going on now, and I've been guilty of > > it myself); if there were more info in the docs there'd be less > > motivation to peek at the implementation. > > More documentation is good. > > >>> * Read and write sync operators may be combined in a single call, > >>> PRE and POST operators may not be. E.G., PREREAD|PREWRITE is > >>> allowed, PREREAD|POSTREAD is not. We should note that while > >>> read and write operations may be combined, on some platforms > >>> PREREAD|PREWRITE is needlessly expensive when only a read is > >>> being performed. > >> > >> > >> PREREAD|POSTREAD doesn't sound useful to me, but > >> why would it be explicitly forbidden? > >> > >> Would you also forbid POSTREAD|PREWRITE? > >> (For a buffer that has just completed a DMA read > >> and is going to be immediately used for a DMA write?) > > > > My thinking on forbidding PREREAD|POSTREAD is at least partly that it > > removes some temptation to do the wrong thing: treat the busdma API as > > if it were a general cpu cache manipulation library. > > I think it should be read as POSTREAD + PREREAD, not PREREAD + POSTREAD. > > > With the new definition of the sequences, a PREREAD|POSTREAD operation > > is nonsensical because it leaves no window during which the DMA hardware > > has access to memory; it is in effect a no-op. If you think in terms of > > implementation you might think "This would have to cause a cache > > invalidation." If you think in terms of API you should be thinking > > something more like "This marks out a time window during which the DMA > > hardware has safe access to that memory which has a duration of zero." > > Acutally, it would allow one to shift the DMA from one device to another, > if read the way I say above. > > > POSTREAD|PREWRITE is interesting. It is not a no-op in terms of the > > API. It closes the hardware access window that was opened by an earlier > > PREREAD, and it opens a new hardware access window with the PREWRITE. > > Whether it touches hardware or caches or anything in a given > > implementation isn't the point, in terms of the API it's the right thing > > to do for a pair of back to back DMA operations, without intervening CPU > > access, on the same memory. > > Right. This is useful in many cases. Consider a log structured device > that reads data into memory, and then writes it back to the tail of the log > as a defragging operation. > > > So PREREAD|POSTREAD and PREWRITE|POSTWRITE make no sense, but all other > > combos should be allowed. Maybe instead of allowing and forbidding > > specific combos, we should just advise that these two are effectively > > no-ops. > > I respectfully disagree.. > > Warner > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmom=nfqNQQNVW6ED0CQ9cFS45GTFzKGLpzkC2TGpc4JC5w>