New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[doc] I2c doc redux #1047
[doc] I2c doc redux #1047
Conversation
FYI: @igk8, @tunghoang290780 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for preparing this PR @martin-lueker! It looks like we're almost there. I've noted a couple style nits, and please squash the commits into one to get CI green (it currently fails since not all commits have a signed-off-by line).
hw/ip/i2c/doc/_index.md
Outdated
|
||
|
||
This feature is not required by the I2C specification. | ||
However it could be used in SMBus applications to support SMBus timeouts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any other SMBus compatibility in this module? If so, this should probably be mentioned in the features section at the top.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, but this was in response to a question by @tjaychen a while ago. I can soften this a bit though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @imphil, please take a look at the revised text to see if that is clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just made it about 1/3 way through, putting these comments out there. will get back to it this weekend.
3838b5c
to
b6c7c35
Compare
Does any one have any idea why the commit lint doesn't like my signoff? |
Your name in the commit is Martin LB, while the signed off by line has your full name. Please use the -s flag to git commit to prevent such problems. |
ca89306
to
ac8c39e
Compare
Thanks @imphil, okay thanks. I saw the author as Martin LB in the log. (I have no idea where that name came from.) A --reset-author fixed it in the log, at least from my machine. It is now listed as Martin Lueker-Boden and the signoff matches. But the CI is still failing. Hmm. Is it perhaps still Martin LB on github? |
Okay, well I don't know why it didn't like the last push, but it seems to be working now. Thanks @imphil! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM on styling and the git commit. Didn't look that much at content, assuming that's already been reviewed in the GDoc.
@sjgitty can you have a look at the content, or suggest someone to review it? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, sorry for the slow review. I have left a few comments for clean up.
hw/ip/i2c/doc/_index.md
Outdated
To read a larger byte stream, multiple 256B reads can be chained together using the RCONT flag. | ||
- RCONT (corresponds to FIFO inputs {{< regref FDATA.RCONT >}}, only used with READ): | ||
If RCONT is set, the Format Byte represents part of a longer sequence of reads, allowing for reads to be chained indefinitely. | ||
The RCONT flag indicates the the final byte returned with the current read |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one line on two lines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
one line on two lines.
Hi @sjgitty, no problem on the delay, I understand. I think I've fixed this one, but could you please look back at this line? I couldn't see the problem (and suspect I actually fixed it a while ago, but didn't commit).
should be responded to which an ACK, allowing the target to continue sending data. | ||
(Note that the first R-1 bytes read will still be acknowledged regardless of whether RCONT is asserted or not.) | ||
- START (corresponds to {{< regref FDATA.START >}}, Ignored when used with READ): | ||
Issue a START condition before transmitting the Format Byte on the bus. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto: sub-bullet for better readability?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ditto: sub-bullet for better readability?
Hi @sjgitty,
If you have a chance, take a look at the latest and see if that is what you had in mind. The current version looks nice in the render.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, looks good thanks
If should be noted that the `scl_interference` interrupt is not raised in the case when the target device is stretching the clock. | ||
(However, it may be raised if the target allows SCL to go high and then pulls SCL down before the end of the current clock cycle.) | ||
|
||
Though normal clock stretching does not count as SCL interference, if the module detects that a target device has held SCL low and stretched the any given SCL cycle for more than {{< regref TIMEOUT_CTRL.VAL >}} clock ticks this will cause the stretch timeout interrupt to be asserted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
some wavejson diagrams for clock stretching would be helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea. I've added a couple in commit 65bc6d7
(Note will be squashed at the end of this)
|
||
To enter override mode, the register field {{< regref OVRD.TXOVRDEN >}} is asserted by software. | ||
In this state the output drivers scl_tx_o and sda_tx_o are controlled directly by the register fields {{< regref OVRD.SCLVAL >}} () and {{< regref OVRD.SDAVAL >}}. | ||
When {{< regref OVRD.SCLVAL >}} and {{< regref OVRD.SDAVAL >}} are set high, the virtual open drain configuration will leave the output resistively pulled high, and controllable by remote targets. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i do not believe virtual open drain is mentioned prior. Would it be helpful to have a brief section talking about integration this IP into the system? And maybe mentioning virtual open drain as one flexible option in addition to real open drain.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @martin-lueker ! sorry for the late reply!
- T<sub>LOW</sub>: set in register {{< regref TIMING0.TLOW >}}. | ||
- T<sub>HIGH</sub>: set in register {{< regref TIMING0.THIGH >}}. | ||
- T<sub>r</sub>: set in register {{< regref TIMING1.T_R >}}. | ||
(Note: The rise time cannot be explicitly controlled by internal hardware, and will be a function of the capacitance of the bus. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this may just be me, but i tend to find an example or two very helpful when discussing setting of timing parameters.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@martin-lueker can you have a look at the review comments and do a (hopefully last) update? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've noticed three minor points below.
Also, it would be good to use the terms "target device" or "target" throughout the document when referring to the target device. In a few places, the term "device" is used. Although one can figure out from context that "target device" is implied, it might confuse someone into thinking that "device" is either "host device" or "target device". Looks good other than that.
Thanks
Translation to Markdown of https://docs.google.com/document/d/1xVGRX7c5jhQyrJ__iubYD2NmKRO7NlXYuspthZIfvfI Minor changes from Google Doc: Elaboration of timing registers. Removal of incomplete section on START, STOP, transmit and read sequences. Removal of section headers related to incompete programmer's manual section (future PR). New to this PR: -Includes minor style guide comments from lowRISC#686. -Hugofied. -Line wrapping sorted out Update 2019-11-22: - Responses to Reviews by @imphil and @sjgitty Nov. 22, 2019 Signed-off-by: Martin Lueker-Boden <martin.lueker-boden@wdc.com> Update 2020-01-10: Maybe changes in response to Dec 3. reviews. Signed-off-by: Martin Lueker-Boden <martin.lueker-boden@wdc.com>
ac8c39e
to
523081b
Compare
Signed-off-by: Martin Lueker-Boden <martin.lueker-boden@wdc.com>
Hi Phillip, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @martin-lueker is this close to landing? Would be good to get some momentum on i2c.
Looks like there are a couple of pending comments.
should be responded to which an ACK, allowing the target to continue sending data. | ||
(Note that the first R-1 bytes read will still be acknowledged regardless of whether RCONT is asserted or not.) | ||
- START (corresponds to {{< regref FDATA.START >}}, Ignored when used with READ): | ||
Issue a START condition before transmitting the Format Byte on the bus. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, looks good thanks
Signed-off-by: Martin Lueker-Boden <martin.lueker-boden@wdc.com>
Yes it is very close. I'm just putting together an example of the timings now. |
To motivate some timing parameter examples requested as part of this PR, lowRISC#1047, the programmers guide was started in order to help explain the examples. The programmers guide at this point only consists of a text description of the tuning algorithm. Also fixed a few minor typos. Signed-off-by: Martin Lueker-Boden <martin.lueker-boden@wdc.com>
These timings are then fed directly to the I2C state machine to control the bus timing. | ||
These timing parameters are then fed directly to the I2C state machine to control the bus timing. | ||
|
||
A detailed description of the algorithm for determining these parameters--as well as a couple of concrete examples--are given in the [Programmers Guide section of this document.]({{<relref "#timing-parameter-tuning-algorithm">}}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Link to nascent Programmers Guide, with examples, as requested by @tjaychen.
@@ -263,6 +265,109 @@ However, all transitions which are dependent on formatting flags are shown expli | |||
|
|||
![](I2C_state_diagram.svg) | |||
|
|||
# Programmers guide |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Programmers Guide created to hold examples of timing parameter generation. C examples to follow in a later pull request.
Alright: @tjaychen, @sjgitty, @igk8, @imphil: With 21fad6f I think we are now good. This (fairly large) commit includes the examples which @tjaychen requested, and the beginnings of a Programmers Guide section to motivate these examples. Unless there are any other points of feedback, I think this PR is done. (Though I acknowledge with such a large commit there is a bit more new text to review, hence my choice to leave it as a new commit rather than squashing/amending it). |
@tjaychen would you mind having a look at this PR again to get it merged soonish? |
thanks for the reminder @imphil |
I'll merge this now. thanks @martin-lueker ! |
Thank /you/ @tjaychen! |
(Repeat PR of #686)
Translation to Markdown of https://docs.google.com/document/d/1xVGRX7c5jhQyrJ__iubYD2NmKRO7NlXYuspthZIfvfI
Minor changes from Google Doc:
Elaboration of timing registers.
Removal of incomplete section on START, STOP, transmit and read sequences.
Removal of section headers related to incompete programmer's manual section (future PR).
New to this PR:
-Includes minor style guide comments from #686.
-Hugofied.
-Line wrapping sorted out (Now that I finally understand the request. Many thanks to @tjaychen and @imphil, and sorry if I gave you too much grief in the meantime.)