Re: [PATCH 1/2] USB: Allow HCDs to specifiy their DMA alignment requirements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 4 Sep 2010, Martin Fuzzey wrote:

> The memory returned from usb_alloc_coherent will always
> be aligned to at least 32 bytes (it uses a set of buffer
> pools with 32/128/512/ PAGE_SIZE/2 and uses the
> smallest suitable buffer. [drivers/usb/core/buffer.c]
> 
> So provided the HCD doesn't have alignment requirements
> stricter then 32 byte that should always work.
> I don't think it is possible for drivers to add an offset to
> the result of usb_alloc_coherent() since that would also
> require adjusting the dma_addr_t which is supposed to
> be an opaque handle not an address right?

Not so.  The USB audio driver does this.  It allocates a coherent 
buffer and then logically divides the buffer up into multiple pieces, 
each of which gets used with its own URB.

There are other places where dma_addr_t values are manipulated
numerically, such as in the host controller drivers.

> However, when a driver maps its own buffers and specifies
> URB_NO_TRANSFER_DMA_MAP what are the requirements?
> Does it have to use usb_alloc_coherent()?
> Does it have to use a coherent mapping at all or can it use
> the streaming dma api and sync the buffers manually?

Why would a driver want to sync the buffers manually when usbcore 
already takes care of all that?  Besides, manual syncing won't mix with 
usbmon.

So the answer is that the mapping must be coherent.  And given that, 
there's no reason not to use usb_alloc_coherent.

> If the buffer is not aligned to the _hardware_ requirements
> fixing it (whether in the HCD or usb core and by whatever
> technique - bounce buffer, PIO,..) will require CPU access
> to the buffer. If the buffer is coherently mapped that will
> work but if not it will need to be unmapped or synced first
> (I believe this applies even if the device hardware never
> touches the buffer?)

Yes.

> How is the HCD or usb core to know how a driver mapped
> buffer was obtained to know if and how to sync it?

Obviously there's no way.

> Maybe it's possible to just dma_sync_single_for_cpu()
> in  all cases where cpu access is required (even if the
> buffer was not obtained from dma_map_single). I don't
> know and suspect the answer is likely to be architecture
> dependant so "try it and see" doesn't seem a good idea.

Why go out of your way to create complexity?  Just assume that 
driver-managed mappings must always be coherent.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux