All of lore.kernel.org
 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

WARNING: multiple messages have this Message-ID (diff)
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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

Thread overview: 56+ 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 ` 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   ` 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   ` 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  1:04   ` Peng Fan (OSS)
2021-05-06  6:30   ` Frieder Schrempf
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  1:04   ` Peng Fan (OSS)
2021-05-06  6:36   ` Frieder Schrempf
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   ` 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   ` 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   ` 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  1:04   ` Peng Fan (OSS)
2021-05-06  6:43   ` Frieder Schrempf
2021-05-06  6:43     ` Frieder Schrempf
2021-05-07 21:16     ` Rob Herring
2021-05-07 21:16       ` Rob Herring
2021-05-08  0:50       ` Peng Fan
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   ` 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   ` 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   ` 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   ` 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  1:04   ` Peng Fan (OSS)
2021-05-06  6:56   ` Frieder Schrempf
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-06  8:32   ` Frieder Schrempf
2021-05-19 16:09   ` Frieder Schrempf
2021-05-19 16:09     ` Frieder Schrempf
2021-05-20 15:16     ` Frieder Schrempf
2021-05-20 15:16       ` Frieder Schrempf
2021-07-21 20:51       ` Lucas Stach
2021-07-21 20:51         ` Lucas Stach
2021-07-22  6:36         ` Frieder Schrempf [this message]
2021-07-22  6:36           ` Frieder Schrempf
2021-08-04 14:30 ` Ezequiel Garcia
2021-08-04 14:30   ` Ezequiel Garcia
2021-08-09  8:15   ` Lucas Stach
2021-08-09  8:15     ` Lucas Stach
2021-09-03 12:26     ` Benjamin Gaignard
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.