mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: lyude@redhat.com
To: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>,
	 linux-kernel@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org,
	Danilo Krummrich <dakr@kernel.org>,
	 Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann	 <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>,
	Simona Vetter	 <simona@ffwll.ch>,
	Mary Guillemard <mary@mary.zone>,
		nouveau@lists.freedesktop.org
Subject: Re: [PATCH v2 05/10] drm/nouveau/disp: fix HDMI GCP AVMute register offsets on GB20x
Date: Fri, 21 Aug 2026 17:59:28 -0400	[thread overview]
Message-ID: <66d7cd7ee0a94e01ccb559a36178497ae2d806ad.camel@redhat.com> (raw)
In-Reply-To: <20260820164929.17117-6-mohamedahmedegypt2001@gmail.com>

Code-wise this looks totally fine, but I'm not actually getting any
audio on my local GB206 setup. Is this expected, e.g. will we need more
work to actually get it working?

On Thu, 2026-08-20 at 20:49 +0400, Mohamed Ahmed wrote:
> The GSP path brackets audio enablement with a General Control Packet
> AVMute toggle. r535_sor_hdmi_audio() calls the gsp.hdmi_gcp hook,
> which
> every chip so far serves with tu102_sor_hdmi_gcp() and the legacy GCP
> unit at 0x6f00c0/0x6f00cc. On GB20x the SF packet units were
> compacted
> and the old generic and VSI units are gone (ACR keeps slot 2) and the
> GCP unit moved from slot 3 to slot 1 (control 0x6f0040 and subpack
> 0x6f004c from NVIDIA's published clc971.h. The same offsets are also
> used by OpenRM's hdmiWriteGeneralCtrlPacketC871() on these chips).
> The
> old addresses are reserved on GB20x, so the AVMute writes were silent
> no-ops and mitigated only by the equivalent GCP r535_sor_hdmi_audio()
> already sends through the SET_OD_PACKET RM control.
> 
> Add a GB20x GCP writer using the new offsets and hook it into
> gb202_gsp_disp, keeping the direct MMIO path in sync with the
> hardware
> as on earlier chips.
> 
> Only SB0 (the AVMute bit) is written. On NVD5.0 the subpack register
> also
> carries SB1_CTRL (bit 24), which selects where the deep-color CD/PP
> fields are generated (hardware or from the driver, with the default
> being
> HW). hdmiWriteGeneralCtrlPacketC871() likewise writes only SB0-SB2.
> 
> Signed-off-by: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
> ---
>  .../gpu/drm/nouveau/nvkm/engine/disp/gb202.c  | 20
> ++++++++++++++++++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gb202.c
> b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gb202.c
> index fa83aee35ae7..4863b2b36db0 100644
> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/gb202.c
> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/gb202.c
> @@ -65,6 +65,24 @@ gb202_sor_hdmi_infoframe_vsi(struct nvkm_ior *ior,
> int head, void *data, u32 siz
>  	nvkm_wr32(device, 0x6f03f8 + hoff, 0x00000002);
>  }
>  
> +/* General Control Packet AVMute bracket. The GCP unit moved to slot
> 1 on
> + * NVD5.0. Only SB0 (the AVMute bit) is ours to write so we must not
> do a
> + * full write here: SB1 carries the deep-color CD/PP fields, and
> SB1_CTRL
> + * (bit 24, new with clc871.h) controls where their generation
> happens (HW
> + * or driver) on these chips, with the default being HW.
> + */
> +static void
> +gb202_sor_hdmi_gcp(struct nvkm_ior *sor, int head, bool enable)
> +{
> +	struct nvkm_device *device = sor->disp-
> >engine.subdev.device;
> +	const u32 hdmi = head * 0x400;
> +
> +	nvkm_mask(device, 0x6f0040 + hdmi, 0x00000001, 0x00000000);
> +	nvkm_mask(device, 0x6f004c + hdmi, 0x000000ff, !enable ?
> 0x00000001 :
> +								
> 0x00000010);
> +	nvkm_mask(device, 0x6f0040 + hdmi, 0x00000001, 0x00000001);
> +}
> +
>  /* GB20x is GSP-only. This table supplies the register programming
> the
>   * GSP-RM display path needs from the chip.
>   */
> @@ -77,7 +95,7 @@ gb202_gsp_disp = {
>  	.gsp.head_rgpos = gv100_head_rgpos,
>  	.gsp.vblank_get = tu102_head_vblank_get,
>  	.gsp.vblank_put = tu102_head_vblank_put,
> -	.gsp.hdmi_gcp = tu102_sor_hdmi_gcp,
> +	.gsp.hdmi_gcp = gb202_sor_hdmi_gcp,
>  	/* The legacy AVI unit is unchanged on GB20x. */
>  	.gsp.hdmi_infoframe_avi = gv100_sor_hdmi_infoframe_avi,
>  	.gsp.hdmi_infoframe_vsi = gb202_sor_hdmi_infoframe_vsi,


  reply	other threads:[~2026-08-21 21:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 16:49 [PATCH v2 00/10] nouveau: assorted display fixes (GB20x, r570 DP_CONFIG_STREAM, HF-EEODB EDIDs) Mohamed Ahmed
2026-08-20 16:49 ` [PATCH v2 01/10] drm/nouveau/disp: move GSP head-timing ISR and vblank helpers to tu102.c Mohamed Ahmed
2026-08-21 19:21   ` lyude
2026-08-21 21:31   ` lyude
2026-08-20 16:49 ` [PATCH v2 02/10] drm/nouveau/disp: move the GSP HDMI GCP AVMute write to engine/disp Mohamed Ahmed
2026-08-21 19:25   ` lyude
2026-08-20 16:49 ` [PATCH v2 03/10] drm/nouveau/disp: route GSP-RM display MMIO through nvkm_disp_func hooks Mohamed Ahmed
2026-08-21 21:30   ` lyude
2026-08-20 16:49 ` [PATCH v2 04/10] drm/nouveau/disp: fix HDMI vendor infoframes on GB20x Mohamed Ahmed
2026-08-21 21:52   ` lyude
2026-08-20 16:49 ` [PATCH v2 05/10] drm/nouveau/disp: fix HDMI GCP AVMute register offsets " Mohamed Ahmed
2026-08-21 21:59   ` lyude [this message]
2026-08-20 16:49 ` [PATCH v2 06/10] drm/nouveau/gsp: use per-version DP_CONFIG_STREAM params on r570 firmware Mohamed Ahmed
2026-08-21 22:02   ` lyude
2026-08-20 16:49 ` [PATCH v2 07/10] drm/nouveau/disp: fix head state readback on GB20x Mohamed Ahmed
2026-08-21 22:06   ` lyude
2026-08-20 16:49 ` [PATCH v2 08/10] drm/nouveau/gsp: fix vblank interrupts " Mohamed Ahmed
2026-08-21 22:12   ` lyude
2026-08-21 22:36     ` Mohamed Ahmed
2026-08-20 16:49 ` [PATCH v2 09/10] drm/nouveau/dispnv50: program pixel clocks above 2.147GHz " Mohamed Ahmed
2026-08-21 22:16   ` lyude
2026-08-20 16:49 ` [PATCH v2 10/10] drm/nouveau: honor HF-EEODB EDIDs by converting to struct drm_edid Mohamed Ahmed
2026-08-21 22:19   ` lyude
2026-08-21 22:09 ` [PATCH v2 00/10] nouveau: assorted display fixes (GB20x, r570 DP_CONFIG_STREAM, HF-EEODB EDIDs) lyude

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=66d7cd7ee0a94e01ccb559a36178497ae2d806ad.camel@redhat.com \
    --to=lyude@redhat.com \
    --cc=airlied@gmail.com \
    --cc=dakr@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mary@mary.zone \
    --cc=mohamedahmedegypt2001@gmail.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®