bus_dmamap_sync() for bounced client buffers from user address space

[Svatopluk Kraus]

On Wed, Apr 29, 2015 at 3:20 PM, Konstantin Belousov
<kostikbel at gmail.com> wrote:
> On Wed, Apr 29, 2015 at 12:22:19PM +0200, Svatopluk Kraus wrote:
>> If using unmapped buffers is the way we will take to play with user
>> space buffers, then:
>>
>> (1) DMA clients, which support DMA for user space buffers, must use
>> some variant of _bus_dmamap_load_phys(). They must wire physical pages
>> in system anyway.
> No, vm_fault_quick_hold_pages() + bus_dmamap_load_ma().
> Or yes, if you count bus_dmamap_load_ma() as a variant of _load_phys().
> I do not.

There are only two basic functions in MD implementations which all
other functions call: _bus_dmamap_load_phys() and
_bus_dmamap_load_buffer() as a synonym for unmapped buffers and mapped
ones. Are you saying that bus_dmamap_load_ma() should be some third
kind?

>
>> (2) Maybe some better way how to temporarily allocate KVA for unmapped
>> buffers should be implemented.
> See some other mail from me about non-blocking sfbuf allocator with
> callback.

This small list was meant as summary. As I saw your emails in this
thread, I added this point . I did not get that it's already in source
tree.

>
>> (3) DMA clients which already use _bus_dmamap_load_uio() with
>> UIO_USERSPACE must be reimplemented or made obsolete.
> Yes.
>
>> (4) UIO_USERSPACE must be off limit in _bus_dmamap_load_uio() and man
>> page should be changed according to it.
> Yes.


Hmm, I think that for the beginning, _bus_dmamap_load_uio() for
UIO_USERSPACE  can be hacked to use bus_dmamap_load_ma(). Maybe with
some warning to force users of old clients to reimplement them.


>
>> (5) And pmap can be deleted from struct bus_dmamap and all functions
>> which use it as argument. Only kernel pmap will be used in DMA
>> framework.
> Probably yes.
>