linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frieder Schrempf <frieder.schrempf@kontron.de>
To: Lucas Stach <l.stach@pengutronix.de>,
	"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	robh+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: kernel@pengutronix.de, festevam@gmail.com, linux-imx@nxp.com,
	p.zabel@pengutronix.de, krzk@kernel.org, agx@sigxcpu.org,
	marex@denx.de, andrew.smirnov@gmail.com,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, ping.bai@nxp.com,
	aford173@gmail.com, abel.vesa@nxp.com,
	Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH V2 00/13] soc: imx: gpcv2: support i.MX8MM
Date: Thu, 22 Jul 2021 08:36:57 +0200	[thread overview]
Message-ID: <94d4a625-bdf2-9b40-8b6b-50c2bfd8f103@kontron.de> (raw)
In-Reply-To: <689e5fd6c290ebec09d45c5d55354d78f5cea647.camel@pengutronix.de>

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

  reply	other threads:[~2021-07-22  6:37 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06  1:04 [PATCH V2 00/13] soc: imx: gpcv2: support i.MX8MM Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 01/13] soc: imx: gpcv2: move to more ideomatic error handling in probe Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 02/13] soc: imx: gpcv2: move domain mapping to domain driver probe Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 03/13] soc: imx: gpcv2: switch to clk_bulk_* API Peng Fan (OSS)
2021-05-06  6:30   ` Frieder Schrempf
2021-05-06  1:04 ` [PATCH V2 04/13] soc: imx: gpcv2: split power up and power down sequence control Peng Fan (OSS)
2021-05-06  6:36   ` Frieder Schrempf
2021-05-06  1:04 ` [PATCH V2 05/13] soc: imx: gpcv2: wait for ADB400 handshake Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 06/13] soc: imx: gpcv2: add runtime PM support for power-domains Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 07/13] soc: imx: gpcv2: allow domains without power-sequence control Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 08/13] dt-bindings: imx: gpcv2: add support for optional resets Peng Fan (OSS)
2021-05-06  6:43   ` Frieder Schrempf
2021-05-07 21:16     ` Rob Herring
2021-05-08  0:50       ` Peng Fan
2021-05-06  1:04 ` [PATCH V2 09/13] soc: " Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 10/13] dt-bindings: power: add defines for i.MX8MM power domains Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 11/13] soc: imx: gpcv2: add support " Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 12/13] soc: imx: gpcv2: Add support for missing i.MX8MM VPU/DISPMIX " Peng Fan (OSS)
2021-05-06  1:04 ` [PATCH V2 13/13] soc: imx: gpcv2: move reset assert after requesting domain power up Peng Fan (OSS)
2021-05-06  6:56   ` Frieder Schrempf
2021-05-06  8:32 ` [PATCH V2 00/13] soc: imx: gpcv2: support i.MX8MM Frieder Schrempf
2021-05-19 16:09   ` Frieder Schrempf
2021-05-20 15:16     ` Frieder Schrempf
2021-07-21 20:51       ` Lucas Stach
2021-07-22  6:36         ` Frieder Schrempf [this message]
2021-08-04 14:30 ` Ezequiel Garcia
2021-08-09  8:15   ` Lucas Stach
2021-09-03 12:26     ` Benjamin Gaignard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=94d4a625-bdf2-9b40-8b6b-50c2bfd8f103@kontron.de \
    --to=frieder.schrempf@kontron.de \
    --cc=abel.vesa@nxp.com \
    --cc=aford173@gmail.com \
    --cc=agx@sigxcpu.org \
    --cc=andrew.smirnov@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=festevam@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=krzk@kernel.org \
    --cc=l.stach@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=p.zabel@pengutronix.de \
    --cc=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=ping.bai@nxp.com \
    --cc=robh+dt@kernel.org \
    --cc=s.hauer@pengutronix.de \
    --cc=shawnguo@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).