Hi Frieder,

Am Donnerstag, dem 20.05.2021 um 17:16 +0200 schrieb Frieder Schrempf:

On 19.05.21 18:09, Frieder Schrempf wrote:

quoted

On 06.05.21 10:32, Frieder Schrempf wrote:

quoted

On 06.05.21 03:04, Peng Fan (OSS) wrote:

quoted

From: Peng Fan <peng.fan@nxp.com>


V2:
 - Add R-b/A-b tag
 - Merge V1 patch 13 to V2 patch 6
 - Drop V1 patch 15
 - Merge V1 patch 16 to V2 patch 5 and add comments in patch 5
to explain
 details
 - Add explaination in patch 8 for "why the resets are not
defined"

This patchset is a pick up Lucas's gpcv2 work for i.MX8MM and
several
minor changes from me to make it could work with i.MX BLK-CTL
driver.

Thanks for Lucas's work and suggestion, Frieder Schrempf for
collecting
all the patches, Jacky Bai on help debug issues.

I tested this series together with the BLK CTL patches by using
the GPU and the display stack. Everything looks good to me.

Tested-by: Frieder Schrempf <redacted>

So after some more testing on different hardware I stumbled upon
the problem that USB autosuspend doesn't work properly anymore.

I have an onboard LTE module that is connected to OTG2 on the
i.MX8MM. When using the mainline TF-A (that enables USB power-
domains by default) and removing the power-domain control from the
kernel, the device comes up after a few seconds and is enumerated
on the bus.

Now, when I let the kernel control the power-domains, the device
comes up at boot, but isn't enumerated on the USB bus. As soon as I
disable autosuspend for the port, it comes up.

Is this something that needs to be fixed on the USB driver side or
is something to be considered for the GPCv2 driver?

So I think this is something that needs to be covered on the USB
driver side. I would expect that a device appearing on the bus should
resume the autosuspended bus, but I don't really know much about USB
so there might be other things I miss. For now I will disable
autosuspend in this case.

A different, probably more severe problem is that I was still able to
reliably run into lockups with suspend/resume and the GPU. I thought
I had tested this before as it was one of the things that already
failed with the previous implementation, but I must have missed
something as it still fails with kernel v5.12.1 + v2 of the GPC
patches.

This is how I run into the lockup:

echo mem > /sys/power/state  # Sleep
                             # Wake up again
glmark2-es2-drm              # Use the GPU
                             # Device locks up

Peng, is this something you can reproduce?

I could reproduce this issue on my last GPC+BLK_CTRL series. This was
caused by a bad interaction between our slightly unusual way to control
the nested power domains via runtime PM and the system suspend/resume
code, which lead to some of the power domains not properly coming up
again in the resume path. v2 of my series fixes this issue and the
above sequence works as expected.

Regards,
Lucas



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel