Shikra hdmi lt9611uxd

[mohitdsor]

Add LT9611UXD DSI-to-HDMI bridge support for the Shikra IQS EVK board
and introduce DT overlay infrastructure for HDMI and panel configurations.

The LT9611UXD bridge is connected via I2C bus 4 (address 0x41), powered
by a GPIO-controlled 3.3V regulator (PM8150 GPIO4) and an always-on 1.8V
rail. Reset is on GPIO76 and interrupt on GPIO85. The bridge receives DSI
output from MDSS DSI0 and drives an HDMI-A connector.

Changes:

• Add LT9611UXD HDMI bridge node, MDSS display enable, regulators and
  pinctrl for Shikra IQS EVK
• Rename HDMI bridge regulators and pinctrl to generic names
  (vreg_disp_3p3, bridge_irq_pin, bridge_rst_pin)
• Add DT overlay files and Makefile entries for shikra-cqm-evk-hdmi,
  shikra-cqs-evk-hdmi and shikra-iqs-evk-dlc-panel

Tested-on: Shikra IQS EVK with LT9611UXD HDMI bridge

Signed-off-by: Mohit Dsor mohit.dsor@oss.qualcomm.com

[qlijarvis]

PR #1808 — validate-patch

PR: #1808

Verdict	Issues	Detailed Report
❌	5	Full report

Final Summary

1. Lore link present: Yes — commit 1/3 links to https://lore.kernel.org/all/20260728-shikra-work-v3-1-e08c322596ac@oss.qualcomm.com/; commits 2/3 and 3/3 are PENDING: (no lore link expected)

2. Lore link matches PR commits: No — commit 1/3 contains extra content (mmc1 alias + 39 additional lines) not present in the lore v3 patch. The PR patch adds 156 lines; the lore patch adds 117 lines.

3. Upstream patch status: ⏳ Decision Pending — lore v3 patch is under review, maintainer feedback not yet addressed, author plans to submit v4 after prerequisite patches merge. Not yet accepted into any maintainer tree.

4. PR present in qcom-next/topics: Partial - 1/3 commit(s) only have partial integration evidence

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1808 - "FROMLIST: arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support" (+ 2 PENDING commits)
Upstream commit: https://lore.kernel.org/all/20260728-shikra-work-v3-1-e08c322596ac@oss.qualcomm.com/
Verdict: ❌ FAIL

---

Commit 1/3: FROMLIST: arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support

Commit Message

Check	Status	Note
Subject matches upstream	✅	Identical with FROMLIST: prefix added
Body preserves rationale	✅	Full description preserved
Fixes tag present/correct	N/A	No Fixes tag in upstream or PR
Authorship preserved	✅	From: matches lore author (Mohit Dsor)
Backport note (if applicable)	N/A	FROMLIST: commit, not a backport

Diff

File	Status	Notes
arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts	❌	Extra content not in lore patch — PR adds mmc1 = &sdhc_2; alias line that does not exist in the upstream v3 patch

Issues

1. Extra content in PR patch (commit 1/3)

The PR patch contains an additional line not present in the lore v3 patch:

+		mmc1 = &sdhc_2; /* SDC2 SD card slot */

This line appears in the aliases node but is not part of the upstream lore patch at https://lore.kernel.org/all/20260728-shikra-work-v3-1-e08c322596ac@oss.qualcomm.com/.

The lore patch adds 117 lines; the PR patch adds 156 lines. The extra 39 lines include this mmc1 alias and other content not attributed to any lore link.

2. Upstream patch status: ⏳ Decision Pending (awaiting prerequisite merges)

The lore thread shows:

• Krzysztof Kozlowski (DT maintainer) replied on 2026-07-29 with review comments
• Mohit Dsor (author) replied on 2026-08-18: "We will fix all comments here and submit new version once dependent patches are merged."
• The patch has not been applied to any maintainer tree
• The patch is blocked on prerequisite patches (5 prerequisite series listed in cover letter)
• No Reviewed-by:, Acked-by:, or applied signal from maintainers

Verdict: ⏳ Decision Pending — patch is under review, author plans to submit v4 after dependencies merge, maintainer feedback not yet addressed.

---

Commit 2/3: PENDING: arm64: dts: qcom: shikra-iqs-evk: Rename HDMI bridge regulators and pinctrl

Check	Status	Note
Lore link present	❌	No lore link — PENDING: prefix indicates work-in-progress
Lore link matches	N/A	No lore link to compare against
Upstream patch status	N/A	Vendor-only change, not posted upstream

Note: PENDING: commits are vendor work-in-progress and are not expected to have lore links. This commit cannot be validated against upstream.

---

Commit 3/3: PENDING: arm64: dts: qcom: shikra: Add HDMI and DLC panel overlay support

Check	Status	Note
Lore link present	❌	No lore link — PENDING: prefix indicates work-in-progress
Lore link matches	N/A	No lore link to compare against
Upstream patch status	N/A	Vendor-only change, not posted upstream

Note: PENDING: commits are vendor work-in-progress and are not expected to have lore links. This commit cannot be validated against upstream.

---

Verdict

