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

[Neil Armstrong]

On 3/19/26 14:17, Bryan O'Donoghue wrote:
> On 19/03/2026 13:08, Vladimir Zapolskiy wrote:
> > > Why do you want a media driver? Isn't PHY driver enough?
> > As for today CAMSS CSIPHY are already media devices, and a user applies media
> > specific properties to them, for instance media bus format, resolution etc.
> > Technically this might be removed from CAMSS, but if so, then it should be
> > done before this new PHY driver model is applied.
> >
> > --
> > Best wishes,
>
> There's no reason to remove that from CAMSS - it would be an ABI break in user-space anyway.
>
> The media entity in CAMSS msm_csiphyX handles format negotiation and pipeline routing. The PHY driver handles electrical configuration. They don't conflict and there multiple cited examples of this upstream already.

If csiphy component was only handling  electrical configuration, the only code handling csiphy would be phy API calls, not be part of the pipeline configuration. Today, it's a media element

The whole CAMSS architecture is wrong, it should be modular, each hardware module should be an independent driver and all be connected via port/endpoint and configured with the media controller API.

If you _really_ want to move the "electrical configuration" part of the CSPIPHY out of camss frankendriver, fine, then first just create an internal PHY device as an aux device, then continue migrating _all_ CAMSS components into independent driver modules, then in the end re-architecture the whole DT description by adding a node per component with a proper port/endpoint representation to be configured via the media controller API.

Neil

> --
> bod