[PATCH v6 0/5] i2c: aspeed: added driver for Aspeed I2C
andrew at aj.id.au
Fri Mar 31 11:01:13 AEDT 2017
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
> - Added support for I2C_M_RECV_LEN which I had incorrectly said was supported
> - 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 at aj.id.au>
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: This is a digitally signed message part
More information about the openbmc