Request for feedback on common data backstore in the kernel

[Scott Long]

Hans Petter Selasky wrote:
> On Thursday 27 September 2007, Scott Long wrote:
>> Hans Petter Selasky wrote:
> 
>>> I'm thinking about putting some wrappers around the "bus_dmamap_load()"
>>> function like:
>>>
>>> void usbd_rx_buf_load(struct usbd_xfer *xfer, void *buf,
>>>   uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len);
>>>
>>> void usbd_tx_buf_load(struct usbd_xfer *xfer, void *buf,
>>>   uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len);
>>>
>>> But I haven't figured out all the details yet. The "usbd_xxx_load()"
>>> functions should automagically figure out what is best to do and it won't
>>> be more than a few lines of code.
>> Can you describe what these two wrappers are supposed to do? 
> 
> Basically these wrappers will setup the DMA address for the USB HC driver. If 
> they need to copy data they will copy data.

Bouncing/copying is built into the busdma API.  If there's a reason to 
duplicate that logic in USB, please let me know.

> 
>> Are you expecting bus_dmamap_load() to operate synchronously?
> 
> Yes. I assume that "bus_dmamap_load()" can sleep and consequently needs a 
> thread context.

Actually, it's the opposite.  The API is meant to NOT block, it is meant
to run in whatever context you want, and it'll provide it's own context
for delayed loads to run in.  This is very different than NetBSD, so if
you haven't read the man page yet, I'd recommend doing so.

Scott