Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue
Date: Fri Mar 20 2026 - 05:57:01 EST
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 should be no two CAMSS CSIPHY device (or subdevice) drivers, where
The standalone PHY driver doesn't require removing the CSIPHY mediaThere's no reason to remove that from CAMSS - it would be an ABI breakIf technically CAMSS CSIPHY could be excluded from the list of CAMSS media
in user-space anyway.
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.
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.
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