diff options
author | Matthew Blecker <matthewb@google.com> | 2019-09-26 09:36:40 -0700 |
---|---|---|
committer | Matthew Blecker <matthewb@chromium.org> | 2019-09-27 00:38:19 +0000 |
commit | 2d74095e5c923e40e6230f803537c1e968fd2631 (patch) | |
tree | b6e2061bb3f7fcaa72faa7ff11ae6df0618bf2ff /extra | |
parent | 23932a57f30994297b9749f432b46d6f267e890d (diff) | |
download | chrome-ec-2d74095e5c923e40e6230f803537c1e968fd2631.tar.gz |
i2c-pseudo: Minor documentation fixes and clarifications.
BRANCH=none
BUG=none
TEST=Viewed the updated file in Gitiles.
Change-Id: Icd10a54500a2521e4d598997385916d59dd38ab3
Signed-off-by: Matthew Blecker <matthewb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1827239
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Diffstat (limited to 'extra')
-rw-r--r-- | extra/i2c_pseudo/Documentation.txt | 20 |
1 files changed, 12 insertions, 8 deletions
diff --git a/extra/i2c_pseudo/Documentation.txt b/extra/i2c_pseudo/Documentation.txt index d8c74653cb..a97786e9b2 100644 --- a/extra/i2c_pseudo/Documentation.txt +++ b/extra/i2c_pseudo/Documentation.txt @@ -73,7 +73,7 @@ Read Command: I2C_ADAPTER_NUM <num> Example: "I2C_ADAPTER_NUM 5\n" Details: This is read in response to the GET_ADAPTER_NUM command being written. -The number is the I2C adapter number in decimal. This is can only occur after +The number is the I2C adapter number in decimal. This can only occur after ADAPTER_START, because before that the number is not known and cannot be predicted reliably. @@ -90,10 +90,10 @@ Example: "I2C_BEGIN_XFER\n" Details: This indicates the start of an I2C transaction request, in other words the start of the I2C messages from a single invocation of the I2C adapter's -master_xfer() callback. This should only ever be read after ADAPTER_START. +master_xfer() callback. This can only occur after ADAPTER_START. -Read Command: I2C_XFER_REQ <xfer_id> <msg_id> <addr> <flags> <data_len> [<write_byte>, ...] +Read Command: I2C_XFER_REQ <xfer_id> <msg_id> <addr> <flags> <data_len> [<write_byte>[:...]] Example: "I2C_XFER_REQ 3 0 0x0070 0x0000 2 AB:9F\n" Example: "I2C_XFER_REQ 3 1 0x0070 0x0001 4\n" @@ -111,9 +111,9 @@ there can never be multiple outstanding transactions with the same ID, due to an internal limit in i2c-pseudo that will block master_xfer() calls when the controller is falling behind in its replies. -The msg_id is a number representing the index of the I2C message within its -transaction, in other words the index in master_xfer() *msgs array arg. This -starts at 0 after each I2C_BEGIN_XFER. This is guaranteed to not wrap. +The msg_id is a decimal number representing the index of the I2C message within +its transaction, in other words the index in master_xfer() *msgs array arg. +This starts at 0 after each I2C_BEGIN_XFER. This is guaranteed to not wrap. The addr is the hexadecimal I2C address for this I2C message. @@ -191,7 +191,7 @@ counter wraps. I2C clients can use this to track specific instances of pseudo adapters, even when adapter numbers have been reused. -Write Command: I2C_XFER_REPLY <xfer_id> <msg_id> <addr> <flags> <errno> [<read_byte>, ...] +Write Command: I2C_XFER_REPLY <xfer_id> <msg_id> <addr> <flags> <errno> [<read_byte>[:...]] Example: "I2C_XFER_REPLY 3 0 0x0070 0x0000 0\n" Example: "I2C_XFER_REPLY 3 1 0x0070 0x0001 0 0B 29 02 D9\n" @@ -225,11 +225,15 @@ perfectly valid to close the controller device fd without ever using this command. This commands unblocks any blocked controller I/O (reads, writes, or polls), and -that is its main reason for existing. +that is its main purpose. Any I2C transactions attempted by a device driver after this command will fail, and will not be passed on to the userspace controller. +This DOES NOT delete the I2C adapter. Only closing the fd will do that. That +MAY CHANGE in the future, such that this does delete the I2C adapter. (However +this will never be required, it will always be okay to simply close the fd.) + ----Example userspace controller code---- |