All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Diederik de Haas" <didi.debian@cknow.org>
To: "Ulf Hansson" <ulf.hansson@linaro.org>,
	"Sebin Francis" <sebin.francis@ti.com>,
	"Saravana Kannan" <saravanak@google.com>
Cc: "Stephen Boyd" <sboyd@kernel.org>, <linux-pm@vger.kernel.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Michael Grzeschik" <m.grzeschik@pengutronix.de>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Abel Vesa" <abel.vesa@linaro.org>,
	"Peng Fan" <peng.fan@oss.nxp.com>,
	"Tomi Valkeinen" <tomi.valkeinen@ideasonboard.com>,
	"Johan Hovold" <johan@kernel.org>,
	"Maulik Shah" <maulik.shah@oss.qualcomm.com>,
	"Michal Simek" <michal.simek@amd.com>,
	"Konrad Dybcio" <konradybcio@kernel.org>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Hiago De Franco" <hiago.franco@toradex.com>,
	"Geert Uytterhoeven" <geert@linux-m68k.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-rockchip@lists.infradead.org>,
	"Nicolas Frattaroli" <nicolas.frattaroli@collabora.com>
Subject: Re: [PATCH v3 00/24] pmdomain: Add generic ->sync_state() support to genpd
Date: Thu, 04 Sep 2025 14:32:31 +0200	[thread overview]
Message-ID: <DCK0O99SYSCF.BMBAEUV24C1G@cknow.org> (raw)
In-Reply-To: <CAPDyKFr8AYuS2aEVs8X2As1NzXnbea4rPLKiF5=fKjq=PAeZgg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3979 bytes --]

Hi,

On Wed Sep 3, 2025 at 12:33 PM CEST, Ulf Hansson wrote:
> On Wed, 3 Sept 2025 at 09:39, Sebin Francis <sebin.francis@ti.com> wrote:
>> On 01/07/25 17:17, Ulf Hansson wrote:
>> >
>> > If a PM domain (genpd) is powered-on during boot, there is probably a good
>> > reason for it. Therefore it's known to be a bad idea to allow such genpd to be
>> > powered-off before all of its consumer devices have been probed. This series
>> > intends to fix this problem.
>> >
>> > We have been discussing these issues at LKML and at various Linux-conferences
>> > in the past. I have therefore tried to include the people I can recall being
>> > involved, but I may have forgotten some (my apologies), feel free to loop them
>> > in.
>> >
>> > Please help review and test!
>>
>> During testing on a TI platform, I observed new kernel warnings after
>> applying this patch series:
>>
>> ti_sci_pm_domains 44043000.system-controller:power-controller:
>> sync_state() pending due to fd00000.gpu
>>
>> These warnings occur when a device (in this case, the GPU) has no driver
>> bound to it. The fw_devlink_dev_sync_state[0] in the core has a check
>> before printing this warning. It checks whether the device driver has a
>> sync_state handler OR the device bus has a sync_state handler in the
>> dev_has_sync_state[1]. If both conditions are false,
>> fw_devlink_dev_sync_state[0] performs an early return before printing
>> the warning.
>>
>> Before this patch series, both handlers were absent for device driver
>> ti_sci_pm_domains and the device bus, so both conditions failed and no
>> warnings were printed.
>>
>> This patch series adds a sync_state handler for the bus, which now
>> satisfies the second condition. So it doesn't do an early return and
>> proceeds to print the warning.
>
> Thanks for the report and testing!
>
> Indeed this is the new and expected behaviour. I agree that it's
> certainly questionable if those prints should be at the warning level.
>
> We should probably downgrade those to dev_info(), at least. Let me
> send a patch to see what Saravana and others are thinking about it!

I want to report that I see similar warnings on Rock64 (rk3328):

[   16.868033] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff300000.gpu
[   16.873637] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff350000.video-codec
[   16.896495] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff360000.video-codec

This is with a 6.17-rc3 kernel with various rkvdec patches and in dmesg
I later see msgs wrt ff300000.gpu (lima) and ff350000.video-codec
(hantro-vpu), but not ff360000.video-codec (rkvdec). Full dmesg:
https://paste.sr.ht/~diederik/951b54ea8422756e5efaa61d6bcefb575cfe28a4

