From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D83CC2E06E6 for ; Fri, 21 Aug 2026 22:12:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787350353; cv=none; b=en9UQzrhW2BUDdLMAisc9My8clBQeCmXPvCVMqo3kha9UoEaW/lwEVh8bsD9DmBwPtSt1v2QZjr0Ou3fNjK23FTOhp30oo1o/Z9Ev2ktonleK8FZZ6lTm4iSwPXxNRa3atdbBcj9twoXdQ5H0gh+bmBb0bDuv5O6lgmI9CDm85E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787350353; c=relaxed/simple; bh=Ufjajzx4IA3guwOhN1w4aI+Kj4DSvo4wC0KgBwNsRM0=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=k8EhVREeUefFmuacyGaZRmR7YOAu/+MtvMbtsKr51CUZTBNbj4e3USt7NnjIZh3oxHnQ+WTXX341J20skXGQriqoCn90vWXr7ZHufqbAV1LlYMrW+wfE3gyNE6AQNsp9l+hLnibszh9Pf0tidpZoOgWYUs/7stciXres8dOJyT4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=G7FosK7L; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=rhelNtc4; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="G7FosK7L"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="rhelNtc4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1787350350; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=I0eUZt+KIoHEj0to+icRP80gEEgroNZ4RZo6TFwXBQ8=; b=G7FosK7L1sBKSs/Bm3OwQhE3euUP9kECyLP70ylrXzU46a+DehXWwe8jjBJuKFlC6giY3U +C0NH96BIsliCyQIjEncv+esz1veo3IuFecz66Of4xkzy0rWA5wPx/7YUF3LPpRILapUue UT2Jyne+4HEpss/m4p0e4kTP7n69jdg= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-183-V25dFOkaN122x17kKzUI4Q-1; Fri, 21 Aug 2026 18:12:29 -0400 X-MC-Unique: V25dFOkaN122x17kKzUI4Q-1 X-Mimecast-MFC-AGG-ID: V25dFOkaN122x17kKzUI4Q_1787350349 Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-934956beec8so251723285a.0 for ; Fri, 21 Aug 2026 15:12:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1787350349; x=1787955149; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to:content-type; bh=I0eUZt+KIoHEj0to+icRP80gEEgroNZ4RZo6TFwXBQ8=; b=rhelNtc4IpM7X5nR8c+LRZI4u0WvzWJ7jtgYA6kuUJuy0NpLPje0Fe97kOsvPuuaxP MZeY8tqPptxJKHojue8MNUyGgGzv9F2tCHTfChZLLshm4sAfHPkTned2RcMI6S9QbFdS 61CKpuUbTQDPsFuyBNhF1WFnE9KUAF773XVS4Uw+YRThFm1BvvOXVJMct4+1WPJLlxdv 5ydSvB4dnhTU0ySYruroBBDM+6XQF9XRlcGYPuC5KXEEQtsfsFSDBM8P02u9rfXFBXLG tdOHI385U4Zh+aaiR7JJjGV/kYlGvydanaCxCmeKH3JAV93ptAYROp1pfmLarX9fuq9t i3cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787350349; x=1787955149; h=mime-version:user-agent:content-transfer-encoding:content-type :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=I0eUZt+KIoHEj0to+icRP80gEEgroNZ4RZo6TFwXBQ8=; b=DCtv+bomnyO85RY8MQBJ5m70/G0xuUpnGdoptWZRrusRvdPZJE0RlyC5vCXG+rbu+t iAK+V6h5KvvrdvCOrh/6EyadIuDjd9mGV7M4ER9vP5FPVpf9VK+3v9Uhiqp3QCQ6XxCT X96Fm13G8GIU6wHwkyg5IJBfQkcVBhJ/Vjb++H67kS/0YYw2oGMZ/3LQtmqfnW+UZHAS GAwXCvSEcUTvs6ocnN4tc3OYl7hC/ZR2F1WOpG2RtSAz8hczddx5WCoLnACr/mkJNZxE f4PT86F51PkJwX3WqQ+TAInNO/YsuOPEB2+o2hKK5bRbGi1Bm4VxfpovQt41vBBBfDkR zqjg== X-Forwarded-Encrypted: i=1; AHgh+Ro6vQSXJ203jehi9ZYX94qVpmY+7oFNm5N6UxI2phFxmV6rk7o3mJOa+vVh0ceVlXllh0h9xWzDeU/4vnY=@vger.kernel.org X-Gm-Message-State: AFuF++lXNjNFYB2cKOQl4vGIgwJQ0HcvUh7dn6fTcX9Bi6w+n3Ub5LR9 nXMwi3OHtxwcK0nXRy6x4yDC+ETBRlPObY8CJpFPoDAS+fESmjl+EHItJ3MDRmgMuJro/BZOvlp 1yC9iZIYR5RURX6HkotlidzQDIaXY5s0/bBnzuGCpmPoO6Sf37lloVZ1O6MKIj+ApvQ== X-Gm-Gg: AR+sD10bHy4xtXIPYsavHPW+lvTyyqFEaevt8DutRwRFx3yb5iyYXSqflEpB4RTl/V7 yrFqfukiZfsPJ5vtFMJGtweAix6D8sWbPgoZ2WnfrrHW5zEa8fbgSqyHWDd1nLrqSgALXXv3Efc q2AukzjUVwLZ6vJ8nYJ4k3LL3aVkXUaItDnC4IzS26qioBjVOevpXdf7i/16fPcum/FBMdt4BFD Zdd1SiSlEMQoodALSvL45qyOJIANuFHj1K7atzRbx/rb0h0N+6RCXAvFo+RMzFHB4/5v1NoMagz 31qY+Cpb8JAriSVaJ3AtoKKgucxy6pP4xKiSBsg7T/rbXP3fuCFDWJKJBs8eP2soN8bzDBCx X-Received: by 2002:ae9:e50d:0:b0:92e:5444:9274 with SMTP id af79cd13be357-937395378e7mr667906785a.30.1787350348740; Fri, 21 Aug 2026 15:12:28 -0700 (PDT) X-Received: by 2002:ae9:e50d:0:b0:92e:5444:9274 with SMTP id af79cd13be357-937395378e7mr667902985a.30.1787350348297; Fri, 21 Aug 2026 15:12:28 -0700 (PDT) Received: from [192.168.8.4] ([100.0.180.93]) by smtp.gmail.com with ESMTPSA id af79cd13be357-93749da8294sm7974085a.32.2026.08.21.15.12.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Aug 2026 15:12:27 -0700 (PDT) Message-ID: <33cd07ffe8f6a9c525f9d9b6d646efbf09cf76e9.camel@redhat.com> Subject: Re: [PATCH v2 08/10] drm/nouveau/gsp: fix vblank interrupts on GB20x From: lyude@redhat.com To: Mohamed Ahmed , linux-kernel@vger.kernel.org Cc: dri-devel@lists.freedesktop.org, Danilo Krummrich , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Mary Guillemard , nouveau@lists.freedesktop.org Date: Fri, 21 Aug 2026 18:12:26 -0400 In-Reply-To: <20260820164929.17117-9-mohamedahmedegypt2001@gmail.com> References: <20260820164929.17117-1-mohamedahmedegypt2001@gmail.com> <20260820164929.17117-9-mohamedahmedegypt2001@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Some comments regarding both patch #2 and this patch below: On Thu, 2026-08-20 at 20:49 +0400, Mohamed Ahmed wrote: > The GSP path programs per-head timing (vblank) interrupts the same > way on > every generation. NVD5.0 (GB20x) reworked the FE interrupt frontend > around four message-based kernel vectors (high latency, low latency, > PMU, > and GSP) and moved RM head-timing interrupts to the dedicated low- > latency > vector: >=20 > =C2=A0- The enable is NV_PDISP_FE_RM_INTR_EN1_HEAD_TIMING, 0x611ef0 + > =C2=A0=C2=A0 head*4 (570.144 kernel_head_0501.c, renamed kernel_head_0502= .c > from > =C2=A0=C2=A0 575.51.02 on, and v05_01 dev_disp.h). >=20 > =C2=A0- The vector is reported as a separate interrupt table entry, > =C2=A0=C2=A0 MC_ENGINE_IDX_DISP_LOW (intr_gb202.c, intrCacheDispIntrVecto= rs). >=20 > =C2=A0- The vector must be re-armed through NV_PDISP_FE_INTR_RETRIGGER(1) > =C2=A0=C2=A0 at 0x611f34 after servicing (kdispServiceInterrupt -> > =C2=A0=C2=A0 kdispIntrRetrigger_v05_01). >=20 > The event latch (0x611800), per-head status (0x611c00), and dispatch > summary (0x611ec0) the interrupt handler uses are unchanged on GB20x > (kheadReadPendingVblank_v03_00 and kheadResetPendingLastData_v03_00 > remain for DISPv0502+). >=20 > On GB20x the old code enables head timing onto the legacy vector, > leaves > its handler there, and never re-arms the message-based vectors. Page > flips still complete (nv50 sends those events from the commit path), > so > the desktop looks fine while DRM vblank waits and vblank sequence > queries > are affected. >=20 > Supply GB20x vblank enables and an interrupt handler that re-arms the > vector after servicing through gb202_gsp_disp, translate the low- > latency > interrupt table entry as a second NVKM_ENGINE_DISP instance, and flag > the table so r535_disp_oneinit() attaches the handler to that > instance. >=20 > Signed-off-by: Mohamed Ahmed > --- > =C2=A0.../gpu/drm/nouveau/nvkm/engine/disp/gb202.c=C2=A0 | 42 > +++++++++++++++++-- > =C2=A0.../nouveau/nvkm/subdev/gsp/rm/r535/disp.c=C2=A0=C2=A0=C2=A0 |=C2= =A0 5 ++- > =C2=A0.../drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c |=C2=A0 9 ++++ > =C2=A03 files changed, 52 insertions(+), 4 deletions(-) >=20 > diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gb202.c > b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gb202.c > index a66c820be9fe..f78669bafd64 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gb202.c > +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gb202.c > @@ -130,6 +130,40 @@ gb202_head_state(struct nvkm_head *head, struct > nvkm_head_state *state) > =C2=A0 } > =C2=A0} > =C2=A0 > +/* NVD5.0 (GB20x and later) moved the RM head-timing interrupt > enable to > + * the low-latency vector's EN1 block. The event latch is unchanged. > + */ > +static void > +gb202_head_vblank_put(struct nvkm_head *head) > +{ > + struct nvkm_device *device =3D head->disp- > >engine.subdev.device; > + > + nvkm_mask(device, 0x611ef0 + (head->id * 4), 0x00000002, > 0x00000000); > +} > + > +static void > +gb202_head_vblank_get(struct nvkm_head *head) > +{ > + struct nvkm_device *device =3D head->disp- > >engine.subdev.device; > + > + nvkm_wr32(device, 0x611800 + (head->id * 4), 0x00000002); > + nvkm_mask(device, 0x611ef0 + (head->id * 4), 0x00000002, > 0x00000002); > +} > + > +static irqreturn_t > +gb202_disp_intr(struct nvkm_inth *inth) > +{ > + struct nvkm_disp *disp =3D container_of(inth, typeof(*disp), > engine.subdev.inth); > + irqreturn_t ret =3D tu102_disp_intr(inth); > + > + /* The FE interrupt vectors are message-based on NVD5.0. Re- > arm the > + * low-latency vector so it fires again for any event that > latched > + * while we were servicing. > + */ > + nvkm_wr32(disp->engine.subdev.device, 0x611f34, 0x00000001); > + return ret; > +} > + > =C2=A0/* GB20x is GSP-only. This table supplies the register programming > the > =C2=A0 * GSP-RM display path needs from the chip. > =C2=A0 */ > @@ -137,11 +171,13 @@ static const struct nvkm_disp_func > =C2=A0gb202_gsp_disp =3D { > =C2=A0 .uevent =3D &gv100_disp_chan_uevent, > =C2=A0 .ramht_size =3D 0x2000, > - .gsp.intr =3D tu102_disp_intr, > + /* Head timing arrives on the dedicated low-latency vector. > */ > + .gsp.intr =3D gb202_disp_intr, > + .gsp.intr_low_latency =3D true, > =C2=A0 .gsp.head_state =3D gb202_head_state, > =C2=A0 .gsp.head_rgpos =3D gv100_head_rgpos, > - .gsp.vblank_get =3D tu102_head_vblank_get, > - .gsp.vblank_put =3D tu102_head_vblank_put, > + .gsp.vblank_get =3D gb202_head_vblank_get, > + .gsp.vblank_put =3D gb202_head_vblank_put, > =C2=A0 .gsp.hdmi_gcp =3D gb202_sor_hdmi_gcp, > =C2=A0 /* The legacy AVI unit is unchanged on GB20x. */ > =C2=A0 .gsp.hdmi_infoframe_avi =3D gv100_sor_hdmi_infoframe_avi, > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/disp.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/disp.c > index 3a8ff621ed62..a95f78c4502f 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/disp.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/disp.c > @@ -1705,7 +1705,10 @@ r535_disp_oneinit(struct nvkm_disp *disp) > =C2=A0 > =C2=A0 /* Chips that raise head-timing interrupts on a separate > low-latency > =C2=A0 * vector report it as a second DISP interrupt table entry, > exposed > - * as instance 1 by the RM engine-index translation. > + * as instance 1 by the RM engine-index translation (see > + * r570_gsp_xlat_mc_engine_idx()). Their high-latency vector > + * (instance 0) is left unhandled as no event nouveau > enables is > + * routed to it, and without a handler it stays masked. > =C2=A0 */ I didn't notice it until I got to this patch, but is it possible you mistakenly added the intr_low_latency stuff a little early with patch #2 and meant to add it here? (doesn't matter to me too much either way, whatever you intended works fine with me) Otherwise: Reviewed-by: Lyude Paul > =C2=A0 ret =3D nvkm_gsp_intr_stall(gsp, disp->engine.subdev.type, > =C2=A0 =C2=A0 disp->func->gsp.intr_low_latency ? > 1 : disp->engine.subdev.inst); > diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c > b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c > index 3e391646d8f7..b45781cd0dfd 100644 > --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c > +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r570/gsp.c > @@ -44,6 +44,15 @@ r570_gsp_xlat_mc_engine_idx(u32 mc_engine_idx, > enum nvkm_subdev_type *ptype, int > =C2=A0 *ptype =3D NVKM_ENGINE_DISP; > =C2=A0 *pinst =3D 0; > =C2=A0 return true; > + case MC_ENGINE_IDX_DISP_LOW: > + /* GB20x+ report a separate low-latency display > vector, used > + * for head-timing interrupts. Expose it as a second > DISP > + * interrupt instance. r535_disp_oneinit() attaches > the > + * handler to it when the chip's > gsp.intr_low_latency is set. > + */ > + *ptype =3D NVKM_ENGINE_DISP; > + *pinst =3D 1; > + return true; > =C2=A0 case MC_ENGINE_IDX_CE0 ... MC_ENGINE_IDX_CE19: > =C2=A0 *ptype =3D NVKM_ENGINE_CE; > =C2=A0 *pinst =3D mc_engine_idx - MC_ENGINE_IDX_CE0;