❌ FAIL — Commit 1/3 contains extra content (mmc1 alias) not present in the linked lore patch. The PR does not faithfully represent the upstream v3 patch.

Recommendation:

1. Split commit 1/3 into two commits:

   • Commit 1a: Faithful FROMLIST: backport of the lore v3 patch (117 lines, no mmc1 alias)
   • Commit 1b: Separate QCLINUX: or PENDING: commit adding the mmc1 alias and any other vendor-specific content

2. Wait for upstream acceptance before merging commit 1a — the lore patch is still under review, maintainer feedback has not been addressed, and the author plans to submit v4 after prerequisite patches merge.

3. Address maintainer feedback — Krzysztof Kozlowski's review comments from 2026-07-29 must be addressed in the upstream v4 before this patch is suitable for integration.

---

Final Summary

1. Lore link present: Yes — commit 1/3 links to https://lore.kernel.org/all/20260728-shikra-work-v3-1-e08c322596ac@oss.qualcomm.com/; commits 2/3 and 3/3 are PENDING: (no lore link expected)

2. Lore link matches PR commits: No — commit 1/3 contains extra content (mmc1 alias + 39 additional lines) not present in the lore v3 patch. The PR patch adds 156 lines; the lore patch adds 117 lines.

3. Upstream patch status: ⏳ Decision Pending — lore v3 patch is under review, maintainer feedback not yet addressed, author plans to submit v4 after prerequisite patches merge. Not yet accepted into any maintainer tree.

4. PR present in qcom-next/topics: Partial — per integration_presence_report.md: commit 1/3 is present in topics (all added lines found), commit 2/3 is present in topics, commit 3/3 is only partially present (subject or partial tree evidence, but full change not verified). Overall status: 2/3 commits fully present, 1/3 partial.

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: d49c33864d06e9672dce57738be8851384578fcf
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit	Subject	qcom-next	topics	Final
1/3	[PATCH 1/3] FROMLIST: arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD	partial - subject or partial tree evidence found, but full change was not verified	present - all checked added lines are present	present
2/3	[PATCH 2/3] PENDING: arm64: dts: qcom: shikra-iqs-evk: Rename HDMI	missing - no subject, patch-id, or full tree-content match found	present - all checked added lines are present	present
3/3	[PATCH 3/3] PENDING: arm64: dts: qcom: shikra: Add HDMI and DLC panel	partial - subject or partial tree evidence found, but full change was not verified	partial - subject or partial tree evidence found, but full change was not verified	partial

Final Status

overall_status: PARTIAL
present_commits: 2/3
partial_commits: 1/3
missing_commits: 0/3
topics_checked_for_commits: 3/3
final_summary: PR present in qcom-next/topics: Partial - 1/3 commit(s) only have partial integration evidence

[qlijarvis]

PR #1808 — checker-log-analyzer

PR: #1808
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/34456933339

Checker	Result	Summary
Checker	Result	Summary
checkpatch	❌	Automerge conflict - checker did not run
dt-binding-check	❌	Automerge conflict - checker did not run
dtb-check	❌	Automerge conflict - checker did not run
sparse-check	❌	Automerge conflict - checker did not run
check-uapi-headers	❌	Automerge conflict - checker did not run
check-patch-compliance	❌	Automerge conflict - checker did not run
tag-check	⚠️	Manual check required (see below)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1808 - Shikra HDMI bridge and panel support
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/34456933339
Target branch: kernel-topics (non-qcom-next branch)

Checker	Result	Summary
checkpatch	❌	Automerge conflict - checker did not run
dt-binding-check	❌	Automerge conflict - checker did not run
dtb-check	❌	Automerge conflict - checker did not run
sparse-check	❌	Automerge conflict - checker did not run
check-uapi-headers	❌	Automerge conflict - checker did not run
check-patch-compliance	❌	Automerge conflict - checker did not run
tag-check	⚠️	Manual check required (see below)

---

❌ Infrastructure Failure: Automerge Conflicts

Root cause: All checker jobs failed during the automerge preparation step before any actual checking could occur. The CI workflow attempts to merge the PR branch with qcom-next baseline, but encountered unresolvable merge conflicts.

Failure details:

From all checker logs:

CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/arm/qcom,coresight-ctcu.yaml
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/clock/qcom,shikra-audiocorecc.yaml
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/media/qcom,qcm2290-venus.yaml
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/net/qcom,ethqos.yaml
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/sound/qcom,q6apm-dai.yaml
CONFLICT (content): Merge conflict in Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/Makefile
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/agatti.dtsi
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/pm4125.dtsi
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/shikra-cqm-evk.dts
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/shikra-cqm-som.dtsi
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/shikra-evk.dtsi
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/shikra-iqs-evk-imx577-camera.dtso
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/shikra-iqs-som.dtsi
CONFLICT (content): Merge conflict in arch/arm64/boot/dts/qcom/shikra.dtsi
CONFLICT (content): Merge conflict in arch/arm64/configs/defconfig
[... and 40+ more files with conflicts ...]

Automatic merge failed; fix conflicts and then commit the result.
automerge returned non-zero; check logs for conflicts
##[error]Process completed with exit code 1.

