Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver

[Bryan O'Donoghue <bod@kernel.org>]

On 20/03/2026 00:37, Vladimir Zapolskiy wrote:
> On 3/19/26 17:18, Bryan O'Donoghue wrote:
>> On 19/03/2026 14:56, Vladimir Zapolskiy wrote:
>>>> There's no reason to remove that from CAMSS - it would be an ABI break
>>>> in user-space anyway.
>>> If technically CAMSS CSIPHY could be excluded from the list of CAMSS media
>>> subdevices, then for the sake of simplification it should be done for all
>>> supported platforms in advance, such a change will be independent from this
>>> particular phy series, and vice versa, this CAMSS only driver change will
>>> prepare a ground for media-less CAMSS CSIPHY device drivers, hence it shall
>>> precede this particular CAMSS CSIPHY series.
>>>
>>> For backward compatibility with userspace a noop stub will be good enough,
>>> it's not an issue at all.
>> The standalone PHY driver doesn't require removing the CSIPHY media
>> entity from CAMSS. They serve different purposes and coexist - its
>> important to have a NOP from user-space perspective for legacy and
>> indeed for new implementations.
>>
> There should be no two CAMSS CSIPHY device (or subdevice) drivers, where
> one chop of CAMSS CSIPHY device driver remains to sit under media, and
> another one is under phy subsystem, since it's a further degradation from
> the current already pretty awful state of the CAMSS driver, but at least
> CSIPHY is not scattered over different subsystems today.
> 
> It might be fine to move device driver parts related to CAMSS CSIPHY
> driver from media subsystem to phy subsystem, however if only a partial
> transition is planned, and CSIPHY device support is split into two device
> (sub-)drivers, then it merely exposes a quite severe design flaw.

It's not two drivers for the same device. It's two layers:

- The media entity in CAMSS is a pipeline routing abstraction.
   It validates formats and connects pads. It does not program
   CSIPHY hardware directly.

- The PHY driver programs the hardware — registers, clocks,
   regulators, power domains.

This is the same layering as rkisp1 (media pipeline) +
phy-rockchip-inno-csidphy (electrical config). The ISP's media
entities and the standalone PHY coexist in different subsystems
without conflict.

No CSIPHY functionality is duplicated across subsystems. This segmenting 
of concepts and functionality isn't even unique. We see this constantly 
with USB (where the MAC lives in drivers/usb/ and the electricals in 
drivers/phy/) and Display/DSI.


> It looks like it's still undecided, if CAMSS CSIPHY IP is a phy or media
> device, it can not be both at the same time.

We are maintaining the existing user-space setup which presents a 
msm_csiphyX v4l2-media device, whilst moving the PHY component out into 
drivers/phy where it belongs - completely transparently to user-space. 
So we already have a dependency in user-space which needs to be maintained.

The concrete hardware benefits, as I alluded to Neil, are:

- Per-PHY voltage rails
- Per-PHY power domains
- Per-PHY operating points (OPPs)

Those are real-world hardware fixes which "just work" as a result of 
dedicated device nodes and a driver specifically written to relieve the 
technical debt we've been accruing with the existing model, for years.

Having been educated - brought to the realisation on OPPS, Power-domains 
and yes voltage rails it is amazing to me this whole legacy system 
hasn't exploded before now but, its certainly way past time to fix it.

We should proceed with moving init sequences, voltages, PDs and OPPs to 
drivers/phy.

I'm happy to have a debate about the status of the PHY media device 
after, however I have to say I'm skeptical about removing the media 
device - something we could do whether the init sequences live in 
drivers/media/qcom/camss or in drivers/phy BTW - I'm skeptical about 
removing that v4l2 node specifically because we've had it in user-space 
for a long time and I do therefore think that constitutes an ABI.

As I've said already though `rm -rf /dev/v4l2-subdev::msm_csiphy*" is 
basically an entirely separate debate.

---
bod