Re: [PATCH 3/4] media: qcom: camss: Add support for SM8150

[Bryan O'Donoghue <bryan.odonoghue@linaro.org>]

On 04/11/2026 20:54, Andrew Gigena via B4 Relay wrote:
> The hardware reuses the existing 3-phase 1.0 CSIPHY, Gen2 CSID and
> VFE 17x implementations; the CSIPHY uses the SC8280XP lane register
> layout. Add CAMSS_8150 to the version enum and to the shared code
> paths, then add the per-block clock, regulator, power domain,
> interrupt and interconnect resources.

That's odd. sm8150 and sm8250 are proximate both seven nanometers 
sc8280xp is five nanometers.

PHYs are about converting the analog to the digital domain and so 
process geometery - ends up making a difference.

You can get the PHY init sequences here:

drivers/media/platform/msm/camera/cam_sensor_module/cam_csiphy/
├── cam_csiphy_core.c
├── cam_csiphy_soc.c
├── cam_csiphy_dev.h
└── include/
     ├── cam_csiphy_1_0_hwreg.h    sdm845
     ├── cam_csiphy_1_1_hwreg.h    sm8150
     ├── cam_csiphy_1_2_hwreg.h    sm7150
     └── cam_csiphy_1_2_1_hwreg.h  kona/sm8250

https://git.codelinaro.org/clo/la/platform/vendor/opensource/camera-kernel/-/blob/LA.AU.1.3.7-02900-gen3_gvmgh.0/drivers/cam_sensor_module/cam_csiphy/include/cam_csiphy_1_1_hwreg.h?ref_type=tags

So yeah going by the name that's CSIPHY 1_1 same for sc8280xp and sm8150.

Hmm so much for my understanding of how dependant on process node these 
sequences really are.. perhaps the PHYs area fully synthesizable in RTL, 
probably.

Anyway.

The one thing to do here is to please _verify_ what's upstream now 
against the tag provided there.

If there is a divergence then we need to upstream a 8150 compliant version.

...

Actually its fine, did the verification for you, the 1.1 init sequence 
as is upstream is fine.

Just please tidy up the ordering of the 8150 switches.

---
bod