From mboxrd@z Thu Jan  1 00:00:00 1970
From: Claude Code Review Bot <claude-review@example.com>
To: dri-devel-reviews@example.com
Subject: Claude review: drm/bridge: dw-hdmi-qp: fix multi-channel audio output
Date: Tue, 03 Mar 2026 14:21:02 +1000
Message-ID: <review-patch1-20260228112822.4056354-1-christianshewitt@gmail.com>
In-Reply-To: <20260228112822.4056354-1-christianshewitt@gmail.com>
References: <20260228112822.4056354-1-christianshewitt@gmail.com> <20260228112822.4056354-1-christianshewitt@gmail.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0

Patch Review

**The bug:** The HDMI Audio InfoFrame buffer layout is:
- `buffer[0..2]` = Header bytes (HB0, HB1, HB2)
- `buffer[3]` = PB0 (Checksum)
- `buffer[4]` = PB1, `buffer[5]` = PB2, `buffer[6]` = PB3
- `buffer[7]` = PB4 (Channel Allocation), `buffer[8]` = PB5 (Level Shift), ...

The registers pack these as:
- `PKT_AUDI_CONTENTS0` (0xc20): `{ RSV, HB2, HB1, RSV }`
- `PKT_AUDI_CONTENTS1` (0xc24): `{ PB3, PB2, PB1, PB0 }`
- `PKT_AUDI_CONTENTS2` (0xc28): `{ PB7, PB6, PB5, PB4 }`

The old code:
```c
regmap_bulk_write(hdmi->regm, PKT_AUDI_CONTENTS1, &buffer[3], 1);
regmap_bulk_write(hdmi->regm, PKT_AUDI_CONTENTS2, &buffer[4], 1);  // BUG
```

`&buffer[4]` points to PB1, but `CONTENTS2` expects `{PB7, PB6, PB5, PB4}` which starts at `buffer[7]`. This caused PB4 (Channel Allocation) to receive the value of PB1 (Coding Type / Channel Count), and PB5 (Level Shift) to receive the value of PB2 (Sample Frequency / Sample Size), explaining the reported missing audio channels and incorrect speaker placement.

**The fix:**
```c
-	regmap_bulk_write(hdmi->regm, PKT_AUDI_CONTENTS2, &buffer[4], 1);
+	regmap_bulk_write(hdmi->regm, PKT_AUDI_CONTENTS2, &buffer[7], 1);
```

Changing to `&buffer[7]` correctly points to PB4, so `CONTENTS2` gets `{PB7, PB6, PB5, PB4}` as intended.

**Verdict:** The fix is correct. The offset arithmetic checks out: CONTENTS1 writes 4 bytes starting at buffer[3] (PB0-PB3), and CONTENTS2 should write the next 4 bytes starting at buffer[7] (PB4-PB7). The gap of 4 between 3 and 7 matches the 4-byte register width. The Fixes tag references the correct commit that introduced the bug.

**One observation for the maintainers:** Since this code has already been refactored in drm-next (replaced with the `dw_hdmi_qp_write_infoframe()` generic helper that handles the offset arithmetic in a loop), this patch is primarily relevant as a stable backport candidate. It may be worth adding a `Cc: stable@vger.kernel.org` tag if one isn't already implied by the Fixes tag, depending on the tree's workflow.

---
Generated by Claude Code Patch Reviewer