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: phy: qualcomm: add MSM8974 HDMI PHY support
Date: Sun, 22 Mar 2026 04:56:09 +1000
Message-ID: <review-patch4-20260319-fd-hdmi-phy-v6-4-cefc08a55470@oss.qualcomm.com>
In-Reply-To: <20260319-fd-hdmi-phy-v6-4-cefc08a55470@oss.qualcomm.com>
References: <20260319-fd-hdmi-phy-v6-0-cefc08a55470@oss.qualcomm.com> <20260319-fd-hdmi-phy-v6-4-cefc08a55470@oss.qualcomm.com>
X-Mailer: Claude Code Patch Reviewer
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Patch Review

Adds PLL rate calculation and programming to the MSM8974 (28HPM) HDMI PHY d=
river. This is the most algorithmically complex patch.

**Critical: Likely unit mismatch for `tmds_char_rate`**

The `struct phy_configure_opts_hdmi` defines `tmds_char_rate` in Hz (unsign=
ed long long). However, the PLL calculation code treats it as kHz:

```c
unsigned long pixclk =3D opts->hdmi.tmds_char_rate;
...
if (pixclk =3D=3D 297000) {
```

297000 Hz is 297 kHz, not the 297 MHz (297000000 Hz) that 4K HDMI requires.=
 Either the comparisons should be against `297000000` (Hz), or `pixclk` sho=
uld be explicitly divided: `pixclk =3D opts->hdmi.tmds_char_rate / 1000`. T=
he VCO calculations later also appear to assume kHz:

```c
unsigned long vco_rate =3D pixclk * 10;
...
unsigned long rem =3D vco_rate % ref_clk;
```

If `pixclk` were in Hz (~148500000 for 1080p), then `vco_rate =3D pixclk * =
10` would overflow a 32-bit intermediate on some platforms, and the divisor=
 values would be wrong. This needs verification against the hardware refere=
nce.

**Good use of FIELD_PREP for register programming**

```c
writel(FIELD_PREP(UNIPHY_PLL_SDM_CFG0_BYP, !sdm_byp) |
       FIELD_PREP(UNIPHY_PLL_SDM_CFG0_BYP_DBLR, sdm_byp),
       pll_base + UNIPHY_PLL_SDM_CFG0);
```

This is much more readable than the raw magic number writes in the old driv=
er.

**`of_device_get_match_data` in probe path**

Same issue as patch 1 =E2=80=94 should use `device_get_match_data()`.

**PLL lock polling**

```c
while (!(readl(pll_base + UNIPHY_PLL_STATUS) & UNIPHY_PLL_STATUS_PLL_LOCK))=
 {
	udelay(1);
	if (timeout_us-- =3D=3D 0)
		return -ETIMEDOUT;
}
```

This is a common pattern but `readl_poll_timeout()` would be the idiomatic =
kernel helper for this, providing consistent timeout behavior and reducing =
boilerplate.

---

**Summary**: The series is architecturally sound but has two critical issue=
s (missing compatible strings for APQ8084/MSM8998, and a likely Hz/kHz unit=
 mismatch in PLL calculations) that must be resolved before merge. The mino=
r issues (typos, API preferences, code duplication) are worth fixing but no=
n-blocking.

---
Generated by Claude Code Patch Reviewer