Thread (28 messages) 28 messages, 7 authors, 2021-09-03

Re: [PATCH V2 00/13] soc: imx: gpcv2: support i.MX8MM

From: Frieder Schrempf <hidden>
Date: 2021-05-20 15:16:32
Also in: linux-arm-kernel, lkml

On 19.05.21 18:09, Frieder Schrempf wrote:
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help