Lines Matching +full:sub +full:- +full:module
1 V4L2 sub-devices
2 ----------------
4 Many drivers need to communicate with sub-devices. These devices can do all
6 encoding or decoding. For webcams common sub-devices are sensors and camera
10 driver with a consistent interface to these sub-devices the
11 :c:type:`v4l2_subdev` struct (v4l2-subdev.h) was created.
13 Each sub-device driver must have a :c:type:`v4l2_subdev` struct. This struct
14 can be stand-alone for simple sub-devices or it might be embedded in a larger
16 low-level device struct (e.g. ``i2c_client``) that contains the device data as
19 it easy to go from a :c:type:`v4l2_subdev` to the actual low-level bus-specific
22 You also need a way to go from the low-level struct to :c:type:`v4l2_subdev`.
27 Bridges might also need to store per-subdev private data, such as a pointer to
28 bridge-specific per-subdev private data. The :c:type:`v4l2_subdev` structure
32 From the bridge driver perspective, you load the sub-device module and somehow
35 Helper functions exists for sub-devices on an I2C bus that do most of this
38 Each :c:type:`v4l2_subdev` contains function pointers that sub-device drivers
39 can implement (or leave ``NULL`` if it is not applicable). Since sub-devices can
44 The top-level ops struct contains pointers to the category ops structs, which
49 .. code-block:: c
82 depending on the sub-device. E.g. a video device is unlikely to support the
88 A sub-device driver initializes the :c:type:`v4l2_subdev` struct using:
94 Afterwards you need to initialize :c:type:`sd <v4l2_subdev>`->name with a
95 unique name and set the module owner. This is done for you if you use the
103 .. code-block:: c
105 struct media_pad *pads = &my_sd->pads;
108 err = media_entity_pads_init(&sd->entity, npads, pads);
117 Don't forget to cleanup the media entity before the sub-device is destroyed:
119 .. code-block:: c
121 media_entity_cleanup(&sd->entity);
130 sub-devices. The driver is still responsible for validating the correctness
131 of the format configuration between sub-devices and video nodes.
156 run-time bridge-subdevice interaction is in both cases the same.
164 This can fail if the subdev module disappeared before it could be registered.
165 After this function was called successfully the subdev->dev field points to
168 If the v4l2_device parent device has a non-NULL mdev field, the sub-device
171 You can unregister a sub-device using:
177 Afterwards the subdev module can be unloaded and
178 :c:type:`sd <v4l2_subdev>`->dev == ``NULL``.
182 .. code-block:: c
184 err = sd->ops->core->g_std(sd, &norm);
188 .. code-block:: c
192 The macro will to the right ``NULL`` pointer checks and returns ``-ENODEV``
193 if :c:type:`sd <v4l2_subdev>` is ``NULL``, ``-ENOIOCTLCMD`` if either
194 :c:type:`sd <v4l2_subdev>`->core or :c:type:`sd <v4l2_subdev>`->core->g_std is ``NULL``, or the act…
195 :c:type:`sd <v4l2_subdev>`->ops->core->g_std ops.
197 It is also possible to call all or a subset of the sub-devices:
199 .. code-block:: c
206 .. code-block:: c
210 Any error except ``-ENOIOCTLCMD`` will exit the loop with that error. If no
211 errors (except ``-ENOIOCTLCMD``) occurred, then 0 is returned.
214 called. If non-zero, then only those whose group ID match that value will
216 :c:type:`sd <v4l2_subdev>`->grp_id to whatever value it wants (it's 0 by
217 default). This value is owned by the bridge driver and the sub-device driver
228 If the sub-device needs to notify its v4l2_device parent of an event, then
230 whether there is a ``notify()`` callback defined and returns ``-ENODEV`` if not.
243 the driver might decide to return ``-EPROBE_DEFER`` to request further reprobing
265 V4L2 sub-device userspace API
266 -----------------------------
269 V4L2 sub-devices can also be controlled directly by userspace applications.
271 Device nodes named ``v4l-subdev``\ *X* can be created in ``/dev`` to access
272 sub-devices directly. If a sub-device supports direct userspace configuration
275 After registering sub-devices, the :c:type:`v4l2_device` driver can create
276 device nodes for all registered sub-devices marked with
279 automatically removed when sub-devices are unregistered.
293 controls implemented in the sub-device. Depending on the driver, those
303 events generated by the sub-device. Depending on the driver, those
306 Sub-device drivers that want to use events need to set the
309 the sub-device. After registration events can be queued as usual on the
317 All ioctls not in the above list are passed directly to the sub-device
321 I2C sub-device drivers
322 ----------------------
325 ease the use of these drivers (``v4l2-common.h``).
335 .. code-block:: c
344 .. code-block:: c
346 v4l2_i2c_subdev_init(&state->sd, client, subdev_ops);
354 .. code-block:: c
364 .. code-block:: c
370 .. code-block:: c
376 when the ``remove()`` callback is called. This will unregister the sub-device
377 from the bridge driver. It is safe to call this even if the sub-device was
390 .. code-block:: c
395 This loads the given module (can be ``NULL`` if no module needs to be loaded)
402 are only used if the previous argument is 0. A non-zero argument means that you
408 the same as the module name. It allows you to specify a chip variant, e.g.
429 V4L2 sub-device functions and data structures
430 ---------------------------------------------
432 .. kernel-doc:: include/media/v4l2-subdev.h
434 .. kernel-doc:: include/media/v4l2-async.h