Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 3/30/26 1:41 PM, Bryan O'Donoghue wrote:
> On 30/03/2026 12:34, Konrad Dybcio wrote:
>> Let's take a step back - since any CSIPHY can feed into any CSID (at runtime),
>> the resulting nodes would either look like:
>>
>> // hardcoded, m may != n
>> csid_n: csid@1000000 {
>>     phys = <&csiphy_m>;
>> };
>>
> 
> Well that would be wrong they can connect to any CSID. We'd be churning the user-space ABI and imposing an artificial constraint on what the hw can do.
> 
>>
>> // determined at runtime
>> csid_n: csid@1000000 {
>>     phys = <&csiphy_0>,
>>            [...]
>>            <&csiphy_n-1>;
>> };
> 
> This I think works well and actually maps to what the hardware can do. This would be where to talk more about Neil's mux.
> 
>>
>> or we could store them once, centrally, in the "CAMSS_TOP" node and
>> pass handles around as necessary:
>>
>> // camss "catalog/manager" driver/library provides CSIDn with PHYm
>> camss: camss@10000000 {
>>     phys = <&csiphy_0>,
>>            [...]
>>            <&csiphy_n-1>;
>>
>>     csid_n: csid@1000 {
>>         // no PHY references
>>     };
>> };
> That could work too.

I personally think this is the cleanest approach, at least from the dt-description
standpoint.

For combo mode..

I forgot what the conclusion was on the sensor-to-(CAMSS vs CSIPHY) connections
or whether there was one, but in any case, I think that data-lanes and bus-type
could be aggregated across each PHY instance and the final operating mode could
be chosen based on that, at runtime by the driver that managed all this (say,
via phy_configure())

Konrad

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy