[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CALHNRZ_hZ5rjGpt4rDmMvxcBBcW2fK6Q2Z_1oKzj+eBi6U-1+g@mail.gmail.com>
Date: Fri, 12 Sep 2025 02:07:54 -0500
From: Aaron Kling <webgeek1234@...il.com>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Lyude Paul <lyude@...hat.com>, Danilo Krummrich <dakr@...nel.org>, David Airlie <airlied@...il.com>,
Simona Vetter <simona@...ll.ch>, Jonathan Hunter <jonathanh@...dia.com>, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, nouveau@...ts.freedesktop.org,
linux-tegra@...r.kernel.org
Subject: Re: [PATCH] drm/nouveau: Support devfreq for Tegra
On Tue, Sep 9, 2025 at 7:05 AM Thierry Reding <thierry.reding@...il.com> wrote:
>
> On Sat, Sep 06, 2025 at 08:01:27PM -0500, Aaron Kling wrote:
> [...]
> > I should note that I have only actively tested this on gm20b and
> > gp10b. I am currently unable to get nouveau running on any gk20a
> > device I own. I am trying to target consumer devices such as the
> > shield tablet, which use the android bootloader. I can boot the kernel
> > just fine and tegra-drm works as well, however when nouveau tries to
> > probe, it hangs the first time it tries to access a register. I have
> > not yet been able to figure out why.
>
> These types of hangs typically indicate that the hardware is not powered
> on, not clocked or in reset. It's odd that it would hang during register
> access on gk20a because nothing significant has changed in any of the
> related drivers, as far as I know.
>
> One thing that you could try is passing the clk_ignore_unused and
> pd_ignore_unused command-line parameters when booting the kernel. If it
> works with those, try finding out which one of them is causing things to
> break to narrow down what we need to fix.
The ignore_unused params didn't make a difference, but this got me
looking closer at the power rails. I noticed that vdd-gpu for the
jetson-tk1 is set to always-on for mainline, which it is not on the
downstream kernel. Mirroring that to ardbeg resulted in nouveau
successfully probing. One of my other devices needed a pwm-regulator
for vdd-gpu, after which it also probes as expected. I will need to
double check the rest of my devices as well. Is there a known reason
why if vdd-gpu is a pmic regulator, it needs to be always-on, or is
this another unsolved mystery?
This change looks to be working okay on gk20a. It does a couple
transitions on startup. I'm having other issues getting full rendering
started, though. Kasan slab-out-of-bounds in nvkm_falcon_v1_load_imem
when drm_hwcomposer tries to start up. Looking into that separately
now, but that shouldn't block any of my open patches.
Aaron
Powered by blists - more mailing lists