Hi,
On 01/24/2017 10:51 AM, Andy Shevchenko wrote:
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?
That is why the goto out gets introduced, baytrail_i2c_release()
and reset_semaphore() are functionally equivalent,
baytrail_i2c_release() does a bunch of argument error checking
and then calls reset_semaphore().
Regards,
Hans
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);
}
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
