On Mon, 2017-03-27 at 22:12 -0700, Brendan Higgins wrote: > Sorry for the delay, I went on a long vacation prior to receiving feedback and > got back in the middle of a hardware bring up that consumed all of my attention > for an extended period of time. I will try to plan upstream submissions around > my other responsibilities better in the future. > > Addressed comments from: > - Vladimir in: https://www.spinics.net/lists/linux-i2c/msg27387.html > and: https://www.spinics.net/lists/linux-i2c/msg27386.html > - Wolfram in: https://www.spinics.net/lists/linux-i2c/msg27476.html > and: https://www.spinics.net/lists/linux-i2c/msg27483.html > > Changes since previous update: > - No longer arbitrarily restrict bus to be slave xor master. > - Pulled out "struct aspeed_i2c_controller" as a interrupt controller. > - Pulled out slave support into its own commit. > - Rewrote code that sets clock divider register because the original version > set it incorrectly. > - Discovered and fixed issue in implementation that caused certain slave > devices to misbehave; the cause was that the master IRQ handler would return > control to the requesting thread after the last RX or TX command was handled > such that the requesting thread would issue either a repeated start or stop. > This was incorrect because the time taken to complete the completion was too > great. I fixed this by rewriting the master IRQ handler so that it now > manages the entire transaction only returning control to the requesting > thread once the entire transaction is complete. > - Rewrote the aspeed_i2c_master_irq handler because the old method of > completing a completion in between restarts was too slow causing devices to > misbehave. > - Added support for I2C_M_RECV_LEN which I had incorrectly said was supported > before. > - Addressed other comments from Vladimir. > > Changes have been tested on the Aspeed 2500 evaluation board, as before, and now > on a real platform with an Aspeed 2520. Looks like there's going to be another revision of the series, but regardless, I've applied and tested v6 and had no issues. So: Tested-by: Andrew Jeffery <andrew@xxxxxxxx>
Attachment:
signature.asc
Description: This is a digitally signed message part
