Date: Tue, 28 Apr 2015 18:42:45 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jason Harmening <jason.harmening@gmail.com> Cc: John Baldwin <jhb@freebsd.org>, freebsd-arch@freebsd.org, Svatopluk Kraus <onwahe@gmail.com> Subject: Re: bus_dmamap_sync() for bounced client buffers from user address space Message-ID: <20150428154245.GJ2390@kib.kiev.ua> In-Reply-To: <553F9DE2.5080908@gmail.com> References: <CAFHCsPXMjge84AR2cR8KXMXWP4kH2YvuV_uqtPKUvn5C3ygknw@mail.gmail.com> <553B9E64.8030907@gmail.com> <20150425163444.GL2390@kib.kiev.ua> <1876382.0PQNo3Rp24@ralph.baldwin.cx> <553F9DE2.5080908@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 28, 2015 at 09:49:06AM -0500, Jason Harmening wrote: > > Either _bus_dmamap_load_ma or out-of-context UIO_USERSPACE bounce > buffering could have issues with waiting on sfbufs on some arches, > including arm. That could be fixed by making each unmapped bounce > buffer set up a kva mapping for the data addr when it's created, but > that fix might be worse than the problem it's trying to solve. I had an implementation of the sfbuf allocator which never sleeps. If sfbuf was not available without sleep, a callback is called later, when a reusable sf buf is freed. It was written to allow drivers like PIO ATA to take unmapped bios, but I never finished it, at least did not converted a single driver. I am not sure if I can find the branch or is it reasonable to try to rebase it, but the base idea may be useful for the UIO_USERSPACE case as well.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150428154245.GJ2390>