Re: [RFC v4] V4L DT bindings

[Nicolas THERY <nicolas.thery@st.com>]

Hello,

Thanks for the feedback.

On 2012-08-30 22:21, Sylwester Nawrocki wrote:
> On 08/30/2012 05:19 PM, Nicolas THERY wrote:

[snip]

>> In imx074@0x1a above, the data-lanes property is<1>,<2>.  Is it
>> reversed here to show that lanes are swapped between the sensor and the
>> CSI rx?  If not, how to express lane swapping?
> 
> Yes, this indicates lanes remapping at the receiver.
> 
> Probably we could make it a single value with length determined by
> 'bus-width', since we're going to use 'bus-width' for CSI buses as well, 
> (optionally) in addition to 'clock-lanes' and 'data-lanes' ?

Looks good to me.

[snip]

>> How to express that the positive and negative signals of a given
>> clock/data lane are inversed?  Is it somehow with the hsync-active
>> property?
> 
> Hmm, I don't think this is covered in this RFC. hsync-active is mostly
> intended for the parallel buses. We need to come up with new properties
> to handle CSI data/clock lane polarity swapping. There was a short
> discussion about that already:
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg41724.html
> 
>> Actually there may be two positive/negative inversion cases to consider:
>>
>> - the positive/negative signals are inversed both in low-power and
>>    high-speed modes (e.g. physical lines between sensor module and SoC
>>    are swapped on the PCB);
>>
>> - the positive/negative signals are inversed in high-speed mode only
>>    (the sensor and CSI rx use opposite polarities in high-speed mode).
> 
> Then is this positive/negative LVDS lines swapping separately configurable
> in hardware for low-power and high-speed mode ? 

Yes.

> What is an advantage of it ?

I suspect our hardware people after years of experience with
not-so-compliant sensors and weird PCBs have adopted a
belt-and-suspenders approach and made configurable everything they
thought could go wrong.

In the "inversion in high-speed mode only" case, that could be because
the sensor does not use the standard-specified polarity.

> One possible solution would be to have a one to two elements array property,
> e.g.
> 
> lanes-polarity = <0 0 0 0 0>, <1 1 1 1 1>;
> 
> where the first entry would indicate lanes polarity for high speed mode and
> the second one for low power mode. For receivers/transmitters that don't
> allow to configure the polarities separately for different bus states there
> could be just one entry. The width of each element could be determined by 
> value of the 'bus-width' property + 1.
> 
> Would it make sense ?

Yes, that looks fine.

Incidentally is it okay to extend DT nodes with manufacturer-specific
properties?  I'm asking because our CSI rx supports other esoteric
lane-related configuration knobs, e.g. for impedance tuning.  We'd like
to put them in the DT but they probably don't warrant an official
property.

Thanks a lot again.

Best regards,
Nicolas