diff options
Diffstat (limited to 'Documentation/media/kapi')
| -rw-r--r-- | Documentation/media/kapi/cec-core.rst | 308 | ||||
| -rw-r--r-- | Documentation/media/kapi/dtv-core.rst | 40 | ||||
| -rw-r--r-- | Documentation/media/kapi/mc-core.rst | 25 | ||||
| -rw-r--r-- | Documentation/media/kapi/v4l2-dev.rst | 10 | ||||
| -rw-r--r-- | Documentation/media/kapi/v4l2-event.rst | 6 | ||||
| -rw-r--r-- | Documentation/media/kapi/v4l2-fh.rst | 4 | ||||
| -rw-r--r-- | Documentation/media/kapi/v4l2-subdev.rst | 23 |
7 files changed, 375 insertions, 41 deletions
diff --git a/Documentation/media/kapi/cec-core.rst b/Documentation/media/kapi/cec-core.rst new file mode 100644 index 000000000000..88c33b53ec13 --- /dev/null +++ b/Documentation/media/kapi/cec-core.rst @@ -0,0 +1,308 @@ +CEC Kernel Support +================== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple types of hardware (receivers, +transmitters, USB dongles). The framework also gives the option to decide +what to do in the kernel driver and what should be handled by userspace +applications. In addition it integrates the remote control passthrough +feature into the kernel's remote control framework. + + +The CEC Protocol +---------------- + +The CEC protocol enables consumer electronic devices to communicate with each +other through the HDMI connection. The protocol uses logical addresses in the +communication. The logical address is strictly connected with the functionality +provided by the device. The TV acting as the communication hub is always +assigned address 0. The physical address is determined by the physical +connection between devices. + +The CEC framework described here is up to date with the CEC 2.0 specification. +It is documented in the HDMI 1.4 specification with the new 2.0 bits documented +in the HDMI 2.0 specification. But for most of the features the freely available +HDMI 1.3a specification is sufficient: + +http://www.microprocessor.org/HDMISpecification13a.pdf + + +The Kernel Interface +==================== + +CEC Adapter +----------- + +The struct cec_adapter represents the CEC adapter hardware. It is created by +calling cec_allocate_adapter() and deleted by calling cec_delete_adapter(): + +.. c:function:: + struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops, + void *priv, const char *name, u32 caps, u8 available_las, + struct device *parent); + +.. c:function:: + void cec_delete_adapter(struct cec_adapter *adap); + +To create an adapter you need to pass the following information: + +ops: + adapter operations which are called by the CEC framework and that you + have to implement. + +priv: + will be stored in adap->priv and can be used by the adapter ops. + +name: + the name of the CEC adapter. Note: this name will be copied. + +caps: + capabilities of the CEC adapter. These capabilities determine the + capabilities of the hardware and which parts are to be handled + by userspace and which parts are handled by kernelspace. The + capabilities are returned by CEC_ADAP_G_CAPS. + +available_las: + the number of simultaneous logical addresses that this + adapter can handle. Must be 1 <= available_las <= CEC_MAX_LOG_ADDRS. + +parent: + the parent device. + + +To register the /dev/cecX device node and the remote control device (if +CEC_CAP_RC is set) you call: + +.. c:function:: + int cec_register_adapter(struct cec_adapter \*adap); + +To unregister the devices call: + +.. c:function:: + void cec_unregister_adapter(struct cec_adapter \*adap); + +Note: if cec_register_adapter() fails, then call cec_delete_adapter() to +clean up. But if cec_register_adapter() succeeded, then only call +cec_unregister_adapter() to clean up, never cec_delete_adapter(). The +unregister function will delete the adapter automatically once the last user +of that /dev/cecX device has closed its file handle. + + +Implementing the Low-Level CEC Adapter +-------------------------------------- + +The following low-level adapter operations have to be implemented in +your driver: + +.. c:type:: struct cec_adap_ops + +.. code-block:: none + + struct cec_adap_ops + { + /* Low-level callbacks */ + int (*adap_enable)(struct cec_adapter *adap, bool enable); + int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable); + int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); + int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, + u32 signal_free_time, struct cec_msg *msg); + void (\*adap_log_status)(struct cec_adapter *adap); + + /* High-level callbacks */ + ... + }; + +The three low-level ops deal with various aspects of controlling the CEC adapter +hardware: + + +To enable/disable the hardware: + +.. c:function:: + int (*adap_enable)(struct cec_adapter *adap, bool enable); + +This callback enables or disables the CEC hardware. Enabling the CEC hardware +means powering it up in a state where no logical addresses are claimed. This +op assumes that the physical address (adap->phys_addr) is valid when enable is +true and will not change while the CEC adapter remains enabled. The initial +state of the CEC adapter after calling cec_allocate_adapter() is disabled. + +Note that adap_enable must return 0 if enable is false. + + +To enable/disable the 'monitor all' mode: + +.. c:function:: + int (*adap_monitor_all_enable)(struct cec_adapter *adap, bool enable); + +If enabled, then the adapter should be put in a mode to also monitor messages +that not for us. Not all hardware supports this and this function is only +called if the CEC_CAP_MONITOR_ALL capability is set. This callback is optional +(some hardware may always be in 'monitor all' mode). + +Note that adap_monitor_all_enable must return 0 if enable is false. + + +To program a new logical address: + +.. c:function:: + int (*adap_log_addr)(struct cec_adapter *adap, u8 logical_addr); + +If logical_addr == CEC_LOG_ADDR_INVALID then all programmed logical addresses +are to be erased. Otherwise the given logical address should be programmed. +If the maximum number of available logical addresses is exceeded, then it +should return -ENXIO. Once a logical address is programmed the CEC hardware +can receive directed messages to that address. + +Note that adap_log_addr must return 0 if logical_addr is CEC_LOG_ADDR_INVALID. + + +To transmit a new message: + +.. c:function:: + int (*adap_transmit)(struct cec_adapter *adap, u8 attempts, + u32 signal_free_time, struct cec_msg *msg); + +This transmits a new message. The attempts argument is the suggested number of +attempts for the transmit. + +The signal_free_time is the number of data bit periods that the adapter should +wait when the line is free before attempting to send a message. This value +depends on whether this transmit is a retry, a message from a new initiator or +a new message for the same initiator. Most hardware will handle this +automatically, but in some cases this information is needed. + +The CEC_FREE_TIME_TO_USEC macro can be used to convert signal_free_time to +microseconds (one data bit period is 2.4 ms). + + +To log the current CEC hardware status: + +.. c:function:: + void (*adap_status)(struct cec_adapter *adap, struct seq_file *file); + +This optional callback can be used to show the status of the CEC hardware. +The status is available through debugfs: cat /sys/kernel/debug/cec/cecX/status + + +Your adapter driver will also have to react to events (typically interrupt +driven) by calling into the framework in the following situations: + +When a transmit finished (successfully or otherwise): + +.. c:function:: + void cec_transmit_done(struct cec_adapter *adap, u8 status, u8 arb_lost_cnt, + u8 nack_cnt, u8 low_drive_cnt, u8 error_cnt); + +The status can be one of: + +CEC_TX_STATUS_OK: + the transmit was successful. + +CEC_TX_STATUS_ARB_LOST: + arbitration was lost: another CEC initiator + took control of the CEC line and you lost the arbitration. + +CEC_TX_STATUS_NACK: + the message was nacked (for a directed message) or + acked (for a broadcast message). A retransmission is needed. + +CEC_TX_STATUS_LOW_DRIVE: + low drive was detected on the CEC bus. This indicates that + a follower detected an error on the bus and requested a + retransmission. + +CEC_TX_STATUS_ERROR: + some unspecified error occurred: this can be one of + the previous two if the hardware cannot differentiate or something + else entirely. + +CEC_TX_STATUS_MAX_RETRIES: + could not transmit the message after trying multiple times. + Should only be set by the driver if it has hardware support for + retrying messages. If set, then the framework assumes that it + doesn't have to make another attempt to transmit the message + since the hardware did that already. + +The \*_cnt arguments are the number of error conditions that were seen. +This may be 0 if no information is available. Drivers that do not support +hardware retry can just set the counter corresponding to the transmit error +to 1, if the hardware does support retry then either set these counters to +0 if the hardware provides no feedback of which errors occurred and how many +times, or fill in the correct values as reported by the hardware. + +When a CEC message was received: + +.. c:function:: + void cec_received_msg(struct cec_adapter *adap, struct cec_msg *msg); + +Speaks for itself. + +Implementing the High-Level CEC Adapter +--------------------------------------- + +The low-level operations drive the hardware, the high-level operations are +CEC protocol driven. The following high-level callbacks are available: + +.. code-block:: none + + struct cec_adap_ops { + /\* Low-level callbacks \*/ + ... + + /\* High-level CEC message callback \*/ + int (\*received)(struct cec_adapter \*adap, struct cec_msg \*msg); + }; + +The received() callback allows the driver to optionally handle a newly +received CEC message + +.. c:function:: + int (*received)(struct cec_adapter *adap, struct cec_msg *msg); + +If the driver wants to process a CEC message, then it can implement this +callback. If it doesn't want to handle this message, then it should return +-ENOMSG, otherwise the CEC framework assumes it processed this message and +it will not no anything with it. + + +CEC framework functions +----------------------- + +CEC Adapter drivers can call the following CEC framework functions: + +.. c:function:: + int cec_transmit_msg(struct cec_adapter *adap, struct cec_msg *msg, + bool block); + +Transmit a CEC message. If block is true, then wait until the message has been +transmitted, otherwise just queue it and return. + +.. c:function:: + void cec_s_phys_addr(struct cec_adapter *adap, u16 phys_addr, + bool block); + +Change the physical address. This function will set adap->phys_addr and +send an event if it has changed. If cec_s_log_addrs() has been called and +the physical address has become valid, then the CEC framework will start +claiming the logical addresses. If block is true, then this function won't +return until this process has finished. + +When the physical address is set to a valid value the CEC adapter will +be enabled (see the adap_enable op). When it is set to CEC_PHYS_ADDR_INVALID, +then the CEC adapter will be disabled. If you change a valid physical address +to another valid physical address, then this function will first set the +address to CEC_PHYS_ADDR_INVALID before enabling the new physical address. + +.. c:function:: + int cec_s_log_addrs(struct cec_adapter *adap, + struct cec_log_addrs *log_addrs, bool block); + +Claim the CEC logical addresses. Should never be called if CEC_CAP_LOG_ADDRS +is set. If block is true, then wait until the logical addresses have been +claimed, otherwise just queue it and return. To unconfigure all logical +addresses call this function with log_addrs set to NULL or with +log_addrs->num_log_addrs set to 0. The block argument is ignored when +unconfiguring. This function will just return if the physical address is +invalid. Once the physical address becomes valid, then the framework will +attempt to claim these logical addresses. diff --git a/Documentation/media/kapi/dtv-core.rst b/Documentation/media/kapi/dtv-core.rst index dd96e846fef9..a3c4642eabfc 100644 --- a/Documentation/media/kapi/dtv-core.rst +++ b/Documentation/media/kapi/dtv-core.rst @@ -6,8 +6,6 @@ Digital TV Common functions .. kernel-doc:: drivers/media/dvb-core/dvb_math.h -.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h - .. kernel-doc:: drivers/media/dvb-core/dvbdev.h @@ -18,6 +16,42 @@ Digital TV Common functions .. kernel-doc:: drivers/media/dvb-core/dvbdev.h :export: drivers/media/dvb-core/dvbdev.c +Digital TV Ring buffer +---------------------- + +Those routines implement ring buffers used to handle digital TV data and +copy it from/to userspace. + +.. note:: + + 1) For performance reasons read and write routines don't check buffer sizes + and/or number of bytes free/available. This has to be done before these + routines are called. For example: + + .. code-block:: c + + /* write @buflen: bytes */ + free = dvb_ringbuffer_free(rbuf); + if (free >= buflen) + count = dvb_ringbuffer_write(rbuf, buffer, buflen); + else + /* do something */ + + /* read min. 1000, max. @bufsize: bytes */ + avail = dvb_ringbuffer_avail(rbuf); + if (avail >= 1000) + count = dvb_ringbuffer_read(rbuf, buffer, min(avail, bufsize)); + else + /* do something */ + + 2) If there is exactly one reader and one writer, there is no need + to lock read or write operations. + Two or more readers must be locked against each other. + Flushing the buffer counts as a read operation. + Resetting the buffer counts as a read and write operation. + Two or more writers must be locked against each other. + +.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h Digital TV Frontend kABI @@ -121,7 +155,7 @@ triggered by a hardware interrupt, it is recommended to use the Linux bottom half mechanism or start a tasklet instead of making the callback function call directly from a hardware interrupt. -This mechanism is implemented by :c:func:`dmx_ts_cb()` and :cpp:func:`dmx_section_cb()` +This mechanism is implemented by :c:func:`dmx_ts_cb()` and :c:func:`dmx_section_cb()` callbacks. .. kernel-doc:: drivers/media/dvb-core/demux.h diff --git a/Documentation/media/kapi/mc-core.rst b/Documentation/media/kapi/mc-core.rst index 569cfc4f01cd..1a738e5f6056 100644 --- a/Documentation/media/kapi/mc-core.rst +++ b/Documentation/media/kapi/mc-core.rst @@ -34,7 +34,7 @@ pad to a sink pad. Media device ^^^^^^^^^^^^ -A media device is represented by a :c:type:`struct media_device <media_device>` +A media device is represented by a struct :c:type:`media_device` instance, defined in ``include/media/media-device.h``. Allocation of the structure is handled by the media device driver, usually by embedding the :c:type:`media_device` instance in a larger driver-specific @@ -47,7 +47,7 @@ and unregistered by calling :c:func:`media_device_unregister()`. Entities ^^^^^^^^ -Entities are represented by a :c:type:`struct media_entity <media_entity>` +Entities are represented by a struct :c:type:`media_entity` instance, defined in ``include/media/media-entity.h``. The structure is usually embedded into a higher-level structure, such as :c:type:`v4l2_subdev` or :c:type:`video_device` @@ -65,10 +65,10 @@ Interfaces ^^^^^^^^^^ Interfaces are represented by a -:c:type:`struct media_interface <media_interface>` instance, defined in +struct :c:type:`media_interface` instance, defined in ``include/media/media-entity.h``. Currently, only one type of interface is defined: a device node. Such interfaces are represented by a -:c:type:`struct media_intf_devnode <media_intf_devnode>`. +struct :c:type:`media_intf_devnode`. Drivers initialize and create device node interfaces by calling :c:func:`media_devnode_create()` @@ -77,7 +77,7 @@ and remove them by calling: Pads ^^^^ -Pads are represented by a :c:type:`struct media_pad <media_pad>` instance, +Pads are represented by a struct :c:type:`media_pad` instance, defined in ``include/media/media-entity.h``. Each entity stores its pads in a pads array managed by the entity driver. Drivers usually embed the array in a driver-specific structure. @@ -85,8 +85,9 @@ a driver-specific structure. Pads are identified by their entity and their 0-based index in the pads array. -Both information are stored in the :c:type:`struct media_pad`, making the -:c:type:`media_pad` pointer the canonical way to store and pass link references. +Both information are stored in the struct :c:type:`media_pad`, +making the struct :c:type:`media_pad` pointer the canonical way +to store and pass link references. Pads have flags that describe the pad capabilities and state. @@ -101,7 +102,7 @@ Pads have flags that describe the pad capabilities and state. Links ^^^^^ -Links are represented by a :c:type:`struct media_link <media_link>` instance, +Links are represented by a struct :c:type:`media_link` instance, defined in ``include/media/media-entity.h``. There are two types of links: **1. pad to pad links**: @@ -184,7 +185,7 @@ Use count and power handling Due to the wide differences between drivers regarding power management needs, the media controller does not implement power management. However, -the :c:type:`struct media_entity <media_entity>` includes a ``use_count`` +the struct :c:type:`media_entity` includes a ``use_count`` field that media drivers can use to track the number of users of every entity for power management needs. @@ -210,11 +211,11 @@ prevent link states from being modified during streaming by calling The function will mark all entities connected to the given entity through enabled links, either directly or indirectly, as streaming. -The :c:type:`struct media_pipeline <media_pipeline>` instance pointed to by +The struct :c:type:`media_pipeline` instance pointed to by the pipe argument will be stored in every entity in the pipeline. -Drivers should embed the :c:type:`struct media_pipeline <media_pipeline>` +Drivers should embed the struct :c:type:`media_pipeline` in higher-level pipeline structures and can then access the -pipeline through the :c:type:`struct media_entity <media_entity>` +pipeline through the struct :c:type:`media_entity` pipe field. Calls to :c:func:`media_entity_pipeline_start()` can be nested. diff --git a/Documentation/media/kapi/v4l2-dev.rst b/Documentation/media/kapi/v4l2-dev.rst index cdfcf0bc78be..b29aa616c267 100644 --- a/Documentation/media/kapi/v4l2-dev.rst +++ b/Documentation/media/kapi/v4l2-dev.rst @@ -56,7 +56,7 @@ You should also set these fields of :c:type:`video_device`: :c:type:`video_device`->vfl_dir fields are used to disable ops that do not match the type/dir combination. E.g. VBI ops are disabled for non-VBI nodes, and output ops are disabled for a capture device. This makes it possible to - provide just one :c:type:`v4l2_ioctl_ops struct` for both vbi and + provide just one :c:type:`v4l2_ioctl_ops` struct for both vbi and video nodes. - :c:type:`video_device`->lock: leave to ``NULL`` if you want to do all the @@ -166,14 +166,14 @@ something. In the case of :ref:`videobuf2 <vb2_framework>` you will need to implement the ``wait_prepare()`` and ``wait_finish()`` callbacks to unlock/lock if applicable. If you use the ``queue->lock`` pointer, then you can use the helper functions -:c:func:`vb2_ops_wait_prepare` and :cpp:func:`vb2_ops_wait_finish`. +:c:func:`vb2_ops_wait_prepare` and :c:func:`vb2_ops_wait_finish`. The implementation of a hotplug disconnect should also take the lock from :c:type:`video_device` before calling v4l2_device_disconnect. If you are also using :c:type:`video_device`->queue->lock, then you have to first lock :c:type:`video_device`->queue->lock followed by :c:type:`video_device`->lock. That way you can be sure no ioctl is running when you call -:c:type:`v4l2_device_disconnect`. +:c:func:`v4l2_device_disconnect`. Video device registration ------------------------- @@ -200,6 +200,7 @@ types exist: - ``VFL_TYPE_VBI``: ``/dev/vbiX`` for vertical blank data (i.e. closed captions, teletext) - ``VFL_TYPE_RADIO``: ``/dev/radioX`` for radio tuners - ``VFL_TYPE_SDR``: ``/dev/swradioX`` for Software Defined Radio tuners +- ``VFL_TYPE_TOUCH``: ``/dev/v4l-touchX`` for touch sensors The last argument gives you a certain amount of control over the device device node number used (i.e. the X in ``videoX``). Normally you will pass -1 @@ -262,6 +263,7 @@ file operations. It is a bitmask and the following bits can be set: +.. tabularcolumns:: |p{5ex}|L| ===== ================================================================ Mask Description @@ -334,7 +336,7 @@ And this function: returns the video_device belonging to the file struct. -The :c:func:`video_devdata` function combines :cpp:func:`video_get_drvdata` +The :c:func:`video_devdata` function combines :c:func:`video_get_drvdata` with :c:func:`video_devdata`: :c:func:`video_drvdata <video_drvdata>` diff --git a/Documentation/media/kapi/v4l2-event.rst b/Documentation/media/kapi/v4l2-event.rst index f962686a7b63..9a5e31546ae3 100644 --- a/Documentation/media/kapi/v4l2-event.rst +++ b/Documentation/media/kapi/v4l2-event.rst @@ -40,7 +40,7 @@ A good example of these ``replace``/``merge`` callbacks is in v4l2-event.c: In order to queue events to video device, drivers should call: :c:func:`v4l2_event_queue <v4l2_event_queue>` - (:c:type:`vdev <video_device>`, :ref:`ev <v4l2-event>`) + (:c:type:`vdev <video_device>`, :c:type:`ev <v4l2_event>`) The driver's only responsibility is to fill in the type and the data fields. The other fields will be filled in by V4L2. @@ -51,7 +51,7 @@ Event subscription Subscribing to an event is via: :c:func:`v4l2_event_subscribe <v4l2_event_subscribe>` - (:c:type:`fh <v4l2_fh>`, :ref:`sub <v4l2-event-subscription>` , + (:c:type:`fh <v4l2_fh>`, :c:type:`sub <v4l2_event_subscription>` , elems, :c:type:`ops <v4l2_subscribed_event_ops>`) @@ -86,7 +86,7 @@ Unsubscribing an event Unsubscribing to an event is via: :c:func:`v4l2_event_unsubscribe <v4l2_event_unsubscribe>` - (:c:type:`fh <v4l2_fh>`, :ref:`sub <v4l2-event-subscription>`) + (:c:type:`fh <v4l2_fh>`, :c:type:`sub <v4l2_event_subscription>`) This function is used to implement :c:type:`video_device`-> :c:type:`ioctl_ops <v4l2_ioctl_ops>`-> ``vidioc_unsubscribe_event``. diff --git a/Documentation/media/kapi/v4l2-fh.rst b/Documentation/media/kapi/v4l2-fh.rst index 9e87d5ca3e4a..3ee64adf4635 100644 --- a/Documentation/media/kapi/v4l2-fh.rst +++ b/Documentation/media/kapi/v4l2-fh.rst @@ -21,8 +21,8 @@ function by the driver. In many cases the struct :c:type:`v4l2_fh` will be embedded in a larger structure. In that case you should call: -#) :c:func:`v4l2_fh_init` and :cpp:func:`v4l2_fh_add` in ``open()`` -#) :c:func:`v4l2_fh_del` and :cpp:func:`v4l2_fh_exit` in ``release()`` +#) :c:func:`v4l2_fh_init` and :c:func:`v4l2_fh_add` in ``open()`` +#) :c:func:`v4l2_fh_del` and :c:func:`v4l2_fh_exit` in ``release()`` Drivers can extract their own file handle structure by using the container_of macro. diff --git a/Documentation/media/kapi/v4l2-subdev.rst b/Documentation/media/kapi/v4l2-subdev.rst index d767b61e9842..e1f0b726e438 100644 --- a/Documentation/media/kapi/v4l2-subdev.rst +++ b/Documentation/media/kapi/v4l2-subdev.rst @@ -27,7 +27,7 @@ methods. Bridges might also need to store per-subdev private data, such as a pointer to bridge-specific per-subdev private data. The :c:type:`v4l2_subdev` structure provides host private data for that purpose that can be accessed with -:c:func:`v4l2_get_subdev_hostdata` and :cpp:func:`v4l2_set_subdev_hostdata`. +:c:func:`v4l2_get_subdev_hostdata` and :c:func:`v4l2_set_subdev_hostdata`. From the bridge driver perspective, you load the sub-device module and somehow obtain the :c:type:`v4l2_subdev` pointer. For i2c devices this is easy: you call @@ -412,19 +412,7 @@ later date. It differs between i2c drivers and as such can be confusing. To see which chip variants are supported you can look in the i2c driver code for the i2c_device_id table. This lists all the possibilities. -There are two more helper functions: - -:c:func:`v4l2_i2c_new_subdev_cfg`: this function adds new irq and -platform_data arguments and has both 'addr' and 'probed_addrs' arguments: -if addr is not 0 then that will be used (non-probing variant), otherwise the -probed_addrs are probed. - -For example: this will probe for address 0x10: - -.. code-block:: c - - struct v4l2_subdev *sd = v4l2_i2c_new_subdev_cfg(v4l2_dev, adapter, - "module_foo", "chipid", 0, NULL, 0, I2C_ADDRS(0x10)); +There are one more helper function: :c:func:`v4l2_i2c_new_subdev_board` uses an :c:type:`i2c_board_info` struct which is passed to the i2c driver and replaces the irq, platform_data and addr @@ -433,9 +421,10 @@ arguments. If the subdev supports the s_config core ops, then that op is called with the irq and platform_data arguments after the subdev was setup. -The older :c:func:`v4l2_i2c_new_subdev` and -:c:func:`v4l2_i2c_new_probed_subdev` functions will call ``s_config`` as -well, but with irq set to 0 and platform_data set to ``NULL``. +The :c:func:`v4l2_i2c_new_subdev` function will call +:c:func:`v4l2_i2c_new_subdev_board`, internally filling a +:c:type:`i2c_board_info` structure using the ``client_type`` and the +``addr`` to fill it. V4L2 sub-device functions and data structures --------------------------------------------- |