aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/media/kapi
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/media/kapi')
-rw-r--r--Documentation/media/kapi/cec-core.rst38
-rw-r--r--Documentation/media/kapi/csi2.rst61
-rw-r--r--Documentation/media/kapi/dtv-core.rst8
3 files changed, 85 insertions, 22 deletions
diff --git a/Documentation/media/kapi/cec-core.rst b/Documentation/media/kapi/cec-core.rst
index 88c33b53ec13..81c6d8e93774 100644
--- a/Documentation/media/kapi/cec-core.rst
+++ b/Documentation/media/kapi/cec-core.rst
@@ -37,9 +37,8 @@ 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);
+ struct cec_adapter *cec_allocate_adapter(const struct cec_adap_ops *ops, void *priv,
+ const char *name, u32 caps, u8 available_las);
.. c:function::
void cec_delete_adapter(struct cec_adapter *adap);
@@ -66,20 +65,19 @@ 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);
+ int cec_register_adapter(struct cec_adapter *adap, struct device *parent);
+
+where parent is the parent device.
To unregister the devices call:
.. c:function::
- void cec_unregister_adapter(struct cec_adapter \*adap);
+ 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
@@ -106,13 +104,13 @@ your driver:
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);
+ void (*adap_status)(struct cec_adapter *adap, struct seq_file *file);
/* High-level callbacks */
...
};
-The three low-level ops deal with various aspects of controlling the CEC adapter
+The five low-level ops deal with various aspects of controlling the CEC adapter
hardware:
@@ -238,6 +236,18 @@ When a CEC message was received:
Speaks for itself.
+Implementing the interrupt handler
+----------------------------------
+
+Typically the CEC hardware provides interrupts that signal when a transmit
+finished and whether it was successful or not, and it provides and interrupt
+when a CEC message was received.
+
+The CEC driver should always process the transmit interrupts first before
+handling the receive interrupt. The framework expects to see the cec_transmit_done
+call before the cec_received_msg call, otherwise it can get confused if the
+received message was in reply to the transmitted message.
+
Implementing the High-Level CEC Adapter
---------------------------------------
@@ -247,11 +257,11 @@ CEC protocol driven. The following high-level callbacks are available:
.. code-block:: none
struct cec_adap_ops {
- /\* Low-level callbacks \*/
+ /* Low-level callbacks */
...
- /\* High-level CEC message callback \*/
- int (\*received)(struct cec_adapter \*adap, struct cec_msg \*msg);
+ /* 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
@@ -263,7 +273,7 @@ received CEC message
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.
+it will not do anything with it.
CEC framework functions
diff --git a/Documentation/media/kapi/csi2.rst b/Documentation/media/kapi/csi2.rst
new file mode 100644
index 000000000000..2004db00b12b
--- /dev/null
+++ b/Documentation/media/kapi/csi2.rst
@@ -0,0 +1,61 @@
+MIPI CSI-2
+==========
+
+CSI-2 is a data bus intended for transferring images from cameras to
+the host SoC. It is defined by the `MIPI alliance`_.
+
+.. _`MIPI alliance`: http://www.mipi.org/
+
+Transmitter drivers
+-------------------
+
+CSI-2 transmitter, such as a sensor or a TV tuner, drivers need to
+provide the CSI-2 receiver with information on the CSI-2 bus
+configuration. These include the V4L2_CID_LINK_FREQ and
+V4L2_CID_PIXEL_RATE controls and
+(:c:type:`v4l2_subdev_video_ops`->s_stream() callback). These
+interface elements must be present on the sub-device represents the
+CSI-2 transmitter.
+
+The V4L2_CID_LINK_FREQ control is used to tell the receiver driver the
+frequency (and not the symbol rate) of the link. The
+V4L2_CID_PIXEL_RATE is may be used by the receiver to obtain the pixel
+rate the transmitter uses. The
+:c:type:`v4l2_subdev_video_ops`->s_stream() callback provides an
+ability to start and stop the stream.
+
+The value of the V4L2_CID_PIXEL_RATE is calculated as follows::
+
+ pixel_rate = link_freq * 2 * nr_of_lanes / bits_per_sample
+
+where
+
+.. list-table:: variables in pixel rate calculation
+ :header-rows: 1
+
+ * - variable or constant
+ - description
+ * - link_freq
+ - The value of the V4L2_CID_LINK_FREQ integer64 menu item.
+ * - nr_of_lanes
+ - Number of data lanes used on the CSI-2 link. This can
+ be obtained from the OF endpoint configuration.
+ * - 2
+ - Two bits are transferred per clock cycle per lane.
+ * - bits_per_sample
+ - Number of bits per sample.
+
+The transmitter drivers must configure the CSI-2 transmitter to *LP-11
+mode* whenever the transmitter is powered on but not active. Some
+transmitters do this automatically but some have to be explicitly
+programmed to do so.
+
+Receiver drivers
+----------------
+
+Before the receiver driver may enable the CSI-2 transmitter by using
+the :c:type:`v4l2_subdev_video_ops`->s_stream(), it must have powered
+the transmitter up by using the
+:c:type:`v4l2_subdev_core_ops`->s_power() callback. This may take
+place either indirectly by using :c:func:`v4l2_pipeline_pm_use` or
+directly.
diff --git a/Documentation/media/kapi/dtv-core.rst b/Documentation/media/kapi/dtv-core.rst
index a3c4642eabfc..ff86bf0abeae 100644
--- a/Documentation/media/kapi/dtv-core.rst
+++ b/Documentation/media/kapi/dtv-core.rst
@@ -8,14 +8,6 @@ Digital TV Common functions
.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
-
-
-.. kernel-doc:: drivers/media/dvb-core/dvb_math.h
- :export: drivers/media/dvb-core/dvb_math.c
-
-.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
- :export: drivers/media/dvb-core/dvbdev.c
-
Digital TV Ring buffer
----------------------