Documentation: i2c: slave: describe buffer problems a bit better
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
This commit is contained in:
Родитель
85946abc96
Коммит
38fa8afff0
|
@ -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
|
||||
|
|
Загрузка…
Ссылка в новой задаче