i2c: refactor function to release a DMA safe buffer

a) rename to 'put' instead of 'release' to match 'get' when obtaining
   the buffer
b) change the argument order to have the buffer as first argument
c) add a new argument telling the function if the message was
   transferred. This allows the function to be used also in cases
   where setting up DMA failed, so the buffer needs to be freed without
   syncing to the message buffer.

Also convert the only user.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This commit is contained in:
Wolfram Sang
2018-08-24 16:52:44 +02:00
committed by Wolfram Sang
parent 1204d12a49
commit 82fe39a6bc
4 changed files with 15 additions and 10 deletions

View File

@@ -50,10 +50,14 @@ bounce buffer. But you don't need to care about that detail, just use the
returned buffer. If NULL is returned, the threshold was not met or a bounce
buffer could not be allocated. Fall back to PIO in that case.
In any case, a buffer obtained from above needs to be released. It ensures data
is copied back to the message and a potentially used bounce buffer is freed::
In any case, a buffer obtained from above needs to be released. Another helper
function ensures a potentially used bounce buffer is freed::
i2c_release_dma_safe_msg_buf(msg, dma_buf);
i2c_put_dma_safe_msg_buf(dma_buf, msg, xferred);
The last argument 'xferred' controls if the buffer is synced back to the
message or not. No syncing is needed in cases setting up DMA had an error and
there was no data transferred.
The bounce buffer handling from the core is generic and simple. It will always
allocate a new bounce buffer. If you want a more sophisticated handling (e.g.