Skip to content

CAMSS: CPHY Support for RB3G2, RB4, RB8 - #872

Open
aarunnan wants to merge 15 commits into
qualcomm-linux:qcom-6.18.yfrom
aarunnan:camss_cphy_6.18y
Open

CAMSS: CPHY Support for RB3G2, RB4, RB8#872
aarunnan wants to merge 15 commits into
qualcomm-linux:qcom-6.18.yfrom
aarunnan:camss_cphy_6.18y

Conversation

@aarunnan

Copy link
Copy Markdown

Enablement of CPHY for RB3G2, RB4, RB8.
CRs-Fixed: 4617368

David Heidelberg (okias) and others added 15 commits July 28, 2026 11:57
The lane mask must be multiplied by 2, but this was accidentally omitted.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-1-83da8a8e4e44@ixit.cz
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Suggested-by: Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Read PHY configuration from the device-tree bus-type and save it into
the csiphy structure for later use.

For C-PHY, skip clock line configuration, as there is none.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-2-83da8a8e4e44@ixit.cz
Acked-by: Cory Keitz <ckeitz@amazon.com>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…g C-PHY lanes

So far, only D-PHY mode was supported, which uses even bits when enabling
or masking lanes. For C-PHY configuration, the hardware instead requires
using the odd bits.

Since there can be unrecognized configuration allow returning failure.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-3-83da8a8e4e44@ixit.cz
Acked-by: Cory Keitz <ckeitz@amazon.com>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Inherit C-PHY information from CSIPHY, so we can configure CSID
properly.

CSI2_RX_CFG0_PHY_TYPE_SEL must be set to 1, when C-PHY mode is used.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-4-83da8a8e4e44@ixit.cz
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Acked-by: Cory Keitz <ckeitz@amazon.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…on is available

The lanes must not be initialized before the driver has access to
the lane configuration, as it depends on whether D-PHY or C-PHY mode
is in use. Move the lane initialization to csiphy_lanes_enable which is
called when the configuration structures are available.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-5-83da8a8e4e44@ixit.cz
Co-developed-by: Petr Hodina <phodina@protonmail.com>
Signed-off-by: Petr Hodina <phodina@protonmail.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Acked-by: Cory Keitz <ckeitz@amazon.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…PHY init

Add a PHY configuration sequence for the sdm845 which uses a Qualcomm
Gen 2 version 1.1 CSI-2 PHY.

The PHY can be configured as two phase or three phase in C-PHY or D-PHY
mode. This configuration supports three-phase C-PHY mode.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-6-83da8a8e4e44@ixit.cz
Acked-by: Cory Keitz <ckeitz@amazon.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
… C-PHY init

These values should improve C-PHY behaviour. Should match most recent
Qualcomm code.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-7-83da8a8e4e44@ixit.cz
Acked-by: Cory Keitz <ckeitz@amazon.com>
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
… frequency

Ensure that the link frequency divider correctly accounts for C-PHY
operation. The divider differs between D-PHY and C-PHY, as described
in the MIPI CSI-2 specification.

For more details, see:
https://docs.kernel.org/driver-api/media/tx-rx.html#pixel-rate

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-8-83da8a8e4e44@ixit.cz
Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://docs.kernel.org/driver-api/media/tx-rx.html#pixel-rate
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
After all the changes done we can now safely enable C-PHY for a SoC
where it's available.

Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-9-83da8a8e4e44@ixit.cz
Acked-by: Cory Keitz <ckeitz@amazon.com>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: David Heidelberg <david@ixit.cz>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Program the CSIPHY common-control registers during lane enable so
SA8775P uses the required 3-phase 1.5 Gsps reset-release values for
both C-PHY and D-PHY. Keep the existing reset-release value for the
other CAMSS variants.

Link: https://lore.kernel.org/r/20260717231331.1229693-2-anusha.nandi@oss.qualcomm.com
Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Program the gen3 CSID CSI2 RX PHY type field from the configured PHY
type. The RX path needs this value to distinguish C-PHY from D-PHY
input, so leaving it at the default makes C-PHY configuration
incomplete.

Link: https://lore.kernel.org/r/20260717231331.1229693-3-anusha.nandi@oss.qualcomm.com
Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Add the lane_regs_sa8775p_3ph[] register table for the
sa8775p Gen3 CSIPHY at 1.5 Gsps, and select it in csiphy_lanes_enable() for
CAMSS_8775P when the endpoint is configured for C-PHY, falling back to the
existing sa8775p D-PHY table otherwise.

