Re: [PATCH 1/3] phy: core: add generic MIPI C-PHY configuration API

[Anusha Arun Nandi <anusha.nandi@oss.qualcomm.com>]

On 10/19/2026 7:15 AM, Loic Poulain wrote:
> On Mon, Oct 19, 2026 at 1:24 PM Bryan O'Donoghue <bod@kernel.org> wrote:
>>
>> On 19/10/2026 11:24, Bryan O'Donoghue wrote:
>>> On 18/10/2026 00:00, Bryan O'Donoghue wrote:
>>>>> +    unsigned int        lanes;
>>>>
>>>> This statement and how you go about using the data aren't consistent.
>>>
>>> Re-reading this.
>>>
>>> unsigned int trios; would be fine too => data_lanes and lane_polarities
>>> is a multiple of trios - always three - does it imply that the first
>>> three entries in data-lanes == the first trio ?
>>>
>>> Presumably.
>>>
>>> That would work too.
>>>
>>> data-lanes = <4 5 6 1 2 3>;
>>>
>>> =>
>>>
>>> trios = 2
>>>
>>> =>
>>>
>>> data_lanes[4, 5, 6, 1, 2, 3];
>>>
>>> trio[0]:lanes == [4, 5, 6];
>>> trio[1]:lanes == [1, 2, 3];
>>>
>>> Probably "trios" instead of "lanes" makes more sense here and the driver
>>> just always validates that count(data_lanes) % 3 is always false.
>>>
>>> ---
>>> bod
>>
>> I'm going to argue with myself.
>>
>> data-lanes = <1>
>>
>> =>
>>
>> lanes = 1; // not trios no need to introduce a new term
> 
> I earlier recommended using "trios" in the other C-PHY series to be
> more accurate and emphasize the distinction from D-PHY's (two-wire
> lanes), and because it is the terminology commonly used in the C-PHY
> specification. That said, I'm fine with either term, but yes, we
> should be consistent and avoid mixing "lanes" and "trios" within the
> same structure.
> 
Completely agree. I will be using data_lanes to clear ambiguity.>>
>> =>
>>
>> three pads on the Soc
>>
>> =>
>>
>> The question is - is data_lanes required for the CPHY opts struct ? For
>> the qcom CAMSS case the answer ~ always no - we will be attaching a
>> sensor and will read-back the positions from that endpoint.
>>
>> It is conceivable that other systems may want to pass data-lanes down to
>> the driver because they won't have a media-graph but, I'd say we should
>> arbitrate that then - leave it up to someone who needs the fields to add
>> them.
>>
>> =>
>>
>> lanes // the CSID and PHY should agree
>> symbol_rate // so both the CSID and phy agree on symbols per second
>>
>> Remove:
>>
>> - lane_positions
>> - lane_polarities
>>
>> Since at least for this series, they won't be needed.
>>
>> The CSID still needs to know the number of lanes and how many symbols so
>> that it can calculate bandwidth so .... lets just include the data we
>> know we need.
>>
>> struct cphy_opts {lanes; rate/symbols}; dropping lane_positions and
>> lane_polarities.
>>
>> I've no objection to the low-level timing variables myself but OTOH we
>> don't require them at this point in time.
>>
>> Perhaps drop unless/until someone can show a need for them.
>>
>> Excellent bod, agree with you now.
>>
>> ---
>> bod