| Message ID | 20170814201726.21045-4-hdegoede@redhat.com |
|---|---|
| State | Accepted |
| Headers | show |
On Mon, Aug 14, 2017 at 10:17:26PM +0200, Hans de Goede wrote: > The Cherry Trail Whiskey Cove PMIC's IRQ line is attached to one of > the GPIOs of the Cherry Trail SoC. The CHT GPIO controller sometimes > fails to deliver IRQs (seen when there is an IRQ storm on another pin). > > This commit works around this by reducing the long timeout which was > a poor attempt to workaround this from 3s to 30ms and after that > manually checking the status register for transfer completion by > calling the threaded IRQ handler directly. > > This is safe todo as the entire threaded IRQ handler is protected > by a mutex. > > Note 30ms should be more then long enough, at 100KHz any smbus single > byte transaction should be finished in 4ms. > > Signed-off-by: Hans de Goede <hdegoede@redhat.com> Applied to for-next, thanks!
diff --git a/drivers/i2c/busses/i2c-cht-wc.c b/drivers/i2c/busses/i2c-cht-wc.c index 11f7e516f1b1..21312eed09e4 100644 --- a/drivers/i2c/busses/i2c-cht-wc.c +++ b/drivers/i2c/busses/i2c-cht-wc.c @@ -158,10 +158,16 @@ static int cht_wc_i2c_adap_smbus_xfer(struct i2c_adapter *_adap, u16 addr, if (ret) return ret; - /* 3 second timeout, during cable plug the PMIC responds quite slow */ - ret = wait_event_timeout(adap->wait, adap->done, 3 * HZ); - if (ret == 0) - return -ETIMEDOUT; + ret = wait_event_timeout(adap->wait, adap->done, msecs_to_jiffies(30)); + if (ret == 0) { + /* + * The CHT GPIO controller serializes all IRQs, sometimes + * causing significant delays, check status manually. + */ + cht_wc_i2c_adap_thread_handler(0, adap); + if (!adap->done) + return -ETIMEDOUT; + } ret = 0; mutex_lock(&adap->adap_lock);
The Cherry Trail Whiskey Cove PMIC's IRQ line is attached to one of the GPIOs of the Cherry Trail SoC. The CHT GPIO controller sometimes fails to deliver IRQs (seen when there is an IRQ storm on another pin). This commit works around this by reducing the long timeout which was a poor attempt to workaround this from 3s to 30ms and after that manually checking the status register for transfer completion by calling the threaded IRQ handler directly. This is safe todo as the entire threaded IRQ handler is protected by a mutex. Note 30ms should be more then long enough, at 100KHz any smbus single byte transaction should be finished in 4ms. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/i2c/busses/i2c-cht-wc.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)