Link: https://lore.kernel.org/r/20260717231331.1229693-4-anusha.nandi@oss.qualcomm.com
Co-developed-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Share the C-PHY/D-PHY lane_regs selection for CAMSS_8300 so
the sa8300 platform uses the same 3ph handling as CAMSS_8775P. Also drop
CAMSS_8300 from the missing-C-PHY-table guard now that a C-PHY table is
provided.

Link: https://lore.kernel.org/r/20260717231331.1229693-5-anusha.nandi@oss.qualcomm.com
Co-developed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
…er settings

The C-PHY PHY register configuration needs to vary with the link
(symbol) data rate. Until now only a single base lane_regs table was
applied per platform, regardless of the negotiated rate.

Introduce a data-rate selection mechanism for C-PHY:

 - Add struct data_rate_reg_info describing a per-bandwidth register
   override table.
 - Add csiphy_cphy_data_rate_config(), which selects the first table
   entry whose bandwidth satisfies the required PHY data rate (derived
   from the resolved link frequency) and writes those overrides on top
   of the base lane_regs configuration. The settle-count parameter
   types are handled specially. When the link frequency cannot be
   resolved, it falls back to the lowest supported rate.

 - Add per-data-rate register tables and data_rate_settings tables for
   sa8775p and 8300(1.5/1.7/2.5/3.5/4.5 GSpS)
   and sm8250 (2.5/3.5/4.5 GSpS).

 - Select the appropriate data-rate settings table in
   csiphy_lanes_enable() for both platforms when the endpoint is
   configured for C-PHY.

Link: https://lore.kernel.org/r/20260717231331.1229693-6-anusha.nandi@oss.qualcomm.com
Co-developed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
A link is invalid if the local CSIPHY endpoint and the remote sensor
endpoint describe different bus types. Such a mismatch can otherwise go
undetected until later probe or streaming failures.

Parse the remote endpoint in camss_parse_endpoint_node() and compare its
bus-type with the local endpoint. Reject the link with -EINVAL if the two
ends disagree, so C-PHY/D-PHY mismatches are caught early during probe.

Link: https://lore.kernel.org/r/20260717231331.1229693-7-anusha.nandi@oss.qualcomm.com
Co-developed-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Jigarkumar Zala <jigarkumar.zala@oss.qualcomm.com>
Signed-off-by: Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>
@qlijarvis

Copy link
Copy Markdown

PR #872 — validate-patch

PR: #872

Verdict Issues Detailed Report
0 Full report

