On Fri, 27 Jul 2012, Laurent Pinchart wrote: > Hi Sylwester, > > On Thursday 26 July 2012 21:51:30 Sylwester Nawrocki wrote: > > On 07/26/2012 04:38 PM, Laurent Pinchart wrote: > > >>>> --- /dev/null > > >>>> +++ b/Documentation/devicetree/bindings/video/mipi.txt > > >>>> @@ -0,0 +1,5 @@ > > >>>> +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and > > >>>> transmitters > > >>>> + > > >>>> + - data-lanes : number of differential data lanes wired and actively > > >>>> used in > > >>>> + communication between the transmitter and the receiver, this > > >>>> + excludes the clock lane; > > >>> > > >>> Wouldn't it be better to use the standard "bus-width" DT property? > > >> > > >> I can't see any problems with using "bus-width". It seems sufficient > > >> and could indeed be better, without a need to invent new MIPI-CSI > > >> specific names. That was my first RFC on that and my perspective > > >> wasn't probably broad enough. :) > > > > > > What about CSI receivers that can reroute the lanes internally ? We would > > > need to specify lane indices for each lane then, maybe with something > > > like > > > > > > clock-lane =<0>; > > > data-lanes =<2 3 1>; > > > > Sounds good to me. And the clock-lane could be made optional, as not all > > devices would need it. > > > > However, as far as I can see, there is currently no generic API for handling > > this kind of data structure. E.g. number of cells for the "interrupts" > > property is specified with an additional "#interrupt-cells" property. > > > > It would have been much easier to handle something like: > > > > data-lanes = <2>, <3>, <1>; > > > > i.e. an array of the lane indexes. > > I'm fine with that. ...on a second thought: shouldn't this be handled by pinctrl? Or is it some CSI-2 module internal lane switching, not the global SoC pin function configuration? Thanks Guennadi > > > For receivers that can't reroute lanes internally, the data-lanes property > > > would be need to specify lanes in sequence. > > > > > > data-lanes =<1 2 3>; > > > > In this case we would be only interested in the number of cells in this > > property, but how it could be retrieved ? With an array, it could have been > > calculated from property length returned by of_property_find() (divided by > > sizof(u32)). > > Agreed. > > -- > Regards, > > Laurent Pinchart > --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
