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: dt-bindings: display: ti, am65x-dss: Fix AM62L DSS reg and clock constraints
Date: Sun, 12 Apr 2026 09:43:12 +1000
Message-ID: <review-patch1-20260410105955.843868-1-s-jain1@ti.com>
In-Reply-To: <20260410105955.843868-1-s-jain1@ti.com>
References: <20260410105955.843868-1-s-jain1@ti.com> <20260410105955.843868-1-s-jain1@ti.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

**Overall: Good patch. The logic is correct and the YAML schema structure i=
s sound.**

**Positive aspects:**

- The `oneOf` for `reg` correctly differentiates AM62L's 5 registers (commo=
n, vidl1, ovr1, vp1, common1) from the dual-VP variants' 8 registers (addin=
g vid, ovr2, vp2). This accurately reflects that AM62L lacks the full VID p=
lane, the second overlay manager, and the second video port.

- The `reg-names` `oneOf` is kept in sync with the `reg` `oneOf`, maintaini=
ng the correct name-to-register mapping.

- The `if`/`then`/`else` conditional tightly binds the register and clock c=
ounts to the `compatible` string, preventing mismatched DTs from validating:

```yaml
    then:
      properties:
        clock-names:
          maxItems: 2
        clocks:
          maxItems: 2
        reg:
          maxItems: 5
    else:
      properties:
        clock-names:
          minItems: 3
        clocks:
          minItems: 3
        reg:
          minItems: 8
```

**Minor observations (not blocking):**

1. **Base `clocks`/`clock-names` still list 3 items:** The base `items` arr=
ay still describes all 3 clocks (fck, vp1, vp2), with `minItems: 2` added t=
o relax the requirement. For AM62L (maxItems: 2), the third item schema (vp=
2) becomes dead/unreachable. This is functionally correct =E2=80=94 JSON Sc=
hema tuple validation simply won't exercise the third schema =E2=80=94 but =
it could be slightly clearer if a comment or the description noted that vp2=
 only applies to dual-VP variants. This is purely a readability nit.

2. **Commit message formatting:** The subject line wraps oddly across two l=
ines in the mbox:
   ```
   Subject: [PATCH v3] dt-bindings: display: ti,
    am65x-dss: Fix AM62L DSS reg and clock constraints
   ```
   This appears to be an artifact of the mail header folding (the comma aft=
er "ti" triggers the line wrap). It should be fine when applied via `git am=
`, but worth verifying the subject renders correctly.

3. **No example DT for AM62L:** The `examples:` section has DT snippets for=
 `am65x-dss` and `am625-dss` but none for `am62l-dss`. Adding an AM62L exam=
ple with the 5-register, 2-clock layout would be helpful for validation and=
 documentation, but this could reasonably be done as a separate follow-up p=
atch. The gist linked in the changelog shows the author has validated with =
examples externally.

4. **Schema cross-validation:** The `oneOf` on `reg`/`reg-names` and the `i=
f`/`then`/`else` on counts are intentionally redundant =E2=80=94 the `oneOf=
` constrains the valid layouts structurally, while the conditional constrai=
ns the counts per-compatible. Together they ensure that e.g. `ti,am62l-dss`=
 with 8 registers would fail both the `maxItems: 5` check and (potentially)=
 the `oneOf` matching. This belt-and-suspenders approach is good practice i=
n dt-bindings.

**No functional issues found. The patch correctly fixes the AM62L DSS bindi=
ng constraints.**

---
Generated by Claude Code Patch Reviewer