Re: RE: [PATCH v3 0/2] usb: Check for DMA capable buffer sanity

[Wolfram Sang <wsa@the-dreams.de>]

[-- Attachment #1: Type: text/plain, Size: 1609 bytes --]


> > Possibly more useful would be a variant of (IIRC) dma_map_for_device()
> > that will allocate a suitable bounce buffer for non-dma memory.
> > I think it can already do so for memory that is outside the address
> > range that the device can address (eg for a 32bit PCIe master in 64bit
> > system).
> > 
> 
> Such generic DMA API would be greatly useful!
> 
> I tried adding bounce buffers support to handle vmalloc'd buffers in
> MTD/SPI subsystem. But, there was a need felt for generic DMA API that
> can allocate bounce buffer for non-dma'able buffers that all drivers can
> make use of[1][2]

Yes, I see this DMA API would make sense for subsystems like SPI, MTD or
USB. For I2C, I don't think it makes a lot of sense because DMA is
rarely used there. Most hardware doesn't even have DMA support and if
so, the drivers apply a threshold (say 8 bytes) because most I2C
transfers are smaller and setting up DMA for that simply doesn't pay
off. And we are still talking of a mostly 100 or 400 kHz bus here.

So, I'd prefer a lightweight helper function telling if DMA is
possible/feasible for a given I2C message. If so, do it. If not, falling
back to PIO might be good enough for now. We can implement bounce buffer
support in the above helper function later. I don't really want to
enforce DMA capable buffers for I2C transactions when DMA is so rarely
needed there.

So, if I2C is a bit different, then it might simply make sense to keep
the function local for I2C now? This seems like a sensible start to me
meanwhile.

Thanks to all for the helpful input here!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]