* [PATCH] nouveau/dpcd: return EBUSY for aux xfer if the device is asleep
@ 2026-02-24 3:17 Dave Airlie
2026-03-04 17:14 ` Danilo Krummrich
0 siblings, 1 reply; 6+ messages in thread
From: Dave Airlie @ 2026-02-24 3:17 UTC (permalink / raw)
To: dri-devel; +Cc: nouveau, dakr
From: Dave Airlie <airlied@redhat.com>
If we have runtime suspended, and userspace wants to use /dev/drm_dp_*
then just tell it the device is busy instead of crashing in the GSP
code.
WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
Modules linked in: overlay uinput rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep s>
snd_soc_acpi intel_rapl_msr libarc4 kvm crc8 soundwire_bus irqbypass snd_soc_sdca rapl iwlwifi snd_soc_avs uvcvideo intel_cstate think_lmi uvc firmware_attributes_class intel_uncore intel_wmi_thunderbolt wmi_bmof snd_hda_codec_conexant snd_hda_codec_nvhdmi videobuf2_vmalloc snd_soc_hda_codec cfg80211 videobu>
processor_thermal_mbox sparse_keymap intel_soc_dts_iosf intel_pch_thermal platform_profile rfkill snd soundcore int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad joydev loop nfnetlink zram lz4hc_compress lz4_compress xfs wacom hid_microsoft ff_memless nouveau ucsi_acpi typec_ucsi>
CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)
Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024
RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them away while fw updates are happening.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com<
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 00d4530aea717..cc239492c7f0b 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1230,6 +1230,9 @@ nouveau_connector_aux_xfer(struct drm_dp_aux *obj, struct drm_dp_aux_msg *msg)
u8 size = msg->size;
int ret;
+ if (pm_runtime_suspended(nv_connector->base.dev->dev))
+ return -EBUSY;
+
nv_encoder = find_encoder(&nv_connector->base, DCB_OUTPUT_DP);
if (!nv_encoder)
return -ENODEV;
--
2.53.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] nouveau/dpcd: return EBUSY for aux xfer if the device is asleep
2026-02-24 3:17 [PATCH] nouveau/dpcd: return EBUSY for aux xfer if the device is asleep Dave Airlie
@ 2026-03-04 17:14 ` Danilo Krummrich
0 siblings, 0 replies; 6+ messages in thread
From: Danilo Krummrich @ 2026-03-04 17:14 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel, nouveau
On Tue Feb 24, 2026 at 4:17 AM CET, Dave Airlie wrote:
> From: Dave Airlie <airlied@redhat.com>
>
> If we have runtime suspended, and userspace wants to use /dev/drm_dp_*
> then just tell it the device is busy instead of crashing in the GSP
> code.
>
> WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
> Modules linked in: overlay uinput rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep s>
> snd_soc_acpi intel_rapl_msr libarc4 kvm crc8 soundwire_bus irqbypass snd_soc_sdca rapl iwlwifi snd_soc_avs uvcvideo intel_cstate think_lmi uvc firmware_attributes_class intel_uncore intel_wmi_thunderbolt wmi_bmof snd_hda_codec_conexant snd_hda_codec_nvhdmi videobuf2_vmalloc snd_soc_hda_codec cfg80211 videobu>
> processor_thermal_mbox sparse_keymap intel_soc_dts_iosf intel_pch_thermal platform_profile rfkill snd soundcore int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad joydev loop nfnetlink zram lz4hc_compress lz4_compress xfs wacom hid_microsoft ff_memless nouveau ucsi_acpi typec_ucsi>
I'd remove the modules linked in, it seems not relevant.
> CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)
> Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024
> RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
>
> This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them away while fw updates are happening.
s/away/awake/ and line length.
> Cc: stable@vger.kernel.org
Do we want this backported before GSP introduction?
I.e. if it's only about the WARN_ON() and otherwise doesn't cause problems it
should probably be
Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
otherwise
Fixes: 8894f4919bc4 ("drm/nouveau: register a drm_dp_aux channel for each dp connector")
> Signed-off-by: Dave Airlie <airlied@redhat.com<
No need to resend, I can fix up the above (and the minor typo in the SoB) on
apply.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] nouveau/dpcd: return EBUSY for aux xfer if the device is asleep
@ 2026-03-04 17:14 ` Danilo Krummrich
0 siblings, 0 replies; 6+ messages in thread
From: Danilo Krummrich @ 2026-03-04 17:14 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel, nouveau
On Tue Feb 24, 2026 at 4:17 AM CET, Dave Airlie wrote:
> From: Dave Airlie <airlied@redhat.com>
>
> If we have runtime suspended, and userspace wants to use /dev/drm_dp_*
> then just tell it the device is busy instead of crashing in the GSP
> code.
>
> WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
> Modules linked in: overlay uinput rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep s>
> snd_soc_acpi intel_rapl_msr libarc4 kvm crc8 soundwire_bus irqbypass snd_soc_sdca rapl iwlwifi snd_soc_avs uvcvideo intel_cstate think_lmi uvc firmware_attributes_class intel_uncore intel_wmi_thunderbolt wmi_bmof snd_hda_codec_conexant snd_hda_codec_nvhdmi videobuf2_vmalloc snd_soc_hda_codec cfg80211 videobu>
> processor_thermal_mbox sparse_keymap intel_soc_dts_iosf intel_pch_thermal platform_profile rfkill snd soundcore int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad joydev loop nfnetlink zram lz4hc_compress lz4_compress xfs wacom hid_microsoft ff_memless nouveau ucsi_acpi typec_ucsi>
I'd remove the modules linked in, it seems not relevant.
> CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)
> Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024
> RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
>
> This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them away while fw updates are happening.
s/away/awake/ and line length.
> Cc: stable@vger.kernel.org
Do we want this backported before GSP introduction?
I.e. if it's only about the WARN_ON() and otherwise doesn't cause problems it
should probably be
Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
otherwise
Fixes: 8894f4919bc4 ("drm/nouveau: register a drm_dp_aux channel for each dp connector")
> Signed-off-by: Dave Airlie <airlied@redhat.com<
No need to resend, I can fix up the above (and the minor typo in the SoB) on
apply.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] nouveau/dpcd: return EBUSY for aux xfer if the device is asleep
2026-03-04 17:14 ` Danilo Krummrich
(?)
@ 2026-03-04 21:02 ` Dave Airlie
2026-03-04 21:09 ` Danilo Krummrich
-1 siblings, 1 reply; 6+ messages in thread
From: Dave Airlie @ 2026-03-04 21:02 UTC (permalink / raw)
To: Danilo Krummrich; +Cc: dri-devel, nouveau
On Thu, 5 Mar 2026 at 03:14, Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Tue Feb 24, 2026 at 4:17 AM CET, Dave Airlie wrote:
> > From: Dave Airlie <airlied@redhat.com>
> >
> > If we have runtime suspended, and userspace wants to use /dev/drm_dp_*
> > then just tell it the device is busy instead of crashing in the GSP
> > code.
> >
> > WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
> > Modules linked in: overlay uinput rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep s>
> > snd_soc_acpi intel_rapl_msr libarc4 kvm crc8 soundwire_bus irqbypass snd_soc_sdca rapl iwlwifi snd_soc_avs uvcvideo intel_cstate think_lmi uvc firmware_attributes_class intel_uncore intel_wmi_thunderbolt wmi_bmof snd_hda_codec_conexant snd_hda_codec_nvhdmi videobuf2_vmalloc snd_soc_hda_codec cfg80211 videobu>
> > processor_thermal_mbox sparse_keymap intel_soc_dts_iosf intel_pch_thermal platform_profile rfkill snd soundcore int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad joydev loop nfnetlink zram lz4hc_compress lz4_compress xfs wacom hid_microsoft ff_memless nouveau ucsi_acpi typec_ucsi>
>
> I'd remove the modules linked in, it seems not relevant.
>
> > CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)
> > Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024
> > RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
> >
> > This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them away while fw updates are happening.
>
> s/away/awake/ and line length.
>
> > Cc: stable@vger.kernel.org
>
> Do we want this backported before GSP introduction?
>
> I.e. if it's only about the WARN_ON() and otherwise doesn't cause problems it
> should probably be
>
> Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
>
> otherwise
>
> Fixes: 8894f4919bc4 ("drm/nouveau: register a drm_dp_aux channel for each dp connector")
Go back to this for safety, probably won't blow up but it could still
cause wierd register timeouts.
>
> > Signed-off-by: Dave Airlie <airlied@redhat.com<
>
> No need to resend, I can fix up the above (and the minor typo in the SoB) on
> apply.
Thanks,
Dave.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] nouveau/dpcd: return EBUSY for aux xfer if the device is asleep
2026-03-04 21:02 ` Dave Airlie
@ 2026-03-04 21:09 ` Danilo Krummrich
0 siblings, 0 replies; 6+ messages in thread
From: Danilo Krummrich @ 2026-03-04 21:09 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel, nouveau
On Wed Mar 4, 2026 at 10:02 PM CET, Dave Airlie wrote:
> On Thu, 5 Mar 2026 at 03:14, Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> On Tue Feb 24, 2026 at 4:17 AM CET, Dave Airlie wrote:
>> > From: Dave Airlie <airlied@redhat.com>
>> >
>> > If we have runtime suspended, and userspace wants to use /dev/drm_dp_*
>> > then just tell it the device is busy instead of crashing in the GSP
>> > code.
>> >
>> > WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
>> > Modules linked in: overlay uinput rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep s>
>> > snd_soc_acpi intel_rapl_msr libarc4 kvm crc8 soundwire_bus irqbypass snd_soc_sdca rapl iwlwifi snd_soc_avs uvcvideo intel_cstate think_lmi uvc firmware_attributes_class intel_uncore intel_wmi_thunderbolt wmi_bmof snd_hda_codec_conexant snd_hda_codec_nvhdmi videobuf2_vmalloc snd_soc_hda_codec cfg80211 videobu>
>> > processor_thermal_mbox sparse_keymap intel_soc_dts_iosf intel_pch_thermal platform_profile rfkill snd soundcore int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad joydev loop nfnetlink zram lz4hc_compress lz4_compress xfs wacom hid_microsoft ff_memless nouveau ucsi_acpi typec_ucsi>
>>
>> I'd remove the modules linked in, it seems not relevant.
>>
>> > CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)
>> > Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024
>> > RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
>> >
>> > This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them away while fw updates are happening.
>>
>> s/away/awake/ and line length.
>>
>> > Cc: stable@vger.kernel.org
>>
>> Do we want this backported before GSP introduction?
>>
>> I.e. if it's only about the WARN_ON() and otherwise doesn't cause problems it
>> should probably be
>>
>> Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
>>
>> otherwise
>>
>> Fixes: 8894f4919bc4 ("drm/nouveau: register a drm_dp_aux channel for each dp connector")
>
> Go back to this for safety, probably won't blow up but it could still
> cause wierd register timeouts.
>
>>
>> > Signed-off-by: Dave Airlie <airlied@redhat.com<
>>
>> No need to resend, I can fix up the above (and the minor typo in the SoB) on
>> apply.
Applied to drm-misc-fixes, thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] nouveau/dpcd: return EBUSY for aux xfer if the device is asleep
@ 2026-03-04 21:09 ` Danilo Krummrich
0 siblings, 0 replies; 6+ messages in thread
From: Danilo Krummrich @ 2026-03-04 21:09 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel, nouveau
On Wed Mar 4, 2026 at 10:02 PM CET, Dave Airlie wrote:
> On Thu, 5 Mar 2026 at 03:14, Danilo Krummrich <dakr@kernel.org> wrote:
>>
>> On Tue Feb 24, 2026 at 4:17 AM CET, Dave Airlie wrote:
>> > From: Dave Airlie <airlied@redhat.com>
>> >
>> > If we have runtime suspended, and userspace wants to use /dev/drm_dp_*
>> > then just tell it the device is busy instead of crashing in the GSP
>> > code.
>> >
>> > WARNING: CPU: 2 PID: 565741 at drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/rpc.c:164 r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
>> > Modules linked in: overlay uinput rfcomm snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables qrtr bnep s>
>> > snd_soc_acpi intel_rapl_msr libarc4 kvm crc8 soundwire_bus irqbypass snd_soc_sdca rapl iwlwifi snd_soc_avs uvcvideo intel_cstate think_lmi uvc firmware_attributes_class intel_uncore intel_wmi_thunderbolt wmi_bmof snd_hda_codec_conexant snd_hda_codec_nvhdmi videobuf2_vmalloc snd_soc_hda_codec cfg80211 videobu>
>> > processor_thermal_mbox sparse_keymap intel_soc_dts_iosf intel_pch_thermal platform_profile rfkill snd soundcore int3403_thermal int340x_thermal_zone int3400_thermal acpi_thermal_rel acpi_pad joydev loop nfnetlink zram lz4hc_compress lz4_compress xfs wacom hid_microsoft ff_memless nouveau ucsi_acpi typec_ucsi>
>>
>> I'd remove the modules linked in, it seems not relevant.
>>
>> > CPU: 2 UID: 0 PID: 565741 Comm: fwupd Not tainted 6.18.10-200.fc43.x86_64 #1 PREEMPT(lazy)
>> > Hardware name: LENOVO 20QTS0PQ00/20QTS0PQ00, BIOS N2OET65W (1.52 ) 08/05/2024
>> > RIP: 0010:r535_gsp_msgq_wait+0x9a/0xb0 [nouveau]
>> >
>> > This is a simple fix to get backported. We should probably engineer a proper power domain solution to wake up devices and keep them away while fw updates are happening.
>>
>> s/away/awake/ and line length.
>>
>> > Cc: stable@vger.kernel.org
>>
>> Do we want this backported before GSP introduction?
>>
>> I.e. if it's only about the WARN_ON() and otherwise doesn't cause problems it
>> should probably be
>>
>> Fixes: 176fdcbddfd2 ("drm/nouveau/gsp/r535: add support for booting GSP-RM")
>>
>> otherwise
>>
>> Fixes: 8894f4919bc4 ("drm/nouveau: register a drm_dp_aux channel for each dp connector")
>
> Go back to this for safety, probably won't blow up but it could still
> cause wierd register timeouts.
>
>>
>> > Signed-off-by: Dave Airlie <airlied@redhat.com<
>>
>> No need to resend, I can fix up the above (and the minor typo in the SoB) on
>> apply.
Applied to drm-misc-fixes, thanks!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-03-04 21:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-02-24 3:17 [PATCH] nouveau/dpcd: return EBUSY for aux xfer if the device is asleep Dave Airlie
2026-03-04 17:14 ` Danilo Krummrich
2026-03-04 17:14 ` Danilo Krummrich
2026-03-04 21:02 ` Dave Airlie
2026-03-04 21:09 ` Danilo Krummrich
2026-03-04 21:09 ` Danilo Krummrich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.