On Sat, 29 Oct 2005, Matthew Orgass wrote:

> On 2005-10-28 plunky@rya-online.net wrote:
>
>> and none of those approaches splvm() so memory allocations should be ok, hm?
>
>  No, memory allocation might sleep, so it needs a process context.

I have nearly always used M_NOWAIT or M_DONTWAIT but, point taken..

relatedly, can one use tsleep from a soft interrupt context?  The time has 
not yet arrived, but I might sometime need to send commands in response to 
events, and sending commands may sleep (because of flow control) so I'm 
thinking I would have to look into replacing the soft interrupt which 
currently services incoming packets with a kthread tsleep/wakeup

>> It may be (certainly is, in fact) that I am unclear on the way the USB
>> code works, documentation is minimal it seems..  not sure why the memory
>> is being allocated in there in any case, as I am providing a buffer though
>> it is not an usbd_alloc_buffer() buffer, was getting the transfer into an
>> MBUF (cluster) data area so I can just pass it off directly.
>
>  The buffer needs to be used for DMA, so it needs to come from bus_dma
> allocation.  Unless you have a usbd_alloc_buffer buffer it will allocate a
> new one.

Hm, I see.. in that case, allocating an mbuf cluster prior to the transfer 
and receiving directly into it may not have been as efficient as I 
imagined.. I will look at it again.

Is usb_transfer_complete() in dev/usb/usbdi.c (and hence my callback) 
called in a process context?  I'm thinking it would likely be a usb_task 
but I can't quite figger it (ie, it would be ok to use m_copyback() in the 
callback routine?)

iain