Re: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
- Subject: Re: [RFC/PATCH 02/13] media: s5p-csis: Add device tree support
- From: Guennadi Liakhovetski <g.liakhovetski@xxxxxx>
- Date: Tue, 31 Jul 2012 12:58:50 +0200 (CEST)
- Cc: Sylwester Nawrocki <sylvester.nawrocki@xxxxxxxxx>, Sylwester Nawrocki <s.nawrocki@xxxxxxxxxxx>, linux-media@xxxxxxxxxxxxxxx, kyungmin.park@xxxxxxxxxxx, m.szyprowski@xxxxxxxxxxx, riverful.kim@xxxxxxxxxxx, sw0312.kim@xxxxxxxxxxx, devicetree-discuss@xxxxxxxxxxxxxxxx, linux-samsung-soc@xxxxxxxxxxxxxxx, b.zolnierkie@xxxxxxxxxxx
- In-reply-to: <24452426.AaRH9zzLOy@avalon>
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
[Linux Input]
[Video for Linux]
[Mplayer Users]
[Linux USB Devel]
[Linux Audio Users]
[Photos]
[Yosemite Photos]
[Linux Kernel]
[Linux SCSI]
[XFree86]
[Devices]
[Yosemite Backpacking]