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

[Bryan O'Donoghue]

On 19/03/2026 16:08, Neil Armstrong wrote:
> On 3/19/26 16: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.
>>
>> 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
Per-PHY voltage rails, per-PHY power domains and per-PHY OPP scaling.

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