Orange Pi5 kernel

^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  1) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  2) Linux I2C and DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  3) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  4) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  5) Given that I2C is a low-speed bus, over which the majority of messages
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  6) transferred are small, it is not considered a prime user of DMA access. At this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  7) time of writing, only 10% of I2C bus master drivers have DMA support
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  8) implemented. And the vast majority of transactions are so small that setting up
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300  9) DMA for it will likely add more overhead than a plain PIO transfer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) Therefore, it is *not* mandatory that the buffer of an I2C message is DMA safe.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) It does not seem reasonable to apply additional burdens when the feature is so
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) rarely used. However, it is recommended to use a DMA-safe buffer if your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) message size is likely applicable for DMA. Most drivers have this threshold
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) around 8 bytes (as of today, this is mostly an educated guess, however). For
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) any message of 16 byte or larger, it is probably a really good idea. Please
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) note that other subsystems you use might add requirements. E.g., if your
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) I2C bus master driver is using USB as a bridge, then you need to have DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) safe buffers always, because USB requires it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) Clients
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) -------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) For clients, if you use a DMA safe buffer in i2c_msg, set the I2C_M_DMA_SAFE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25) flag with it. Then, the I2C core and drivers know they can safely operate DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) on it. Note that using this flag is optional. I2C host drivers which are not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) updated to use this flag will work like before. And like before, they risk
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) using an unsafe DMA buffer. To improve this situation, using I2C_M_DMA_SAFE in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) more and more clients and host drivers is the planned way forward. Note also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) that setting this flag makes only sense in kernel space. User space data is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) copied into kernel space anyhow. The I2C core makes sure the destination
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) buffers in kernel space are always DMA capable. Also, when the core emulates
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) SMBus transactions via I2C, the buffers for block transfers are DMA safe. Users
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) of i2c_master_send() and i2c_master_recv() functions can now use DMA safe
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) variants (i2c_master_send_dmasafe() and i2c_master_recv_dmasafe()) once they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) know their buffers are DMA safe. Users of i2c_transfer() must set the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) I2C_M_DMA_SAFE flag manually.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) Masters
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) -------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) Bus master drivers wishing to implement safe DMA can use helper functions from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) the I2C core. One gives you a DMA-safe buffer for a given i2c_msg as long as a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) certain threshold is met::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) 	dma_buf = i2c_get_dma_safe_msg_buf(msg, threshold_in_byte);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) If a buffer is returned, it is either msg->buf for the I2C_M_DMA_SAFE case or a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) bounce buffer. But you don't need to care about that detail, just use the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) returned buffer. If NULL is returned, the threshold was not met or a bounce
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) buffer could not be allocated. Fall back to PIO in that case.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) In any case, a buffer obtained from above needs to be released. Another helper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) function ensures a potentially used bounce buffer is freed::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) 	i2c_put_dma_safe_msg_buf(dma_buf, msg, xferred);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) The last argument 'xferred' controls if the buffer is synced back to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) message or not. No syncing is needed in cases setting up DMA had an error and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) there was no data transferred.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) The bounce buffer handling from the core is generic and simple. It will always
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) allocate a new bounce buffer. If you want a more sophisticated handling (e.g.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) reusing pre-allocated buffers), you are free to implement your own.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) Please also check the in-kernel documentation for details. The i2c-sh_mobile
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) driver can be used as a reference example how to use the above helpers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) 
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) Final note: If you plan to use DMA with I2C (or with anything else, actually)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) make sure you have CONFIG_DMA_API_DEBUG enabled during development. It can help
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) you find various issues which can be complex to debug otherwise.