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

[Anusha Arun Nandi]

Thanks Bryan,

I align with your thought process. We don't need
- lane_positions
- lane_polarities

I will add symbol_rate and fill in the data appropriately.

Best Regards,
Anusha

On 10/19/2026 4:24 AM, Bryan O'Donoghue 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
> 
> =>
> 
> 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