> > 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:
signature.asc
Description: PGP signature
