On 19.05.21 18:09, Frieder Schrempf wrote: > On 06.05.21 10:32, Frieder Schrempf wrote: >> On 06.05.21 03:04, Peng Fan (OSS) wrote: >>> From: Peng Fan <peng.fan@xxxxxxx> >>> >>> >>> 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 <frieder.schrempf@xxxxxxxxxx> > > 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?