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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <689e5fd6c290ebec09d45c5d55354d78f5cea647.camel@pengutronix.de>
Date:   Wed, 21 Jul 2021 22:51:43 +0200
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Frieder Schrempf <frieder.schrempf@...tron.de>,
        "Peng Fan (OSS)" <peng.fan@....nxp.com>, robh+dt@...nel.org,
        shawnguo@...nel.org, s.hauer@...gutronix.de
Cc:     kernel@...gutronix.de, festevam@...il.com, linux-imx@....com,
        p.zabel@...gutronix.de, krzk@...nel.org, agx@...xcpu.org,
        marex@...x.de, andrew.smirnov@...il.com,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, ping.bai@....com, aford173@...il.com,
        abel.vesa@....com, Peng Fan <peng.fan@....com>
Subject: Re: [PATCH V2 00/13] soc: imx: gpcv2: support i.MX8MM

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@....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 <frieder.schrempf@...tron.de>
> > 
> > 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