But there were also USB issues (not sure why), so I rebooted and then I
did see msgs wrt rkvdec. Full dmesg:
https://paste.sr.ht/~diederik/156f65fc6be05d02484568dfd303c46ba76b3a8e

I also have a 6.17-rc4 kernel which is clean upstream, thus without any
media patches. This time no USB issues (also no USB device plugged in)
and I see msgs wrt lima and hantro-vpu, but not rkvdec. Full dmesg:
https://paste.sr.ht/~diederik/4affea034b0c9fb522a8ad5b90e8b59b4bd856ec

What's possibly relevant is that the 6.17-rc3+unreleased kernel also has
this patch added, which adds 'power-domain@RK3328_PD_GPU' to rk3328.dtsi
https://lore.kernel.org/linux-rockchip/20250830115135.3549305-1-christianshewitt@gmail.com/

I actually found this thread because I too couldn't find the commit ID
Nicolas referenced in this post:
https://lore.kernel.org/linux-rockchip/20250902-rk3576-lockup-regression-v1-1-c4a0c9daeb00@collabora.com/

I have no idea whether it's related though (I have no rk3576 device).

I haven't tried (yet) whether the sync_state() msg is also present on
other Rockchip based devices.

Cheers,
  Diederik

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: "Diederik de Haas" <didi.debian@cknow.org>
To: "Ulf Hansson" <ulf.hansson@linaro.org>,
	"Sebin Francis" <sebin.francis@ti.com>,
	"Saravana Kannan" <saravanak@google.com>
Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>,
	Maulik Shah <maulik.shah@oss.qualcomm.com>,
	Peng Fan <peng.fan@oss.nxp.com>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	Stephen Boyd <sboyd@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Bjorn Andersson <andersson@kernel.org>,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Johan Hovold <johan@kernel.org>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-rockchip@lists.infradead.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>,
	Abel Vesa <abel.vesa@linaro.org>,
	Hiago De Franco <hiago.franco@toradex.com>,
	Michal Simek <michal.simek@amd.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v3 00/24] pmdomain: Add generic ->sync_state() support to genpd
Date: Thu, 04 Sep 2025 14:32:31 +0200	[thread overview]
Message-ID: <DCK0O99SYSCF.BMBAEUV24C1G@cknow.org> (raw)
In-Reply-To: <CAPDyKFr8AYuS2aEVs8X2As1NzXnbea4rPLKiF5=fKjq=PAeZgg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3979 bytes --]

Hi,

On Wed Sep 3, 2025 at 12:33 PM CEST, Ulf Hansson wrote:
> On Wed, 3 Sept 2025 at 09:39, Sebin Francis <sebin.francis@ti.com> wrote:
>> On 01/07/25 17:17, Ulf Hansson wrote:
>> >
>> > If a PM domain (genpd) is powered-on during boot, there is probably a good
>> > reason for it. Therefore it's known to be a bad idea to allow such genpd to be
>> > powered-off before all of its consumer devices have been probed. This series
>> > intends to fix this problem.
>> >
>> > We have been discussing these issues at LKML and at various Linux-conferences
>> > in the past. I have therefore tried to include the people I can recall being
>> > involved, but I may have forgotten some (my apologies), feel free to loop them
>> > in.
>> >
>> > Please help review and test!
>>
>> During testing on a TI platform, I observed new kernel warnings after
>> applying this patch series:
>>
>> ti_sci_pm_domains 44043000.system-controller:power-controller:
>> sync_state() pending due to fd00000.gpu
>>
>> These warnings occur when a device (in this case, the GPU) has no driver
>> bound to it. The fw_devlink_dev_sync_state[0] in the core has a check
>> before printing this warning. It checks whether the device driver has a
>> sync_state handler OR the device bus has a sync_state handler in the
>> dev_has_sync_state[1]. If both conditions are false,
>> fw_devlink_dev_sync_state[0] performs an early return before printing
>> the warning.
>>
>> Before this patch series, both handlers were absent for device driver
>> ti_sci_pm_domains and the device bus, so both conditions failed and no
>> warnings were printed.
>>
>> This patch series adds a sync_state handler for the bus, which now
>> satisfies the second condition. So it doesn't do an early return and
>> proceeds to print the warning.
>
> Thanks for the report and testing!
>
> Indeed this is the new and expected behaviour. I agree that it's
> certainly questionable if those prints should be at the warning level.
>
> We should probably downgrade those to dev_info(), at least. Let me
> send a patch to see what Saravana and others are thinking about it!

