On Mon, 2017-01-23 at 22:09 +0100, Hans de Goede wrote: > On my cherrytrail tablet with axp288 pmic, just doing a bunch of > repeated > reads from the pmic, e.g. "i2cdump -y 14 0x34" would lookup the tablet > in > 1 - 3 runs guaranteed. > > This seems to be causes by the cpu trying to enter C6 or C7 while we > hold > the punit bus semaphore, at which point everything just hangs. > > Avoid this by disallowing the CPU to enter C6 or C7 before acquiring > the > punit bus semaphore. > Changes in v5: > -Update the pm_qos for a latency of 0 *before* requesting the > semaphore, > instead of doing it while waiting for the request to be acked So, that's why you put to reset_semaphore() instead of baytrail_i2c_release(), right? I perhaps missed your answer to my comment about that. > > @@ -56,6 +57,8 @@ static void reset_semaphore(struct dw_i2c_dev > > *dev) > data &= ~PUNIT_SEMAPHORE_BIT; > if (iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_REG_WRITE, > PUNIT_SEMAPHORE, data)) > dev_err(dev->dev, "iosf failed to reset punit > semaphore during write\n"); > + > + pm_qos_update_request(&dev->pm_qos, PM_QOS_DEFAULT_VALUE); > } -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
