gpu: host1x: Skip reset assert on Tegra186

Commit Message

Mikko Perttunen Feb. 14, 2024, 11:40 a.m. UTC

From: Mikko Perttunen <[e-mail]>

On Tegra186, other software components may rely on the kernel to
keep Host1x operational even during suspend. As such, as a quirk,
skip asserting Host1x's reset on Tegra186.

We don't need to keep the clocks enabled, as BPMP ensures the clock
stays on while Host1x is being used. On newer SoC's, the reset line
is inaccessible, so there is no need for the quirk.

Signed-off-by: Mikko Perttunen <[e-mail]>
---
 drivers/gpu/host1x/dev.c | 15 +++++++++------
 drivers/gpu/host1x/dev.h |  1 +
 2 files changed, 10 insertions(+), 6 deletions(-)

Comments

Jon Hunter Feb. 15, 2024, 11:07 a.m. UTC | #1

On 14/02/2024 11:40, Mikko Perttunen wrote:
> From: Mikko Perttunen <[e-mail]>
> 
> On Tegra186, other software components may rely on the kernel to
> keep Host1x operational even during suspend. As such, as a quirk,
> skip asserting Host1x's reset on Tegra186.
> 
> We don't need to keep the clocks enabled, as BPMP ensures the clock
> stays on while Host1x is being used. On newer SoC's, the reset line
> is inaccessible, so there is no need for the quirk.
> 
> Signed-off-by: Mikko Perttunen <[e-mail]>


We should add the fixes tag ...

Fixes: b7c00cdf6df5 ("gpu: host1x: Enable system suspend callbacks")

... because this fixes a suspend regression on Tegra186.

Thierry, would you be able to add the fixes-tag and send out as a fix 
for v6.8? Otherwise ...

Reviewed-by: Jon Hunter <[e-mail]>
Tested-by: Jon Hunter <[e-mail]>

Thanks!
Jon

Thierry Reding Feb. 16, 2024, 10:02 a.m. UTC | #2

On Wed Feb 14, 2024 at 12:40 PM CET, Mikko Perttunen wrote:
> From: Mikko Perttunen <[e-mail]>
>
> On Tegra186, other software components may rely on the kernel to
> keep Host1x operational even during suspend. As such, as a quirk,
> skip asserting Host1x's reset on Tegra186.

This all sounds a bit vague. What other software components rely on the
kernel to keep host1x operational during suspend? And why do they do so?
Why is this not a problem elsewhere?

Thierry

Mikko Perttunen Feb. 19, 2024, 2:18 a.m. UTC | #3

On 2/16/24 19:02, Thierry Reding wrote:
> On Wed Feb 14, 2024 at 12:40 PM CET, Mikko Perttunen wrote:
>> From: Mikko Perttunen <[e-mail]>
>>
>> On Tegra186, other software components may rely on the kernel to
>> keep Host1x operational even during suspend. As such, as a quirk,
>> skip asserting Host1x's reset on Tegra186.
> 
> This all sounds a bit vague. What other software components rely on the
> kernel to keep host1x operational during suspend? And why do they do so?
> Why is this not a problem elsewhere?

My assumption is that it's due to a secure world application accessing 
NVDEC or display engines during suspend or resume. This happening 
without kernel knowledge is a bad thing, but it's hard to change at this 
point.

The reset line (CAR vs BPMP vs non-accessible reset line), and the 
secure application code programming this stuff is slightly different in 
every chip generation, which is where I think the differences happen.

Mikko

> 
> Thierry

Thierry Reding Feb. 19, 2024, 4:31 p.m. UTC | #4

On Mon Feb 19, 2024 at 3:18 AM CET, Mikko Perttunen wrote:
> On 2/16/24 19:02, Thierry Reding wrote:
> > On Wed Feb 14, 2024 at 12:40 PM CET, Mikko Perttunen wrote:
> >> From: Mikko Perttunen <[e-mail]>
> >>
> >> On Tegra186, other software components may rely on the kernel to
> >> keep Host1x operational even during suspend. As such, as a quirk,
> >> skip asserting Host1x's reset on Tegra186.
> > 
> > This all sounds a bit vague. What other software components rely on the
> > kernel to keep host1x operational during suspend? And why do they do so?
> > Why is this not a problem elsewhere?
>
> My assumption is that it's due to a secure world application accessing 
> NVDEC or display engines during suspend or resume. This happening 
> without kernel knowledge is a bad thing, but it's hard to change at this 
> point.
>
> The reset line (CAR vs BPMP vs non-accessible reset line), and the 
> secure application code programming this stuff is slightly different in 
> every chip generation, which is where I think the differences happen.

*sigh*

I guess it is what it is. Please add a bit more background information
to the commit message and also a comment for the skip_reset field so
that people (including myself) will remember down the road why this
exists.

Thierry

Patch

diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
index 42fd504abbcd..89983d7d73ca 100644
--- a/drivers/gpu/host1x/dev.c
+++ b/drivers/gpu/host1x/dev.c
@@ -169,6 +169,7 @@  static const struct host1x_info host1x06_info = {
 	.num_sid_entries = ARRAY_SIZE(tegra186_sid_table),
 	.sid_table = tegra186_sid_table,
 	.reserve_vblank_syncpts = false,
+	.skip_reset_assert = true,
 };
 
 static const struct host1x_sid_entry tegra194_sid_table[] = {
@@ -680,13 +681,15 @@  static int __maybe_unused host1x_runtime_suspend(struct device *dev)
 	host1x_intr_stop(host);
 	host1x_syncpt_save(host);
 
-	err = reset_control_bulk_assert(host->nresets, host->resets);
-	if (err) {
-		dev_err(dev, "failed to assert reset: %d\n", err);
-		goto resume_host1x;
-	}
+	if (!host->info->skip_reset_assert) {
+		err = reset_control_bulk_assert(host->nresets, host->resets);
+		if (err) {
+			dev_err(dev, "failed to assert reset: %d\n", err);
+			goto resume_host1x;
+		}
 
-	usleep_range(1000, 2000);
+		usleep_range(1000, 2000);
+	}
 
 	clk_disable_unprepare(host->clk);
 	reset_control_bulk_release(host->nresets, host->resets);
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index c8e302de7625..9c13e71a31ff 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -116,6 +116,7 @@  struct host1x_info {
 	 * the display driver disables VBLANK increments.
 	 */
 	bool reserve_vblank_syncpts;
+	bool skip_reset_assert;
 };
 
 struct host1x {