Hi Hans,
On Tuesday 17 July 2012 21:37:05 Hans Verkuil wrote:
> On Wed July 11 2012 16:27:52 Guennadi Liakhovetski wrote:
> > Hi all
> >
> > Background
> > ==========
> >
> > With ARM adoption of flat Device Trees a need arises to move platform
> > device descriptions and their data from platform files to DT. This has
> > also to be done for media devices, e.g., video capture and output
> > interfaces, data processing devices, camera sensors, TV decoders and
> > encoders. This RFC is trying to spawn a discussion to define standard V4L
> > DT bindings. The first version will concentrate on the capture path,
> > mostly taking care of simple capture-interface - camera sensor / TV
> > decoder configurations. Since the author is not working intensively yet
> > with the Media Controller API, pad-level configuration, these topics might
> > be underrepresented in this RFC. I hope others, actively working in these
> > areas, will fill me in on them.
> >
> > Overview
> > ========
> >
> > As mentioned above, typical configurations, that we'll be dealing with
> > consist of a DMA data capture engine, one or more data sources like camera
> > sensors, possibly some data processing units. Data capture and processing
> > engines are usually platform devices, whereas data source devices are
> > typically I2C slaves. Apart from defining each device we'll also describe
> > connections between them as well as properties of those connections.
> >
> > Capture devices
> > ==============================
> >
> > These are usually platform devices, integrated into respective SoCs. There
> > also exist external image processing devices, but they are rare. Obvious
> > differences between them and integrated devices include a different bus
> > attribution and a need to explicitly describe the connection to the SoC.
> > As far as capture devices are concerned, their configuration will
> > typically include a few device-specific bindings, as well as standard
> > ones. Standard bindings will include the usual "reg," "interrupts,"
> > "clock-frequency" properties.
> >
> > It is more complex to describe external links. We need to describe
> > configurations, used with various devices, attached to various pads. It is
> > proposed to describe such links as child nodes. Each such link will
> > reference a client pad, a local pad and specify the bus configuration. The
> > media bus can be either parallel or serial, e.g., MIPI CSI-2. It is
> > proposed to describe both the bus-width in the parallel case and the
> > number of lanes in the serial case, using the standard "bus-width"
> > property.
> >
> > On the parallel bus common properties include signal polarities, possibly
> > data line shift (8 if lines 15:8 are used, 2 if 9:2, and 0 if lines 7:0),
> > protocol (e.g., BT.656). Additionally device-specific properties can be
> > defined.
> >
> > A MIPI CSI-2 bus common properties would include, apart from the number of
> > lanes, routed to that client, the clock frequency, a channel number,
> > possibly CRC and ECC flags.
> >
> > An sh-mobile CEU DT node could look like
> >
> > ceu0@0xfe910000 = {
> >
> > compatible = "renesas,sh-mobile-ceu";
> > reg = <0xfe910000 0xa0>;
> > interrupts = <0x880>;
> > bus-width = <16>; /* #lines routed on the board */
> > clock-frequency = <50000000>; /* max clock */
> > #address-cells = <1>;
> > #size-cells = <0>;
> > ...
> > ov772x-1 = {
> >
> > reg = <0>;
> > client = <&ov772x@0x21-0>;
> > local-pad = "parallel-sink";
> > remote-pad = "parallel-source";
> > bus-width = <8>; /* used data lines */
> > data-shift = <0>; /* lines 7:0 are used */
> > hsync-active = <1>; /* active high */
> > vsync-active = <1>; /* active high */
> > pclk-sample = <1>; /* rising */
> > clock-frequency = <24000000>;
> >
> > };
> >
> > };
> >
> > Client devices
> > ==============
> >
> > Client nodes are children on their respective busses, e.g., i2c. This
> > placement leads to these devices being possibly probed before respective
> > host interfaces, which will fail due to known reasons. Therefore client
> > drivers have to be adapted to request a delayed probing, as long as the
> > respective video host hasn't probed.
> >
> > Client nodes will include all the properties, usual for their busses.
> > Additionally they will specify properties private to this device type and
> > common for all V4L2 client devices - device global and per-link. I think,
> > we should make it possible to define client devices, that can at run-time
> > be connected to different sinks, even though such configurations might not
> > be very frequent. To achieve this we also specify link information in
> > child devices, similar to those in host nodes above. This also helps
> > uniformity and will let us implement and use a universal link-binding
> > parser. So, a node, that has been referenced above could look like
> >
> > ov772x@0x21-0 = {
> >
> > compatible = "omnivision,ov772x";
> > reg = <0x21>;
> > vdd-supply = <®ulator>;
> > bus-width = <10>;
> > #address-cells = <1>;
> > #size-cells = <0>;
> > ...
> > ceu0-1 = {
> >
> > reg = <0>;
> > media-parent = <&ceu0@0xfe910000>;
> > bus-width = <8>;
> > hsync-active = <1>;
> > vsync-active = <0>; /* who came up with an inverter
> > here?...
*/
> > pclk-sample = <1>;
> >
> > };
> >
> > };
> >
> > Data processors
> > ===============
> >
> > Data processing modules include resizers, codecs, rotators, serialisers,
> > etc. A node for an sh-mobile CSI-2 subdevice could look like
> >
> > csi2@0xffc90000 = {
> >
> > compatible = "renesas,sh-mobile-csi2";
> > reg = <0xffc90000 0x1000>;
> > interrupts = <0x17a0>;
> > bus-width = <4>;
> > clock-frequency = <30000000>;
> > ...
> > imx074-1 = {
> >
> > client = <&imx074@0x1a-0>;
> > local-pad = "csi2-sink";
> > remote-pad = "csi2-source";
> > bus-width = <2>;
> > clock-frequency = <25000000>;
> > csi2-crc;
> > csi2-ecc;
> > sh-csi2,phy = <0>;
> >
> > };
> > ceu0 = {
> >
> > media-parent = <&ceu0@0xfe910000>;
> > immutable;
> >
> > };
> >
> > };
> >
> > The respective child binding in the CEU node could then look like
> >
> > csi2-1 = {
> >
> > reg = <1>;
> > client = <&csi2@0xffc90000>;
> > immutable;
> >
> > };
> >
> > Comments welcome.
>
> One thing that is missing, but that is quite important is that the
> information from ENUMINPUT/ENUMOUTPUT needs to be part of the device tree
> as well, since that is generally completely board specific. See for example
> how the davinci vpif_capture.c and vpif_display.c do that now using
> platform data. This would be solved much more elegantly using the device
> tree.
>
> This tends not to feature much when dealing with sensors, but any video
> receiver or transmitter will need this.
What about just adding connector entities to the DT ?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
