[RFC] phy: qcom: mipi-csi2-3ph: SM8750 ships CSIPHY 2.4.0 lane table - preferred shape?

[RFC] phy: qcom: mipi-csi2-3ph: SM8750 ships CSIPHY 2.4.0 lane table - preferred shape?

[Qianhui Xu]

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.

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.

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)?

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.

Disclosure: this mail was written with AI assistance; the author reviewed and
verified every statement, and all measurements and decisions are the author's.

Thanks,
Qianhui Xu

Re: [RFC] phy: qcom: mipi-csi2-3ph: SM8750 ships CSIPHY 2.4.0 lane table - preferred shape?

[Bryan O'Donoghue]

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