Re: [PATCH RFC 0/6] phy/media: Add generic MIPI C-PHY support to CSI-2 stack

[Nihal Kumar Gupta <nihal.gupta@oss.qualcomm.com>]

On 18-10-2026 05:09, Bryan O'Donoghue wrote:
>>   drivers/media/platform/qcom/camss/camss.c          |   8 +-
>>   drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 159 +++++++++++++++++----
> 
> So on thing I notice about this series and like is that there's a small change to the existing 3ph-dphy.c
> 
> - Since it supports 3ph-cphy the file should be renamed
>   3ph-cphy-dphy.c (or something)
I agree with the direction here. Keeping the 3-phase CPHY and DPHY support
in a single driver looks like the right model.

> - I like the progressive nature of he changes in this series
>   as structurally the right way to add stuff in. Small digestable
>   commits
> - I think the missing piece here is data_lanes[] and lane_polarities[]
>   per the other series from Qcom
> - Another thing is the other series from Anusha has
>   a more advanced mipi_ops data-structure for CPHY.
> 
> Basically I like the approach taken in this series for a smaller change to the phy-qcom-mipi-csi2-3ph-dphy.c file.
> 
> I'd like the best of both series - I think there is alot to resolve on lanes, data-lanes and lane-polarities in the other series and looking at this series, it seems to me we don't need a separate phy-qcom-mipi-csi2-3ph-cphy.c, I think Konrad observed in George's series that really the file deals with 3-phase PHYs and that seems true enough.
> 
> Please work out between yourself and Anusha what's next.
> 
> If possible I would prefer to contain 3ph CPHY and DPHY to one file as is done here - at the same time the definition of CPHY ops and lane mappings is closer to the spec in the other series.
> 
> I think either you should take Anusha's structs and lane definitions or Anusha should take your approach to minimal change to the phy-qcom-mipi-csi2-3ph-dphy.c renaming it.
> One of you needs to pick up the patches from the other one.
> 
I can pick up the CPHY ops/lane mapping pieces from Anusha's series and
post the combined common series. Anusha, if you prefer to carry it instead,
please feel free to take this series and fold in your CPHY ops/lane mapping
changes.

The split I suggest is:

- Combined common series: driver rename + generic 3ph CPHY support + CPHY ops/lane mapping.
- Follow-up from Anusha: Lemans/Monaco-specific lane/register programming.
- Follow-up from George: Hamoa support on top of the common CPHY support.

-- 
Regards,
Nihal Kumar Gupta