> Yes, but the statistics that 10% of I2C bus master drivers > are DMA-safe is not true, if you take those into account ;-) > > Perhaps you could write it as (or something similar): > > At this time of writing, only +10% of I2C bus master > drivers for non-remote boards have DMA support implemented. No, this is confusing IMO. Being remote has nothing to with DMA. What has to do with DMA is that these are using USB as communication channel. And USB clearly needs DMA-safe buffers. The encapsulation needs DMA-safe buffers. So, I think the new sentence "other subsystems might impose" mentions that. Let me recap what this series is for: a) It makes clear that I2C subsystem does not require DMA-safety because for the reasons given in the textfile. If I2C is encapsulated over USB, then DMA-safety is of course required, but this comes from USB. So, those USB-I2C master drivers need to do something to make sure DMA-safety is guaranteed because i2c_msg buffers don't need to be DMA safe because of a). They could use the newly introduced features, but they don't have to. b) a flag for DMA safe i2c_msgs is added So, for messages we know to be DMA safe, we can flag that. Drivers could check that and use a bounce buffer if the flag is not set. However, this is all optional. Your drivers can still choose to not check the flag and everything will stay as before. Check patch 5 for a use case. c) helper functions for bounce buffers are added These are *helper* functions for drivers wishing to do DMA. A super simple bounce buffer support. Check patch 4 for a use case. Again, this is optional. Drivers can implement their own bounce buffer support. Or, as in your case, if you know that your buffers are good, then don't use any of this and things will keep going. This all is to allow bus master drivers to opt-in for DMA safety if they want to do DMA directly. Because currently, with a lot of i2c_msgs on stack, this is more or less working accidently. And, yes, I know I have to add this new flag to a few central places in client drivers. Otherwise, master drivers checking for DMA safety will initially have a performance regression. This is scheduled for V5 and mentioned in this series. > In the past, on lots of drivers, the i2c_xfer logic just used to assume > that the I2C client driver allocated a DMA-safe buffer, as it just used to > pass whatever buffer it receives directly to USB core. We did an effort to > change it, as it can be messy, but I'm not sure if this is solved everywhere. Good, I can imagine this being some effort. But again, this is because USB needs the DMA-safety, not I2C. AFAICS, most i2c_msgs are register accesses and thus, small messages. > The usage of I2C at the media subsystem predates the I2C subsystem. > at V4L2 drivers, a great effort was done to port it to fully use the > I2C subsystem when it was added upstream, but there were some problems > a the initial implementation of the i2c subsystem that prevented its > usage for the DVB drivers. By the time such restrictions got removed, > it was too late, as there were already a large amount of drivers relying > on i2c "low level" functions. Didn't know that, but this is good to know! Thanks. > Even on the drivers that use i2c_add_adapter(), the usage of DMA can't > be get by the above grep, as the DMA usage is actually at drivers/usb. Ok. But as said before, what works now will continue to work. This series is about clarifying that i2c_msg buffers need not to be DMA safe and offering some helpers for those bus master drivers wanting to opt-in to be sure. Clearer now? Regards, Wolfram
Attachment:
signature.asc
Description: PGP signature
