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