I want to report that I see similar warnings on Rock64 (rk3328):

[   16.868033] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff300000.gpu
[   16.873637] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff350000.video-codec
[   16.896495] rockchip-pm-domain ff100000.syscon:power-controller: sync_state() pending due to ff360000.video-codec

This is with a 6.17-rc3 kernel with various rkvdec patches and in dmesg
I later see msgs wrt ff300000.gpu (lima) and ff350000.video-codec
(hantro-vpu), but not ff360000.video-codec (rkvdec). Full dmesg:
https://paste.sr.ht/~diederik/951b54ea8422756e5efaa61d6bcefb575cfe28a4

But there were also USB issues (not sure why), so I rebooted and then I
did see msgs wrt rkvdec. Full dmesg:
https://paste.sr.ht/~diederik/156f65fc6be05d02484568dfd303c46ba76b3a8e

I also have a 6.17-rc4 kernel which is clean upstream, thus without any
media patches. This time no USB issues (also no USB device plugged in)
and I see msgs wrt lima and hantro-vpu, but not rkvdec. Full dmesg:
https://paste.sr.ht/~diederik/4affea034b0c9fb522a8ad5b90e8b59b4bd856ec

What's possibly relevant is that the 6.17-rc3+unreleased kernel also has
this patch added, which adds 'power-domain@RK3328_PD_GPU' to rk3328.dtsi
https://lore.kernel.org/linux-rockchip/20250830115135.3549305-1-christianshewitt@gmail.com/

I actually found this thread because I too couldn't find the commit ID
Nicolas referenced in this post:
https://lore.kernel.org/linux-rockchip/20250902-rk3576-lockup-regression-v1-1-c4a0c9daeb00@collabora.com/

I have no idea whether it's related though (I have no rk3576 device).

I haven't tried (yet) whether the sync_state() msg is also present on
other Rockchip based devices.

Cheers,
  Diederik

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2025-09-04 18:34 UTC|newest]

