lkml.org 
[lkml]   [2021]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH V2 00/13] soc: imx: gpcv2: support i.MX8MM
    From
    Date
    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@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 <frieder.schrempf@kontron.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.

    Glad you could reproduce and fix this issue. Thanks for the effort. I will try to do some tests myself soon.

    Thanks
    Frieder

    \
     
     \ /
      Last update: 2021-07-22 08:38    [W:2.714 / U:0.572 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site