Analysis:

This is not a patch quality issue — it's an infrastructure/workflow problem. The PR targets a topic branch (kernel-topics) that has diverged significantly from qcom-next, causing the CI's automerge step to fail. The checker workflow is designed to:

1. Checkout qcom-next baseline
2. Run automerge to integrate all topic branches
3. Merge the PR on top
4. Run checkers on the merged result

Step 2 (automerge) is failing with 60+ merge conflicts across bindings, DTS files, drivers, and sound subsystem files. This prevents any checker from running.

Why this happened:

Based on the integration presence report, 2 out of 3 commits in this PR are already present in the topic branches:

• Commit 1/3: Present in topics
• Commit 2/3: Present in topics
• Commit 3/3: Partially present

The conflicts arise because:

1. The PR branch was created from an older baseline
2. Significant changes have landed in qcom-next and topic branches since then
3. Many of the same files touched by this PR have been modified upstream
4. The automerge tool cannot automatically resolve these conflicts

Fix:

This requires rebasing the PR branch onto the current qcom-next tip:

# In the PR branch
git fetch origin qcom-next
git rebase origin/qcom-next

# Resolve conflicts manually for each commit
# For each conflict:
git add <resolved-files>
git rebase --continue

# Force-push the rebased branch
git push --force-with-lease

Alternative approach:

Since the integration presence report shows that 2/3 commits are already present in topics, consider:

1. Dropping commits 1 and 2 from the PR (already integrated)
2. Keeping only commit 3/3 (the partial one)
3. Rebasing that single commit onto current qcom-next
4. Re-triggering CI

Reproduce locally:

git clone https://github.com/qualcomm-linux/kernel.git
cd kernel
git checkout qcom-next
git pull

# Clone automerge tool
cd ..
git clone https://github.com/qualcomm-linux/automerge.git

# Create merge.conf for the topic branch
echo "baseline https://github.com/qualcomm-linux/kernel.git qcom-next" > merge.conf
echo "topic https://github.com/qualcomm-linux/kernel-topics.git <PR-branch>" >> merge.conf

# Run automerge
cd kernel
../automerge/ci-merge -f ../merge.conf -t head -n

---

⚠️ tag-check — Subject Prefix Validation

Since the PR targets kernel-topics (not qcom-next or qcom-next-staging), every commit must have a valid subject prefix.

PR commits:

From pr.patch:

1. ✅ FROMLIST: arm64: dts: qcom: shikra-iqs-evk: Add LT9611UXD HDMI bridge support
2. ⚠️ PENDING: arm64: dts: qcom: shikra-iqs-evk: Rename HDMI
3. ⚠️ PENDING: arm64: dts: qcom: shikra: Add HDMI and DLC panel

Analysis:

• Commit 1/3: ✅ PASS — Has FROMLIST: prefix and includes a Link: to lore.kernel.org
• Commits 2/3 and 3/3: ⚠️ WARNING — Use PENDING: prefix

About PENDING: prefix:

The PENDING: prefix is used for work-in-progress commits that have not yet been posted upstream. While this is a valid internal prefix for tracking purposes, it has implications:

1. check-patch-compliance will fail for PENDING: commits because that checker only accepts upstream-linkable prefixes (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:).
2. This is a known limitation of the checker — vendor-internal prefixes like PENDING: and QCLINUX: are not recognized.
3. If these commits are intended to be upstreamed, they should be posted to the mailing list first, then the prefix changed to FROMLIST: with a Link: tag added.

Verdict for tag-check:

• ✅ All commits have a recognized prefix tag
• ⚠️ Commits 2/3 and 3/3 use PENDING:, which will cause check-patch-compliance to fail (expected behavior for non-upstream commits)

---

📋 Summary: What Actually Needs Checking

Since no checkers actually ran, we cannot assess:

• ❓ Coding style issues (checkpatch)
• ❓ DT binding schema validity (dt-binding-check)
• ❓ DTB validation errors (dtb-check)
• ❓ Sparse static analysis warnings (sparse-check)
• ❓ UAPI/ABI compatibility (check-uapi-headers)
• ❓ Upstream link compliance (check-patch-compliance)

To get actual checker results:

1. Rebase the PR onto current qcom-next to resolve automerge conflicts
2. Re-trigger CI to get fresh checker runs
3. Or: Drop already-integrated commits (1/3, 2/3) and only keep commit 3/3

---

🎯 Verdict

Status: ❌ CI infrastructure failure — no checkers executed

Blockers:

1. Critical: Automerge conflicts prevent all checkers from running
2. Action required: Rebase PR branch onto current qcom-next tip
3. Optional: Consider dropping commits 1/3 and 2/3 (already present in topics per integration report)

Next steps:

1. Rebase the PR branch to resolve conflicts
2. Re-trigger CI to get actual checker results
3. Address any checker failures that emerge after rebase

Note: The PENDING: prefix on commits 2/3 and 3/3 will cause check-patch-compliance to fail even after rebase. This is expected behavior for commits not yet posted upstream. If these are intended for upstream submission, post them to the mailing list first and update the prefix to FROMLIST: with a Link: tag.