Re: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Guennadi,

On Tuesday 31 July 2012 12:58:50 Guennadi Liakhovetski wrote:
> On Fri, 27 Jul 2012, Laurent Pinchart wrote:
> > 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?

On the hardware I came across, it's handled by the CSI2 receiver, not the SoC 
pinmux feature.

-- 
Regards,

Laurent Pinchart