xref: /openbmc/linux/Documentation/i2c/dma-considerations.rst (revision 8dd06ef34b6e2f41b29fbf5fc1663780f2524285)
1ccf988b6SMauro Carvalho Chehab=================
2ccf988b6SMauro Carvalho ChehabLinux I2C and DMA
3ccf988b6SMauro Carvalho Chehab=================
4ccf988b6SMauro Carvalho Chehab
5*2f07c05fSLuca CeresoliGiven that I2C is a low-speed bus, over which the majority of messages
6ccf988b6SMauro Carvalho Chehabtransferred are small, it is not considered a prime user of DMA access. At this
7ccf988b6SMauro Carvalho Chehabtime of writing, only 10% of I2C bus master drivers have DMA support
8ccf988b6SMauro Carvalho Chehabimplemented. And the vast majority of transactions are so small that setting up
9ccf988b6SMauro Carvalho ChehabDMA for it will likely add more overhead than a plain PIO transfer.
10ccf988b6SMauro Carvalho Chehab
11ccf988b6SMauro Carvalho ChehabTherefore, it is *not* mandatory that the buffer of an I2C message is DMA safe.
12ccf988b6SMauro Carvalho ChehabIt does not seem reasonable to apply additional burdens when the feature is so
13ccf988b6SMauro Carvalho Chehabrarely used. However, it is recommended to use a DMA-safe buffer if your
14ccf988b6SMauro Carvalho Chehabmessage size is likely applicable for DMA. Most drivers have this threshold
15ccf988b6SMauro Carvalho Chehabaround 8 bytes (as of today, this is mostly an educated guess, however). For
16ccf988b6SMauro Carvalho Chehabany message of 16 byte or larger, it is probably a really good idea. Please
17ccf988b6SMauro Carvalho Chehabnote that other subsystems you use might add requirements. E.g., if your
18ccf988b6SMauro Carvalho ChehabI2C bus master driver is using USB as a bridge, then you need to have DMA
19ccf988b6SMauro Carvalho Chehabsafe buffers always, because USB requires it.
20ccf988b6SMauro Carvalho Chehab
21ccf988b6SMauro Carvalho ChehabClients
22ccf988b6SMauro Carvalho Chehab-------
23ccf988b6SMauro Carvalho Chehab
24ccf988b6SMauro Carvalho ChehabFor clients, if you use a DMA safe buffer in i2c_msg, set the I2C_M_DMA_SAFE
25ccf988b6SMauro Carvalho Chehabflag with it. Then, the I2C core and drivers know they can safely operate DMA
26ccf988b6SMauro Carvalho Chehabon it. Note that using this flag is optional. I2C host drivers which are not
27ccf988b6SMauro Carvalho Chehabupdated to use this flag will work like before. And like before, they risk
28ccf988b6SMauro Carvalho Chehabusing an unsafe DMA buffer. To improve this situation, using I2C_M_DMA_SAFE in
29ccf988b6SMauro Carvalho Chehabmore and more clients and host drivers is the planned way forward. Note also
30ccf988b6SMauro Carvalho Chehabthat setting this flag makes only sense in kernel space. User space data is
31ccf988b6SMauro Carvalho Chehabcopied into kernel space anyhow. The I2C core makes sure the destination
32ccf988b6SMauro Carvalho Chehabbuffers in kernel space are always DMA capable. Also, when the core emulates
33ccf988b6SMauro Carvalho ChehabSMBus transactions via I2C, the buffers for block transfers are DMA safe. Users
34ccf988b6SMauro Carvalho Chehabof i2c_master_send() and i2c_master_recv() functions can now use DMA safe
35ccf988b6SMauro Carvalho Chehabvariants (i2c_master_send_dmasafe() and i2c_master_recv_dmasafe()) once they
36ccf988b6SMauro Carvalho Chehabknow their buffers are DMA safe. Users of i2c_transfer() must set the
37ccf988b6SMauro Carvalho ChehabI2C_M_DMA_SAFE flag manually.
38ccf988b6SMauro Carvalho Chehab
39ccf988b6SMauro Carvalho ChehabMasters
40ccf988b6SMauro Carvalho Chehab-------
41ccf988b6SMauro Carvalho Chehab
42ccf988b6SMauro Carvalho ChehabBus master drivers wishing to implement safe DMA can use helper functions from
43ccf988b6SMauro Carvalho Chehabthe I2C core. One gives you a DMA-safe buffer for a given i2c_msg as long as a
44ccf988b6SMauro Carvalho Chehabcertain threshold is met::
45ccf988b6SMauro Carvalho Chehab
46ccf988b6SMauro Carvalho Chehab	dma_buf = i2c_get_dma_safe_msg_buf(msg, threshold_in_byte);
47ccf988b6SMauro Carvalho Chehab
48ccf988b6SMauro Carvalho ChehabIf a buffer is returned, it is either msg->buf for the I2C_M_DMA_SAFE case or a
49ccf988b6SMauro Carvalho Chehabbounce buffer. But you don't need to care about that detail, just use the
50ccf988b6SMauro Carvalho Chehabreturned buffer. If NULL is returned, the threshold was not met or a bounce
51ccf988b6SMauro Carvalho Chehabbuffer could not be allocated. Fall back to PIO in that case.
52ccf988b6SMauro Carvalho Chehab
53ccf988b6SMauro Carvalho ChehabIn any case, a buffer obtained from above needs to be released. Another helper
54ccf988b6SMauro Carvalho Chehabfunction ensures a potentially used bounce buffer is freed::
55ccf988b6SMauro Carvalho Chehab
56ccf988b6SMauro Carvalho Chehab	i2c_put_dma_safe_msg_buf(dma_buf, msg, xferred);
57ccf988b6SMauro Carvalho Chehab
58ccf988b6SMauro Carvalho ChehabThe last argument 'xferred' controls if the buffer is synced back to the
59ccf988b6SMauro Carvalho Chehabmessage or not. No syncing is needed in cases setting up DMA had an error and
60ccf988b6SMauro Carvalho Chehabthere was no data transferred.
61ccf988b6SMauro Carvalho Chehab
62ccf988b6SMauro Carvalho ChehabThe bounce buffer handling from the core is generic and simple. It will always
63ccf988b6SMauro Carvalho Chehaballocate a new bounce buffer. If you want a more sophisticated handling (e.g.
64ccf988b6SMauro Carvalho Chehabreusing pre-allocated buffers), you are free to implement your own.
65ccf988b6SMauro Carvalho Chehab
66ccf988b6SMauro Carvalho ChehabPlease also check the in-kernel documentation for details. The i2c-sh_mobile
67ccf988b6SMauro Carvalho Chehabdriver can be used as a reference example how to use the above helpers.
68ccf988b6SMauro Carvalho Chehab
69ccf988b6SMauro Carvalho ChehabFinal note: If you plan to use DMA with I2C (or with anything else, actually)
70ccf988b6SMauro Carvalho Chehabmake sure you have CONFIG_DMA_API_DEBUG enabled during development. It can help
71ccf988b6SMauro Carvalho Chehabyou find various issues which can be complex to debug otherwise.
72