brain-hackers_pepepper-mirror/linux-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/linux-brain.git synced 2024-06-09 23:36:23 +09:00
Code Issues Projects Releases Wiki Activity

Documentation: i2c: slave: describe buffer problems a bit better

Browse Source 
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This commit is contained in:
Wolfram Sang 2016-07-23 21:59:21 +02:00
parent 85946abc96
commit 38fa8afff0
1 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
Documentation/i2c/slave-interface
View File

@ -173,13 +173,14 @@ During development of this API, the question of using buffers instead of just
bytes came up. Such an extension might be possible, usefulness is unclear at
this time of writing. Some points to keep in mind when using buffers:
* Buffers should be opt-in and slave drivers will always have to support
byte-based transactions as the ultimate fallback because this is how the
majority of HW works.
* Buffers should be opt-in and backend drivers will always have to support
byte-based transactions as the ultimate fallback anyhow because this is how
the majority of HW works.
* For backends simulating hardware registers, buffers are not helpful because
on writes an action should be immediately triggered. For reads, the data in
the buffer might get stale.
* For backends simulating hardware registers, buffers are largely not helpful
because after each byte written an action should be immediately triggered.
For reads, the data kept in the buffer might get stale if the backend just
updated a register because of internal processing.
* A master can send STOP at any time. For partially transferred buffers, this
means additional code to handle this exception. Such code tends to be