Re: [PATCH v3 20/24] pmdomain: core: Default to use of_genpd_sync_state() for genpd providers
From: Ulf Hansson <hidden>
Date: 2025-09-24 15:53:47
Also in:
linux-pm, linux-tegra, lkml
On Wed, 24 Sept 2025 at 13:41, Jon Hunter [off-list ref] wrote:
Hi Ulf, On 03/09/2025 13:33, Jon Hunter wrote: ...quoted
quoted
quoted
Following this change I am seeing the following warning on our Tegra194 devices ... WARNING KERN tegra-bpmp bpmp: sync_state() pending due to 17000000.gpu WARNING KERN tegra-bpmp bpmp: sync_state() pending due to 3960000.cec WARNING KERN tegra-bpmp bpmp: sync_state() pending due to 15380000.nvjpg WARNING KERN tegra-bpmp bpmp: sync_state() pending due to 154c0000.nvenc WARNING KERN tegra-bpmp bpmp: sync_state() pending due to 15a80000.nvenc Per your change [0], the 'GENPD_FLAG_NO_SYNC_STATE' is set for Tegra and so should Tegra be using of_genpd_sync_state() by default?This is a different power-domain provider (bpmp) in drivers/firmware/tegra/bpmp.c and drivers/pmdomain/tegra/powergate-bpmp.c. For the bpmp we don't need GENPD_FLAG_NO_SYNC_STATE, as the power-domain provider is described along with the "nvidia,tegra186-bpmp" compatible string. In the other case (drivers/soc/tegra/pmc.c) the "core-domain" and "powergates" are described through child-nodes, while ->sync_state() is managed by the parent-device-node. In the bpmp case there is no ->sync_state() callback assigned, which means genpd decides to assign a default one. The reason for the warnings above is because we are still waiting for those devices to be probed, hence the ->sync_state() callback is still waiting to be invoked. Enforcing ->sync_state() callback to be invoked can be done via user-space if that is needed. Did that make sense?Sorry for the delay, I was on vacation. Yes makes sense and drivers for some of the above drivers are not yet upstreamed to mainline and so this would be expected for now.I have been doing more testing and do see a lot of "tegra-bpmp bpmp: sync_state() pending due to" on our platforms for basically are driver that is built as a module. It seems a bit noisy given that these do eventually probe OK. I am wondering if this should be more of a dev_info() or dev_dbg() print?
Yes, I agree. We have had similar reports for other platforms too. I intend to send a patch for this in the next day or so. Kind regards Uffe