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@xxxxxxxxxxxxxxx/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-- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