Thread overview: 80+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-01 11:47 [PATCH v3 00/24] pmdomain: Add generic ->sync_state() support to genpd Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 01/24] pmdomain: renesas: rcar-sysc: Add genpd OF provider at postcore_initcall Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 02/24] pmdomain: renesas: rmobile-sysc: Move init to postcore_initcall Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 03/24] pmdomain: renesas: rcar-gen4-sysc: " Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 04/24] pmdomain: core: Prevent registering devices before the bus Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 05/24] pmdomain: core: Add a bus and a driver for genpd providers Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 06/24] pmdomain: core: Add the genpd->dev to the genpd provider bus Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 07/24] pmdomain: core: Export a common ->sync_state() helper for genpd providers Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 08/24] pmdomain: core: Prepare to add the common ->sync_state() support Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 09/24] soc/tegra: pmc: Opt-out from genpd's " Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 10/24] cpuidle: psci: " Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 11/24] cpuidle: riscv-sbi: " Ulf Hansson
2025-07-01 11:47   ` Ulf Hansson
2025-07-04 10:14   ` Rahul Pathak
2025-07-04 10:14     ` Rahul Pathak
2025-07-07  9:36   ` Anup Patel
2025-07-07  9:36     ` Anup Patel
2025-08-10 21:12   ` patchwork-bot+linux-riscv
2025-08-10 21:12     ` patchwork-bot+linux-riscv
2025-07-01 11:47 ` [PATCH v3 12/24] pmdomain: qcom: rpmpd: Use of_genpd_sync_state() Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 13/24] pmdomain: qcom: rpmhpd: " Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 14/24] firmware/pmdomain: xilinx: Move ->sync_state() support to firmware driver Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 15/24] firmware: xilinx: Don't share zynqmp_pm_init_finalize() Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 16/24] firmware: xilinx: Use of_genpd_sync_state() Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 17/24] driver core: Export get_dev_from_fwnode() Ulf Hansson
2025-07-02  7:34   ` Greg Kroah-Hartman
2025-07-02 19:26     ` Danilo Krummrich
2025-07-02 21:34       ` Saravana Kannan
2025-07-02 21:55         ` Danilo Krummrich
2025-07-01 11:47 ` [PATCH v3 18/24] pmdomain: core: Add common ->sync_state() support for genpd providers Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 19/24] driver core: Add dev_set_drv_sync_state() Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 20/24] pmdomain: core: Default to use of_genpd_sync_state() for genpd providers Ulf Hansson
2025-07-31 15:07   ` Jon Hunter
2025-08-11 12:11     ` Ulf Hansson
2025-09-03 12:33       ` Jon Hunter
2025-09-24 11:40         ` Jon Hunter
2025-09-24 15:53           ` Ulf Hansson
2025-09-25  9:34             ` Jon Hunter
2025-09-25 22:31           ` Saravana Kannan
2025-09-26 15:32             ` Jon Hunter
2025-09-30 11:33               ` Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 21/24] pmdomain: core: Leave powered-on genpds on until late_initcall_sync Ulf Hansson
2025-07-10 12:26   ` Marek Szyprowski
2025-07-10 14:54     ` Ulf Hansson
2025-07-15 10:28       ` Jon Hunter
2025-07-15 11:32         ` Ulf Hansson
2025-07-15 11:34           ` Ulf Hansson
2025-07-31 12:53             ` Jon Hunter
2025-07-01 11:47 ` [PATCH v3 22/24] pmdomain: core: Leave powered-on genpds on until sync_state Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 23/24] cpuidle: psci: Drop redundant sync_state support Ulf Hansson
2025-07-01 11:47 ` [PATCH v3 24/24] cpuidle: riscv-sbi: " Ulf Hansson
2025-07-01 11:47   ` Ulf Hansson
2025-07-04 10:39   ` Rahul Pathak
2025-07-04 10:39     ` Rahul Pathak
2025-07-07  9:38   ` Anup Patel
2025-07-07  9:38     ` Anup Patel
2025-07-09 11:30 ` [PATCH v3 00/24] pmdomain: Add generic ->sync_state() support to genpd Ulf Hansson
2025-07-15  8:50   ` Danilo Krummrich
2025-07-16 12:46     ` Ulf Hansson
2025-07-16 13:08       ` Danilo Krummrich
2025-07-30  9:56   ` Geert Uytterhoeven
2025-07-30 10:29     ` Ulf Hansson
2025-08-07  9:38       ` Geert Uytterhoeven
2025-08-12 10:00         ` Ulf Hansson
2025-08-13 11:58           ` Geert Uytterhoeven
2025-08-14 15:49             ` Ulf Hansson
2025-09-04 12:41               ` Geert Uytterhoeven
2025-09-04 15:44                 ` Ulf Hansson
2025-09-05  7:49                   ` Geert Uytterhoeven
2025-09-05 11:09                     ` Ulf Hansson
2025-09-09  7:19                       ` Geert Uytterhoeven
2025-09-25 22:41         ` Saravana Kannan
2025-09-26  6:57           ` Geert Uytterhoeven
2025-09-26 12:23             ` Ulf Hansson
2025-09-29  7:53               ` Geert Uytterhoeven
2025-08-13 12:04   ` Geert Uytterhoeven
2025-09-03  7:39 ` Sebin Francis
2025-09-03 10:33   ` Ulf Hansson
2025-09-04 12:32     ` Diederik de Haas [this message]
2025-09-04 12:32       ` Diederik de Haas

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=DCK0O99SYSCF.BMBAEUV24C1G@cknow.org \
    --to=didi.debian@cknow.org \
    --cc=abel.vesa@linaro.org \
    --cc=andersson@kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hiago.franco@toradex.com \
    --cc=johan@kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=konradybcio@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=m.grzeschik@pengutronix.de \
    --cc=maulik.shah@oss.qualcomm.com \
    --cc=michal.simek@amd.com \
    --cc=nicolas.frattaroli@collabora.com \
    --cc=peng.fan@oss.nxp.com \
    --cc=rafael@kernel.org \
    --cc=saravanak@google.com \
    --cc=sboyd@kernel.org \
    --cc=sebin.francis@ti.com \
    --cc=thierry.reding@gmail.com \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=ulf.hansson@linaro.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.