* Russell King - ARM Linux <linux@xxxxxxxxxxxxxxx> [181206 18:08]:
> reverted, the problem is still there. Revert:
>
> ec0daae685b2 ("gpio: omap: Add level wakeup handling for omap4 based SoCs")
>
> on top, and networking returns to normal. So it appears to be this
> last commit causing the issue.
>
> With that and b764a5863fd8 applied, it still misbehaves. Then, poking
> at the OMAP4_GPIO_IRQWAKEN0 register, changing it from 0 to 4 with
> devmem2 restores normal behaviour - ping times are normal and NFS is
> happy.
>
> # devmem2 0x48055044 w 4
OK thanks.
> Given that this GPIO device is not runtime suspended, and is
> permanently active (which is what I think we expect, given that it
> has an IRQ claimed against it) does the hardware still attempt to
> idle the GPIO block - if so, could that be why we need to program
> the wakeup register, so the GPIO block signals that it's active?
Yes we now idle non-irq GPIOs only from CPU_CLUSTER_PM_ENTER
as the selected cpuidle state triggers the domain transitions
with WFI. And that's why runtime_suspended_time does not increase
for a GPIO instance with IRQs.
I can reproduce the long ping latencies on duovero smsc connected
to gpio_44, I'll try to debug it more.
Regards,
Tony
