Date: Tue, 18 Dec 2012 13:32:46 -0700 From: Warner Losh <imp@bsdimp.com> To: Hans Petter Selasky <hselasky@c2i.net> Cc: Oleksandr Tymoshenko <gonzo@freebsd.org>, Andrew Turner <andrew@fubar.geek.nz>, freebsd-usb@freebsd.org Subject: Re: EHCI on armv6 with Write-Back caches Message-ID: <1482FC19-720A-480A-BAD2-C8CD306E2E5F@bsdimp.com> In-Reply-To: <201212182044.11326.hselasky@c2i.net> References: <20121218204931.5322922d@fubar.geek.nz> <201212181306.44926.hselasky@c2i.net> <20121219081229.383d9f41@fubar.geek.nz> <201212182044.11326.hselasky@c2i.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 18, 2012, at 12:44 PM, Hans Petter Selasky wrote: > On Tuesday 18 December 2012 20:12:29 Andrew Turner wrote: >> On Tue, 18 Dec 2012 13:06:44 +0100 >>=20 >> Hans Petter Selasky <hselasky@c2i.net> wrote: >>> Hi Andrew, >>>=20 >>>> The BUS_DMA_COHERENT flag does nothing on armv6 as we need the = cache >>>> enabled for atomic operations to work correctly and we would have = to >>>> disable the cache on the entire page. This is acceptable behaviour >>>> from the description of the flag in the busdma man page. >>>=20 >>> Yes, but when I allocate memory from the USB stack, then I want that >>> memory to not be cached. It is simply not that useful to have that >>> memory cached. I didn't check the latest state of busdma, but if I'm >>> not mistaken, if the BUS_DMA_COHERENT flag is set on the DMA tag, = the >>> flush/invalidate will simply return and do nothing. Maybe that is = the >>> problem ... >>=20 >> The exact meaning of BUS_DMA_COHERENT depends on the architecture. = The >> code is still required to call bus_dmamap_sync with a coherent map = but >> when the flag is implemented the cost of the operation will be = reduced. >> It doesn't guarantee the memory is uncached, it may be implemented = that >> way but the USB code can't rely on it. >>=20 >> Andrew >=20 > The USB code doesn't rely on this flag. I'm wondering if BUSDMA by = accident=20 > sets this flag, so that the cache sync ops are not called. No. It doesn't. Does the USB code still touch bytes in the same cache line while the DMA = is still outstanding? Warner=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1482FC19-720A-480A-BAD2-C8CD306E2E5F>