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
