* Re: [RFC] phy: qcom: mipi-csi2-3ph: SM8750 ships CSIPHY 2.4.0 lane table - preferred shape?
2026-11-15 5:28 ` [RFC] phy: qcom: mipi-csi2-3ph: SM8750 ships CSIPHY 2.4.0 lane table - preferred shape? Qianhui Xu
@ 2026-11-15 17:44 ` Bryan O'Donoghue
0 siblings, 0 replies; 2+ messages in thread
From: Bryan O'Donoghue @ 2026-11-15 17:44 UTC (permalink / raw)
To: Qianhui Xu; +Cc: linux-phy, linux-arm-msm, devicetree
On 15/11/2026 05:28, Qianhui Xu wrote:
> Hi Bryan,
>
> SM8750 (Lenovo TB322FC, mainline bring-up) carries a CSIPHY whose vendor driver
> describes its lane table as csiphy_2ph_v2_4_0_reg. Upstream's lane_regs_x1e80100[]
> in phy-qcom-mipi-csi2-3ph-dphy.c is the 2.1.2 generation, so the two differ.
> Before sending anything I'd like your preference on the shape.
OK I's not clear to me if what is meant is stuff that Hangxiang is
working on
There's a v25 on list for sm8750
https://patchwork.linuxtv.org/user/todo/linux-media/?series=33877
New work/additional-work/bug-fixes on top of that branch or absorption
of downstream work ?
> What I measured (vendor camera_dlkm module, unstripped; 103-entry table, 1648 B):
>
> - address set identical, 103/103; (addr, data, param_type) differs in 13 entries
> - 0x0000/0x0400/0x0800/0x0c00 : 0x8e -> 0x8c (DEFAULT, 4)
> - 0x0008/0x0408/0x0808/0x0c08/0x0e08 : 0x10 -> 0x19 (SETTLE_CNT_LOWER_BYTE, 5)
> - 0x0060/0x0460/0x0860/0x0c60 : 0xbd -> 0xfd (SKEW_CAL, 4)
>
> Those three values also track the vendor's own generation numbering across every
> 2ph table in that module: v2.1.x = (8e,10,bd), v2.2.x = (8e,19,bd),
> v2.3.0/2.4.0/2.4.1 = (8c,19,fd). So they look like generation markers rather than
> per-SoC tuning.
OK but I still don't really get the context - against 7.4-rc3 or against
that with Hangxiang's changes or something else ?
I think I already indicated the stuff on-list is good to go so if you
have more fixes/changes/enhancements please ensure to base off of those.
> One thing worth stating up front, because it bounds what the patch can claim:
> in phy_qcom_mipi_csi2_gen2_config_lanes() the SETTLE entries are overwritten with the
> value computed from the link frequency, and SKEW entries are skipped (still
> "TODO: support application of skew from dt flag"). Only the four 0x0000 writes
> (0x8c) actually change behaviour today.
>
> Questions:
>
> 1) Shape: a new lane_regs_sm8750[] plus a mipi_csi2_dphy_3nm_sm8750 soc cfg
> (compatible "qcom,sm8750-csi2-phy" with "qcom,kaanapali-csi2-phy" as fallback),
> or would you rather see the difference expressed per generation
> (e.g. lane_regs_2_4_0[] shared by any future SoC on that generation)?
I think I pointed you at Hangxiang's series before, if not please check
it out now.
>
> 2) Evidence level: with only one SM8750 unit I can measure a 30 fps capture
> regression, nothing more. Is "matches the vendor table for that generation"
> an acceptable justification for the 0x0000 value change, or do you want the
> SETTLE/SKEW entries dropped from the table until the driver actually applies
> them (so the patch carries no dead data)?
> 3) Binding: standalone "qcom,sm8750-csi2-phy" const vs. an items
entry with the
> kaanapali fallback. I see a kaanapali series in flight touching the same oneOf,
> so I'd rather follow whatever shape that series lands with.
>
> I have a two-patch draft ready (binding + driver) that applies on 7.4-rc3 and passes
> checkpatch --strict, W=1 and dt_binding_check; I'll hold it until you answer.
Please align your work with the on-list stuff.
> Disclosure: this mail was written with AI assistance; the author reviewed and
> verified every statement, and all measurements and decisions are the author's.
I'm finding the LLM output pretty difficult to understand to be honest.
But if I've understood you here I think you've missed
Hangxiang/Qualcomm's work for 8750 so please pick up on that and see if
there are still gaps for you.
---
bod
^ permalink raw reply [flat|nested] 2+ messages in thread