i2c: davinci: Fix problems discovered on Keystone CPU
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest3 patches 12 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | i2c: davinci: Rework racy ISRdrivers/ | +95 | 4 replies | |
| 2/3 | i2c: davinci: Refactor i2c_davinci_wait_bus_not_busy()drivers/ | +30 | 5 replies | |
| 3/3 | i2c: davinci: Avoid sending to own addressdrivers/ | +6 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 0/3] i2c: davinci: Fix problems discovered on Keystone CPU
During intensive I2C tests on Keystone CPU we've discovered several problems with the i2c-davinci driver. Maybe Keystone is the first relatively powerful CPU utilizing davinci controller and therefore the races in the driver became more obvious, but it's clear that many users had problems with the driver and even though driver has received many band aids over the years, nobody addressed the original racy design.
The series address the follwing problems:
"i2c: davinci: Rework racy ISR" -- stop the parallel activities in the driver including concurrect registers access. Also simplifies the design and removes some bad aids.
"i2c: davinci: Refactor i2c_davinci_wait_bus_not_busy()" -- the routine is over-designed and instead of "waiting" will trigger the bus recovering immediately.
"i2c: davinci: Avoid sending to own address" -- works around one davinci controller issue when it unexpectedly switches to some sort of slave mode trying to send to its own address. The controller remains in this locked state until reset, so it's better to avoid this situation than to deal with transfer timeouts.