Final Summary

  1. Lore link present: Yes — all 15 commits have valid lore.kernel.org links in commit messages
  2. Lore link matches PR commits: Yes — diff content is faithful to lore for all commits; no semantic changes, extra hunks, or missing content
  3. Upstream patch status: ⏳ Decision Pending — patches have Reviewed-by/Acked-by tags from subsystem reviewers (Vladimir Zapolskiy, Bryan O'Donoghue, Cory Keitz, Frank Li) but no definitive merge signal yet; posted June 17 and July 17, 2026; under active review on linux-media mailing list
  4. PR present in qcom-next/topics: Yes - all 15 commit(s) are present in qcom-next or topics
Verdict: ✅ — click to expand

🔍 Patch Validation

PR: [#872] media: qcom: camss: Add C-PHY support for sa8775p, sa8300 and sm8250
Upstream commits: Two lore series: v9 (commits 1-9) + sa8775p/sa8300 series (commits 10-15)
Verdict: ✅ PASS

Commit Message

Check Status Note
Subject matches upstream All 15 subjects match lore patches
Body preserves rationale Commit bodies preserved faithfully
Fixes tag present/correct N/A No Fixes tags in upstream patches
Authorship preserved All authors match lore: David (1-9), Jigarkumar (10-12), Anusha (13-15)
Backport note (if applicable) N/A FROMLIST prefix used correctly
Co-developed-by used correctly Present where needed (commits 5, 10-15)

Diff

File Status Notes
camss-csiphy-3ph-1-0.c Matches lore v9 + sa8775p series
camss-csiphy.h Matches lore v9
camss.c Matches lore v9 + sa8775p series
camss-csid-gen2.c Matches lore v9
camss-csid.c Matches lore v9 + sa8775p series
camss-csid.h Matches lore v9
camss-csiphy.c Matches lore v9
camss.h Matches lore v9

Issues

None — all commits faithfully represent their lore upstream sources.

Verdict

Merge as-is. All 15 commits correctly use the FROMLIST: prefix, preserve original authorship, include proper Co-developed-by/Signed-off-by chains, and match their lore upstream diffs. The PR combines two related patch series (David's v9 C-PHY enablement + Anusha/Jigarkumar's sa8775p/sa8300 support) into a single coherent feature addition.

Final Summary

  1. Lore link present: Yes — all 15 commits have valid lore.kernel.org links in commit messages
  2. Lore link matches PR commits: Yes — diff content is faithful to lore for all commits; no semantic changes, extra hunks, or missing content
  3. Upstream patch status: ⏳ Decision Pending — patches have Reviewed-by/Acked-by tags from subsystem reviewers (Vladimir Zapolskiy, Bryan O'Donoghue, Cory Keitz, Frank Li) but no definitive merge signal yet; posted June 17 and July 17, 2026; under active review on linux-media mailing list
  4. PR present in qcom-next/topics: Yes — all 15 commits are present in qcom-next or topics branches (per integration_presence_report.md)

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: 07f50dc44eddcf748a99d1a7523a466438bfffa6
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/15 [PATCH 01/15] FROMLIST: media: qcom: camss: csiphy-3ph: Fix lane mask missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 17d49b1 present
2/15 [PATCH 02/15] FROMLIST: media: qcom: camss: csiphy: Introduce PHY partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 5ae2ab5 present
3/15 [PATCH 03/15] FROMLIST: media: qcom: camss: csiphy-3ph: Use odd bits partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at b9f74b6 present
4/15 [PATCH 04/15] FROMLIST: media: qcom: camss: Prepare CSID for C-PHY partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at b2b8807 present
5/15 [PATCH 05/15] FROMLIST: media: qcom: camss: Initialize lanes after partial - subject or partial tree evidence found, but full change was not verified present - all checked added lines are present present
6/15 [PATCH 06/15] FROMLIST: media: qcom: camss: csiphy-3ph: Add Gen2 v1.1 partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 84b7d78 present
7/15 [PATCH 07/15] FROMLIST: media: qcom: camss: csiphy-3ph: Update Gen2 missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at 43b8192 present
8/15 [PATCH 08/15] FROMLIST: media: qcom: camss: Account for C-PHY when missing - no subject, patch-id, or full tree-content match found present - all checked added lines are present present
9/15 [PATCH 09/15] FROMLIST: media: qcom: camss: Enable C-PHY where partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at caf35e1 present
10/15 [PATCH 10/15] FROMLIST: media: qcom: camss: Program CSIPHY common partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at b08a6c5 present
11/15 [PATCH 11/15] FROMLIST: media: qcom: camss: Prepare CSID for C-PHY missing - no subject, patch-id, or full tree-content match found present - exact patch-id match at ad70e63 present
12/15 [PATCH 12/15] FROMLIST: media: qcom: camss: Add sa8775p C-PHY 3ph partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 0133569 present
13/15 [PATCH 13/15] FROMLIST: media: qcom: camss: Add sa8300 C-PHY 3ph lane present - all checked added lines are present skipped - not checked because qcom-next already contains the change present
14/15 [PATCH 14/15] FROMLIST: media: qcom: camss: Dynamic data-rate partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 301874a present
15/15 [PATCH 15/15] FROMLIST: media: qcom: camss: validate local/remote partial - subject or partial tree evidence found, but full change was not verified present - exact patch-id match at 3bcce10 present

Final Status

overall_status: PASS
present_commits: 15/15
partial_commits: 0/15
missing_commits: 0/15
topics_checked_for_commits: 14/15
final_summary: PR present in qcom-next/topics: Yes - all 15 commit(s) are present in qcom-next or topics

@qlijarvis

Copy link
Copy Markdown

PR #872 — checker-log-analyzer

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

Checker Result Summary
Checker Result Summary
checkpatch All 15 commits passed
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check Passed
check-uapi-headers Passed (no UAPI changes)
check-patch-compliance 3 commits failed
tag-check All commits have FROMLIST: prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #872 - FROMLIST: media: qcom: camss C-PHY support series (15 patches)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/30393056623
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch All 15 commits passed
dt-binding-check ⏭️ Skipped (no binding changes)
dtb-check ⏭️ Skipped (no DTS changes)
sparse-check Passed
check-uapi-headers Passed (no UAPI changes)
check-patch-compliance 3 commits failed
tag-check All commits have FROMLIST: prefix

❌ check-patch-compliance

Root cause: Three commits have content mismatches or invalid lore links compared to their upstream versions.

Failure details:

Commit 5/15: FROMLIST: media: qcom: camss: Initialize lanes after lane configuration is available

Change is different from the one mentioned in Link
Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-5-83da8a8e4e44@ixit.cz

Commit 8/15: FROMLIST: media: qcom: camss: Account for C-PHY when calculating link frequency

Something seems wrong with the provided link. Please verify it
Link: https://lore.kernel.org/r/20260617-qcom-cphy-v9-8-83da8a8e4e44@ixit.cz
https://docs.kernel.org/driver-api/media/tx-rx.html#pixel-rate

→ The checker detected two URLs in the commit message and attempted to fetch from the documentation URL, which is not a valid lore link. The actual lore link appears valid.

Commit 13/15: FROMLIST: media: qcom: camss: Add sa8300 C-PHY 3ph lane config

Change is different from the one mentioned in Link
Link: https://lore.kernel.org/r/20260717231331.1229693-5-anusha.nandi@oss.qualcomm.com

→ This commit references a different patch series (July 17 vs June 17) than the rest of the PR.

Fix:

For commit 5/15 and commit 13/15 (content mismatch):

  1. Fetch the upstream patch and compare:
    b4 am --single-message -C -l -3 <link> -o /tmp/upstream
    git format-patch -1 <sha> --stdout > /tmp/pr-patch
    diff <(awk '/^diff/,/^--$/' /tmp/pr-patch | grep -E '^[+-][^+-]') \
         <(awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]')
  2. Determine if the difference is:
    • Context-only shift (line numbers changed but code is identical) → False positive, no action needed
    • Legitimate adaptation (e.g., backport adjustments) → Document the changes in the commit message
    • Missing/extra hunks → Sync with upstream or split into separate commits

For commit 8/15 (invalid link detection):

  • The checker incorrectly parsed the documentation URL as a lore link.
  • The actual lore link https://lore.kernel.org/r/20260617-qcom-cphy-v9-8-83da8a8e4e44@ixit.cz appears valid.
  • Workaround: Move the documentation URL to the commit body text (not on a Link: line) or verify the lore link manually:
    b4 am --single-message -C -l -3 https://lore.kernel.org/r/20260617-qcom-cphy-v9-8-83da8a8e4e44@ixit.cz

Reproduce locally:

# For each failing commit:
b4 am --single-message -C -l -3 <lore-link> -o /tmp/out
git format-patch -1 <commit-sha> --stdout > /tmp/pr.patch
diff /tmp/pr.patch /tmp/out/*.mbx

Recommendation

3 blockers to fix before merge:

  1. Commit 5/15 — Verify content match with upstream or document adaptations
  2. Commit 8/15 — Fix documentation URL placement or verify lore link is fetchable
  3. Commit 13/15 — Verify content match with upstream (different patch series date suggests potential mismatch)

All other checkers passed cleanly. Once the check-patch-compliance issues are resolved, the PR should be ready to merge.

@qcomlnxci

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ⚠️ skip ⚠️ skip
BT_FW_KMD_Service ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
BT_ON_OFF ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
BT_SCAN ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
CPUFreq_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
CPU_affinity ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
DSP_AudioPD ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
Ethernet ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
IPA ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
Interrupts ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
OpenCV ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
PCIe ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
Probe_Failure_Check ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail
RMNET ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
UFS_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
USBHost ✅ Pass ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail
WiFi_Firmware_Driver ❌ Fail ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass
WiFi_OnOff ❌ Fail ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass
adsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
cdsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
gpdsp_remoteproc ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ✅ Pass ✅ Pass
hotplug ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
irq ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
kaslr ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
pinctrl ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
qcom_hwrng ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
rngtest ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
shmbridge ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
smmu ❌ Fail ❌ Fail ✅ Pass ❌ Fail ✅ Pass ✅ Pass ❌ Fail
watchdog ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
wpss_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass

@sgaud-quic

Copy link
Copy Markdown
Contributor

Shiraz Hashim (@shashim-quic) I see there is a NAK from community on below series :
https://lore.kernel.org/all/286a1fc6-bd58-4ade-b183-e53776ba7a09@linaro.org/

aarunnan are these comments addressed ?

@aarunnan

Copy link
Copy Markdown
Author

Shiraz Hashim (Shiraz Hashim (@shashim-quic)) I see there is a NAK from community on below series : https://lore.kernel.org/all/286a1fc6-bd58-4ade-b183-e53776ba7a09@linaro.org/

aarunnan are these comments addressed ?

Yes, the comments are addressed and its come to a conclusion there will be another patchset version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants