power saving, dpcd access and fwupd/userspace expectations

power saving, dpcd access and fwupd/userspace expectations

[Dave Airlie]

I've been hitting a problem on the laptop I used as my desktop for the
last while, and I finally has the inspiration to track it down this
morning at 5am.

The problem is when nouveau goes into runtime pm suspend, and fwupd
hits the /dev/drm_dp_aux* nothing wakes up nouveau, we get to sending
a message to GSP and it times out and I get an oops and things fail.

Now the question I have is what do we want to do in this situation, do
we really want to restore power to the GPU because fwupd is probing
possibly attached docks, or whatever. Like do we want to integrate the
drm_dp_aux stuff into the power domains properly so we can have a
proper hierarchy so it wakes up the parent device when it gets used,
or do we just want to return -EBUSY from the driver when the device is
dynamically off.

I'll probably submit a patch doing the latter when I get to writing it
and test it on my laptop.

Regards,
Dave.

Re: power saving, dpcd access and fwupd/userspace expectations

[Ville Syrjälä]

On Mon, Feb 23, 2026 at 08:54:43AM +1000, Dave Airlie wrote:
> I've been hitting a problem on the laptop I used as my desktop for the
> last while, and I finally has the inspiration to track it down this
> morning at 5am.
> 
> The problem is when nouveau goes into runtime pm suspend, and fwupd
> hits the /dev/drm_dp_aux* nothing wakes up nouveau, we get to sending
> a message to GSP and it times out and I get an oops and things fail.
> 
> Now the question I have is what do we want to do in this situation, do
> we really want to restore power to the GPU because fwupd is probing
> possibly attached docks, or whatever. Like do we want to integrate the
> drm_dp_aux stuff into the power domains properly so we can have a
> proper hierarchy so it wakes up the parent device when it gets used,
> or do we just want to return -EBUSY from the driver when the device is
> dynamically off.
> 
> I'll probably submit a patch doing the latter when I get to writing it
> and test it on my laptop.

FWIW i915 has always woken up the device for any kind of userspace
access that needs to poke the hardware.

Simply returning -EBUSY or something doesn't sound very safe in
case the hardware powers down while the DPCD access for some
firmware update has already started. I suppose at the very least
you'd need to hold some kind of power reference even if you don't
wake the hardware. Though if you already have to figure out the
correct power reference then I'm not sure why you wouldn't just
wake it up anyway.

And if you don't wake the hardware, is is safe to let the device
power down during a firmware update because then only some of
AUX transfers would go through and subsequent ones could still
fail.

I've also occasionally wondered what happens to the thing whose
firmware is being updated if other AUX transfers are happening at
the same time...

-- 
Ville Syrjälä
Intel

Re: power saving, dpcd access and fwupd/userspace expectations

[Dave Airlie]

On Mon, 23 Feb 2026 at 16:36, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Mon, Feb 23, 2026 at 08:54:43AM +1000, Dave Airlie wrote:
> > I've been hitting a problem on the laptop I used as my desktop for the
> > last while, and I finally has the inspiration to track it down this
> > morning at 5am.
> >
> > The problem is when nouveau goes into runtime pm suspend, and fwupd
> > hits the /dev/drm_dp_aux* nothing wakes up nouveau, we get to sending
> > a message to GSP and it times out and I get an oops and things fail.
> >
> > Now the question I have is what do we want to do in this situation, do
> > we really want to restore power to the GPU because fwupd is probing
> > possibly attached docks, or whatever. Like do we want to integrate the
> > drm_dp_aux stuff into the power domains properly so we can have a
> > proper hierarchy so it wakes up the parent device when it gets used,
> > or do we just want to return -EBUSY from the driver when the device is
> > dynamically off.
> >
> > I'll probably submit a patch doing the latter when I get to writing it
> > and test it on my laptop.
>
> FWIW i915 has always woken up the device for any kind of userspace
> access that needs to poke the hardware.
>
> Simply returning -EBUSY or something doesn't sound very safe in
> case the hardware powers down while the DPCD access for some
> firmware update has already started. I suppose at the very least
> you'd need to hold some kind of power reference even if you don't
> wake the hardware. Though if you already have to figure out the
> correct power reference then I'm not sure why you wouldn't just
> wake it up anyway.

Well waking up a power well is very different from waking up a
complete GPU with post equiv and complete VRAM migration and
modesetting.

I'd rather not wake up the discrete GPU on the off-chance there is
something plugged into displayport that needs a firmware update.

But you do point out some other actual problems if a firmware update
is required to happen while the powerwell isn't open.

In that case we should probably hook the dpcd device into runtime
power and have it make sure that the parent is awake, so if someone
opens the dpcd device and keeps it open, we keep the power on?

>
> I've also occasionally wondered what happens to the thing whose
> firmware is being updated if other AUX transfers are happening at
> the same time...

That is a good question also.

Dave.

Re: power saving, dpcd access and fwupd/userspace expectations

[Richard Hughes]

On Monday, 23 February 2026 at 07:35, Dave Airlie <airlied@gmail.com> wrote:
> In that case we should probably hook the dpcd device into runtime
> power and have it make sure that the parent is awake, so if someone
> opens the dpcd device and keeps it open, we keep the power on?

I think that's sensible. I'm also not against fwupd also poking the hardware before and after the update, e.g. like a powersave "inhibit" that gets enabled and disabled.

> > I've also occasionally wondered what happens to the thing whose
> > firmware is being updated if other AUX transfers are happening at
> > the same time...
> That is a good question also.

Ideally, I'd like vendors to use the USB interface to update dock hardware -- it's much safer as you said. At the moment the problem is "solved" by lots of retries. :/

Richard