On 25/08/17 14:52, Mauro Carvalho Chehab wrote: > From: "mchehab@xxxxxxxxxxxxxxxx" <mchehab@xxxxxxxxxxxxxxxx> > > When we added support for omap3, back in 2010, we added a new > type of V4L2 devices that aren't fully controlled via the V4L2 > device node. Yet, we never made it clear, at the V4L2 spec, > about the differences between both types. > > Let's document them with the current implementation. > > Signed-off-by: Mauro Carvalho Chehab <mchehab@xxxxxxxxxxxxxxxx> > --- > Documentation/media/uapi/v4l/open.rst | 53 +++++++++++++++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > > diff --git a/Documentation/media/uapi/v4l/open.rst b/Documentation/media/uapi/v4l/open.rst > index 9b98d10d5153..bbd1887f83a0 100644 > --- a/Documentation/media/uapi/v4l/open.rst > +++ b/Documentation/media/uapi/v4l/open.rst > @@ -6,6 +6,59 @@ > Opening and Closing Devices > *************************** > > +Types of V4L2 hardware control > +============================== > + > +V4L2 hardware is usually complex: support for the hardware is implemented > +via a main driver (also known as bridge driver) and often several > +additional drivers. The main driver always exposes one or > +more **V4L2 device nodes** (see :ref:`v4l2_device_naming`). > + > +The other drivers are called **V4L2 sub-devices** and provide control to > +other parts of the hardware usually connected via a serial bus (like > +I²C, SMBus or SPI). Depending on the main driver, they can be implicitly > +controlled directly by the main driver or explicitly via > +the **V4L2 sub-device API** (see :ref:`subdev`). > + > +When V4L2 was originally designed, there was only one type of hardware > +control. The entire V4L2 hardware is controlled via the > +**V4L2 device nodes**. We refer to this kind of control as > +**V4L2 device node centric** (or, simply, **vdev-centric**). > + > +Since the end of 2010, a new type of V4L2 hardware control was added, in Just drop 'the end of'. s/, in/ in/ > +order to support complex devices that are common for embedded systems. > +Those hardware are controlled mainly via the media controller and Such hardware is > +sub-devices. So, they are called: **Media controller centric** > +(or, simply, "**MC-centric**"). > + > +For **vdev-centric** hardware control, the hardware is controlled via > +the **V4L2 device nodes**. They may optionally support the > +:ref:`media controller API <media_controller>` as well, in order to let > +the application to know with device nodes are available. to know with -> know which > + > +.. note:: > + > + A **vdev-centric** may optionally expose V4L2 sub-devices via I propose adding 'also' before 'expose' to indicate that it is in addition to the V4L2 device nodes that were mentioned in the previous paragraph. > + :ref:`sub-device API <subdev>`. In that case, it has to implement > + the :ref:`media controller API <media_controller>` as well. > + > +For **MC-centric** hardware control, before using the V4L2 hardware, > +it is required to set the pipelines via the I'd reword this a bit: For **MC-centric** hardware control it is required to configure the pipelines via the :ref:`media controller API <media_controller>` before the hardware can be used. > +:ref:`media controller API <media_controller>`. For those devices, the s/those/such/ > +sub-devices' configuration can be controlled via the > +:ref:`sub-device API <subdev>`, whith creates one device node s/whith/which/ > +per sub-device. > + > +In summary, for **MC-centric** hardware control: > + > +- The **V4L2 device** node is responsible for controlling the streaming > + features; > +- The **media controller device** is responsible to setup the pipelines; > +- The **V4L2 sub-devices** are responsible for sub-device > + specific settings. > + > + > +.. _v4l2_device_naming: > > V4L2 Device Node Naming > ======================= > The only thing I am not sure about is vdev-centric vs V4L2-centric. 'Laziness while typing' is not a convincing argument :-) Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
