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 Thu, Sep 2, 2010 at 6:32 PM, David Brownell <david-b@xxxxxxxxxxx> wrote:
>
>
> --- On Thu, 9/2/10, Oliver Neukum <oneukum@xxxxxxx> wrote:
>
>> >
>> >
>> > Passing a pointer to a few bytes inside of a
>> > kmalloc'd block has always been legit, even if
>> > that pointer isn't aligned to N!=1 bytes.
>>
>> Is that also true with respect to usb_alloc_coherent() ?
>
> Why wouldn't it be?  The buffer pointer is valid...
>
>
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?

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?

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?)

How is the HCD or usb core to know how a driver mapped
buffer was obtained to know if and how to sync it?
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.

Regards,
Martin
--
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