Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Bryan O'Donoghue
Date: Thu Mar 19 2026 - 13:03:37 EST
On 19/03/2026 16:08, Neil Armstrong wrote:
On 3/19/26 16:18, Bryan O'Donoghue wrote:Per-PHY voltage rails, per-PHY power domains and per-PHY OPP scaling.
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.
How the PHY gets represented in the kernel is of zero interest to user-sapce.
That said, stubbing out the media entity is independent work that can happen in any order and IMO is a separate debate. Whether or not CSIPHY init sequences live inside of a monolithic CAMSS driver or live inside off a discrete csiphy driver is not related to the media graph.
Happy to have that debate - and if indicated, carefully apply patches separately.
So what does this actually solves ?
Neil
Using the PHY API instead of rolling our own, as well as separate nodes in the DT.
We've been getting away with power-domains, opp scaling etc by sheer luck. The feedback from the list alone now addressed in this driver makes the conversion worthwhile.
---
bod