Date: Wed, 8 Jul 2015 12:51:34 -0500 From: Jason Harmening <jason.harmening@gmail.com> To: Adrian Chadd <adrian.chadd@gmail.com> Cc: Ian Lepore <ian@freebsd.org>, Zbigniew Bodek <zbb@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r285270 - head/sys/sys Message-ID: <CAM=8qanqZRoC34zwJdPUHFjw0cDa4oZT6o5ckKq=9og4oADZ0Q@mail.gmail.com> In-Reply-To: <CAJ-Vmo=V5J98J=tvmtgnuVtsR_DEjHs=%2BK1=V5WRcPJWZDkdPg@mail.gmail.com> References: <201507081353.t68Dr0up028388@repo.freebsd.org> <CAJ-Vmoku0OzPU=v6X3jb04EQqXXrgSFC9=iFxO8JYCri=XX4XQ@mail.gmail.com> <1436366547.1334.81.camel@freebsd.org> <CAJ-Vmo=V5J98J=tvmtgnuVtsR_DEjHs=%2BK1=V5WRcPJWZDkdPg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
+2 This has always bugged me. I'll do it if no one else gets to it first. If the new pmap KPI makes it in, I'll be messing with a bunch of the MD busdma code anyway. On Wed, Jul 8, 2015 at 9:47 AM, Adrian Chadd <adrian.chadd@gmail.com> wrote: > On 8 July 2015 at 07:42, Ian Lepore <ian@freebsd.org> wrote: > > On Wed, 2015-07-08 at 07:30 -0700, Adrian Chadd wrote: > >> Why is this implemented in sys/sys/bus_dma.h, rather than in a machdep > header? > >> > >> > > > > Indeed, this stuff is a mess that really needs to be cleaned up. The > > pre-existing assumption that MI functions don't need to be called, just > > because one of the parameters of that function has some value that has a > > special meaning on one platform, is purely x86-MD code in an MI header > > file. This change just complicates the existing mess. > > +1 > > (So who's going to do it? I'm already taken.) > > > > -a > > >> -a > >> > >> > >> On 8 July 2015 at 06:53, Zbigniew Bodek <zbb@freebsd.org> wrote: > >> > Author: zbb > >> > Date: Wed Jul 8 13:52:59 2015 > >> > New Revision: 285270 > >> > URL: https://svnweb.freebsd.org/changeset/base/285270 > >> > > >> > Log: > >> > Add memory barrier to bus_dmamap_sync() > >> > > >> > On platforms which are fully IO-coherent, the map might be null. > >> > We need to guarantee that all data is observable after the > >> > sync operation is called. Add a memory barrier to ensure that on > ARM. > >> > > >> > Reviewed by: andrew, kib > >> > Obtained from: Semihalf > >> > Sponsored by: The FreeBSD Foundation > >> > Differential Revision: https://reviews.freebsd.org/D3012 > >> > > >> > Modified: > >> > head/sys/sys/bus_dma.h > >> > > >> > Modified: head/sys/sys/bus_dma.h > >> > > ============================================================================== > >> > --- head/sys/sys/bus_dma.h Wed Jul 8 13:19:13 2015 > (r285269) > >> > +++ head/sys/sys/bus_dma.h Wed Jul 8 13:52:59 2015 > (r285270) > >> > @@ -282,13 +282,25 @@ int bus_dmamem_alloc(bus_dma_tag_t dmat, > >> > void bus_dmamem_free(bus_dma_tag_t dmat, void *vaddr, bus_dmamap_t > map); > >> > > >> > /* > >> > - * Perform a synchronization operation on the given map. > >> > + * Perform a synchronization operation on the given map. If the map > >> > + * is NULL we have a fully IO-coherent system. On every ARM > architecture > >> > + * there must be a memory barrier placed to ensure that all data > >> > + * accesses are visible before going any further. > >> > */ > >> > void _bus_dmamap_sync(bus_dma_tag_t, bus_dmamap_t, bus_dmasync_op_t); > >> > +#if defined(__arm__) > >> > + #define __BUS_DMAMAP_SYNC_DEFAULT mb(); > >> > +#elif defined(__aarch64__) > >> > + #define __BUS_DMAMAP_SYNC_DEFAULT dmb(sy); > >> > +#else > >> > + #define __BUS_DMAMAP_SYNC_DEFAULT {} > >> > +#endif > >> > #define bus_dmamap_sync(dmat, dmamap, op) \ > >> > do { \ > >> > if ((dmamap) != NULL) \ > >> > _bus_dmamap_sync(dmat, dmamap, op); \ > >> > + else \ > >> > + __BUS_DMAMAP_SYNC_DEFAULT \ > >> > } while (0) > >> > > >> > /* > >> > > >> > > > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM=8qanqZRoC34zwJdPUHFjw0cDa4oZT6o5ckKq=9og4oADZ0Q>