* [PATCH] drm/tegra: dc: Propagate powergate failures on suspend
@ 2026-08-29 4:20 Pengpeng Hou
2026-08-29 4:31 ` sashiko-bot
0 siblings, 1 reply; 2+ messages in thread
From: Pengpeng Hou @ 2026-08-29 4:20 UTC (permalink / raw)
To: Thierry Reding, Mikko Perttunen
Cc: Pengpeng Hou, David Airlie, Simona Vetter, Jonathan Hunter,
Philipp Zabel, dri-devel, linux-tegra, linux-kernel
A lifecycle transition can continue after a required state restore
operation fails, leaving software state inconsistent with hardware.
Propagate the failure and unwind state acquired by the transition so
callers cannot observe a false success.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/gpu/drm/tegra/dc.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 0b3fcc7011b3..bac78b57dcff 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -2878,8 +2878,14 @@ static int tegra_dc_runtime_suspend(struct host1x_client *client)
return err;
}
- if (dc->soc->has_powergate)
- tegra_pmc_powergate_power_off(dc->pmc, dc->powergate);
+ if (dc->soc->has_powergate) {
+ err = tegra_pmc_powergate_power_off(dc->pmc, dc->powergate);
+ if (err < 0) {
+ dev_err(dev, "failed to powergate partition: %d\n", err);
+ reset_control_deassert(dc->rst);
+ return err;
+ }
+ }
clk_disable_unprepare(dc->clk);
pm_runtime_put_sync(dev);
--
2.43.0
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] drm/tegra: dc: Propagate powergate failures on suspend
2026-08-29 4:20 [PATCH] drm/tegra: dc: Propagate powergate failures on suspend Pengpeng Hou
@ 2026-08-29 4:31 ` sashiko-bot
0 siblings, 0 replies; 2+ messages in thread
From: sashiko-bot @ 2026-08-29 4:31 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: dri-devel
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Returning an error from the suspend callback causes a permanent usecount desynchronization in host1x and leaks runtime PM and clock resources.
- [High] Returning early on suspend failure leaves the clock running, but the caller unconditionally drops the performance state, violating DVFS constraints.
--
commit c243459159c6fcb1671762433a70d770456532d9
Author: Pengpeng Hou <pengpeng@iscas.ac.cn>
drm/tegra: dc: Propagate powergate failures on suspend
A lifecycle transition can continue after a required state restore
operation fails, leaving software state inconsistent with hardware.
Propagate the failure and unwind state acquired by the transition so
callers cannot observe a false success.
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 0b3fcc7011b35..bac78b57dcffb 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -2878,8 +2878,14 @@ static int tegra_dc_runtime_suspend(struct host1x_client *client)
> return err;
> }
[Severity: High]
This is a pre-existing issue, but does returning an error from the suspend
callback cause a permanent usecount desynchronization in host1x?
If tegra_dc_runtime_suspend() fails during reset_control_assert() or
tegra_pmc_powergate_power_off(), it returns an error.
host1x_client_suspend() intercepts this error and skips decrementing
client->usecount, leaving it at 1.
The caller tegra_crtc_atomic_disable() (which returns void) cannot abort the
disable process and ignores the error.
Upon the next atomic enable, host1x_client_resume() skips calling the resume
callback because usecount is 1 (not 0), and increments it to 2.
The subsequent disable drops it to 1, skipping suspend. This permanently
disables callbacks, leaking clocks, power domains, and runtime PM references.
>
> - if (dc->soc->has_powergate)
> - tegra_pmc_powergate_power_off(dc->pmc, dc->powergate);
> + if (dc->soc->has_powergate) {
> + err = tegra_pmc_powergate_power_off(dc->pmc, dc->powergate);
> + if (err < 0) {
> + dev_err(dev, "failed to powergate partition: %d\n", err);
> + reset_control_deassert(dc->rst);
> + return err;
[Severity: High]
This isn't a bug introduced by this patch, but does returning early on suspend
failure leave the clock running, while the caller unconditionally drops the
performance state?
If tegra_dc_runtime_suspend() returns early on failure, it skips
clk_disable_unprepare(dc->clk). The hardware clock remains enabled.
However, the caller tegra_crtc_atomic_disable() proceeds to drop the voltage:
drivers/gpu/drm/tegra/dc.c:tegra_crtc_atomic_disable() {
...
err = host1x_client_suspend(&dc->client);
if (err < 0)
dev_err(dc->dev, "failed to suspend: %d\n", err);
if (dc->has_opp_table) {
err = dev_pm_genpd_set_performance_state(dc->dev, 0);
...
}
Operating the hardware at an active frequency with zero voltage violates DVFS
constraints and can cause hardware brownouts, potentially locking up the
system bus or hanging the SoC.
> + }
> + }
>
> clk_disable_unprepare(dc->clk);
> pm_runtime_put_sync(dev);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260829042030.21346-1-pengpeng@iscas.ac.cn?part=1
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-08-31 7:00 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-29 4:20 [PATCH] drm/tegra: dc: Propagate powergate failures on suspend Pengpeng Hou
2026-08-29 4:31 ` sashiko-bot
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox