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/amd/display: Increase DCN314 SR latency by 1us
Date: Mon, 16 Mar 2026 12:18:56 +1000
Message-ID: <review-patch1-KUZPR04MB9265F4DDEF7627D2E3747BBBE645A@KUZPR04MB9265.apcprd04.prod.outlook.com>
In-Reply-To: <KUZPR04MB9265F4DDEF7627D2E3747BBBE645A@KUZPR04MB9265.apcprd04.prod.outlook.com>
References: <KUZPR04MB9265F4DDEF7627D2E3747BBBE645A@KUZPR04MB9265.apcprd04.prod.outlook.com> <KUZPR04MB9265F4DDEF7627D2E3747BBBE645A@KUZPR04MB9265.apcprd04.prod.outlook.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

**Correctness:** The patch consistently updates all relevant locations:

1. **`dcn314_clk_mgr.c`** =E2=80=94 The `lpddr5_wm_table` has all four wate=
rmark entries (WM_A through WM_D) updated identically:
   - `sr_exit_time_us`: 30.0 =E2=86=92 31.0
   - `sr_enter_plus_exit_time_us`: 32.0 =E2=86=92 33.0

   This is correct =E2=80=94 the difference between `sr_enter_plus_exit_tim=
e_us` and `sr_exit_time_us` remains 2.0=CE=BCs (i.e., the enter time alone =
is still 2=CE=BCs), which preserves the original relationship.

2. **`dcn314_fpu.c`** =E2=80=94 The `dcn3_14_soc` bounding box is updated:
   - `sr_exit_time_us`: 16.5 =E2=86=92 17.5
   - `sr_enter_plus_exit_time_us`: 18.5 =E2=86=92 19.5

   Again, the 2=CE=BCs delta between enter+exit and exit-only is preserved.

**Observations:**

- The DDR5 table (`ddr5_wm_table` at line 410) is **not** modified =E2=80=
=94 only the LPDDR5 table is changed. This is consistent with the commit me=
ssage stating the issue is specific to LPDDR5 modules. However, the soc bou=
nding box values in `dcn314_fpu.c` are global (not memory-type-specific), s=
o both DDR5 and LPDDR5 paths will see the increased latency from the FPU si=
de. This seems intentional as a conservative safety margin, but the reviewe=
r may want to confirm the author considered whether the FPU change could af=
fect DDR5 configurations.

- The `Fixes:` tag references a freedesktop.org GitLab issue rather than a =
commit SHA. This is non-standard for the kernel =E2=80=94 typically a `Fixe=
s:` tag references a commit that introduced the bug (format: `Fixes: <sha1>=
 ("commit subject")`). If this is intended for stable backports, a proper `=
Fixes:` tag with a commit hash would be needed. If the issue just tracks th=
e bug report, consider using `Link:` or `Closes:` instead.

- The patch lacks a `Cc: stable@vger.kernel.org` tag, which would be approp=
riate if this is meant to fix a user-visible regression.

**Nit:** The commit message `[Why & How]` marker is an AMD-internal convent=
ion =E2=80=94 no issue, just noting it.

**Verdict:** The change itself looks correct and safe. The main feedback it=
ems are:
1. Fix the `Fixes:` tag to reference a commit hash (or change to `Link:`/`C=
loses:`)
2. Confirm the FPU bounding box change (which affects all memory types) is =
intentional
3. Consider adding `Cc: stable@vger.kernel.org` if this should be backported

---
Generated by Claude Code Patch Reviewer