Hi Lucas, On 21.07.21 22:51, Lucas Stach wrote: > Hi Frieder, > > Am Donnerstag, dem 20.05.2021 um 17:16 +0200 schrieb Frieder Schrempf: >> 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? > > 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. Glad you could reproduce and fix this issue. Thanks for the effort. I will try to do some tests myself soon. Thanks Frieder