diff options
Diffstat (limited to 'Documentation')
81 files changed, 5218 insertions, 582 deletions
diff --git a/Documentation/ABI/stable/sysfs-driver-qaic b/Documentation/ABI/stable/sysfs-driver-qaic new file mode 100644 index 000000000000..c767a93342b3 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-qaic @@ -0,0 +1,19 @@ +What: /sys/bus/pci/drivers/qaic/XXXX:XX:XX.X/accel/accel<minor_nr>/dbc<N>_state +Date: October 2025 +KernelVersion: 6.19 +Contact: Jeff Hugo <jeff.hugo@oss.qualcomm.com> +Description: Represents the current state of DMA Bridge channel (DBC). Below are the possible + states: + + =================== ========================================================== + IDLE (0) DBC is free and can be activated + ASSIGNED (1) DBC is activated and a workload is running on device + BEFORE_SHUTDOWN (2) Sub-system associated with this workload has crashed and + it will shutdown soon + AFTER_SHUTDOWN (3) Sub-system associated with this workload has crashed and + it has shutdown + BEFORE_POWER_UP (4) Sub-system associated with this workload is shutdown and + it will be powered up soon + AFTER_POWER_UP (5) Sub-system associated with this workload is now powered up + =================== ========================================================== +Users: Any userspace application or clients interested in DBC state. diff --git a/Documentation/ABI/testing/sysfs-auxdisplay-linedisp b/Documentation/ABI/testing/sysfs-auxdisplay-linedisp new file mode 100644 index 000000000000..55f1b559e84e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-auxdisplay-linedisp @@ -0,0 +1,90 @@ +What: /sys/.../message +Date: October 2021 +KernelVersion: 5.16 +Description: + Controls the text message displayed on character line displays. + + Reading returns the current message with a trailing newline. + Writing updates the displayed message. Messages longer than the + display width will automatically scroll. Trailing newlines in + input are automatically trimmed. + + Writing an empty string clears the display. + + Example: + echo "Hello World" > message + cat message # Returns "Hello World\n" + +What: /sys/.../num_chars +Date: November 2025 +KernelVersion: 6.18 +Contact: Jean-François Lessard <jefflessard3@gmail.com> +Description: + Read-only attribute showing the character width capacity of + the line display device. Messages longer than this will scroll. + + Example: + cat num_chars # Returns "16\n" for 16-char display + +What: /sys/.../scroll_step_ms +Date: October 2021 +KernelVersion: 5.16 +Description: + Controls the scrolling speed for messages longer than the display + width, specified in milliseconds per scroll step. + + Setting to 0 disables scrolling. Default is 500ms. + + Example: + echo "250" > scroll_step_ms # 4Hz scrolling + cat scroll_step_ms # Returns "250\n" + +What: /sys/.../map_seg7 +Date: January 2024 +KernelVersion: 6.9 +Description: + Read/write binary blob representing the ASCII-to-7-segment + display conversion table used by the linedisp driver, as defined + by struct seg7_conversion_map in <linux/map_to_7segment.h>. + + Only visible on displays with 7-segment capability. + + This attribute is not human-readable. Writes must match the + struct size exactly, else -EINVAL is returned; reads return the + entire mapping as a binary blob. + + This interface and its implementation match existing conventions + used in segment-mapped display drivers since 2005. + + ABI note: This style of binary sysfs attribute *is an exception* + to current "one value per file, text only" sysfs rules, for + historical compatibility and driver uniformity. New drivers are + discouraged from introducing additional binary sysfs ABIs. + + Reference interface guidance: + - include/uapi/linux/map_to_7segment.h + +What: /sys/.../map_seg14 +Date: January 2024 +KernelVersion: 6.9 +Description: + Read/write binary blob representing the ASCII-to-14-segment + display conversion table used by the linedisp driver, as defined + by struct seg14_conversion_map in <linux/map_to_14segment.h>. + + Only visible on displays with 14-segment capability. + + This attribute is not human-readable. Writes must match the + struct size exactly, else -EINVAL is returned; reads return the + entire mapping as a binary blob. + + This interface and its implementation match existing conventions + used by segment-mapped display drivers since 2005. + + ABI note: This style of binary sysfs attribute *is an exception* + to current "one value per file, text only" sysfs rules, for + historical compatibility and driver uniformity. New drivers are + discouraged from introducing additional binary sysfs ABIs. + + Reference interface guidance: + - include/uapi/linux/map_to_14segment.h diff --git a/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov b/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov new file mode 100644 index 000000000000..2fd7e9b7bacc --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel-xe-sriov @@ -0,0 +1,159 @@ +What: /sys/bus/pci/drivers/xe/.../sriov_admin/ +Date: October 2025 +KernelVersion: 6.19 +Contact: intel-xe@lists.freedesktop.org +Description: + This directory appears for the particular Intel Xe device when: + + - device supports SR-IOV, and + - device is a Physical Function (PF), and + - driver support for the SR-IOV PF is enabled on given device. + + This directory is used as a root for all attributes required to + manage both Physical Function (PF) and Virtual Functions (VFs). + + +What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/ +Date: October 2025 +KernelVersion: 6.19 +Contact: intel-xe@lists.freedesktop.org +Description: + This directory holds attributes related to the SR-IOV Physical + Function (PF). + + +What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf1/ +What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf2/ +What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<N>/ +Date: October 2025 +KernelVersion: 6.19 +Contact: intel-xe@lists.freedesktop.org +Description: + These directories hold attributes related to the SR-IOV Virtual + Functions (VFs). + + Note that the VF number <N> is 1-based as described in PCI SR-IOV + specification as the Xe driver follows that naming schema. + + There could be "vf1", "vf2" and so on, up to "vf<N>", where <N> + matches the value of the "sriov_totalvfs" attribute. + + +What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/profile/exec_quantum_ms +What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/profile/preempt_timeout_us +What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/profile/sched_priority +What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/profile/exec_quantum_ms +What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/profile/preempt_timeout_us +What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/profile/sched_priority +Date: October 2025 +KernelVersion: 6.19 +Contact: intel-xe@lists.freedesktop.org +Description: + These files expose scheduling parameters for the PF and its VFs, and + are visible only on Intel Xe platforms that use time-sliced GPU sharing. + They can be changed even if VFs are enabled and running and reflect the + settings of all tiles/GTs assigned to the given function. + + exec_quantum_ms: (RW) unsigned integer + The GT execution quantum (EQ) in [ms] for the given function. + Actual quantum value might be aligned per HW/FW requirements. + + Default is 0 (unlimited). + + preempt_timeout_us: (RW) unsigned integer + The GT preemption timeout in [us] of the given function. + Actual timeout value might be aligned per HW/FW requirements. + + Default is 0 (unlimited). + + sched_priority: (RW/RO) string + The GT scheduling priority of the given function. + + "low" - function will be scheduled on the GPU for its EQ/PT + only if function has any work already submitted. + + "normal" - functions will be scheduled on the GPU for its EQ/PT + irrespective of whether it has submitted a work or not. + + "high" - function will be scheduled on the GPU for its EQ/PT + in the next time-slice after the current one completes + and function has a work submitted. + + Default is "low". + + When read, this file will display the current and available + scheduling priorities. The currently active priority level will + be enclosed in square brackets, like: + + [low] normal high + + This file can be read-only if changing the priority is not + supported. + + Writes to these attributes may fail with errors like: + -EINVAL if provided input is malformed or not recognized, + -EPERM if change is not applicable on given HW/FW, + -EIO if FW refuses to change the provisioning. + + Reads from these attributes may fail with: + -EUCLEAN if value is not consistent across all tiles/GTs. + + +What: /sys/bus/pci/drivers/xe/.../sriov_admin/.bulk_profile/exec_quantum_ms +What: /sys/bus/pci/drivers/xe/.../sriov_admin/.bulk_profile/preempt_timeout_us +What: /sys/bus/pci/drivers/xe/.../sriov_admin/.bulk_profile/sched_priority +Date: October 2025 +KernelVersion: 6.19 +Contact: intel-xe@lists.freedesktop.org +Description: + These files allows bulk reconfiguration of the scheduling parameters + of the PF or VFs and are available only for Intel Xe platforms with + GPU sharing based on the time-slice basis. These scheduling parameters + can be changed even if VFs are enabled and running. + + exec_quantum_ms: (WO) unsigned integer + The GT execution quantum (EQ) in [ms] to be applied to all functions. + See sriov_admin/{pf,vf<N>}/profile/exec_quantum_ms for more details. + + preempt_timeout_us: (WO) unsigned integer + The GT preemption timeout (PT) in [us] to be applied to all functions. + See sriov_admin/{pf,vf<N>}/profile/preempt_timeout_us for more details. + + sched_priority: (RW/RO) string + The GT scheduling priority to be applied for all functions. + See sriov_admin/{pf,vf<N>}/profile/sched_priority for more details. + + Writes to these attributes may fail with errors like: + -EINVAL if provided input is malformed or not recognized, + -EPERM if change is not applicable on given HW/FW, + -EIO if FW refuses to change the provisioning. + + +What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/stop +Date: October 2025 +KernelVersion: 6.19 +Contact: intel-xe@lists.freedesktop.org +Description: + This file allows to control scheduling of the VF on the Intel Xe GPU + platforms. It allows to implement custom policy mechanism in case VFs + are misbehaving or triggering adverse events above defined thresholds. + + stop: (WO) bool + All GT executions of given function shall be immediately stopped. + To allow scheduling this VF again, the VF FLR must be triggered. + + Writes to this attribute may fail with errors like: + -EINVAL if provided input is malformed or not recognized, + -EPERM if change is not applicable on given HW/FW, + -EIO if FW refuses to change the scheduling. + + +What: /sys/bus/pci/drivers/xe/.../sriov_admin/pf/device +What: /sys/bus/pci/drivers/xe/.../sriov_admin/vf<n>/device +Date: October 2025 +KernelVersion: 6.19 +Contact: intel-xe@lists.freedesktop.org +Description: + These are symlinks to the underlying PCI device entry representing + given Xe SR-IOV function. For the PF, this link is always present. + For VFs, this link is present only for currently enabled VFs. diff --git a/Documentation/accel/qaic/aic100.rst b/Documentation/accel/qaic/aic100.rst index 273da6192fb3..41331cf580b1 100644 --- a/Documentation/accel/qaic/aic100.rst +++ b/Documentation/accel/qaic/aic100.rst @@ -487,8 +487,8 @@ one user crashes, the fallout of that should be limited to that workload and not impact other workloads. SSR accomplishes this. If a particular workload crashes, QSM notifies the host via the QAIC_SSR MHI -channel. This notification identifies the workload by it's assigned DBC. A -multi-stage recovery process is then used to cleanup both sides, and get the +channel. This notification identifies the workload by its assigned DBC. A +multi-stage recovery process is then used to cleanup both sides, and gets the DBC/NSPs into a working state. When SSR occurs, any state in the workload is lost. Any inputs that were in @@ -496,6 +496,27 @@ process, or queued by not yet serviced, are lost. The loaded artifacts will remain in on-card DDR, but the host will need to re-activate the workload if it desires to recover the workload. +When SSR occurs for a specific NSP, the assigned DBC goes through the +following state transactions in order: + +DBC_STATE_BEFORE_SHUTDOWN + Indicates that the affected NSP was found in an unrecoverable error + condition. +DBC_STATE_AFTER_SHUTDOWN + Indicates that the NSP is under reset. +DBC_STATE_BEFORE_POWER_UP + Indicates that the NSP's debug information has been collected, and is + ready to be collected by the host (if desired). At that stage the NSP + is restarted by QSM. +DBC_STATE_AFTER_POWER_UP + Indicates that the NSP has been restarted, fully operational and is + in idle state. + +SSR also has an optional crashdump collection feature. If enabled, the host can +collect the memory dump for the crashed NSP and dump it to the user space via +the dev_coredump subsystem. The host can also decline the crashdump collection +request from the device. + Reliability, Accessibility, Serviceability (RAS) ================================================ diff --git a/Documentation/accel/qaic/qaic.rst b/Documentation/accel/qaic/qaic.rst index 018d6cc173d7..ef27e262cb91 100644 --- a/Documentation/accel/qaic/qaic.rst +++ b/Documentation/accel/qaic/qaic.rst @@ -36,7 +36,7 @@ polling mode and reenables the IRQ line. This mitigation in QAIC is very effective. The same lprnet usecase that generates 100k IRQs per second (per /proc/interrupts) is reduced to roughly 64 IRQs over 5 minutes while keeping the host system stable, and having the same -workload throughput performance (within run to run noise variation). +workload throughput performance (within run-to-run noise variation). Single MSI Mode --------------- @@ -49,7 +49,7 @@ useful to be able to fall back to a single MSI when needed. To support this fallback, we allow the case where only one MSI is able to be allocated, and share that one MSI between MHI and the DBCs. The device detects when only one MSI has been configured and directs the interrupts for the DBCs -to the interrupt normally used for MHI. Unfortunately this means that the +to the interrupt normally used for MHI. Unfortunately, this means that the interrupt handlers for every DBC and MHI wake up for every interrupt that arrives; however, the DBC threaded irq handlers only are started when work to be done is detected (MHI will always start its threaded handler). @@ -62,9 +62,9 @@ never disabled, allowing each new entry to the FIFO to trigger a new interrupt. Neural Network Control (NNC) Protocol ===================================== -The implementation of NNC is split between the KMD (QAIC) and UMD. In general +The implementation of NNC is split between the KMD (QAIC) and UMD. In general, QAIC understands how to encode/decode NNC wire protocol, and elements of the -protocol which require kernel space knowledge to process (for example, mapping +protocol which requires kernel space knowledge to process (for example, mapping host memory to device IOVAs). QAIC understands the structure of a message, and all of the transactions. QAIC does not understand commands (the payload of a passthrough transaction). diff --git a/Documentation/admin-guide/media/mali-c55-graph.dot b/Documentation/admin-guide/media/mali-c55-graph.dot new file mode 100644 index 000000000000..0775ba42bf4c --- /dev/null +++ b/Documentation/admin-guide/media/mali-c55-graph.dot @@ -0,0 +1,19 @@ +digraph board { + rankdir=TB + n00000001 [label="{{} | mali-c55 tpg\n/dev/v4l-subdev0 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green] + n00000001:port0 -> n00000003:port0 [style=dashed] + n00000003 [label="{{<port0> 0} | mali-c55 isp\n/dev/v4l-subdev1 | {<port1> 1 | <port2> 2}}", shape=Mrecord, style=filled, fillcolor=green] + n00000003:port1 -> n00000007:port0 [style=bold] + n00000003:port2 -> n00000007:port2 [style=bold] + n00000003:port1 -> n0000000b:port0 [style=bold] + n00000007 [label="{{<port0> 0 | <port2> 2} | mali-c55 resizer fr\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green] + n00000007:port1 -> n0000000e [style=bold] + n0000000b [label="{{<port0> 0} | mali-c55 resizer ds\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green] + n0000000b:port1 -> n00000012 [style=bold] + n0000000e [label="mali-c55 fr\n/dev/video0", shape=box, style=filled, fillcolor=yellow] + n00000012 [label="mali-c55 ds\n/dev/video1", shape=box, style=filled, fillcolor=yellow] + n00000022 [label="{{<port0> 0} | csi2-rx\n/dev/v4l-subdev4 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green] + n00000022:port1 -> n00000003:port0 + n00000027 [label="{{} | imx415 1-001a\n/dev/v4l-subdev5 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green] + n00000027:port0 -> n00000022:port0 [style=bold] +}
\ No newline at end of file diff --git a/Documentation/admin-guide/media/mali-c55.rst b/Documentation/admin-guide/media/mali-c55.rst new file mode 100644 index 000000000000..315f982000c4 --- /dev/null +++ b/Documentation/admin-guide/media/mali-c55.rst @@ -0,0 +1,413 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================== +ARM Mali-C55 Image Signal Processor driver +========================================== + +Introduction +============ + +This file documents the driver for ARM's Mali-C55 Image Signal Processor. The +driver is located under drivers/media/platform/arm/mali-c55. + +The Mali-C55 ISP receives data in either raw Bayer format or RGB/YUV format from +sensors through either a parallel interface or a memory bus before processing it +and outputting it through an internal DMA engine. Two output pipelines are +possible (though one may not be fitted, depending on the implementation). These +are referred to as "Full resolution" and "Downscale", but the naming is historic +and both pipes are capable of cropping/scaling operations. The full resolution +pipe is also capable of outputting RAW data, bypassing much of the ISP's +processing. The downscale pipe cannot output RAW data. An integrated test +pattern generator can be used to drive the ISP and produce image data in the +absence of a connected camera sensor. The driver module is named mali_c55, and +is enabled through the CONFIG_VIDEO_MALI_C55 config option. + +The driver implements V4L2, Media Controller and V4L2 Subdevice interfaces and +expects camera sensors connected to the ISP to have V4L2 subdevice interfaces. + +Mali-C55 ISP hardware +===================== + +A high level functional view of the Mali-C55 ISP is presented below. The ISP +takes input from either a live source or through a DMA engine for memory input, +depending on the SoC integration.:: + + +---------+ +----------+ +--------+ + | Sensor |--->| CSI-2 Rx | "Full Resolution" | DMA | + +---------+ +----------+ |\ Output +--->| Writer | + | | \ | +--------+ + | | \ +----------+ +------+---> Streaming I/O + +------------+ +------->| | | | | + | | | |-->| Mali-C55 |--+ + | DMA Reader |--------------->| | | ISP | | + | | | / | | | +---> Streaming I/O + +------------+ | / +----------+ | | + |/ +------+ + | +--------+ + +--->| DMA | + "Downscaled" | Writer | + Output +--------+ + +Media Controller Topology +========================= + +An example of the ISP's topology (as implemented in a system with an IMX415 +camera sensor and generic CSI-2 receiver) is below: + + +.. kernel-figure:: mali-c55-graph.dot + :alt: mali-c55-graph.dot + :align: center + +The driver has 4 V4L2 subdevices: + +- `mali_c55 isp`: Responsible for configuring input crop and color space + conversion +- `mali_c55 tpg`: The test pattern generator, emulating a camera sensor. +- `mali_c55 resizer fr`: The Full-Resolution pipe resizer +- `mali_c55 resizer ds`: The Downscale pipe resizer + +The driver has 3 V4L2 video devices: + +- `mali-c55 fr`: The full-resolution pipe's capture device +- `mali-c55 ds`: The downscale pipe's capture device +- `mali-c55 3a stats`: The 3A statistics capture device + +Frame sequences are synchronised across to two capture devices, meaning if one +pipe is started later than the other the sequence numbers returned in its +buffers will match those of the other pipe rather than starting from zero. + +Idiosyncrasies +-------------- + +**mali-c55 isp** +The `mali-c55 isp` subdevice has a single sink pad to which all sources of data +should be connected. The active source is selected by enabling the appropriate +media link and disabling all others. The ISP has two source pads, reflecting the +different paths through which it can internally route data. Tap points within +the ISP allow users to divert data to avoid processing by some or all of the +hardware's processing steps. The diagram below is intended only to highlight how +the bypassing works and is not a true reflection of those processing steps; for +a high-level functional block diagram see ARM's developer page for the +ISP [3]_:: + + +--------------------------------------------------------------+ + | Possible Internal ISP Data Routes | + | +------------+ +----------+ +------------+ | + +---+ | | | | | Colour | +---+ + | 0 |--+-->| Processing |->| Demosaic |->| Space |--->| 1 | + +---+ | | | | | | Conversion | +---+ + | | +------------+ +----------+ +------------+ | + | | +---+ + | +---------------------------------------------------| 2 | + | +---+ + | | + +--------------------------------------------------------------+ + + +.. flat-table:: + :header-rows: 1 + + * - Pad + - Direction + - Purpose + + * - 0 + - sink + - Data input, connected to the TPG and camera sensors + + * - 1 + - source + - RGB/YUV data, connected to the FR and DS V4L2 subdevices + + * - 2 + - source + - RAW bayer data, connected to the FR V4L2 subdevices + +The ISP is limited to both input and output resolutions between 640x480 and +8192x8192, and this is reflected in the ISP and resizer subdevice's .set_fmt() +operations. + +**mali-c55 resizer fr** +The `mali-c55 resizer fr` subdevice has two _sink_ pads to reflect the different +insertion points in the hardware (either RAW or demosaiced data): + +.. flat-table:: + :header-rows: 1 + + * - Pad + - Direction + - Purpose + + * - 0 + - sink + - Data input connected to the ISP's demosaiced stream. + + * - 1 + - source + - Data output connected to the capture video device + + * - 2 + - sink + - Data input connected to the ISP's raw data stream + +The data source in use is selected through the routing API; two routes each of a +single stream are available: + +.. flat-table:: + :header-rows: 1 + + * - Sink Pad + - Source Pad + - Purpose + + * - 0 + - 1 + - Demosaiced data route + + * - 2 + - 1 + - Raw data route + + +If the demosaiced route is active then the FR pipe is only capable of output +in RGB/YUV formats. If the raw route is active then the output reflects the +input (which may be either Bayer or RGB/YUV data). + +Using the driver to capture video +================================= + +Using the media controller APIs we can configure the input source and ISP to +capture images in a variety of formats. In the examples below, configuring the +media graph is done with the v4l-utils [1]_ package's media-ctl utility. +Capturing the images is done with yavta [2]_. + +Configuring the input source +---------------------------- + +The first step is to set the input source that we wish by enabling the correct +media link. Using the example topology above, we can select the TPG as follows: + +.. code-block:: none + + media-ctl -l "'lte-csi2-rx':1->'mali-c55 isp':0[0]" + media-ctl -l "'mali-c55 tpg':0->'mali-c55 isp':0[1]" + +Configuring which video devices will stream data +------------------------------------------------ + +The driver will wait for all video devices to have their VIDIOC_STREAMON ioctl +called before it tells the sensor to start streaming. To facilitate this we need +to enable links to the video devices that we want to use. In the example below +we enable the links to both of the image capture video devices + +.. code-block:: none + + media-ctl -l "'mali-c55 resizer fr':1->'mali-c55 fr':0[1]" + media-ctl -l "'mali-c55 resizer ds':1->'mali-c55 ds':0[1]" + +Capturing bayer data from the source and processing to RGB/YUV +-------------------------------------------------------------- + +To capture 1920x1080 bayer data from the source and push it through the ISP's +full processing pipeline, we configure the data formats appropriately on the +source, ISP and resizer subdevices and set the FR resizer's routing to select +processed data. The media bus format on the resizer's source pad will be either +RGB121212_1X36 or YUV10_1X30, depending on whether you want to capture RGB or +YUV. The ISP's debayering block outputs RGB data natively, setting the source +pad format to YUV10_1X30 enables the colour space conversion block. + +In this example we target RGB565 output, so select RGB121212_1X36 as the resizer +source pad's format: + +.. code-block:: none + + # Set formats on the TPG and ISP + media-ctl -V "'mali-c55 tpg':0[fmt:SRGGB20_1X20/1920x1080]" + media-ctl -V "'mali-c55 isp':0[fmt:SRGGB20_1X20/1920x1080]" + media-ctl -V "'mali-c55 isp':1[fmt:SRGGB20_1X20/1920x1080]" + + # Set routing on the FR resizer + media-ctl -R "'mali-c55 resizer fr'[0/0->1/0[1],2/0->1/0[0]]" + + # Set format on the resizer, must be done AFTER the routing. + media-ctl -V "'mali-c55 resizer fr':1[fmt:RGB121212_1X36/1920x1080]" + +The downscale output can also be used to stream data at the same time. In this +case since only processed data can be captured through the downscale output no +routing need be set: + +.. code-block:: none + + # Set format on the resizer + media-ctl -V "'mali-c55 resizer ds':1[fmt:RGB121212_1X36/1920x1080]" + +Following which images can be captured from both the FR and DS output's video +devices (simultaneously, if desired): + +.. code-block:: none + + yavta -f RGB565 -s 1920x1080 -c10 /dev/video0 + yavta -f RGB565 -s 1920x1080 -c10 /dev/video1 + +Cropping the image +~~~~~~~~~~~~~~~~~~ + +Both the full resolution and downscale pipes can crop to a minimum resolution of +640x480. To crop the image simply configure the resizer's sink pad's crop and +compose rectangles and set the format on the video device: + +.. code-block:: none + + media-ctl -V "'mali-c55 resizer fr':0[fmt:RGB121212_1X36/1920x1080 crop:(480,270)/640x480 compose:(0,0)/640x480]" + media-ctl -V "'mali-c55 resizer fr':1[fmt:RGB121212_1X36/640x480]" + yavta -f RGB565 -s 640x480 -c10 /dev/video0 + +Downscaling the image +~~~~~~~~~~~~~~~~~~~~~ + +Both the full resolution and downscale pipes can downscale the image by up to 8x +provided the minimum 640x480 output resolution is adhered to. For the best image +result the scaling ratio for each direction should be the same. To configure +scaling we use the compose rectangle on the resizer's sink pad: + +.. code-block:: none + + media-ctl -V "'mali-c55 resizer fr':0[fmt:RGB121212_1X36/1920x1080 crop:(0,0)/1920x1080 compose:(0,0)/640x480]" + media-ctl -V "'mali-c55 resizer fr':1[fmt:RGB121212_1X36/640x480]" + yavta -f RGB565 -s 640x480 -c10 /dev/video0 + +Capturing images in YUV formats +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If we need to output YUV data rather than RGB the color space conversion block +needs to be active, which is achieved by setting MEDIA_BUS_FMT_YUV10_1X30 on the +resizer's source pad. We can then configure a capture format like NV12 (here in +its multi-planar variant) + +.. code-block:: none + + media-ctl -V "'mali-c55 resizer fr':1[fmt:YUV10_1X30/1920x1080]" + yavta -f NV12M -s 1920x1080 -c10 /dev/video0 + +Capturing RGB data from the source and processing it with the resizers +---------------------------------------------------------------------- + +The Mali-C55 ISP can work with sensors capable of outputting RGB data. In this +case although none of the image quality blocks would be used it can still +crop/scale the data in the usual way. For this reason RGB data input to the ISP +still goes through the ISP subdevice's pad 1 to the resizer. + +To achieve this, the ISP's sink pad's format is set to +MEDIA_BUS_FMT_RGB202020_1X60 - this reflects the format that data must be in to +work with the ISP. Converting the camera sensor's output to that format is the +responsibility of external hardware. + +In this example we ask the test pattern generator to give us RGB data instead of +bayer. + +.. code-block:: none + + media-ctl -V "'mali-c55 tpg':0[fmt:RGB202020_1X60/1920x1080]" + media-ctl -V "'mali-c55 isp':0[fmt:RGB202020_1X60/1920x1080]" + +Cropping or scaling the data can be done in exactly the same way as outlined +earlier. + +Capturing raw data from the source and outputting it unmodified +----------------------------------------------------------------- + +The ISP can additionally capture raw data from the source and output it on the +full resolution pipe only, completely unmodified. In this case the downscale +pipe can still process the data normally and be used at the same time. + +To configure raw bypass the FR resizer's subdevice's routing table needs to be +configured, followed by formats in the appropriate places: + +.. code-block:: none + + media-ctl -R "'mali-c55 resizer fr'[0/0->1/0[0],2/0->1/0[1]]" + media-ctl -V "'mali-c55 isp':0[fmt:RGB202020_1X60/1920x1080]" + media-ctl -V "'mali-c55 resizer fr':2[fmt:RGB202020_1X60/1920x1080]" + media-ctl -V "'mali-c55 resizer fr':1[fmt:RGB202020_1X60/1920x1080]" + + # Set format on the video device and stream + yavta -f RGB565 -s 1920x1080 -c10 /dev/video0 + +.. _mali-c55-3a-stats: + +Capturing ISP Statistics +======================== + +The ISP is capable of producing statistics for consumption by image processing +algorithms running in userspace. These statistics can be captured by queueing +buffers to the `mali-c55 3a stats` V4L2 Device whilst the ISP is streaming. Only +the :ref:`V4L2_META_FMT_MALI_C55_STATS <v4l2-meta-fmt-mali-c55-stats>` +format is supported, so no format-setting need be done: + +.. code-block:: none + + # We assume the media graph has been configured to support RGB565 capture + # from the mali-c55 fr V4L2 Device, which is at /dev/video0. The statistics + # V4L2 device is at /dev/video3 + + yavta -f RGB565 -s 1920x1080 -c32 /dev/video0 && \ + yavta -c10 -F /dev/video3 + +The layout of the buffer is described by :c:type:`mali_c55_stats_buffer`, +but broadly statistics are generated to support three image processing +algorithms; AEXP (Auto-Exposure), AWB (Auto-White Balance) and AF (Auto-Focus). +These stats can be drawn from various places in the Mali C55 ISP pipeline, known +as "tap points". This high-level block diagram is intended to explain where in +the processing flow the statistics can be drawn from:: + + +--> AEXP-2 +----> AEXP-1 +--> AF-0 + | +----> AF-1 | + | | | + +---------+ | +--------------+ | +--------------+ | + | Input +-+-->+ Digital Gain +---+-->+ Black Level +---+---+ + +---------+ +--------------+ +--------------+ | + +-----------------------------------------------------------------+ + | + | +--------------+ +---------+ +----------------+ + +-->| Sinter Noise +-+ White +--+--->| Lens Shading +--+---------------+ + | Reduction | | Balance | | | | | | + +--------------+ +---------+ | +----------------+ | | + +---> AEXP-0 (A) +--> AEXP-0 (B) | + +--------------------------------------------------------------------------+ + | + | +----------------+ +--------------+ +----------------+ + +-->| Tone mapping +-+--->| Demosaicing +->+ Purple Fringe +-+-----------+ + | | | +--------------+ | Correction | | | + +----------------+ +-> AEXP-IRIDIX +----------------+ +---> AWB-0 | + +----------------------------------------------------------------------------+ + | +-------------+ +-------------+ + +------------------->| Colour +---+--->| Output | + | Correction | | | Pipelines | + +-------------+ | +-------------+ + +--> AWB-1 + +By default all statistics are drawn from the 0th tap point for each algorithm; +I.E. AEXP statistics from AEXP-0 (A), AWB statistics from AWB-0 and AF +statistics from AF-0. This is configurable for AEXP and AWB statsistics through +programming the ISP's parameters. + +.. _mali-c55-3a-params: + +Programming ISP Parameters +========================== + +The ISP can be programmed with various parameters from userspace to apply to the +hardware before and during video stream. This allows userspace to dynamically +change values such as black level, white balance and lens shading gains and so +on. + +The buffer format and how to populate it are described by the +:ref:`V4L2_META_FMT_MALI_C55_PARAMS <v4l2-meta-fmt-mali-c55-params>` format, +which should be set as the data format for the `mali-c55 3a params` video node. + +References +========== +.. [1] https://git.linuxtv.org/v4l-utils.git/ +.. [2] https://git.ideasonboard.org/yavta.git +.. [3] https://developer.arm.com/Processors/Mali-C55 diff --git a/Documentation/admin-guide/media/platform-cardlist.rst b/Documentation/admin-guide/media/platform-cardlist.rst index 1230ae4037ad..63f4b19c3628 100644 --- a/Documentation/admin-guide/media/platform-cardlist.rst +++ b/Documentation/admin-guide/media/platform-cardlist.rst @@ -18,8 +18,6 @@ am437x-vpfe TI AM437x VPFE aspeed-video Aspeed AST2400 and AST2500 atmel-isc ATMEL Image Sensor Controller (ISC) atmel-isi ATMEL Image Sensor Interface (ISI) -c8sectpfe SDR platform devices -c8sectpfe SDR platform devices cafe_ccic Marvell 88ALP01 (Cafe) CMOS Camera Controller cdns-csi2rx Cadence MIPI-CSI2 RX Controller cdns-csi2tx Cadence MIPI-CSI2 TX Controller diff --git a/Documentation/admin-guide/media/rkcif-rk3568-vicap.dot b/Documentation/admin-guide/media/rkcif-rk3568-vicap.dot new file mode 100644 index 000000000000..3fac59335459 --- /dev/null +++ b/Documentation/admin-guide/media/rkcif-rk3568-vicap.dot @@ -0,0 +1,8 @@ +digraph board { + rankdir=TB + n00000001 [label="{{<port0> 0} | rkcif-dvp0\n/dev/v4l-subdev0 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green] + n00000001:port1 -> n00000004 + n00000004 [label="rkcif-dvp0-id0\n/dev/video0", shape=box, style=filled, fillcolor=yellow] + n00000025 [label="{{} | it6801 2-0048\n/dev/v4l-subdev1 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green] + n00000025:port0 -> n00000001:port0 +} diff --git a/Documentation/admin-guide/media/rkcif.rst b/Documentation/admin-guide/media/rkcif.rst new file mode 100644 index 000000000000..2558c121abc4 --- /dev/null +++ b/Documentation/admin-guide/media/rkcif.rst @@ -0,0 +1,79 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================================= +Rockchip Camera Interface (CIF) +========================================= + +Introduction +============ + +The Rockchip Camera Interface (CIF) is featured in many Rockchip SoCs in +different variants. +The different variants are combinations of common building blocks, such as + +* INTERFACE blocks of different types, namely + + * the Digital Video Port (DVP, a parallel data interface) + * the interface block for the MIPI CSI-2 receiver + +* CROP units + +* MIPI CSI-2 receiver (not available on all variants): This unit is referred + to as MIPI CSI HOST in the Rockchip documentation. + Technically, it is a separate hardware block, but it is strongly coupled to + the CIF and therefore included here. + +* MUX units (not available on all variants) that pass the video data to an + image signal processor (ISP) + +* SCALE units (not available on all variants) + +* DMA engines that transfer video data into system memory using a + double-buffering mechanism called ping-pong mode + +* Support for four streams per INTERFACE block (not available on all + variants), e.g., for MIPI CSI-2 Virtual Channels (VCs) + +This document describes the different variants of the CIF, their hardware +layout, as well as their representation in the media controller centric rkcif +device driver, which is located under drivers/media/platform/rockchip/rkcif. + +Variants +======== + +Rockchip PX30 Video Input Processor (VIP) +----------------------------------------- + +The PX30 Video Input Processor (VIP) features a digital video port that accepts +parallel video data or BT.656. +Since these protocols do not feature multiple streams, the VIP has one DMA +engine that transfers the input video data into system memory. + +The rkcif driver represents this hardware variant by exposing one V4L2 subdevice +(the DVP INTERFACE/CROP block) and one V4L2 device (the DVP DMA engine). + +Rockchip RK3568 Video Capture (VICAP) +------------------------------------- + +The RK3568 Video Capture (VICAP) unit features a digital video port and a MIPI +CSI-2 receiver that can receive video data independently. +The DVP accepts parallel video data, BT.656 and BT.1120. +Since the BT.1120 protocol may feature more than one stream, the RK3568 VICAP +DVP features four DMA engines that can capture different streams. +Similarly, the RK3568 VICAP MIPI CSI-2 receiver features four DMA engines to +handle different Virtual Channels (VCs). + +The rkcif driver represents this hardware variant by exposing up the following +V4L2 subdevices: + +* rkcif-dvp0: INTERFACE/CROP block for the DVP + +and the following video devices: + +* rkcif-dvp0-id0: The support for multiple streams on the DVP is not yet + implemented, as it is hard to find test hardware. Thus, this video device + represents the first DMA engine of the RK3568 DVP. + +.. kernel-figure:: rkcif-rk3568-vicap.dot + :alt: Topology of the RK3568 Video Capture (VICAP) unit + :align: center diff --git a/Documentation/admin-guide/media/v4l-drivers.rst b/Documentation/admin-guide/media/v4l-drivers.rst index 3bac5165b134..393f83e8dc4d 100644 --- a/Documentation/admin-guide/media/v4l-drivers.rst +++ b/Documentation/admin-guide/media/v4l-drivers.rst @@ -19,12 +19,14 @@ Video4Linux (V4L) driver-specific documentation ipu3 ipu6-isys ivtv + mali-c55 mgb4 omap3isp philips qcom_camss raspberrypi-pisp-be rcar-fdp1 + rkcif rkisp1 raspberrypi-rp1-cfe saa7134 diff --git a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml index 05442d437755..6211ab8bbb0e 100644 --- a/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml +++ b/Documentation/devicetree/bindings/display/bridge/fsl,imx8mp-hdmi-tx.yaml @@ -49,6 +49,10 @@ properties: $ref: /schemas/graph.yaml#/properties/port description: HDMI output port + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: Parallel audio input port + required: - port@0 - port@1 @@ -98,5 +102,13 @@ examples: remote-endpoint = <&hdmi0_con>; }; }; + + port@2 { + reg = <2>; + + endpoint { + remote-endpoint = <&pai_to_hdmi_tx>; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml index ba644c30dcf4..17d1f97ce8c2 100644 --- a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml @@ -19,6 +19,7 @@ properties: compatible: enum: - ite,it66121 + - ite,it66122 - ite,it6610 reg: diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml index c167795c63f6..b95f10edd3a2 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml @@ -14,6 +14,9 @@ description: | R-Car Gen4 SoCs. The encoder can operate in either DSI or CSI-2 mode, with up to four data lanes. +allOf: + - $ref: /schemas/display/dsi-controller.yaml# + properties: compatible: enum: @@ -80,14 +83,14 @@ required: - resets - ports -additionalProperties: false +unevaluatedProperties: false examples: - | #include <dt-bindings/clock/r8a779a0-cpg-mssr.h> #include <dt-bindings/power/r8a779a0-sysc.h> - dsi0: dsi-encoder@fed80000 { + dsi@fed80000 { compatible = "renesas,r8a779a0-dsi-csi2-tx"; reg = <0xfed80000 0x10000>; power-domains = <&sysc R8A779A0_PD_ALWAYS_ON>; @@ -117,4 +120,51 @@ examples: }; }; }; + + - | + #include <dt-bindings/clock/r8a779g0-cpg-mssr.h> + #include <dt-bindings/power/r8a779g0-sysc.h> + + dsi@fed80000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,r8a779g0-dsi-csi2-tx"; + reg = <0xfed80000 0x10000>; + clocks = <&cpg CPG_MOD 415>, + <&cpg CPG_CORE R8A779G0_CLK_DSIEXT>, + <&cpg CPG_CORE R8A779G0_CLK_DSIREF>; + clock-names = "fck", "dsi", "pll"; + power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>; + resets = <&cpg 415>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + }; + + port@1 { + reg = <1>; + + dsi0port1_out: endpoint { + remote-endpoint = <&panel_in>; + data-lanes = <1 2>; + }; + }; + }; + + panel@0 { + reg = <0>; + compatible = "raspberrypi,dsi-7inch", "ilitek,ili9881c"; + power-supply = <&vcc_lcd_reg>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi0port1_out>; + }; + }; + }; + }; ... diff --git a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml index 9ef587d46506..20c7e0a77802 100644 --- a/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml +++ b/Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml @@ -27,7 +27,9 @@ properties: - const: adi,adv7123 - enum: - adi,adv7123 + - asl-tek,cs5263 - dumb-vga-dac + - parade,ps185hdm - radxa,ra620 - realtek,rtd2171 - ti,opa362 diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pai.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pai.yaml new file mode 100644 index 000000000000..4f99682a308d --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx8mp-hdmi-pai.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/imx/fsl,imx8mp-hdmi-pai.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8MP HDMI Parallel Audio Interface + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +description: + The HDMI TX Parallel Audio Interface (HTX_PAI) is a bridge between the + Audio Subsystem to the HDMI TX Controller. + +properties: + compatible: + const: fsl,imx8mp-hdmi-pai + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: apb + + power-domains: + maxItems: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + description: Output to the HDMI TX controller. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mp-clock.h> + #include <dt-bindings/power/imx8mp-power.h> + + audio-bridge@32fc4800 { + compatible = "fsl,imx8mp-hdmi-pai"; + reg = <0x32fc4800 0x800>; + interrupt-parent = <&irqsteer_hdmi>; + interrupts = <14>; + clocks = <&clk IMX8MP_CLK_HDMI_APB>; + clock-names = "apb"; + power-domains = <&hdmi_blk_ctrl IMX8MP_HDMIBLK_PD_PAI>; + + port { + pai_to_hdmi_tx: endpoint { + remote-endpoint = <&hdmi_tx_from_pai>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index aeb4e4f36044..ebda78db87a6 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -18,6 +18,7 @@ properties: compatible: oneOf: - enum: + - qcom,glymur-dp - qcom,sa8775p-dp - qcom,sc7180-dp - qcom,sc7280-dp @@ -33,6 +34,11 @@ properties: - items: - enum: + - qcom,qcs8300-dp + - const: qcom,sa8775p-dp + + - items: + - enum: - qcom,sm6350-dp - const: qcom,sc7180-dp @@ -55,6 +61,12 @@ properties: - items: - enum: + - qcom,sm6150-dp + - const: qcom,sm8150-dp + - const: qcom,sm8350-dp + + - items: + - enum: - qcom,sm8750-dp - const: qcom,sm8650-dp @@ -195,9 +207,11 @@ allOf: compatible: contains: enum: + - qcom,glymur-dp - qcom,sa8775p-dp - qcom,x1e80100-dp then: + $ref: /schemas/sound/dai-common.yaml# oneOf: - required: - aux-bus @@ -239,6 +253,7 @@ allOf: enum: # these platforms support 2 streams MST on some interfaces, # others are SST only + - qcom,glymur-dp - qcom,sc8280xp-dp - qcom,x1e80100-dp then: @@ -295,7 +310,7 @@ allOf: minItems: 6 maxItems: 8 -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml index afc187935744..e32056ae0f5d 100644 --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml @@ -21,7 +21,7 @@ properties: compatible: oneOf: - items: - - pattern: '^qcom,adreno-gmu-[67][0-9][0-9]\.[0-9]$' + - pattern: '^qcom,adreno-gmu-[6-8][0-9][0-9]\.[0-9]$' - const: qcom,adreno-gmu - items: - pattern: '^qcom,adreno-gmu-x[1-9][0-9][0-9]\.[0-9]$' @@ -303,6 +303,64 @@ allOf: properties: compatible: contains: + const: qcom,adreno-gmu-840.1 + then: + properties: + reg: + items: + - description: Core GMU registers + reg-names: + items: + - const: gmu + clocks: + items: + - description: GPU AHB clock + - description: GMU clock + - description: GPU CX clock + - description: GPU MEMNOC clock + - description: GMU HUB clock + clock-names: + items: + - const: ahb + - const: gmu + - const: cxo + - const: memnoc + - const: hub + + - if: + properties: + compatible: + contains: + const: qcom,adreno-gmu-x285.1 + then: + properties: + reg: + items: + - description: Core GMU registers + reg-names: + items: + - const: gmu + clocks: + items: + - description: GPU AHB clock + - description: GMU clock + - description: GPU CX clock + - description: GPU MEMNOC clock + - description: GMU HUB clock + - description: GMU RSCC HUB clock + clock-names: + items: + - const: ahb + - const: gmu + - const: cxo + - const: memnoc + - const: hub + - const: rscc + + - if: + properties: + compatible: + contains: const: qcom,adreno-gmu-wrapper then: properties: diff --git a/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml new file mode 100644 index 000000000000..2329ed96e6cb --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,glymur-mdss.yaml @@ -0,0 +1,264 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,glymur-mdss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Glymur Display MDSS + +maintainers: + - Abel Vesa <abel.vesa@linaro.org> + +description: + Glymur MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like + DPU display controller, DP interfaces, etc. + +$ref: /schemas/display/msm/mdss-common.yaml# + +properties: + compatible: + const: qcom,glymur-mdss + + clocks: + items: + - description: Display AHB + - description: Display hf AXI + - description: Display core + + iommus: + maxItems: 1 + + interconnects: + items: + - description: Interconnect path from mdp0 port to the data bus + - description: Interconnect path from CPU to the reg bus + + interconnect-names: + items: + - const: mdp0-mem + - const: cpu-cfg + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + const: qcom,glymur-dpu + + "^displayport-controller@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + const: qcom,glymur-dp + + "^phy@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + const: qcom,glymur-dp-phy + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interconnect/qcom,glymur-rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/phy/phy-qcom-qmp.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + + display-subsystem@ae00000 { + compatible = "qcom,glymur-mdss"; + reg = <0x0ae00000 0x1000>; + reg-names = "mdss"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + + clocks = <&dispcc_ahb_clk>, + <&gcc_disp_hf_axi_clk>, + <&dispcc_mdp_clk>; + clock-names = "bus", "nrt_bus", "core"; + + interconnects = <&mmss_noc MASTER_MDP QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, + <&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY + &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>; + interconnect-names = "mdp0-mem", + "cpu-cfg"; + + resets = <&disp_cc_mdss_core_bcr>; + + power-domains = <&mdss_gdsc>; + + iommus = <&apps_smmu 0x1c00 0x2>; + + interrupt-controller; + #interrupt-cells = <1>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,glymur-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc_axi_clk>, + <&dispcc_ahb_clk>, + <&dispcc_mdp_lut_clk>, + <&dispcc_mdp_clk>, + <&dispcc_mdp_vsync_clk>; + clock-names = "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + + assigned-clocks = <&dispcc_mdp_vsync_clk>; + assigned-clock-rates = <19200000>; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd RPMHPD_MMCX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf2_out: endpoint { + remote-endpoint = <&dsi1_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-325000000 { + opp-hz = /bits/ 64 <325000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-375000000 { + opp-hz = /bits/ 64 <375000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-514000000 { + opp-hz = /bits/ 64 <514000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; + + displayport-controller@ae90000 { + compatible = "qcom,glymur-dp"; + reg = <0xae90000 0x200>, + <0xae90200 0x200>, + <0xae90400 0x600>, + <0xae91000 0x400>, + <0xae91400 0x400>; + + interrupt-parent = <&mdss>; + interrupts = <12>; + + clocks = <&dispcc_mdss_ahb_clk>, + <&dispcc_dptx0_aux_clk>, + <&dispcc_dptx0_link_clk>, + <&dispcc_dptx0_link_intf_clk>, + <&dispcc_dptx0_pixel0_clk>, + <&dispcc_dptx0_pixel1_clk>; + clock-names = "core_iface", + "core_aux", + "ctrl_link", + "ctrl_link_iface", + "stream_pixel", + "stream_1_pixel"; + + assigned-clocks = <&dispcc_mdss_dptx0_link_clk_src>, + <&dispcc_mdss_dptx0_pixel0_clk_src>, + <&dispcc_mdss_dptx0_pixel1_clk_src>; + assigned-clock-parents = <&usb_1_ss0_qmpphy QMP_USB43DP_DP_LINK_CLK>, + <&usb_1_ss0_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>, + <&usb_1_ss0_qmpphy QMP_USB43DP_DP_VCO_DIV_CLK>; + + operating-points-v2 = <&mdss_dp0_opp_table>; + + power-domains = <&rpmhpd RPMHPD_MMCX>; + + phys = <&usb_1_ss0_qmpphy QMP_USB43DP_DP_PHY>; + phy-names = "dp"; + + #sound-dai-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mdss_dp0_in: endpoint { + remote-endpoint = <&mdss_intf0_out>; + }; + }; + + port@1 { + reg = <1>; + + mdss_dp0_out: endpoint { + }; + }; + }; + + mdss_dp0_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-160000000 { + opp-hz = /bits/ 64 <160000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-270000000 { + opp-hz = /bits/ 64 <270000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-540000000 { + opp-hz = /bits/ 64 <540000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-810000000 { + opp-hz = /bits/ 64 <810000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/qcom,qcs8300-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,qcs8300-mdss.yaml new file mode 100644 index 000000000000..e96baaae9ba9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/qcom,qcs8300-mdss.yaml @@ -0,0 +1,286 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/qcom,qcs8300-mdss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. QCS8300 Display MDSS + +maintainers: + - Yongxing Mou <yongxing.mou@oss.qualcomm.com> + +description: + QCS8300 MSM Mobile Display Subsystem(MDSS), which encapsulates sub-blocks like + DPU display controller, DP interfaces and EDP etc. + +$ref: /schemas/display/msm/mdss-common.yaml# + +properties: + compatible: + const: qcom,qcs8300-mdss + + clocks: + items: + - description: Display AHB + - description: Display hf AXI + - description: Display core + + iommus: + maxItems: 1 + + interconnects: + maxItems: 3 + + interconnect-names: + maxItems: 3 + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + additionalProperties: true + + properties: + compatible: + contains: + const: qcom,qcs8300-dpu + + "^displayport-controller@[0-9a-f]+$": + type: object + additionalProperties: true + + properties: + compatible: + contains: + const: qcom,qcs8300-dp + + "^phy@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + contains: + const: qcom,qcs8300-edp-phy + +required: + - compatible + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interconnect/qcom,icc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,qcs8300-gcc.h> + #include <dt-bindings/clock/qcom,sa8775p-dispcc.h> + #include <dt-bindings/interconnect/qcom,qcs8300-rpmh.h> + #include <dt-bindings/power/qcom,rpmhpd.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + mdss: display-subsystem@ae00000 { + compatible = "qcom,qcs8300-mdss"; + reg = <0x0ae00000 0x1000>; + reg-names = "mdss"; + + interconnects = <&mmss_noc MASTER_MDP0 QCOM_ICC_TAG_ACTIVE_ONLY + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>, + <&mmss_noc MASTER_MDP1 QCOM_ICC_TAG_ACTIVE_ONLY + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ACTIVE_ONLY>, + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY + &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ACTIVE_ONLY>; + interconnect-names = "mdp0-mem", + "mdp1-mem", + "cpu-cfg"; + + resets = <&dispcc_core_bcr>; + power-domains = <&dispcc_gdsc>; + + clocks = <&dispcc_ahb_clk>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc_mdp_clk>; + + interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + iommus = <&apps_smmu 0x1000 0x402>; + + #address-cells = <1>; + #size-cells = <1>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,qcs8300-dpu", "qcom,sa8775p-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_MDP_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + + assigned-clocks = <&dispcc0 MDSS_DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates = <19200000>; + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd RPMHPD_MMCX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + + dpu_intf0_out: endpoint { + remote-endpoint = <&mdss_dp0_in>; + }; + }; + }; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-375000000 { + opp-hz = /bits/ 64 <375000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-500000000 { + opp-hz = /bits/ 64 <500000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + + opp-575000000 { + opp-hz = /bits/ 64 <575000000>; + required-opps = <&rpmhpd_opp_turbo>; + }; + + opp-650000000 { + opp-hz = /bits/ 64 <650000000>; + required-opps = <&rpmhpd_opp_turbo_l1>; + }; + }; + }; + + mdss_dp0_phy: phy@aec2a00 { + compatible = "qcom,qcs8300-edp-phy", "qcom,sa8775p-edp-phy"; + + reg = <0x0aec2a00 0x200>, + <0x0aec2200 0xd0>, + <0x0aec2600 0xd0>, + <0x0aec2000 0x1c8>; + + clocks = <&dispcc MDSS_DISP_CC_MDSS_DPTX0_AUX_CLK>, + <&dispcc MDSS_DISP_CC_MDSS_AHB_CLK>; + clock-names = "aux", + "cfg_ahb"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdda-phy-supply = <&vreg_l1c>; + vdda-pll-supply = <&vreg_l4a>; + }; + + displayport-controller@af54000 { + compatible = "qcom,qcs8300-dp", "qcom,sa8775p-dp"; + + pinctrl-0 = <&dp_hot_plug_det>; + pinctrl-names = "default"; + + reg = <0xaf54000 0x104>, + <0xaf54200 0x0c0>, + <0xaf55000 0x770>, + <0xaf56000 0x09c>, + <0xaf57000 0x09c>, + <0xaf58000 0x09c>, + <0xaf59000 0x09c>, + <0xaf5a000 0x23c>, + <0xaf5b000 0x23c>; + + interrupt-parent = <&mdss>; + interrupts = <12>; + clocks = <&dispcc0 MDSS_DISP_CC_MDSS_AHB_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_AUX_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_LINK_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_LINK_INTF_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL0_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL1_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL2_CLK>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL3_CLK>; + clock-names = "core_iface", + "core_aux", + "ctrl_link", + "ctrl_link_iface", + "stream_pixel", + "stream_1_pixel", + "stream_2_pixel", + "stream_3_pixel"; + assigned-clocks = <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_LINK_CLK_SRC>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL0_CLK_SRC>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL1_CLK_SRC>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL2_CLK_SRC>, + <&dispcc0 MDSS_DISP_CC_MDSS_DPTX0_PIXEL3_CLK_SRC>; + assigned-clock-parents = <&mdss_dp0_phy 0>, + <&mdss_dp0_phy 1>, + <&mdss_dp0_phy 1>, + <&mdss_dp0_phy 1>; + phys = <&mdss_dp0_phy>; + phy-names = "dp"; + operating-points-v2 = <&dp_opp_table>; + power-domains = <&rpmhpd RPMHPD_MMCX>; + + #sound-dai-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + mdss_dp0_in: endpoint { + remote-endpoint = <&dpu_intf0_out>; + }; + }; + + port@1 { + reg = <1>; + + mdss_dp_out: endpoint { }; + }; + }; + + dp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-160000000 { + opp-hz = /bits/ 64 <160000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-270000000 { + opp-hz = /bits/ 64 <270000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-540000000 { + opp-hz = /bits/ 64 <540000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-810000000 { + opp-hz = /bits/ 64 <810000000>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml index 9ac24f99d3ad..46e9335f849f 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm6150-mdss.yaml @@ -51,6 +51,14 @@ patternProperties: compatible: const: qcom,sm6150-dpu + "^displayport-controller@[0-9a-f]+$": + type: object + additionalProperties: true + properties: + compatible: + contains: + const: qcom,sm6150-dp + "^dsi@[0-9a-f]+$": type: object additionalProperties: true @@ -130,35 +138,37 @@ examples: #size-cells = <0>; port@0 { - reg = <0>; - dpu_intf0_out: endpoint { - }; + reg = <0>; + + dpu_intf0_out: endpoint { + }; }; port@1 { - reg = <1>; - dpu_intf1_out: endpoint { - remote-endpoint = <&mdss_dsi0_in>; - }; + reg = <1>; + + dpu_intf1_out: endpoint { + remote-endpoint = <&mdss_dsi0_in>; + }; }; }; mdp_opp_table: opp-table { compatible = "operating-points-v2"; - opp-19200000 { - opp-hz = /bits/ 64 <19200000>; - required-opps = <&rpmhpd_opp_low_svs>; + opp-192000000 { + opp-hz = /bits/ 64 <192000000>; + required-opps = <&rpmhpd_opp_low_svs>; }; - opp-25600000 { - opp-hz = /bits/ 64 <25600000>; - required-opps = <&rpmhpd_opp_svs>; + opp-256000000 { + opp-hz = /bits/ 64 <256000000>; + required-opps = <&rpmhpd_opp_svs>; }; opp-307200000 { - opp-hz = /bits/ 64 <307200000>; - required-opps = <&rpmhpd_opp_nom>; + opp-hz = /bits/ 64 <307200000>; + required-opps = <&rpmhpd_opp_nom>; }; }; }; diff --git a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml index 0a46120dd868..fe296e3186d0 100644 --- a/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml @@ -13,11 +13,17 @@ $ref: /schemas/display/msm/dpu-common.yaml# properties: compatible: - enum: - - qcom,sa8775p-dpu - - qcom,sm8650-dpu - - qcom,sm8750-dpu - - qcom,x1e80100-dpu + oneOf: + - enum: + - qcom,glymur-dpu + - qcom,sa8775p-dpu + - qcom,sm8650-dpu + - qcom,sm8750-dpu + - qcom,x1e80100-dpu + - items: + - enum: + - qcom,qcs8300-dpu + - const: qcom,sa8775p-dpu reg: items: diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,il79900a.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,il79900a.yaml new file mode 100644 index 000000000000..02f7fb1f16dc --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ilitek,il79900a.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/ilitek,il79900a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Ilitek IL79900a based MIPI-DSI panels + +maintainers: + - Langyan Ye <yelangyan@huaqin.corp-partner.google.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + - tianma,tl121bvms07-00 + - const: ilitek,il79900a + + reg: + maxItems: 1 + description: DSI virtual channel used by the panel + + enable-gpios: + maxItems: 1 + description: GPIO specifier for the enable pin + + avdd-supply: + description: Positive analog voltage supply (AVDD) + + avee-supply: + description: Negative analog voltage supply (AVEE) + + pp1800-supply: + description: 1.8V logic voltage supply + + backlight: true + +required: + - compatible + - reg + - enable-gpios + - avdd-supply + - avee-supply + - pp1800-supply + +additionalProperties: false + +examples: + - | + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "tianma,tl121bvms07-00", "ilitek,il79900a"; + reg = <0>; + enable-gpios = <&pio 25 0>; + avdd-supply = <®_avdd>; + avee-supply = <®_avee>; + pp1800-supply = <®_pp1800>; + backlight = <&backlight>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index 434cc6af9c95..d979701a00a8 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -20,9 +20,11 @@ properties: - bananapi,lhr050h41 - bestar,bsd1218-a101kl68 - feixin,k101-im2byl02 + - raspberrypi,dsi-5inch - raspberrypi,dsi-7inch - startek,kd050hdfia020 - tdo,tl050hdv35 + - wanchanglong,w552946aaa - wanchanglong,w552946aba - const: ilitek,ili9881c @@ -30,6 +32,7 @@ properties: maxItems: 1 backlight: true + port: true power-supply: true reset-gpios: true rotation: true diff --git a/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.yaml b/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.yaml new file mode 100644 index 000000000000..0f0b9079f199 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/lg,ld070wx3-sl01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LG Corporation 7" WXGA TFT LCD panel + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - const: lg,ld070wx3-sl01 + + reg: + maxItems: 1 + + vdd-supply: true + vcc-supply: true + + backlight: true + port: true + +required: + - compatible + - vdd-supply + - vcc-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "lg,ld070wx3-sl01"; + reg = <0>; + + vdd-supply = <&vdd_3v3_lcd>; + vcc-supply = <&vcc_1v8_lcd>; + + backlight = <&backlight>; + + port { + endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml index 4388d5375851..dbc01e640895 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -59,6 +59,8 @@ properties: # Jenson Display BL-JT60050-01A 7" WSVGA (1024x600) color TFT LCD LVDS panel - jenson,bl-jt60050-01a - tbs,a711-panel + # Winstar WF70A8SYJHLNGA 7" WSVGA (1024x600) color TFT LCD LVDS panel + - winstar,wf70a8syjhlnga - const: panel-lvds diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 9b92a05791cc..8d668979b62d 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -19,6 +19,9 @@ description: | If the panel is more advanced a dedicated binding file is required. +allOf: + - $ref: panel-common.yaml# + properties: compatible: @@ -42,8 +45,6 @@ properties: - kingdisplay,kd097d04 # LG ACX467AKM-7 4.95" 1080×1920 LCD Panel - lg,acx467akm-7 - # LG Corporation 7" WXGA TFT LCD panel - - lg,ld070wx3-sl01 # LG Corporation 5" HD TFT LCD panel - lg,lh500wx1-sd03 # Lincoln LCD197 5" 1080x1920 LCD panel @@ -56,10 +57,6 @@ properties: - panasonic,vvx10f034n00 # Samsung s6e3fa7 1080x2220 based AMS559NK06 AMOLED panel - samsung,s6e3fa7-ams559nk06 - # Samsung s6e3fc2x01 1080x2340 AMOLED panel - - samsung,s6e3fc2x01 - # Samsung sofef00 1080x2280 AMOLED panel - - samsung,sofef00 # Shangai Top Display Optoelectronics 7" TL070WSH30 1024x600 TFT LCD panel - tdo,tl070wsh30 @@ -72,31 +69,12 @@ properties: reset-gpios: true port: true power-supply: true - vddio-supply: true - -allOf: - - $ref: panel-common.yaml# - - if: - properties: - compatible: - enum: - - samsung,s6e3fc2x01 - - samsung,sofef00 - then: - properties: - power-supply: false - required: - - vddio-supply - else: - properties: - vddio-supply: false - required: - - power-supply additionalProperties: false required: - compatible + - power-supply - reg examples: diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 2017428d8828..24e277b19094 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -184,6 +184,8 @@ properties: - innolux,n156bge-l21 # Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel - innolux,zj070na-01p + # JuTouch Technology Co.. 10" JT101TM023 WXGA (1280 x 800) LVDS panel + - jutouch,jt101tm023 # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel - koe,tx14d24vm1bpa # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel @@ -268,6 +270,8 @@ properties: - qiaodian,qd43003c0-40 # Shenzhen QiShenglong Industrialist Co., Ltd. Gopher 2b 4.3" 480(RGB)x272 TFT LCD panel - qishenglong,gopher2b-lcd + # Raystar Optronics, Inc. RFF500F-AWH-DNN 5.0" TFT 840x480 + - raystar,rff500f-awh-dnn # Rocktech Displays Ltd. RK101II01D-CT 10.1" TFT 1280x800 - rocktech,rk101ii01d-ct # Rocktech Display Ltd. RK070ER9427 800(RGB)x480 TFT LCD panel @@ -276,6 +280,8 @@ properties: - rocktech,rk043fn48h # Samsung Electronics 10.1" WXGA (1280x800) TFT LCD panel - samsung,ltl101al01 + # Samsung Electronics 10.6" FWXGA (1366x768) TFT LCD panel + - samsung,ltl106al01 # Samsung Electronics 10.1" WSVGA TFT LCD panel - samsung,ltn101nt05 # Satoz SAT050AT40H12R2 5.0" WVGA TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml index 04f86e0cbac9..694037301583 100644 --- a/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml +++ b/Documentation/devicetree/bindings/display/panel/ronbo,rb070d30.yaml @@ -9,6 +9,9 @@ title: Ronbo RB070D30 DSI Display Panel maintainers: - Maxime Ripard <mripard@kernel.org> +allOf: + - $ref: panel-common.yaml# + properties: compatible: const: ronbo,rb070d30 @@ -20,10 +23,6 @@ properties: description: GPIO used for the power pin maxItems: 1 - reset-gpios: - description: GPIO used for the reset pin - maxItems: 1 - shlr-gpios: description: GPIO used for the shlr pin (horizontal flip) maxItems: 1 @@ -35,10 +34,6 @@ properties: vcc-lcd-supply: description: Power regulator - backlight: - description: Backlight used by the panel - $ref: /schemas/types.yaml#/definitions/phandle - required: - compatible - power-gpios @@ -47,5 +42,6 @@ required: - shlr-gpios - updn-gpios - vcc-lcd-supply + - port -additionalProperties: false +unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml index ccb574caed28..f1723e910252 100644 --- a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml +++ b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml @@ -33,6 +33,8 @@ properties: - samsung,atna45dc02 # Samsung 15.6" 3K (2880x1620 pixels) eDP AMOLED panel - samsung,atna56ac03 + # Samsung 16.0" 3K (2880x1800 pixels) eDP AMOLED panel + - samsung,atna60cl08 - const: samsung,atna33xc20 enable-gpios: true diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e3fc2x01.yaml b/Documentation/devicetree/bindings/display/panel/samsung,s6e3fc2x01.yaml new file mode 100644 index 000000000000..d48354fb52ea --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3fc2x01.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,s6e3fc2x01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S6E3FC2X01 AMOLED DDIC + +description: The S6E3FC2X01 is display driver IC with connected panel. + +maintainers: + - David Heidelberg <david@ixit.cz> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + # Samsung 6.41 inch, 1080x2340 pixels, 19.5:9 ratio + - samsung,s6e3fc2x01-ams641rw + - const: samsung,s6e3fc2x01 + + reg: + maxItems: 1 + + reset-gpios: true + + port: true + + vddio-supply: + description: VDD regulator + + vci-supply: + description: VCI regulator + + poc-supply: + description: POC regulator + +required: + - compatible + - reset-gpios + - vddio-supply + - vci-supply + - poc-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,s6e3fc2x01-ams641rw", "samsung,s6e3fc2x01"; + reg = <0>; + + vddio-supply = <&vreg_l14a_1p88>; + vci-supply = <&s2dos05_buck1>; + poc-supply = <&s2dos05_ldo1>; + + te-gpios = <&tlmm 10 GPIO_ACTIVE_HIGH>; + reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>; + + pinctrl-0 = <&sde_dsi_active &sde_te_active_sleep>; + pinctrl-1 = <&sde_dsi_suspend &sde_te_active_sleep>; + pinctrl-names = "default", "sleep"; + + port { + panel_in: endpoint { + remote-endpoint = <&mdss_dsi0_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/samsung,sofef00.yaml b/Documentation/devicetree/bindings/display/panel/samsung,sofef00.yaml new file mode 100644 index 000000000000..eeee3cac72e3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,sofef00.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,sofef00.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SOFEF00 AMOLED DDIC + +description: The SOFEF00 is display driver IC with connected panel. + +maintainers: + - David Heidelberg <david@ixit.cz> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + # Samsung 6.01 inch, 1080x2160 pixels, 18:9 ratio + - samsung,sofef00-ams601nt22 + # Samsung 6.28 inch, 1080x2280 pixels, 19:9 ratio + - samsung,sofef00-ams628nw01 + - const: samsung,sofef00 + + reg: + maxItems: 1 + + poc-supply: + description: POC regulator + + vci-supply: + description: VCI regulator + + vddio-supply: + description: VDD regulator + +required: + - compatible + - reset-gpios + - poc-supply + - vci-supply + - vddio-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "samsung,sofef00-ams628nw01", "samsung,sofef00"; + reg = <0>; + + vddio-supply = <&vreg_l14a_1p88>; + vci-supply = <&s2dos05_buck1>; + poc-supply = <&s2dos05_ldo1>; + + te-gpios = <&tlmm 10 GPIO_ACTIVE_HIGH>; + reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>; + + pinctrl-0 = <&panel_active>; + pinctrl-1 = <&panel_suspend>; + pinctrl-names = "default", "sleep"; + + port { + panel_in: endpoint { + remote-endpoint = <&mdss_dsi0_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq079l1sx01.yaml b/Documentation/devicetree/bindings/display/panel/sharp,lq079l1sx01.yaml new file mode 100644 index 000000000000..08a35ebbbb3c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq079l1sx01.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/sharp,lq079l1sx01.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sharp Microelectronics 7.9" WQXGA TFT LCD panel + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +description: > + This panel requires a dual-channel DSI host to operate and it supports + only left-right split mode, where each channel drives the left or right + half of the screen and only video mode. + + Each of the DSI channels controls a separate DSI peripheral. + The peripheral driven by the first link (DSI-LINK1), left one, is + considered the primary peripheral and controls the device. + +allOf: + - $ref: panel-common-dual.yaml# + +properties: + compatible: + const: sharp,lq079l1sx01 + + reg: + maxItems: 1 + + avdd-supply: + description: regulator that supplies the analog voltage + + vddio-supply: + description: regulator that supplies the I/O voltage + + vsp-supply: + description: positive boost supply regulator + + vsn-supply: + description: negative boost supply regulator + + reset-gpios: + maxItems: 1 + + backlight: true + ports: true + +required: + - compatible + - reg + - avdd-supply + - vddio-supply + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "sharp,lq079l1sx01"; + reg = <0>; + + reset-gpios = <&gpio 59 GPIO_ACTIVE_LOW>; + + avdd-supply = <&avdd_lcd>; + vddio-supply = <&vdd_lcd_io>; + vsp-supply = <&vsp_5v5_lcd>; + vsn-supply = <&vsn_5v5_lcd>; + + backlight = <&backlight>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + panel_in0: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + + port@1 { + reg = <1>; + panel_in1: endpoint { + remote-endpoint = <&dsi1_out>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/panel/synaptics,td4300-panel.yaml b/Documentation/devicetree/bindings/display/panel/synaptics,td4300-panel.yaml new file mode 100644 index 000000000000..152d94367130 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/synaptics,td4300-panel.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/synaptics,td4300-panel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synaptics TDDI Display Panel Controller + +maintainers: + - Kaustabh Chakraborty <kauschluss@disroot.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + enum: + - syna,td4101-panel + - syna,td4300-panel + + reg: + maxItems: 1 + + vio-supply: + description: core I/O voltage supply + + vsn-supply: + description: negative voltage supply for analog circuits + + vsp-supply: + description: positive voltage supply for analog circuits + + backlight-gpios: + maxItems: 1 + description: backlight enable GPIO + + reset-gpios: true + width-mm: true + height-mm: true + panel-timing: true + +required: + - compatible + - reg + - width-mm + - height-mm + - panel-timing + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + dsi { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "syna,td4300-panel"; + reg = <0>; + + vio-supply = <&panel_vio_reg>; + vsn-supply = <&panel_vsn_reg>; + vsp-supply = <&panel_vsp_reg>; + + backlight-gpios = <&gpd3 5 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpd3 4 GPIO_ACTIVE_LOW>; + + width-mm = <68>; + height-mm = <121>; + + panel-timing { + clock-frequency = <144389520>; + + hactive = <1080>; + hsync-len = <4>; + hfront-porch = <120>; + hback-porch = <32>; + + vactive = <1920>; + vsync-len = <2>; + vfront-porch = <21>; + vback-porch = <4>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml index 1e32d14b6edb..2cc66dcef870 100644 --- a/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,rzg2l-du.yaml @@ -25,6 +25,9 @@ properties: - enum: - renesas,r9a07g054-du # RZ/V2L - const: renesas,r9a07g044-du # RZ/G2L fallback + - items: + - const: renesas,r9a09g056-du # RZ/V2N + - const: renesas,r9a09g057-du # RZ/V2H(P) fallback reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml index c59df3c1a3f7..632b48bfabb9 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-mipi-dsi.yaml @@ -17,6 +17,7 @@ properties: - rockchip,px30-mipi-dsi - rockchip,rk3128-mipi-dsi - rockchip,rk3288-mipi-dsi + - rockchip,rk3368-mipi-dsi - rockchip,rk3399-mipi-dsi - rockchip,rk3568-mipi-dsi - rockchip,rv1126-mipi-dsi @@ -73,6 +74,7 @@ allOf: enum: - rockchip,px30-mipi-dsi - rockchip,rk3128-mipi-dsi + - rockchip,rk3368-mipi-dsi - rockchip,rk3568-mipi-dsi - rockchip,rv1126-mipi-dsi diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml index 96b4b088eebe..d649808c59da 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml @@ -113,6 +113,14 @@ properties: description: Additional HDMI QP related data is accessed through VO GRF regs. + frl-enable-gpios: + description: + Optional GPIO line to be asserted when operating in HDMI 2.1 FRL mode and + deasserted for HDMI 1.4/2.0 TMDS. It can be used to control external + voltage bias for HDMI data lines. When not present the HDMI encoder will + operate in TMDS mode only. + maxItems: 1 + required: - compatible - reg @@ -132,8 +140,10 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/clock/rockchip,rk3588-cru.h> + #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/pinctrl/rockchip.h> #include <dt-bindings/power/rk3588-power.h> #include <dt-bindings/reset/rockchip,rk3588-cru.h> @@ -164,6 +174,7 @@ examples: rockchip,grf = <&sys_grf>; rockchip,vo-grf = <&vo1_grf>; #sound-dai-cells = <0>; + frl-enable-gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_LOW>; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml index a5b4e0021758..bee9faf1d3f8 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml @@ -18,6 +18,8 @@ properties: oneOf: - items: - enum: + - mediatek,mt8196-mali + - nxp,imx95-mali # G310 - rockchip,rk3588-mali - const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable @@ -44,7 +46,9 @@ properties: minItems: 1 items: - const: core - - const: coregroup + - enum: + - coregroup + - stacks - const: stacks mali-supply: true @@ -91,7 +95,6 @@ required: - interrupts - interrupt-names - clocks - - mali-supply additionalProperties: false @@ -108,6 +111,29 @@ allOf: power-domains: maxItems: 1 power-domain-names: false + required: + - mali-supply + - if: + properties: + compatible: + contains: + const: mediatek,mt8196-mali + then: + properties: + mali-supply: false + sram-supply: false + operating-points-v2: false + power-domains: + maxItems: 1 + power-domain-names: false + clocks: + maxItems: 2 + clock-names: + items: + - const: core + - const: stacks + required: + - power-domains examples: - | @@ -143,5 +169,17 @@ examples: }; }; }; + - | + gpu@48000000 { + compatible = "mediatek,mt8196-mali", "arm,mali-valhall-csf"; + reg = <0x48000000 0x480000>; + clocks = <&gpufreq 0>, <&gpufreq 1>; + clock-names = "core", "stacks"; + interrupts = <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH 0>, + <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH 0>; + interrupt-names = "job", "mmu", "gpu"; + power-domains = <&gpufreq>; + }; ... diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml index c87d7bece0ec..225a6e1b7fcd 100644 --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml @@ -15,6 +15,16 @@ properties: oneOf: - items: - enum: + - renesas,r8a7796-gpu + - renesas,r8a77961-gpu + - const: img,img-gx6250 + - const: img,img-rogue + - items: + - const: renesas,r8a77965-gpu + - const: img,img-ge7800 + - const: img,img-rogue + - items: + - enum: - ti,am62-gpu - const: img,img-axe-1-16m # This deprecated element must be kept around to allow old kernels to @@ -86,48 +96,56 @@ allOf: properties: compatible: contains: - const: img,img-axe-1-16m + enum: + - ti,am62-gpu + - ti,j721s2-gpu then: properties: - power-domains: - items: - - description: Power domain A - power-domain-names: + clocks: maxItems: 1 - required: - - power-domains - - power-domain-names - if: properties: compatible: contains: - const: thead,th1520-gpu + enum: + - img,img-ge7800 + - img,img-gx6250 + - thead,th1520-gpu then: properties: clocks: minItems: 3 clock-names: minItems: 3 + + - if: + properties: + compatible: + contains: + const: img,img-axe-1-16m + then: + properties: power-domains: - items: - - description: The single, unified power domain for the GPU on the - TH1520 SoC, integrating all internal IP power domains. - power-domain-names: false + maxItems: 1 + power-domain-names: + maxItems: 1 required: - power-domains + - power-domain-names - if: properties: compatible: contains: - const: img,img-bxs-4-64 + enum: + - img,img-bxs-4-64 + - img,img-ge7800 + - img,img-gx6250 then: properties: power-domains: - items: - - description: Power domain A - - description: Power domain B + minItems: 2 power-domain-names: minItems: 2 required: @@ -138,13 +156,16 @@ allOf: properties: compatible: contains: - enum: - - ti,am62-gpu - - ti,j721s2-gpu + const: thead,th1520-gpu then: properties: - clocks: - maxItems: 1 + power-domains: + items: + - description: The single, unified power domain for the GPU on the + TH1520 SoC, integrating all internal IP power domains. + power-domain-names: false + required: + - power-domains examples: - | diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 89495f094d52..c9efdd1a6d1c 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -89,6 +89,8 @@ properties: - description: Qcom Adreno GPUs implementing "qcom,smmu-500" and "arm,mmu-500" items: - enum: + - qcom,glymur-smmu-500 + - qcom,kaanapali-smmu-500 - qcom,milos-smmu-500 - qcom,qcm2290-smmu-500 - qcom,qcs615-smmu-500 diff --git a/Documentation/devicetree/bindings/media/arm,mali-c55.yaml b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml new file mode 100644 index 000000000000..fc4fcd19922a --- /dev/null +++ b/Documentation/devicetree/bindings/media/arm,mali-c55.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/arm,mali-c55.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Mali-C55 Image Signal Processor + +maintainers: + - Daniel Scally <dan.scally@ideasonboard.com> + - Jacopo Mondi <jacopo.mondi@ideasonboard.com> + +properties: + compatible: + const: arm,mali-c55 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: ISP Video Clock + - description: ISP AXI clock + - description: ISP AHB-lite clock + + clock-names: + items: + - const: vclk + - const: aclk + - const: hclk + + resets: + items: + - description: vclk domain reset + - description: aclk domain reset + - description: hclk domain reset + + reset-names: + items: + - const: vresetn + - const: aresetn + - const: hresetn + + port: + $ref: /schemas/graph.yaml#/properties/port + description: Input parallel video bus + + properties: + endpoint: + $ref: /schemas/graph.yaml#/properties/endpoint + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - resets + - reset-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + isp@400000 { + compatible = "arm,mali-c55"; + reg = <0x400000 0x200000>; + clocks = <&clk 0>, <&clk 1>, <&clk 2>; + clock-names = "vclk", "aclk", "hclk"; + resets = <&resets 0>, <&resets 1>, <&resets 2>; + reset-names = "vresetn", "aresetn", "hresetn"; + interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>; + + port { + isp_in: endpoint { + remote-endpoint = <&csi2_rx_out>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9719.yaml b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9719.yaml new file mode 100644 index 000000000000..8e8d62436e0d --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/dongwoon,dw9719.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/dongwoon,dw9719.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Dongwoon Anatech DW9719 Voice Coil Motor (VCM) Controller + +maintainers: + - André Apitzsch <git@apitzsch.eu> + +description: + The Dongwoon DW9718S/9719/9761 is a single 10-bit digital-to-analog converter + with 100 mA output current sink capability, designed for linear control of + voice coil motors (VCM) in camera lenses. This chip provides a Smart Actuator + Control (SAC) mode intended for driving voice coil lenses in camera modules. + +properties: + compatible: + enum: + - dongwoon,dw9718s + - dongwoon,dw9719 + - dongwoon,dw9761 + - dongwoon,dw9800k + + reg: + maxItems: 1 + + vdd-supply: + description: VDD power supply + + dongwoon,sac-mode: + description: | + Slew Rate Control mode to use: direct, LSC (Linear Slope Control) or + SAC1-SAC6 (Smart Actuator Control). + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # Direct mode + - 1 # LSC mode + - 2 # SAC1 mode (operation time# 0.32 x Tvib) + - 3 # SAC2 mode (operation time# 0.48 x Tvib) + - 4 # SAC3 mode (operation time# 0.72 x Tvib) + - 5 # SAC4 mode (operation time# 1.20 x Tvib) + - 6 # SAC5 mode (operation time# 1.64 x Tvib) + - 7 # SAC6 mode (operation time# 1.88 x Tvib) + default: 4 + + dongwoon,vcm-prescale: + description: + Indication of VCM switching frequency dividing rate select. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - vdd-supply + +allOf: + - if: + properties: + compatible: + contains: + const: dongwoon,dw9718s + then: + properties: + dongwoon,vcm-prescale: + description: + The final frequency is 10 MHz divided by (value + 2). + maximum: 15 + default: 0 + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + actuator@c { + compatible = "dongwoon,dw9718s"; + reg = <0x0c>; + + vdd-supply = <&pm8937_l17>; + + dongwoon,sac-mode = <4>; + dongwoon,vcm-prescale = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/nxp,tda19971.yaml b/Documentation/devicetree/bindings/media/i2c/nxp,tda19971.yaml new file mode 100644 index 000000000000..477e59316dfa --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/nxp,tda19971.yaml @@ -0,0 +1,162 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/nxp,tda19971.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP TDA1997x HDMI receiver + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: | + The TDA19971/73 are HDMI video receivers. + + The TDA19971 Video port output pins can be used as follows: + - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4] + - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4] + - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4] + - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2] + - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0] + - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles) + - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles) + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles) + + The TDA19973 Video port output pins can be used as follows: + - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0] + - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0] + - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0] + - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles) + + The Video port output pins are mapped via 4-bit 'pin groups' allowing + for a variety of connection possibilities including swapping pin order within + pin groups. The video_portcfg device-tree property consists of register mapping + pairs which map a chip-specific VP output register to a 4-bit pin group. If + the pin group needs to be bit-swapped you can use the *_S pin-group defines. + +properties: + compatible: + enum: + - nxp,tda19971 + - nxp,tda19973 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + DOVDD-supply: true + + DVDD-supply: true + + AVDD-supply: true + + '#sound-dai-cells': + const: 0 + + port: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + nxp,vidout-portcfg: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + minItems: 1 + maxItems: 4 + items: + items: + - description: Video Port control registers index. + maximum: 8 + minimum: 0 + - description: pin(pinswapped) groups + + description: + array of pairs mapping VP output pins to pin groups. + + nxp,audout-format: + enum: + - i2s + - spdif + + nxp,audout-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16, 24, 32] + description: + width of audio output data bus. + + nxp,audout-layout: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: + data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used). + + nxp,audout-mclk-fs: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Multiplication factor between stream rate and codec mclk. + +required: + - compatible + - reg + - interrupts + - DOVDD-supply + - AVDD-supply + - DVDD-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/media/tda1997x.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hdmi-receiver@48 { + compatible = "nxp,tda19971"; + reg = <0x48>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_tda1997x>; + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_LEVEL_LOW>; + DOVDD-supply = <®_3p3v>; + AVDD-supply = <®_1p8v>; + DVDD-supply = <®_1p8v>; + /* audio */ + #sound-dai-cells = <0>; + nxp,audout-format = "i2s"; + nxp,audout-layout = <0>; + nxp,audout-width = <16>; + nxp,audout-mclk-fs = <128>; + /* + * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4] + * and Y[11:4] across 16bits in the same pixclk cycle. + */ + nxp,vidout-portcfg = + /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */ + < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >, + /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */ + < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >, + /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */ + < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >, + /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */ + < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >; + + port { + endpoint { + remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>; + bus-width = <16>; + hsync-active = <1>; + vsync-active = <1>; + data-active = <1>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/nxp,tda1997x.txt b/Documentation/devicetree/bindings/media/i2c/nxp,tda1997x.txt deleted file mode 100644 index e76167999d76..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/nxp,tda1997x.txt +++ /dev/null @@ -1,178 +0,0 @@ -Device-Tree bindings for the NXP TDA1997x HDMI receiver - -The TDA19971/73 are HDMI video receivers. - -The TDA19971 Video port output pins can be used as follows: - - RGB 8bit per color (24 bits total): R[11:4] B[11:4] G[11:4] - - YUV444 8bit per color (24 bits total): Y[11:4] Cr[11:4] Cb[11:4] - - YUV422 semi-planar 8bit per component (16 bits total): Y[11:4] CbCr[11:4] - - YUV422 semi-planar 10bit per component (20 bits total): Y[11:2] CbCr[11:2] - - YUV422 semi-planar 12bit per component (24 bits total): - Y[11:0] CbCr[11:0] - - YUV422 BT656 8bit per component (8 bits total): YCbCr[11:4] (2-cycles) - - YUV422 BT656 10bit per component (10 bits total): YCbCr[11:2] (2-cycles) - - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles) - -The TDA19973 Video port output pins can be used as follows: - - RGB 12bit per color (36 bits total): R[11:0] B[11:0] G[11:0] - - YUV444 12bit per color (36 bits total): Y[11:0] Cb[11:0] Cr[11:0] - - YUV422 semi-planar 12bit per component (24 bits total): Y[11:0] CbCr[11:0] - - YUV422 BT656 12bit per component (12 bits total): YCbCr[11:0] (2-cycles) - -The Video port output pins are mapped via 4-bit 'pin groups' allowing -for a variety of connection possibilities including swapping pin order within -pin groups. The video_portcfg device-tree property consists of register mapping -pairs which map a chip-specific VP output register to a 4-bit pin group. If -the pin group needs to be bit-swapped you can use the *_S pin-group defines. - -Required Properties: - - compatible : - - "nxp,tda19971" for the TDA19971 - - "nxp,tda19973" for the TDA19973 - - reg : I2C slave address - - interrupts : The interrupt number - - DOVDD-supply : Digital I/O supply - - DVDD-supply : Digital Core supply - - AVDD-supply : Analog supply - - nxp,vidout-portcfg : array of pairs mapping VP output pins to pin groups. - -Optional Properties: - - nxp,audout-format : DAI bus format: "i2s" or "spdif". - - nxp,audout-width : width of audio output data bus (1-4). - - nxp,audout-layout : data layout (0=AP0 used, 1=AP0/AP1/AP2/AP3 used). - - nxp,audout-mclk-fs : Multiplication factor between stream rate and codec - mclk. - -The port node shall contain one endpoint child node for its digital -output video port, in accordance with the video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. - -Optional Endpoint Properties: - The following three properties are defined in video-interfaces.txt and - are valid for the output parallel bus endpoint: - - hsync-active: Horizontal synchronization polarity. Defaults to active high. - - vsync-active: Vertical synchronization polarity. Defaults to active high. - - data-active: Data polarity. Defaults to active high. - -Examples: - - VP[15:0] connected to IMX6 CSI_DATA[19:4] for 16bit YUV422 - 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins) - hdmi-receiver@48 { - compatible = "nxp,tda19971"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_tda1997x>; - reg = <0x48>; - interrupt-parent = <&gpio1>; - interrupts = <7 IRQ_TYPE_LEVEL_LOW>; - DOVDD-supply = <®_3p3v>; - AVDD-supply = <®_1p8v>; - DVDD-supply = <®_1p8v>; - /* audio */ - #sound-dai-cells = <0>; - nxp,audout-format = "i2s"; - nxp,audout-layout = <0>; - nxp,audout-width = <16>; - nxp,audout-mclk-fs = <128>; - /* - * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4] - * and Y[11:4] across 16bits in the same pixclk cycle. - */ - nxp,vidout-portcfg = - /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */ - < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >, - /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */ - < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >, - /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */ - < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >, - /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */ - < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >; - - port { - tda1997x_to_ipu1_csi0_mux: endpoint { - remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>; - bus-width = <16>; - hsync-active = <1>; - vsync-active = <1>; - data-active = <1>; - }; - }; - }; - - VP[15:8] connected to IMX6 CSI_DATA[19:12] for 8bit BT656 - 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins) - hdmi-receiver@48 { - compatible = "nxp,tda19971"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_tda1997x>; - reg = <0x48>; - interrupt-parent = <&gpio1>; - interrupts = <7 IRQ_TYPE_LEVEL_LOW>; - DOVDD-supply = <®_3p3v>; - AVDD-supply = <®_1p8v>; - DVDD-supply = <®_1p8v>; - /* audio */ - #sound-dai-cells = <0>; - nxp,audout-format = "i2s"; - nxp,audout-layout = <0>; - nxp,audout-width = <16>; - nxp,audout-mclk-fs = <128>; - /* - * The 8bpp YUV422 semi-planar mode outputs CbCr[11:4] - * and Y[11:4] across 16bits in the same pixclk cycle. - */ - nxp,vidout-portcfg = - /* Y[11:8]<->VP[15:12]<->CSI_DATA[19:16] */ - < TDA1997X_VP24_V15_12 TDA1997X_G_Y_11_8 >, - /* Y[7:4]<->VP[11:08]<->CSI_DATA[15:12] */ - < TDA1997X_VP24_V11_08 TDA1997X_G_Y_7_4 >, - /* CbCc[11:8]<->VP[07:04]<->CSI_DATA[11:8] */ - < TDA1997X_VP24_V07_04 TDA1997X_R_CR_CBCR_11_8 >, - /* CbCr[7:4]<->VP[03:00]<->CSI_DATA[7:4] */ - < TDA1997X_VP24_V03_00 TDA1997X_R_CR_CBCR_7_4 >; - - port { - tda1997x_to_ipu1_csi0_mux: endpoint { - remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>; - bus-width = <16>; - hsync-active = <1>; - vsync-active = <1>; - data-active = <1>; - }; - }; - }; - - VP[15:8] connected to IMX6 CSI_DATA[19:12] for 8bit BT656 - 16bit I2S layout0 with a 128*fs clock (A_WS, AP0, A_CLK pins) - hdmi-receiver@48 { - compatible = "nxp,tda19971"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_tda1997x>; - reg = <0x48>; - interrupt-parent = <&gpio1>; - interrupts = <7 IRQ_TYPE_LEVEL_LOW>; - DOVDD-supply = <®_3p3v>; - AVDD-supply = <®_1p8v>; - DVDD-supply = <®_1p8v>; - /* audio */ - #sound-dai-cells = <0>; - nxp,audout-format = "i2s"; - nxp,audout-layout = <0>; - nxp,audout-width = <16>; - nxp,audout-mclk-fs = <128>; - /* - * The 8bpp BT656 mode outputs YCbCr[11:4] across 8bits over - * 2 pixclk cycles. - */ - nxp,vidout-portcfg = - /* YCbCr[11:8]<->VP[15:12]<->CSI_DATA[19:16] */ - < TDA1997X_VP24_V15_12 TDA1997X_R_CR_CBCR_11_8 >, - /* YCbCr[7:4]<->VP[11:08]<->CSI_DATA[15:12] */ - < TDA1997X_VP24_V11_08 TDA1997X_R_CR_CBCR_7_4 >, - - port { - tda1997x_to_ipu1_csi0_mux: endpoint { - remote-endpoint = <&ipu1_csi0_mux_from_parallel_sensor>; - bus-width = <16>; - hsync-active = <1>; - vsync-active = <1>; - data-active = <1>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml new file mode 100644 index 000000000000..20f48d5e9b2d --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/sony,imx111.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sony IMX111 8MP CMOS Digital Image Sensor + +maintainers: + - Svyatoslav Ryhel <clamor95@gmail.com> + +description: + IMX111 sensor is a Sony CMOS active pixel digital image sensor with an active + array size of 2464H x 3280V. It is programmable through I2C interface. Image + data is sent through MIPI CSI-2, through 1 or 2 lanes. + +allOf: + - $ref: /schemas/media/video-interface-devices.yaml# + - $ref: /schemas/nvmem/nvmem-consumer.yaml# + +properties: + compatible: + const: sony,imx111 + + reg: + maxItems: 1 + + clocks: + description: EXTCLK with possible frequency from 6 to 54 MHz + maxItems: 1 + + reset-gpios: + maxItems: 1 + + iovdd-supply: + description: Digital IO power supply (1.8V) + + dvdd-supply: + description: Digital power supply (1.2V) + + avdd-supply: + description: Analog power supply (2.7V) + + port: + additionalProperties: false + $ref: /schemas/graph.yaml#/$defs/port-base + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + required: + - data-lanes + - link-frequencies + + required: + - endpoint + +required: + - compatible + - reg + - clocks + - port + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/media/video-interfaces.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + camera@10 { + compatible = "sony,imx111"; + reg = <0x10>; + + clocks = <&imx111_clk>; + + iovdd-supply = <&camera_vddio_1v8>; + dvdd-supply = <&camera_vddd_1v2>; + avdd-supply = <&camera_vdda_2v7>; + + orientation = <1>; + rotation = <90>; + + nvmem = <&eeprom>; + flash-leds = <&led>; + lens-focus = <&vcm>; + + reset-gpios = <&gpio 84 GPIO_ACTIVE_LOW>; + + port { + imx111_output: endpoint { + data-lanes = <1 2>; + link-frequencies = /bits/ 64 <542400000>; + remote-endpoint = <&csi_input>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml index 3c071e6fbea6..060ac6829b66 100644 --- a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml +++ b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml @@ -25,7 +25,11 @@ allOf: properties: compatible: - const: st,vd55g1 + enum: + - st,vd55g1 + - st,vd65g4 + description: + VD55G1 is the monochrome variant, while VD65G4 is the color one. reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/i2c/ti,tvp5150.txt b/Documentation/devicetree/bindings/media/i2c/ti,tvp5150.txt deleted file mode 100644 index 94b908ace53c..000000000000 --- a/Documentation/devicetree/bindings/media/i2c/ti,tvp5150.txt +++ /dev/null @@ -1,157 +0,0 @@ -* Texas Instruments TVP5150 and TVP5151 video decoders - -The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL -(and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2 YUV -with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats. - -Required Properties: -==================== -- compatible: Value must be "ti,tvp5150". -- reg: I2C slave address. - -Optional Properties: -==================== -- pdn-gpios: Phandle for the GPIO connected to the PDN pin, if any. -- reset-gpios: Phandle for the GPIO connected to the RESETB pin, if any. - -The device node must contain one 'port' child node per device physical input -and output port, in accordance with the video interface bindings defined in -Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes -are numbered as follows - - Name Type Port - -------------------------------------- - AIP1A sink 0 - AIP1B sink 1 - Y-OUT src 2 - -The device node must contain at least one sink port and the src port. Each input -port must be linked to an endpoint defined in [1]. The port/connector layout is -as follows - -tvp-5150 port@0 (AIP1A) - endpoint@0 -----------> Comp0-Con port - endpoint@1 ------+----> Svideo-Con port -tvp-5150 port@1 (AIP1B) | - endpoint@1 ------+ - endpoint@0 -----------> Comp1-Con port -tvp-5150 port@2 - endpoint (video bitstream output at YOUT[0-7] parallel bus) - -Required Endpoint Properties for parallel synchronization on output port: -========================================================================= - -- hsync-active: Active state of the HSYNC signal. Must be <1> (HIGH). -- vsync-active: Active state of the VSYNC signal. Must be <1> (HIGH). -- field-even-active: Field signal level during the even field data - transmission. Must be <0>. - -Note: Do not specify any of these properties if you want to use the embedded - BT.656 synchronization. - -Optional Connector Properties: -============================== - -- sdtv-standards: Set the possible signals to which the hardware tries to lock - instead of using the autodetection mechanism. Please look at - [1] for more information. - -[1] Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml. - -Example - three input sources: -#include <dt-bindings/display/sdtv-standards.h> - -comp_connector_0 { - compatible = "composite-video-connector"; - label = "Composite0"; - sdtv-standards = <SDTV_STD_PAL_M>; /* limit to pal-m signals */ - - port { - composite0_to_tvp5150: endpoint { - remote-endpoint = <&tvp5150_to_composite0>; - }; - }; -}; - -comp_connector_1 { - compatible = "composite-video-connector"; - label = "Composite1"; - sdtv-standards = <SDTV_STD_NTSC_M>; /* limit to ntsc-m signals */ - - port { - composite1_to_tvp5150: endpoint { - remote-endpoint = <&tvp5150_to_composite1>; - }; - }; -}; - -svideo_connector { - compatible = "svideo-connector"; - label = "S-Video"; - - port { - #address-cells = <1>; - #size-cells = <0>; - - svideo_luma_to_tvp5150: endpoint@0 { - reg = <0>; - remote-endpoint = <&tvp5150_to_svideo_luma>; - }; - - svideo_chroma_to_tvp5150: endpoint@1 { - reg = <1>; - remote-endpoint = <&tvp5150_to_svideo_chroma>; - }; - }; -}; - -&i2c2 { - tvp5150@5c { - compatible = "ti,tvp5150"; - reg = <0x5c>; - pdn-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>; - reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>; - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; - - tvp5150_to_composite0: endpoint@0 { - reg = <0>; - remote-endpoint = <&composite0_to_tvp5150>; - }; - - tvp5150_to_svideo_luma: endpoint@1 { - reg = <1>; - remote-endpoint = <&svideo_luma_to_tvp5150>; - }; - }; - - port@1 { - #address-cells = <1>; - #size-cells = <0>; - reg = <1>; - - tvp5150_to_composite1: endpoint@0 { - reg = <0>; - remote-endpoint = <&composite1_to_tvp5150>; - }; - - tvp5150_to_svideo_chroma: endpoint@1 { - reg = <1>; - remote-endpoint = <&svideo_chroma_to_tvp5150>; - }; - }; - - port@2 { - reg = <2>; - - tvp5150_1: endpoint { - remote-endpoint = <&ccdc_ep>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/media/i2c/ti,tvp5150.yaml b/Documentation/devicetree/bindings/media/i2c/ti,tvp5150.yaml new file mode 100644 index 000000000000..382a29652a05 --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/ti,tvp5150.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/ti,tvp5150.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TVP5150 and TVP5151 video decoders + +maintainers: + - Frank Li <Frank.Li@nxp.com> + +description: + The TVP5150 and TVP5151 are video decoders that convert baseband NTSC and PAL + (and also SECAM in the TVP5151 case) video signals to either 8-bit 4:2:2 YUV + with discrete syncs or 8-bit ITU-R BT.656 with embedded syncs output formats. + +properties: + compatible: + const: ti,tvp5150 + + reg: + maxItems: 1 + + pdn-gpios: + maxItems: 1 + + reset-gpios: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + sink port node, AIP1A + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + sink port node, AIP1B + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + source port node, Y-OUT + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + - port@2 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/display/sdtv-standards.h> + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@5c { + compatible = "ti,tvp5150"; + reg = <0x5c>; + pdn-gpios = <&gpio4 30 GPIO_ACTIVE_LOW>; + reset-gpios = <&gpio6 7 GPIO_ACTIVE_LOW>; + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + endpoint@0 { + reg = <0>; + remote-endpoint = <&composite0_to_tvp5150>; + }; + + endpoint@1 { + reg = <1>; + remote-endpoint = <&svideo_luma_to_tvp5150>; + }; + }; + + port@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + endpoint@0 { + reg = <0>; + remote-endpoint = <&composite1_to_tvp5150>; + }; + + endpoint@1 { + reg = <1>; + remote-endpoint = <&svideo_chroma_to_tvp5150>; + }; + }; + + port@2 { + reg = <2>; + + endpoint { + remote-endpoint = <&ccdc_ep>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml index f43b91984f01..001a0d9b71e0 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8-isi.yaml @@ -22,6 +22,7 @@ properties: - fsl,imx8mn-isi - fsl,imx8mp-isi - fsl,imx8ulp-isi + - fsl,imx91-isi - fsl,imx93-isi reg: @@ -66,7 +67,6 @@ required: - interrupts - clocks - clock-names - - fsl,blk-ctrl - ports allOf: @@ -77,6 +77,7 @@ allOf: enum: - fsl,imx8mn-isi - fsl,imx8ulp-isi + - fsl,imx91-isi - fsl,imx93-isi then: properties: @@ -109,6 +110,16 @@ allOf: - port@0 - port@1 + - if: + properties: + compatible: + not: + contains: + const: fsl,imx91-isi + then: + required: + - fsl,blk-ctrl + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml new file mode 100644 index 000000000000..77b389d76a43 --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,msm8939-camss.yaml @@ -0,0 +1,254 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,msm8939-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm MSM8939 Camera Subsystem (CAMSS) + +maintainers: + - Vincent Knecht <vincent.knecht@mailoo.org> + +description: + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms + +properties: + compatible: + const: qcom,msm8939-camss + + reg: + maxItems: 11 + + reg-names: + items: + - const: csiphy0 + - const: csiphy0_clk_mux + - const: csiphy1 + - const: csiphy1_clk_mux + - const: csid0 + - const: csid1 + - const: ispif + - const: csi_clk_mux + - const: vfe0 + - const: csid2 + - const: vfe0_vbif + + clocks: + maxItems: 24 + + clock-names: + items: + - const: top_ahb + - const: ispif_ahb + - const: csiphy0_timer + - const: csiphy1_timer + - const: csi0_ahb + - const: csi0 + - const: csi0_phy + - const: csi0_pix + - const: csi0_rdi + - const: csi1_ahb + - const: csi1 + - const: csi1_phy + - const: csi1_pix + - const: csi1_rdi + - const: ahb + - const: vfe0 + - const: csi_vfe0 + - const: vfe_ahb + - const: vfe_axi + - const: csi2_ahb + - const: csi2 + - const: csi2_phy + - const: csi2_pix + - const: csi2_rdi + + interrupts: + maxItems: 7 + + interrupt-names: + items: + - const: csiphy0 + - const: csiphy1 + - const: csid0 + - const: csid1 + - const: ispif + - const: vfe0 + - const: csid2 + + iommus: + maxItems: 1 + + power-domains: + items: + - description: VFE GDSC - Video Front End, Global Distributed Switch + Controller. + + vdda-supply: + description: + Definition of the regulator used as 1.2V analog power supply. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + patternProperties: + "^port@[0-1]$": + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - data-lanes + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + - interrupt-names + - iommus + - power-domains + - vdda-supply + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,gcc-msm8939.h> + + isp@1b0ac00 { + compatible = "qcom,msm8939-camss"; + + reg = <0x01b0ac00 0x200>, + <0x01b00030 0x4>, + <0x01b0b000 0x200>, + <0x01b00038 0x4>, + <0x01b08000 0x100>, + <0x01b08400 0x100>, + <0x01b0a000 0x500>, + <0x01b00020 0x10>, + <0x01b10000 0x1000>, + <0x01b08800 0x100>, + <0x01b40000 0x200>; + + reg-names = "csiphy0", + "csiphy0_clk_mux", + "csiphy1", + "csiphy1_clk_mux", + "csid0", + "csid1", + "ispif", + "csi_clk_mux", + "vfe0", + "csid2", + "vfe0_vbif"; + + clocks = <&gcc GCC_CAMSS_TOP_AHB_CLK>, + <&gcc GCC_CAMSS_ISPIF_AHB_CLK>, + <&gcc GCC_CAMSS_CSI0PHYTIMER_CLK>, + <&gcc GCC_CAMSS_CSI1PHYTIMER_CLK>, + <&gcc GCC_CAMSS_CSI0_AHB_CLK>, + <&gcc GCC_CAMSS_CSI0_CLK>, + <&gcc GCC_CAMSS_CSI0PHY_CLK>, + <&gcc GCC_CAMSS_CSI0PIX_CLK>, + <&gcc GCC_CAMSS_CSI0RDI_CLK>, + <&gcc GCC_CAMSS_CSI1_AHB_CLK>, + <&gcc GCC_CAMSS_CSI1_CLK>, + <&gcc GCC_CAMSS_CSI1PHY_CLK>, + <&gcc GCC_CAMSS_CSI1PIX_CLK>, + <&gcc GCC_CAMSS_CSI1RDI_CLK>, + <&gcc GCC_CAMSS_AHB_CLK>, + <&gcc GCC_CAMSS_VFE0_CLK>, + <&gcc GCC_CAMSS_CSI_VFE0_CLK>, + <&gcc GCC_CAMSS_VFE_AHB_CLK>, + <&gcc GCC_CAMSS_VFE_AXI_CLK>, + <&gcc GCC_CAMSS_CSI2_AHB_CLK>, + <&gcc GCC_CAMSS_CSI2_CLK>, + <&gcc GCC_CAMSS_CSI2PHY_CLK>, + <&gcc GCC_CAMSS_CSI2PIX_CLK>, + <&gcc GCC_CAMSS_CSI2RDI_CLK>; + + clock-names = "top_ahb", + "ispif_ahb", + "csiphy0_timer", + "csiphy1_timer", + "csi0_ahb", + "csi0", + "csi0_phy", + "csi0_pix", + "csi0_rdi", + "csi1_ahb", + "csi1", + "csi1_phy", + "csi1_pix", + "csi1_rdi", + "ahb", + "vfe0", + "csi_vfe0", + "vfe_ahb", + "vfe_axi", + "csi2_ahb", + "csi2", + "csi2_phy", + "csi2_pix", + "csi2_rdi"; + + interrupts = <GIC_SPI 78 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 79 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 51 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 52 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 55 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 57 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 153 IRQ_TYPE_EDGE_RISING>; + + interrupt-names = "csiphy0", + "csiphy1", + "csid0", + "csid1", + "ispif", + "vfe0", + "csid2"; + + iommus = <&apps_iommu 3>; + + power-domains = <&gcc VFE_GDSC>; + + vdda-supply = <®_1v2>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + + csiphy1_ep: endpoint { + data-lanes = <0 2>; + remote-endpoint = <&sensor_ep>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,sm8650-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8650-camss.yaml new file mode 100644 index 000000000000..9c8de722601e --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sm8650-camss.yaml @@ -0,0 +1,375 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/qcom,sm8650-camss.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SM8650 Camera Subsystem (CAMSS) + +maintainers: + - Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> + +description: + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,sm8650-camss + + reg: + maxItems: 17 + + reg-names: + items: + - const: csid_wrapper + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid_lite0 + - const: csid_lite1 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: vfe0 + - const: vfe1 + - const: vfe2 + - const: vfe_lite0 + - const: vfe_lite1 + + clocks: + maxItems: 33 + + clock-names: + items: + - const: camnoc_axi + - const: cpas_ahb + - const: cpas_fast_ahb + - const: cpas_vfe0 + - const: cpas_vfe1 + - const: cpas_vfe2 + - const: cpas_vfe_lite + - const: csid + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy2 + - const: csiphy2_timer + - const: csiphy3 + - const: csiphy3_timer + - const: csiphy4 + - const: csiphy4_timer + - const: csiphy5 + - const: csiphy5_timer + - const: csiphy_rx + - const: gcc_axi_hf + - const: qdss_debug_xo + - const: vfe0 + - const: vfe0_fast_ahb + - const: vfe1 + - const: vfe1_fast_ahb + - const: vfe2 + - const: vfe2_fast_ahb + - const: vfe_lite + - const: vfe_lite_ahb + - const: vfe_lite_cphy_rx + - const: vfe_lite_csid + + interrupts: + maxItems: 16 + + interrupt-names: + items: + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid_lite0 + - const: csid_lite1 + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: vfe0 + - const: vfe1 + - const: vfe2 + - const: vfe_lite0 + - const: vfe_lite1 + + interconnects: + maxItems: 2 + + interconnect-names: + items: + - const: ahb + - const: hf_mnoc + + iommus: + maxItems: 3 + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller. + + power-domain-names: + items: + - const: ife0 + - const: ife1 + - const: ife2 + - const: top + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + patternProperties: + "^port@[0-5]$": + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + + description: + Input port for receiving CSI data from a CSIPHY. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 4 + + bus-type: + enum: + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY + + required: + - data-lanes + + vdd-csiphy01-0p9-supply: + description: + Phandle to a 0.9V regulator supply to CSIPHY0 and CSIPHY1 IP blocks. + + vdd-csiphy01-1p2-supply: + description: + Phandle to a 1.2V regulator supply to CSIPHY0 and CSIPHY1 IP blocks. + + vdd-csiphy24-0p9-supply: + description: + Phandle to a 0.9V regulator supply to CSIPHY2 and CSIPHY4 IP blocks. + + vdd-csiphy24-1p2-supply: + description: + Phandle to a 1.2V regulator supply to CSIPHY2 and CSIPHY4 IP blocks. + + vdd-csiphy35-0p9-supply: + description: + Phandle to a 0.9V regulator supply to CSIPHY3 and CSIPHY5 IP blocks. + + vdd-csiphy35-1p2-supply: + description: + Phandle to a 1.2V regulator supply to CSIPHY3 and CSIPHY5 IP blocks. + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interconnects + - interconnect-names + - interrupts + - interrupt-names + - iommus + - power-domains + - power-domain-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,sm8650-camcc.h> + #include <dt-bindings/clock/qcom,sm8650-gcc.h> + #include <dt-bindings/interconnect/qcom,sm8650-rpmh.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + isp@acb6000 { + compatible = "qcom,sm8650-camss"; + reg = <0 0x0acb6000 0 0x1000>, + <0 0x0acb8000 0 0x1000>, + <0 0x0acba000 0 0x1000>, + <0 0x0acbc000 0 0x1000>, + <0 0x0accb000 0 0x1000>, + <0 0x0acd0000 0 0x1000>, + <0 0x0ace4000 0 0x2000>, + <0 0x0ace6000 0 0x2000>, + <0 0x0ace8000 0 0x2000>, + <0 0x0acea000 0 0x2000>, + <0 0x0acec000 0 0x2000>, + <0 0x0acee000 0 0x2000>, + <0 0x0ac62000 0 0xf000>, + <0 0x0ac71000 0 0xf000>, + <0 0x0ac80000 0 0xf000>, + <0 0x0accc000 0 0x2000>, + <0 0x0acd1000 0 0x2000>; + reg-names = "csid_wrapper", + "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "vfe0", + "vfe1", + "vfe2", + "vfe_lite0", + "vfe_lite1"; + clocks = <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_CPAS_FAST_AHB_CLK>, + <&camcc CAM_CC_CPAS_IFE_0_CLK>, + <&camcc CAM_CC_CPAS_IFE_1_CLK>, + <&camcc CAM_CC_CPAS_IFE_2_CLK>, + <&camcc CAM_CC_CPAS_IFE_LITE_CLK>, + <&camcc CAM_CC_CSID_CLK>, + <&camcc CAM_CC_CSIPHY0_CLK>, + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY1_CLK>, + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY2_CLK>, + <&camcc CAM_CC_CSI3PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY3_CLK>, + <&camcc CAM_CC_CSI4PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY4_CLK>, + <&camcc CAM_CC_CSI5PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY5_CLK>, + <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>, + <&gcc GCC_CAMERA_HF_AXI_CLK>, + <&camcc CAM_CC_QDSS_DEBUG_XO_CLK>, + <&camcc CAM_CC_IFE_0_CLK>, + <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_2_CLK>, + <&camcc CAM_CC_IFE_2_FAST_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_CLK>, + <&camcc CAM_CC_IFE_LITE_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_CSID_CLK>; + clock-names = "camnoc_axi", + "cpas_ahb", + "cpas_fast_ahb", + "cpas_vfe0", + "cpas_vfe1", + "cpas_vfe2", + "cpas_vfe_lite", + "csid", + "csiphy0", + "csiphy0_timer", + "csiphy1", + "csiphy1_timer", + "csiphy2", + "csiphy2_timer", + "csiphy3", + "csiphy3_timer", + "csiphy4", + "csiphy4_timer", + "csiphy5", + "csiphy5_timer", + "csiphy_rx", + "gcc_axi_hf", + "qdss_debug_xo", + "vfe0", + "vfe0_fast_ahb", + "vfe1", + "vfe1_fast_ahb", + "vfe2", + "vfe2_fast_ahb", + "vfe_lite", + "vfe_lite_ahb", + "vfe_lite_cphy_rx", + "vfe_lite_csid"; + interrupts = <GIC_SPI 601 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 603 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 605 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 376 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 478 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 479 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 448 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 89 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 602 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 604 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 688 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 606 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 377 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "csid0", + "csid1", + "csid2", + "csid_lite0", + "csid_lite1", + "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "vfe0", + "vfe1", + "vfe2", + "vfe_lite0", + "vfe_lite1"; + interconnects = <&gem_noc MASTER_APPSS_PROC 0 + &config_noc SLAVE_CAMERA_CFG 0>, + <&mmss_noc MASTER_CAMNOC_HF 0 + &mc_virt SLAVE_EBI1 0>; + interconnect-names = "ahb", "hf_mnoc"; + iommus = <&apps_smmu 0x800 0x20>, + <&apps_smmu 0x18a0 0x40>, + <&apps_smmu 0x1860 0x00>; + power-domains = <&camcc CAM_CC_IFE_0_GDSC>, + <&camcc CAM_CC_IFE_1_GDSC>, + <&camcc CAM_CC_IFE_2_GDSC>, + <&camcc CAM_CC_TITAN_TOP_GDSC>; + power-domain-names = "ife0", "ife1", "ife2", "top"; + vdd-csiphy01-0p9-supply = <&vreg_0p9>; + vdd-csiphy01-1p2-supply = <&vreg_1p2>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + reg = <1>; + + csiphy1_ep: endpoint { + data-lanes = <0 1>; + remote-endpoint = <&camera_sensor>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml index b075341caafc..b87a13479a4b 100644 --- a/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,x1e80100-camss.yaml @@ -124,7 +124,7 @@ properties: vdd-csiphy-1p2-supply: description: - Phandle to 1.8V regulator supply to a PHY. + Phandle to 1.2V regulator supply to a PHY. ports: $ref: /schemas/graph.yaml#/properties/ports diff --git a/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml b/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml new file mode 100644 index 000000000000..c09cbd8c9e35 --- /dev/null +++ b/Documentation/devicetree/bindings/media/renesas,r9a09g057-ivc.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/renesas,r9a09g057-ivc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/V2H(P) Input Video Control Block + +maintainers: + - Daniel Scally <dan.scally@ideasonboard.com> + +description: + The IVC block is a module that takes video frames from memory and feeds them + to the Image Signal Processor for processing. + +properties: + compatible: + const: renesas,r9a09g057-ivc # RZ/V2H(P) + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Input Video Control block register access clock + - description: Video input data AXI bus clock + - description: ISP system clock + + clock-names: + items: + - const: reg + - const: axi + - const: isp + + power-domains: + maxItems: 1 + + resets: + items: + - description: Input Video Control block register access reset + - description: Video input data AXI bus reset + - description: ISP core reset + + reset-names: + items: + - const: reg + - const: axi + - const: isp + + port: + $ref: /schemas/graph.yaml#/properties/port + description: Output parallel video bus + + properties: + endpoint: + $ref: /schemas/graph.yaml#/properties/endpoint + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - resets + - reset-names + - port + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/renesas,r9a09g057-cpg.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + isp-input@16040000 { + compatible = "renesas,r9a09g057-ivc"; + reg = <0x16040000 0x230>; + + clocks = <&cpg CPG_MOD 0xe3>, + <&cpg CPG_MOD 0xe4>, + <&cpg CPG_MOD 0xe5>; + clock-names = "reg", "axi", "isp"; + + power-domains = <&cpg>; + + resets = <&cpg 0xd4>, + <&cpg 0xd1>, + <&cpg 0xd3>; + reset-names = "reg", "axi", "isp"; + + interrupts = <GIC_SPI 861 IRQ_TYPE_EDGE_RISING>; + + port { + ivc_out: endpoint { + remote-endpoint = <&isp_in>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/media/rockchip,px30-vip.yaml b/Documentation/devicetree/bindings/media/rockchip,px30-vip.yaml new file mode 100644 index 000000000000..cc08ce94bef7 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rockchip,px30-vip.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/rockchip,px30-vip.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip PX30 Video Input Processor (VIP) + +maintainers: + - Mehdi Djait <mehdi.djait@linux.intel.com> + - Michael Riesch <michael.riesch@collabora.com> + +description: + The Rockchip PX30 Video Input Processor (VIP) receives the data from a camera + sensor or CCIR656 encoder and transfers it into system main memory by AXI bus. + +properties: + compatible: + const: rockchip,px30-vip + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: ACLK + - description: HCLK + - description: PCLK + + clock-names: + items: + - const: aclk + - const: hclk + - const: pclk + + resets: + items: + - description: AXI + - description: AHB + - description: PCLK IN + + reset-names: + items: + - const: axi + - const: ahb + - const: pclkin + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: input port on the parallel interface + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + bus-type: + enum: + - 5 # MEDIA_BUS_TYPE_PARALLEL + - 6 # MEDIA_BUS_TYPE_BT656 + + required: + - bus-type + + required: + - port@0 + +required: + - compatible + - reg + - interrupts + - clocks + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/px30-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/media/video-interfaces.h> + #include <dt-bindings/power/px30-power.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + video-capture@ff490000 { + compatible = "rockchip,px30-vip"; + reg = <0x0 0xff490000 0x0 0x200>; + interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru ACLK_CIF>, <&cru HCLK_CIF>, <&cru PCLK_CIF>; + clock-names = "aclk", "hclk", "pclk"; + power-domains = <&power PX30_PD_VI>; + resets = <&cru SRST_CIF_A>, <&cru SRST_CIF_H>, <&cru SRST_CIF_PCLKIN>; + reset-names = "axi", "ahb", "pclkin"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + cif_in: endpoint { + remote-endpoint = <&tw9900_out>; + bus-type = <MEDIA_BUS_TYPE_BT656>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml new file mode 100644 index 000000000000..18cd0a5a5318 --- /dev/null +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml @@ -0,0 +1,172 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/rockchip,rk3568-vicap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3568 Video Capture (VICAP) + +maintainers: + - Michael Riesch <michael.riesch@collabora.com> + +description: + The Rockchip RK3568 Video Capture (VICAP) block features a digital video + port (DVP, a parallel video interface) and a MIPI CSI-2 port. It receives + the data from camera sensors, video decoders, or other companion ICs and + transfers it into system main memory by AXI bus. + +properties: + compatible: + const: rockchip,rk3568-vicap + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: ACLK + - description: HCLK + - description: DCLK + - description: ICLK + + clock-names: + items: + - const: aclk + - const: hclk + - const: dclk + - const: iclk + + iommus: + maxItems: 1 + + resets: + items: + - description: ARST + - description: HRST + - description: DRST + - description: PRST + - description: IRST + + reset-names: + items: + - const: arst + - const: hrst + - const: drst + - const: prst + - const: irst + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to general register file used for video input block control. + + power-domains: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: The digital video port (DVP, a parallel video interface). + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + bus-type: + enum: + - 5 # MEDIA_BUS_TYPE_PARALLEL + - 6 # MEDIA_BUS_TYPE_BT656 + + rockchip,dvp-clk-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + minimum: 0 + maximum: 127 + description: + Delay the DVP path clock input to align the sampling phase, + only valid in dual edge sampling mode. Delay is zero by + default and can be adjusted optionally. + + required: + - bus-type + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Port connected to the MIPI CSI-2 receiver output. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3568-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/rk3568-power.h> + #include <dt-bindings/media/video-interfaces.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + vicap: video-capture@fdfe0000 { + compatible = "rockchip,rk3568-vicap"; + reg = <0x0 0xfdfe0000 0x0 0x200>; + interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>; + assigned-clocks = <&cru DCLK_VICAP>; + assigned-clock-rates = <300000000>; + clocks = <&cru ACLK_VICAP>, <&cru HCLK_VICAP>, + <&cru DCLK_VICAP>, <&cru ICLK_VICAP_G>; + clock-names = "aclk", "hclk", "dclk", "iclk"; + iommus = <&vicap_mmu>; + power-domains = <&power RK3568_PD_VI>; + resets = <&cru SRST_A_VICAP>, <&cru SRST_H_VICAP>, + <&cru SRST_D_VICAP>, <&cru SRST_P_VICAP>, + <&cru SRST_I_VICAP>; + reset-names = "arst", "hrst", "drst", "prst", "irst"; + rockchip,grf = <&grf>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + vicap_dvp: port@0 { + reg = <0>; + + vicap_dvp_input: endpoint { + bus-type = <MEDIA_BUS_TYPE_BT656>; + bus-width = <16>; + pclk-sample = <MEDIA_PCLK_SAMPLE_DUAL_EDGE>; + remote-endpoint = <&it6801_output>; + }; + }; + + vicap_mipi: port@1 { + reg = <1>; + + vicap_mipi_input: endpoint { + remote-endpoint = <&csi_output>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml index 96b6c8938768..809fda45b3bd 100644 --- a/Documentation/devicetree/bindings/media/rockchip,vdec.yaml +++ b/Documentation/devicetree/bindings/media/rockchip,vdec.yaml @@ -16,6 +16,7 @@ description: |- properties: compatible: oneOf: + - const: rockchip,rk3288-vdec - const: rockchip,rk3399-vdec - const: rockchip,rk3576-vdec - const: rockchip,rk3588-vdec diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml index 510e94e9ca3a..b7f6c87d0e06 100644 --- a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml @@ -8,7 +8,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Synopsys DesignWare HDMI RX Controller maintainers: - - Shreeya Patel <shreeya.patel@collabora.com> + - Dmitry Osipenko <dmitry.osipenko@collabora.com> description: Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs diff --git a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt b/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt deleted file mode 100644 index 880d4d70c9fd..000000000000 --- a/Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt +++ /dev/null @@ -1,88 +0,0 @@ -STMicroelectronics STi c8sectpfe binding -============================================ - -This document describes the c8sectpfe device bindings that is used to get transport -stream data into the SoC on the TS pins, and into DDR for further processing. - -It is typically used in conjunction with one or more demodulator and tuner devices -which converts from the RF to digital domain. Demodulators and tuners are usually -located on an external DVB frontend card connected to SoC TS input pins. - -Currently 7 TS input (tsin) channels are supported on the stih407 family SoC. - -Required properties (controller (parent) node): -- compatible : Should be "stih407-c8sectpfe" - -- reg : Address and length of register sets for each device in - "reg-names" - -- reg-names : The names of the register addresses corresponding to the - registers filled in "reg": - - c8sectpfe: c8sectpfe registers - - c8sectpfe-ram: c8sectpfe internal sram - -- clocks : phandle list of c8sectpfe clocks -- clock-names : should be "c8sectpfe" -See: Documentation/devicetree/bindings/clock/clock-bindings.txt - -- pinctrl-names : a pinctrl state named tsin%d-serial or tsin%d-parallel (where %d is tsin-num) - must be defined for each tsin child node. -- pinctrl-0 : phandle referencing pin configuration for this tsin configuration -See: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - - -Required properties (tsin (child) node): - -- tsin-num : tsin id of the InputBlock (must be between 0 to 6) -- i2c-bus : phandle to the I2C bus DT node which the demodulators & tuners on this tsin channel are connected. -- reset-gpios : reset gpio for this tsin channel. - -Optional properties (tsin (child) node): - -- invert-ts-clk : Bool property to control sense of ts input clock (data stored on falling edge of clk). -- serial-not-parallel : Bool property to configure input bus width (serial on ts_data<7>). -- async-not-sync : Bool property to control if data is received in asynchronous mode - (all bits/bytes with ts_valid or ts_packet asserted are valid). - -- dvb-card : Describes the NIM card connected to this tsin channel. - -Example: - -/* stih410 SoC b2120 + b2004a + stv0367-pll(NIMB) + stv0367-tda18212 (NIMA) DT example) */ - - c8sectpfe@8a20000 { - compatible = "st,stih407-c8sectpfe"; - reg = <0x08a20000 0x10000>, <0x08a00000 0x4000>; - reg-names = "stfe", "stfe-ram"; - interrupts = <GIC_SPI 34 IRQ_TYPE_NONE>, <GIC_SPI 35 IRQ_TYPE_NONE>; - interrupt-names = "stfe-error-irq", "stfe-idle-irq"; - pinctrl-0 = <&pinctrl_tsin0_serial>; - pinctrl-1 = <&pinctrl_tsin0_parallel>; - pinctrl-2 = <&pinctrl_tsin3_serial>; - pinctrl-3 = <&pinctrl_tsin4_serial_alt3>; - pinctrl-4 = <&pinctrl_tsin5_serial_alt1>; - pinctrl-names = "tsin0-serial", - "tsin0-parallel", - "tsin3-serial", - "tsin4-serial", - "tsin5-serial"; - clocks = <&clk_s_c0_flexgen CLK_PROC_STFE>; - clock-names = "c8sectpfe"; - - /* tsin0 is TSA on NIMA */ - tsin0: port@0 { - tsin-num = <0>; - serial-not-parallel; - i2c-bus = <&ssc2>; - reset-gpios = <&pio15 4 GPIO_ACTIVE_HIGH>; - dvb-card = <STV0367_TDA18212_NIMA_1>; - }; - - tsin3: port@3 { - tsin-num = <3>; - serial-not-parallel; - i2c-bus = <&ssc3>; - reset-gpios = <&pio15 7 GPIO_ACTIVE_HIGH>; - dvb-card = <STV0367_TDA18212_NIMB_1>; - }; - }; diff --git a/Documentation/devicetree/bindings/media/video-interfaces.yaml b/Documentation/devicetree/bindings/media/video-interfaces.yaml index 038e85b45bef..6ed4695cacf7 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.yaml +++ b/Documentation/devicetree/bindings/media/video-interfaces.yaml @@ -95,7 +95,7 @@ properties: - 6 # BT.656 - 7 # DPI description: - Data bus type. + Data bus type. See include/dt-bindings/media/video-interfaces.h. bus-width: $ref: /schemas/types.yaml#/definitions/uint32 @@ -229,7 +229,7 @@ properties: Imaging. The length of the array must be the same length as the data-lanes property. If the line-orders property is omitted, the value shall be interpreted as 0 (ABC). This property is valid for CSI-2 C-PHY - busses only. + busses only. See include/dt-bindings/media/video-interfaces.h. strobe: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/npu/arm,ethos.yaml b/Documentation/devicetree/bindings/npu/arm,ethos.yaml new file mode 100644 index 000000000000..716c4997f976 --- /dev/null +++ b/Documentation/devicetree/bindings/npu/arm,ethos.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/npu/arm,ethos.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm Ethos U65/U85 + +maintainers: + - Rob Herring <robh@kernel.org> + +description: > + The Arm Ethos-U NPUs are designed for IoT inference applications. The NPUs + can accelerate 8-bit and 16-bit integer quantized networks: + + Transformer networks (U85 only) + Convolutional Neural Networks (CNN) + Recurrent Neural Networks (RNN) + + Further documentation is available here: + + U65 TRM: https://developer.arm.com/documentation/102023/ + U85 TRM: https://developer.arm.com/documentation/102685/ + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx93-npu + - const: arm,ethos-u65 + - items: + - {} + - const: arm,ethos-u85 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: core + - const: apb + + power-domains: + maxItems: 1 + + sram: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/imx93-clock.h> + + npu@4a900000 { + compatible = "fsl,imx93-npu", "arm,ethos-u65"; + reg = <0x4a900000 0x1000>; + interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&mlmix>; + clocks = <&clk IMX93_CLK_ML>, <&clk IMX93_CLK_ML_APB>; + clock-names = "core", "apb"; + sram = <&sram>; + }; +... diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index beab81e462d2..f2ae0c538e48 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -176,6 +176,8 @@ patternProperties: description: All Sensors Corporation "^asix,.*": description: ASIX Electronics Corporation + "^asl-tek,.*": + description: ASL Xiamen Technology Co., Ltd. "^aspeed,.*": description: ASPEED Technology Inc. "^asrock,.*": @@ -835,6 +837,8 @@ patternProperties: description: JOZ BV "^jty,.*": description: JTY + "^jutouch,.*": + description: JuTouch Technology Co., Ltd. "^kam,.*": description: Kamstrup A/S "^karo,.*": @@ -1323,6 +1327,8 @@ patternProperties: description: Raumfeld GmbH "^raydium,.*": description: Raydium Semiconductor Corp. + "^raystar,.*": + description: Raystar Optronics, Inc. "^rda,.*": description: Unisoc Communications, Inc. "^realtek,.*": diff --git a/Documentation/driver-api/media/v4l2-core.rst b/Documentation/driver-api/media/v4l2-core.rst index ad987c34ad2a..a5f5102c64cc 100644 --- a/Documentation/driver-api/media/v4l2-core.rst +++ b/Documentation/driver-api/media/v4l2-core.rst @@ -27,3 +27,4 @@ Video4Linux devices v4l2-common v4l2-tveeprom v4l2-jpeg + v4l2-isp diff --git a/Documentation/driver-api/media/v4l2-isp.rst b/Documentation/driver-api/media/v4l2-isp.rst new file mode 100644 index 000000000000..618ae614ff79 --- /dev/null +++ b/Documentation/driver-api/media/v4l2-isp.rst @@ -0,0 +1,49 @@ +.. SPDX-License-Identifier: GPL-2.0 + +V4L2 generic ISP parameters and statistics support +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Design rationale +================ + +ISP configuration parameters and statistics are processed and collected by +drivers and exchanged with userspace through data types that usually +reflect the ISP peripheral registers layout. + +Each ISP driver defines its own metadata output format for parameters and +a metadata capture format for statistics. The buffer layout is realized by a +set of C structures that reflects the registers layout. The number and types +of C structures is fixed by the format definition and becomes part of the Linux +kernel uAPI/uABI interface. + +Because of the hard requirement of backward compatibility when extending the +user API/ABI interface, modifying an ISP driver capture or output metadata +format after it has been accepted by mainline is very hard if not impossible. + +It generally happens, in fact, that after the first accepted revision of an ISP +driver the buffers layout need to be modified, either to support new hardware +blocks, to fix bugs or to support different revisions of the hardware. + +Each of these situations would require defining a new metadata format, making it +really hard to maintain and extend drivers and requiring userspace to use +the correct format depending on the kernel revision in use. + +V4L2 ISP configuration parameters +================================= + +For these reasons, Video4Linux2 defines generic types for ISP configuration +parameters and statistics. Drivers are still expected to define their own +formats for their metadata output and capture nodes, but the buffers layout can +be defined using the extensible and versioned types defined by +include/uapi/linux/media/v4l2-isp.h. + +Drivers are expected to provide the definitions of their supported ISP blocks +and the expected maximum size of a buffer. + +For driver developers a set of helper functions to assist them with validation +of the buffer received from userspace is available in +drivers/media/v4l2-core/v4l2-isp.c + +V4L2 ISP support driver documentation +===================================== +.. kernel-doc:: include/media/v4l2-isp.h diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 5139705089f2..781129f78b06 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -92,6 +92,18 @@ GEM Atomic Helper Reference .. kernel-doc:: drivers/gpu/drm/drm_gem_atomic_helper.c :export: +VBLANK Helper Reference +----------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_vblank_helper.c + :doc: overview + +.. kernel-doc:: include/drm/drm_vblank_helper.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_vblank_helper.c + :export: + Simple KMS Helper Reference =========================== diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index abfe220764e1..2292e65f044c 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -413,6 +413,21 @@ Plane Panic Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_panic.c :export: +Colorop Abstraction +=================== + +.. kernel-doc:: drivers/gpu/drm/drm_colorop.c + :doc: overview + +Colorop Functions Reference +--------------------------- + +.. kernel-doc:: include/drm/drm_colorop.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_colorop.c + :export: + Display Modes Function Reference ================================ diff --git a/Documentation/gpu/nova/core/todo.rst b/Documentation/gpu/nova/core/todo.rst index 0972cb905f7a..35cc7c31d423 100644 --- a/Documentation/gpu/nova/core/todo.rst +++ b/Documentation/gpu/nova/core/todo.rst @@ -44,25 +44,6 @@ automatically generates the corresponding mappings between a value and a number. | Complexity: Beginner | Link: https://docs.rs/num/latest/num/trait.FromPrimitive.html -Conversion from byte slices for types implementing FromBytes [TRSM] -------------------------------------------------------------------- - -We retrieve several structures from byte streams coming from the BIOS or loaded -firmware. At the moment converting the bytes slice into the proper type require -an inelegant `unsafe` operation; this will go away once `FromBytes` implements -a proper `from_bytes` method. - -| Complexity: Beginner - -CoherentAllocation improvements [COHA] --------------------------------------- - -`CoherentAllocation` needs a safe way to write into the allocation, and to -obtain slices within the allocation. - -| Complexity: Beginner -| Contact: Abdiel Janulgue - Generic register abstraction [REGA] ----------------------------------- @@ -153,17 +134,6 @@ A `num` core kernel module is being designed to provide these operations. | Complexity: Intermediate | Contact: Alexandre Courbot -Delay / Sleep abstractions [DLAY] ---------------------------------- - -Rust abstractions for the kernel's delay() and sleep() functions. - -FUJITA Tomonori plans to work on abstractions for read_poll_timeout_atomic() -(and friends) [1]. - -| Complexity: Beginner -| Link: https://lore.kernel.org/netdev/20250228.080550.354359820929821928.fujita.tomonori@gmail.com/ [1] - IRQ abstractions ---------------- diff --git a/Documentation/gpu/rfc/color_pipeline.rst b/Documentation/gpu/rfc/color_pipeline.rst new file mode 100644 index 000000000000..cd1cc2d0f988 --- /dev/null +++ b/Documentation/gpu/rfc/color_pipeline.rst @@ -0,0 +1,378 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================== +Linux Color Pipeline API +======================== + +What problem are we solving? +============================ + +We would like to support pre-, and post-blending complex color +transformations in display controller hardware in order to allow for +HW-supported HDR use-cases, as well as to provide support to +color-managed applications, such as video or image editors. + +It is possible to support an HDR output on HW supporting the Colorspace +and HDR Metadata drm_connector properties, but that requires the +compositor or application to render and compose the content into one +final buffer intended for display. Doing so is costly. + +Most modern display HW offers various 1D LUTs, 3D LUTs, matrices, and other +operations to support color transformations. These operations are often +implemented in fixed-function HW and therefore much more power efficient than +performing similar operations via shaders or CPU. + +We would like to make use of this HW functionality to support complex color +transformations with no, or minimal CPU or shader load. The switch between HW +fixed-function blocks and shaders/CPU must be seamless with no visible +difference when fallback to shaders/CPU is neceesary at any time. + + +How are other OSes solving this problem? +======================================== + +The most widely supported use-cases regard HDR content, whether video or +gaming. + +Most OSes will specify the source content format (color gamut, encoding transfer +function, and other metadata, such as max and average light levels) to a driver. +Drivers will then program their fixed-function HW accordingly to map from a +source content buffer's space to a display's space. + +When fixed-function HW is not available the compositor will assemble a shader to +ask the GPU to perform the transformation from the source content format to the +display's format. + +A compositor's mapping function and a driver's mapping function are usually +entirely separate concepts. On OSes where a HW vendor has no insight into +closed-source compositor code such a vendor will tune their color management +code to visually match the compositor's. On other OSes, where both mapping +functions are open to an implementer they will ensure both mappings match. + +This results in mapping algorithm lock-in, meaning that no-one alone can +experiment with or introduce new mapping algorithms and achieve +consistent results regardless of which implementation path is taken. + +Why is Linux different? +======================= + +Unlike other OSes, where there is one compositor for one or more drivers, on +Linux we have a many-to-many relationship. Many compositors; many drivers. +In addition each compositor vendor or community has their own view of how +color management should be done. This is what makes Linux so beautiful. + +This means that a HW vendor can now no longer tune their driver to one +compositor, as tuning it to one could make it look fairly different from +another compositor's color mapping. + +We need a better solution. + + +Descriptive API +=============== + +An API that describes the source and destination colorspaces is a descriptive +API. It describes the input and output color spaces but does not describe +how precisely they should be mapped. Such a mapping includes many minute +design decision that can greatly affect the look of the final result. + +It is not feasible to describe such mapping with enough detail to ensure the +same result from each implementation. In fact, these mappings are a very active +research area. + + +Prescriptive API +================ + +A prescriptive API describes not the source and destination colorspaces. It +instead prescribes a recipe for how to manipulate pixel values to arrive at the +desired outcome. + +This recipe is generally an ordered list of straight-forward operations, +with clear mathematical definitions, such as 1D LUTs, 3D LUTs, matrices, +or other operations that can be described in a precise manner. + + +The Color Pipeline API +====================== + +HW color management pipelines can significantly differ between HW +vendors in terms of availability, ordering, and capabilities of HW +blocks. This makes a common definition of color management blocks and +their ordering nigh impossible. Instead we are defining an API that +allows user space to discover the HW capabilities in a generic manner, +agnostic of specific drivers and hardware. + + +drm_colorop Object +================== + +To support the definition of color pipelines we define the DRM core +object type drm_colorop. Individual drm_colorop objects will be chained +via the NEXT property of a drm_colorop to constitute a color pipeline. +Each drm_colorop object is unique, i.e., even if multiple color +pipelines have the same operation they won't share the same drm_colorop +object to describe that operation. + +Note that drivers are not expected to map drm_colorop objects statically +to specific HW blocks. The mapping of drm_colorop objects is entirely a +driver-internal detail and can be as dynamic or static as a driver needs +it to be. See more in the Driver Implementation Guide section below. + +Each drm_colorop has three core properties: + +TYPE: An enumeration property, defining the type of transformation, such as +* enumerated curve +* custom (uniform) 1D LUT +* 3x3 matrix +* 3x4 matrix +* 3D LUT +* etc. + +Depending on the type of transformation other properties will describe +more details. + +BYPASS: A boolean property that can be used to easily put a block into +bypass mode. The BYPASS property is not mandatory for a colorop, as long +as the entire pipeline can get bypassed by setting the COLOR_PIPELINE on +a plane to '0'. + +NEXT: The ID of the next drm_colorop in a color pipeline, or 0 if this +drm_colorop is the last in the chain. + +An example of a drm_colorop object might look like one of these:: + + /* 1D enumerated curve */ + Color operation 42 + ├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 matrix, 3x4 matrix, 3D LUT, etc.} = 1D enumerated curve + ├─ "BYPASS": bool {true, false} + ├─ "CURVE_1D_TYPE": enum {sRGB EOTF, sRGB inverse EOTF, PQ EOTF, PQ inverse EOTF, …} + └─ "NEXT": immutable color operation ID = 43 + + /* custom 4k entry 1D LUT */ + Color operation 52 + ├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 matrix, 3x4 matrix, 3D LUT, etc.} = 1D LUT + ├─ "BYPASS": bool {true, false} + ├─ "SIZE": immutable range = 4096 + ├─ "DATA": blob + └─ "NEXT": immutable color operation ID = 0 + + /* 17^3 3D LUT */ + Color operation 72 + ├─ "TYPE": immutable enum {1D enumerated curve, 1D LUT, 3x3 matrix, 3x4 matrix, 3D LUT, etc.} = 3D LUT + ├─ "BYPASS": bool {true, false} + ├─ "SIZE": immutable range = 17 + ├─ "DATA": blob + └─ "NEXT": immutable color operation ID = 73 + +drm_colorop extensibility +------------------------- + +Unlike existing DRM core objects, like &drm_plane, drm_colorop is not +extensible. This simplifies implementations and keeps all functionality +for managing &drm_colorop objects in the DRM core. + +If there is a need one may introduce a simple &drm_colorop_funcs +function table in the future, for example to support an IN_FORMATS +property on a &drm_colorop. + +If a driver requires the ability to create a driver-specific colorop +object they will need to add &drm_colorop func table support with +support for the usual functions, like destroy, atomic_duplicate_state, +and atomic_destroy_state. + + +COLOR_PIPELINE Plane Property +============================= + +Color Pipelines are created by a driver and advertised via a new +COLOR_PIPELINE enum property on each plane. Values of the property +always include object id 0, which is the default and means all color +processing is disabled. Additional values will be the object IDs of the +first drm_colorop in a pipeline. A driver can create and advertise none, +one, or more possible color pipelines. A DRM client will select a color +pipeline by setting the COLOR PIPELINE to the respective value. + +NOTE: Many DRM clients will set enumeration properties via the string +value, often hard-coding it. Since this enumeration is generated based +on the colorop object IDs it is important to perform the Color Pipeline +Discovery, described below, instead of hard-coding color pipeline +assignment. Drivers might generate the enum strings dynamically. +Hard-coded strings might only work for specific drivers on a specific +pieces of HW. Color Pipeline Discovery can work universally, as long as +drivers implement the required color operations. + +The COLOR_PIPELINE property is only exposed when the +DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE is set. Drivers shall ignore any +existing pre-blend color operations when this cap is set, such as +COLOR_RANGE and COLOR_ENCODING. If drivers want to support COLOR_RANGE +or COLOR_ENCODING functionality when the color pipeline client cap is +set, they are expected to expose colorops in the pipeline to allow for +the appropriate color transformation. + +Setting of the COLOR_PIPELINE plane property or drm_colorop properties +is only allowed for userspace that sets this client cap. + +An example of a COLOR_PIPELINE property on a plane might look like this:: + + Plane 10 + ├─ "TYPE": immutable enum {Overlay, Primary, Cursor} = Primary + ├─ … + └─ "COLOR_PIPELINE": enum {0, 42, 52} = 0 + + +Color Pipeline Discovery +======================== + +A DRM client wanting color management on a drm_plane will: + +1. Get the COLOR_PIPELINE property of the plane +2. iterate all COLOR_PIPELINE enum values +3. for each enum value walk the color pipeline (via the NEXT pointers) + and see if the available color operations are suitable for the + desired color management operations + +If userspace encounters an unknown or unsuitable color operation during +discovery it does not need to reject the entire color pipeline outright, +as long as the unknown or unsuitable colorop has a "BYPASS" property. +Drivers will ensure that a bypassed block does not have any effect. + +An example of chained properties to define an AMD pre-blending color +pipeline might look like this:: + + Plane 10 + ├─ "TYPE" (immutable) = Primary + └─ "COLOR_PIPELINE": enum {0, 44} = 0 + + Color operation 44 + ├─ "TYPE" (immutable) = 1D enumerated curve + ├─ "BYPASS": bool + ├─ "CURVE_1D_TYPE": enum {sRGB EOTF, PQ EOTF} = sRGB EOTF + └─ "NEXT" (immutable) = 45 + + Color operation 45 + ├─ "TYPE" (immutable) = 3x4 Matrix + ├─ "BYPASS": bool + ├─ "DATA": blob + └─ "NEXT" (immutable) = 46 + + Color operation 46 + ├─ "TYPE" (immutable) = 1D enumerated curve + ├─ "BYPASS": bool + ├─ "CURVE_1D_TYPE": enum {sRGB Inverse EOTF, PQ Inverse EOTF} = sRGB EOTF + └─ "NEXT" (immutable) = 47 + + Color operation 47 + ├─ "TYPE" (immutable) = 1D LUT + ├─ "SIZE": immutable range = 4096 + ├─ "DATA": blob + └─ "NEXT" (immutable) = 48 + + Color operation 48 + ├─ "TYPE" (immutable) = 3D LUT + ├─ "DATA": blob + └─ "NEXT" (immutable) = 49 + + Color operation 49 + ├─ "TYPE" (immutable) = 1D enumerated curve + ├─ "BYPASS": bool + ├─ "CURVE_1D_TYPE": enum {sRGB EOTF, PQ EOTF} = sRGB EOTF + └─ "NEXT" (immutable) = 0 + + +Color Pipeline Programming +========================== + +Once a DRM client has found a suitable pipeline it will: + +1. Set the COLOR_PIPELINE enum value to the one pointing at the first + drm_colorop object of the desired pipeline +2. Set the properties for all drm_colorop objects in the pipeline to the + desired values, setting BYPASS to true for unused drm_colorop blocks, + and false for enabled drm_colorop blocks +3. Perform (TEST_ONLY or not) atomic commit with all the other KMS + states it wishes to change + +To configure the pipeline for an HDR10 PQ plane and blending in linear +space, a compositor might perform an atomic commit with the following +property values:: + + Plane 10 + └─ "COLOR_PIPELINE" = 42 + + Color operation 42 + └─ "BYPASS" = true + + Color operation 44 + └─ "BYPASS" = true + + Color operation 45 + └─ "BYPASS" = true + + Color operation 46 + └─ "BYPASS" = true + + Color operation 47 + ├─ "DATA" = Gamut mapping + tone mapping + night mode + └─ "BYPASS" = false + + Color operation 48 + ├─ "CURVE_1D_TYPE" = PQ EOTF + └─ "BYPASS" = false + + +Driver Implementer's Guide +========================== + +What does this all mean for driver implementations? As noted above the +colorops can map to HW directly but don't need to do so. Here are some +suggestions on how to think about creating your color pipelines: + +- Try to expose pipelines that use already defined colorops, even if + your hardware pipeline is split differently. This allows existing + userspace to immediately take advantage of the hardware. + +- Additionally, try to expose your actual hardware blocks as colorops. + Define new colorop types where you believe it can offer significant + benefits if userspace learns to program them. + +- Avoid defining new colorops for compound operations with very narrow + scope. If you have a hardware block for a special operation that + cannot be split further, you can expose that as a new colorop type. + However, try to not define colorops for "use cases", especially if + they require you to combine multiple hardware blocks. + +- Design new colorops as prescriptive, not descriptive; by the + mathematical formula, not by the assumed input and output. + +A defined colorop type must be deterministic. The exact behavior of the +colorop must be documented entirely, whether via a mathematical formula +or some other description. Its operation can depend only on its +properties and input and nothing else, allowed error tolerance +notwithstanding. + + +Driver Forward/Backward Compatibility +===================================== + +As this is uAPI drivers can't regress color pipelines that have been +introduced for a given HW generation. New HW generations are free to +abandon color pipelines advertised for previous generations. +Nevertheless, it can be beneficial to carry support for existing color +pipelines forward as those will likely already have support in DRM +clients. + +Introducing new colorops to a pipeline is fine, as long as they can be +bypassed or are purely informational. DRM clients implementing support +for the pipeline can always skip unknown properties as long as they can +be confident that doing so will not cause unexpected results. + +If a new colorop doesn't fall into one of the above categories +(bypassable or informational) the modified pipeline would be unusable +for user space. In this case a new pipeline should be defined. + + +References +========== + +1. https://lore.kernel.org/dri-devel/QMers3awXvNCQlyhWdTtsPwkp5ie9bze_hD5nAccFW7a_RXlWjYB7MoUW_8CKLT2bSQwIXVi5H6VULYIxCdgvryZoAoJnC5lZgyK1QWn488=@emersion.fr/
\ No newline at end of file diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index 396e535377fb..ef19b0ba2a3e 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -35,3 +35,6 @@ host such documentation: .. toctree:: i915_vm_bind.rst + +.. toctree:: + color_pipeline.rst
\ No newline at end of file diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index b5f58b4274b1..9013ced318cb 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -623,6 +623,43 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de>, Simona Vetter Level: Advanced +Implement a new DUMB_CREATE2 ioctl +---------------------------------- + +The current DUMB_CREATE ioctl is not well defined. Instead of a pixel and +framebuffer format, it only accepts a color mode of vague semantics. Assuming +a linear framebuffer, the color mode gives an idea of the supported pixel +format. But userspace effectively has to guess the correct values. It really +only works reliably with framebuffers in XRGB8888. Userspace has begun to +workaround these limitations by computing arbitrary format's buffer sizes and +calculating their sizes in terms of XRGB8888 pixels. + +One possible solution is a new ioctl DUMB_CREATE2. It should accept a DRM +format and a format modifier to resolve the color mode's ambiguity. As +framebuffers can be multi-planar, the new ioctl has to return the buffer size, +pitch and GEM handle for each individual color plane. + +In the first step, the new ioctl can be limited to the current features of +the existing DUMB_CREATE. Individual drivers can then be extended to support +multi-planar formats. Rockchip might require this and would be a good candidate. + +It might also be helpful to userspace to query information about the size of +a potential buffer, if allocated. Userspace would supply geometry and format; +the kernel would return minimal allocation sizes and scanline pitch. There is +interest to allocate that memory from another device and provide it to the +DRM driver (say via dma-buf). + +Another requested feature is the ability to allocate a buffer by size, without +format. Accelators use this for their buffer allocation and it could likely be +generalized. + +In addition to the kernel implementation, there must be user-space support +for the new ioctl. There's code in Mesa that might be able to use the new +call. + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Advanced Better Testing ============== diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 8a8b1002931f..1e79e62a6bc4 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -51,6 +51,97 @@ To disable the driver, use :: sudo modprobe -r vkms +Configuring With Configfs +========================= + +It is possible to create and configure multiple VKMS instances via configfs. + +Start by mounting configfs and loading VKMS:: + + sudo mount -t configfs none /config + sudo modprobe vkms + +Once VKMS is loaded, ``/config/vkms`` is created automatically. Each directory +under ``/config/vkms`` represents a VKMS instance, create a new one:: + + sudo mkdir /config/vkms/my-vkms + +By default, the instance is disabled:: + + cat /config/vkms/my-vkms/enabled + 0 + +And directories are created for each configurable item of the display pipeline:: + + tree /config/vkms/my-vkms + ├── connectors + ├── crtcs + ├── enabled + ├── encoders + └── planes + +To add items to the display pipeline, create one or more directories under the +available paths. + +Start by creating one or more planes:: + + sudo mkdir /config/vkms/my-vkms/planes/plane0 + +Planes have 1 configurable attribute: + +- type: Plane type: 0 overlay, 1 primary, 2 cursor (same values as those + exposed by the "type" property of a plane) + +Continue by creating one or more CRTCs:: + + sudo mkdir /config/vkms/my-vkms/crtcs/crtc0 + +CRTCs have 1 configurable attribute: + +- writeback: Enable or disable writeback connector support by writing 1 or 0 + +Next, create one or more encoders:: + + sudo mkdir /config/vkms/my-vkms/encoders/encoder0 + +Last but not least, create one or more connectors:: + + sudo mkdir /config/vkms/my-vkms/connectors/connector0 + +Connectors have 1 configurable attribute: + +- status: Connection status: 1 connected, 2 disconnected, 3 unknown (same values + as those exposed by the "status" property of a connector) + +To finish the configuration, link the different pipeline items:: + + sudo ln -s /config/vkms/my-vkms/crtcs/crtc0 /config/vkms/my-vkms/planes/plane0/possible_crtcs + sudo ln -s /config/vkms/my-vkms/crtcs/crtc0 /config/vkms/my-vkms/encoders/encoder0/possible_crtcs + sudo ln -s /config/vkms/my-vkms/encoders/encoder0 /config/vkms/my-vkms/connectors/connector0/possible_encoders + +Since at least one primary plane is required, make sure to set the right type:: + + echo "1" | sudo tee /config/vkms/my-vkms/planes/plane0/type + +Once you are done configuring the VKMS instance, enable it:: + + echo "1" | sudo tee /config/vkms/my-vkms/enabled + +Finally, you can remove the VKMS instance disabling it:: + + echo "0" | sudo tee /config/vkms/my-vkms/enabled + +And removing the top level directory and its subdirectories:: + + sudo rm /config/vkms/my-vkms/planes/*/possible_crtcs/* + sudo rm /config/vkms/my-vkms/encoders/*/possible_crtcs/* + sudo rm /config/vkms/my-vkms/connectors/*/possible_encoders/* + sudo rmdir /config/vkms/my-vkms/planes/* + sudo rmdir /config/vkms/my-vkms/crtcs/* + sudo rmdir /config/vkms/my-vkms/encoders/* + sudo rmdir /config/vkms/my-vkms/connectors/* + sudo rmdir /config/vkms/my-vkms + Testing With IGT ================ @@ -68,26 +159,23 @@ To return to graphical mode, do:: sudo systemctl isolate graphical.target -Once you are in text only mode, you can run tests using the --device switch -or IGT_DEVICE variable to specify the device filter for the driver we want -to test. IGT_DEVICE can also be used with the run-test.sh script to run the +Once you are in text only mode, you can run tests using the IGT_FORCE_DRIVER +variable to specify the device filter for the driver we want to test. +IGT_FORCE_DRIVER can also be used with the run-tests.sh script to run the tests for a specific driver:: - sudo ./build/tests/<name of test> --device "sys:/sys/devices/platform/vkms" - sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/<name of test> - sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t <name of test> + sudo IGT_FORCE_DRIVER="vkms" ./build/tests/<name of test> + sudo IGT_FORCE_DRIVER="vkms" ./scripts/run-tests.sh -t <name of test> For example, to test the functionality of the writeback library, we can run the kms_writeback test:: - sudo ./build/tests/kms_writeback --device "sys:/sys/devices/platform/vkms" - sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_writeback - sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./scripts/run-tests.sh -t kms_writeback + sudo IGT_FORCE_DRIVER="vkms" ./build/tests/kms_writeback + sudo IGT_FORCE_DRIVER="vkms" ./scripts/run-tests.sh -t kms_writeback You can also run subtests if you do not want to run the entire test:: - sudo ./build/tests/kms_flip --run-subtest basic-plain-flip --device "sys:/sys/devices/platform/vkms" - sudo IGT_DEVICE="sys:/sys/devices/platform/vkms" ./build/tests/kms_flip --run-subtest basic-plain-flip + sudo IGT_FORCE_DRIVER="vkms" ./build/tests/kms_flip --run-subtest basic-plain-flip Testing With KUnit ================== @@ -147,21 +235,14 @@ Runtime Configuration --------------------- We want to be able to reconfigure vkms instance without having to reload the -module. Use/Test-cases: +module through configfs. Use/Test-cases: - Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of compositors). -- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of - them first). - - Change output configuration: Plug/unplug screens, change EDID, allow changing the refresh rate. -The currently proposed solution is to expose vkms configuration through -configfs. All existing module options should be supported through configfs -too. - Writeback support ----------------- diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst index 88b22fad880e..bc432c95d1a3 100644 --- a/Documentation/gpu/xe/index.rst +++ b/Documentation/gpu/xe/index.rst @@ -14,6 +14,7 @@ DG2, etc is provided to prototype the driver. xe_mm xe_map xe_migrate + xe_exec_queue xe_cs xe_pm xe_gt_freq diff --git a/Documentation/gpu/xe/xe_exec_queue.rst b/Documentation/gpu/xe/xe_exec_queue.rst new file mode 100644 index 000000000000..6076569e311c --- /dev/null +++ b/Documentation/gpu/xe/xe_exec_queue.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT) + +=============== +Execution Queue +=============== + +.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue.c + :doc: Execution Queue + +Internal API +============ + +.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue_types.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/xe/xe_exec_queue.c + :internal: diff --git a/Documentation/gpu/xe/xe_gt_freq.rst b/Documentation/gpu/xe/xe_gt_freq.rst index c0811200e327..182d6aabeee1 100644 --- a/Documentation/gpu/xe/xe_gt_freq.rst +++ b/Documentation/gpu/xe/xe_gt_freq.rst @@ -7,6 +7,9 @@ Xe GT Frequency Management .. kernel-doc:: drivers/gpu/drm/xe/xe_gt_freq.c :doc: Xe GT Frequency Management +.. kernel-doc:: drivers/gpu/drm/xe/xe_gt_throttle.c + :doc: Xe GT Throttle + Internal API ============ diff --git a/Documentation/userspace-api/dma-buf-heaps.rst b/Documentation/userspace-api/dma-buf-heaps.rst index 1dfe5e7acd5a..05445c83b79a 100644 --- a/Documentation/userspace-api/dma-buf-heaps.rst +++ b/Documentation/userspace-api/dma-buf-heaps.rst @@ -16,13 +16,52 @@ following heaps: - The ``system`` heap allocates virtually contiguous, cacheable, buffers. - - The ``cma`` heap allocates physically contiguous, cacheable, - buffers. Only present if a CMA region is present. Such a region is - usually created either through the kernel commandline through the - ``cma`` parameter, a memory region Device-Tree node with the - ``linux,cma-default`` property set, or through the ``CMA_SIZE_MBYTES`` or - ``CMA_SIZE_PERCENTAGE`` Kconfig options. The heap's name in devtmpfs is - ``default_cma_region``. For backwards compatibility, when the - ``DMABUF_HEAPS_CMA_LEGACY`` Kconfig option is set, a duplicate node is - created following legacy naming conventions; the legacy name might be - ``reserved``, ``linux,cma``, or ``default-pool``. + - The ``default_cma_region`` heap allocates physically contiguous, + cacheable, buffers. Only present if a CMA region is present. Such a + region is usually created either through the kernel commandline + through the ``cma`` parameter, a memory region Device-Tree node with + the ``linux,cma-default`` property set, or through the + ``CMA_SIZE_MBYTES`` or ``CMA_SIZE_PERCENTAGE`` Kconfig options. Prior + to Linux 6.17, its name wasn't stable and could be called + ``reserved``, ``linux,cma``, or ``default-pool``, depending on the + platform. + + - A heap will be created for each reusable region in the device tree + with the ``shared-dma-pool`` compatible, using the full device tree + node name as its name. The buffer semantics are identical to + ``default-cma-region``. + +Naming Convention +================= + +``dma-buf`` heaps name should meet a number of constraints: + +- The name must be stable, and must not change from one version to the other. + Userspace identifies heaps by their name, so if the names ever change, we + would be likely to introduce regressions. + +- The name must describe the memory region the heap will allocate from, and + must uniquely identify it in a given platform. Since userspace applications + use the heap name as the discriminant, it must be able to tell which heap it + wants to use reliably if there's multiple heaps. + +- The name must not mention implementation details, such as the allocator. The + heap driver will change over time, and implementation details when it was + introduced might not be relevant in the future. + +- The name should describe properties of the buffers that would be allocated. + Doing so will make heap identification easier for userspace. Such properties + are: + + - ``contiguous`` for physically contiguous buffers; + + - ``protected`` for encrypted buffers not accessible the OS; + +- The name may describe intended usage. Doing so will make heap identification + easier for userspace applications and users. + +For example, assuming a platform with a reserved memory region located +at the RAM address 0x42000000, intended to allocate video framebuffers, +physically contiguous, and backed by the CMA kernel allocator, good +names would be ``memory@42000000-contiguous`` or ``video@42000000``, but +``cma-video`` wouldn't. diff --git a/Documentation/userspace-api/media/drivers/index.rst b/Documentation/userspace-api/media/drivers/index.rst index d706cb47b112..02967c9b18d6 100644 --- a/Documentation/userspace-api/media/drivers/index.rst +++ b/Documentation/userspace-api/media/drivers/index.rst @@ -32,6 +32,7 @@ For more details see the file COPYING in the source distribution of Linux. cx2341x-uapi dw100 imx-uapi + mali-c55 max2175 npcm-video omap3isp-uapi diff --git a/Documentation/userspace-api/media/drivers/mali-c55.rst b/Documentation/userspace-api/media/drivers/mali-c55.rst new file mode 100644 index 000000000000..21148b187856 --- /dev/null +++ b/Documentation/userspace-api/media/drivers/mali-c55.rst @@ -0,0 +1,55 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +Arm Mali-C55 ISP driver +======================= + +The Arm Mali-C55 ISP driver implements a single driver-specific control: + +``V4L2_CID_MALI_C55_CAPABILITIES (bitmask)`` + Detail the capabilities of the ISP by giving detail about the fitted blocks. + + .. flat-table:: Bitmask meaning definitions + :header-rows: 1 + :widths: 2 4 8 + + * - Bit + - Macro + - Meaning + * - 0 + - MALI_C55_PONG + - Pong configuration space is fitted in the ISP + * - 1 + - MALI_C55_WDR + - WDR Framestitch, offset and gain is fitted in the ISP + * - 2 + - MALI_C55_COMPRESSION + - Temper compression is fitted in the ISP + * - 3 + - MALI_C55_TEMPER + - Temper is fitted in the ISP + * - 4 + - MALI_C55_SINTER_LITE + - Sinter Lite is fitted in the ISP instead of the full Sinter version + * - 5 + - MALI_C55_SINTER + - Sinter is fitted in the ISP + * - 6 + - MALI_C55_IRIDIX_LTM + - Iridix local tone mappine is fitted in the ISP + * - 7 + - MALI_C55_IRIDIX_GTM + - Iridix global tone mapping is fitted in the ISP + * - 8 + - MALI_C55_CNR + - Colour noise reduction is fitted in the ISP + * - 9 + - MALI_C55_FRSCALER + - The full resolution pipe scaler is fitted in the ISP + * - 10 + - MALI_C55_DS_PIPE + - The downscale pipe is fitted in the ISP + + The Mali-C55 ISP can be configured in a number of ways to include or exclude + blocks which may not be necessary. This control provides a way for the + driver to communicate to userspace which of the blocks are fitted in the + design.
\ No newline at end of file diff --git a/Documentation/userspace-api/media/v4l/meta-formats.rst b/Documentation/userspace-api/media/v4l/meta-formats.rst index d9868ee88a07..3e0cab153f0a 100644 --- a/Documentation/userspace-api/media/v4l/meta-formats.rst +++ b/Documentation/userspace-api/media/v4l/meta-formats.rst @@ -13,6 +13,7 @@ These formats are used for the :ref:`metadata` interface only. .. toctree:: :maxdepth: 1 + metafmt-arm-mali-c55 metafmt-c3-isp metafmt-d4xx metafmt-generic @@ -25,3 +26,4 @@ These formats are used for the :ref:`metadata` interface only. metafmt-vivid metafmt-vsp1-hgo metafmt-vsp1-hgt + v4l2-isp diff --git a/Documentation/userspace-api/media/v4l/metafmt-arm-mali-c55.rst b/Documentation/userspace-api/media/v4l/metafmt-arm-mali-c55.rst new file mode 100644 index 000000000000..696e0a645a7e --- /dev/null +++ b/Documentation/userspace-api/media/v4l/metafmt-arm-mali-c55.rst @@ -0,0 +1,84 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _v4l2-meta-fmt-mali-c55-params: +.. _v4l2-meta-fmt-mali-c55-stats: + +***************************************************************************** +V4L2_META_FMT_MALI_C55_STATS ('C55S'), V4L2_META_FMT_MALI_C55_PARAMS ('C55P') +***************************************************************************** + +3A Statistics +============= + +The ISP device collects different statistics over an input bayer frame. Those +statistics can be obtained by userspace from the +:ref:`mali-c55 3a stats <mali-c55-3a-stats>` metadata capture video node, using +the :c:type:`v4l2_meta_format` interface. The buffer contains a single instance +of the C structure :c:type:`mali_c55_stats_buffer` defined in +``mali-c55-config.h``, so the structure can be obtained from the buffer by: + +.. code-block:: C + + struct mali_c55_stats_buffer *stats = + (struct mali_c55_stats_buffer *)buf; + +For details of the statistics see :c:type:`mali_c55_stats_buffer`. + +Configuration Parameters +======================== + +The configuration parameters are passed to the :ref:`mali-c55 3a params +<mali-c55-3a-params>` metadata output video node, using the +:c:type:`v4l2_meta_format` interface. Rather than a single struct containing +sub-structs for each configurable area of the ISP, parameters for the Mali-C55 +use the v4l2-isp parameters system, through which groups of parameters are +defined as distinct structs or "blocks" which may be added to the data member of +:c:type:`v4l2_isp_params_buffer`. Userspace is responsible for populating the +data member with the blocks that need to be configured by the driver. Each +block-specific struct embeds :c:type:`v4l2_isp_params_block_header` as its first +member and userspace must populate the type member with a value from +:c:type:`mali_c55_param_block_type`. + +.. code-block:: c + + struct v4l2_isp_params_buffer *params = + (struct v4l2_isp_params_buffer *)buffer; + + params->version = MALI_C55_PARAM_BUFFER_V1; + params->data_size = 0; + + void *data = (void *)params->data; + + struct mali_c55_params_awb_gains *gains = + (struct mali_c55_params_awb_gains *)data; + + gains->header.type = MALI_C55_PARAM_BLOCK_AWB_GAINS; + gains->header.flags |= V4L2_ISP_PARAMS_FL_BLOCK_ENABLE; + gains->header.size = sizeof(struct mali_c55_params_awb_gains); + + gains->gain00 = 256; + gains->gain00 = 256; + gains->gain00 = 256; + gains->gain00 = 256; + + data += sizeof(struct mali_c55_params_awb_gains); + params->data_size += sizeof(struct mali_c55_params_awb_gains); + + struct mali_c55_params_sensor_off_preshading *blc = + (struct mali_c55_params_sensor_off_preshading *)data; + + blc->header.type = MALI_C55_PARAM_BLOCK_SENSOR_OFFS; + blc->header.flags |= V4L2_ISP_PARAMS_FL_BLOCK_ENABLE; + blc->header.size = sizeof(struct mali_c55_params_sensor_off_preshading); + + blc->chan00 = 51200; + blc->chan01 = 51200; + blc->chan10 = 51200; + blc->chan11 = 51200; + + params->data_size += sizeof(struct mali_c55_params_sensor_off_preshading); + +Arm Mali-C55 uAPI data types +============================ + +.. kernel-doc:: include/uapi/linux/media/arm/mali-c55-config.h diff --git a/Documentation/userspace-api/media/v4l/subdev-formats.rst b/Documentation/userspace-api/media/v4l/subdev-formats.rst index 1904390df830..cf970750dd4c 100644 --- a/Documentation/userspace-api/media/v4l/subdev-formats.rst +++ b/Documentation/userspace-api/media/v4l/subdev-formats.rst @@ -2225,6 +2225,174 @@ The following table list existing packed 48bit wide RGB formats. \endgroup +The following table list existing packed 60bit wide RGB formats. + +.. tabularcolumns:: |p{4.0cm}|p{0.7cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| + +.. _v4l2-mbus-pixelcode-rgb-60: + +.. raw:: latex + + \begingroup + \tiny + \setlength{\tabcolsep}{2pt} + +.. flat-table:: 60bit RGB formats + :header-rows: 3 + :stub-columns: 0 + :widths: 36 7 3 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 + + * - Identifier + - Code + - + - :cspan:`31` Data organization + * - + - + - Bit + - + - + - + - + - 59 + - 58 + - 57 + - 56 + - 55 + - 54 + - 53 + - 52 + - 51 + - 50 + - 49 + - 48 + - 47 + - 46 + - 45 + - 44 + - 43 + - 42 + - 41 + - 40 + - 39 + - 38 + - 37 + - 36 + - 35 + - 34 + - 33 + - 32 + * - + - + - + - 31 + - 30 + - 29 + - 28 + - 27 + - 26 + - 25 + - 24 + - 23 + - 22 + - 21 + - 20 + - 19 + - 18 + - 17 + - 16 + - 15 + - 14 + - 13 + - 12 + - 11 + - 10 + - 9 + - 8 + - 7 + - 6 + - 5 + - 4 + - 3 + - 2 + - 1 + - 0 + * .. _MEDIA-BUS-FMT-RGB202020-1X60: + + - MEDIA_BUS_FMT_RGB202020_1X60 + - 0x1026 + - + - + - + - + - + - r\ :sub:`19` + - r\ :sub:`18` + - r\ :sub:`17` + - r\ :sub:`16` + - r\ :sub:`15` + - r\ :sub:`14` + - r\ :sub:`13` + - r\ :sub:`12` + - r\ :sub:`11` + - r\ :sub:`10` + - r\ :sub:`9` + - r\ :sub:`8` + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + - g\ :sub:`19` + - g\ :sub:`18` + - g\ :sub:`17` + - g\ :sub:`16` + - g\ :sub:`15` + - g\ :sub:`14` + - g\ :sub:`13` + - g\ :sub:`12` + * - + - + - + - g\ :sub:`11` + - g\ :sub:`10` + - g\ :sub:`9` + - g\ :sub:`8` + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + - b\ :sub:`19` + - b\ :sub:`18` + - b\ :sub:`17` + - b\ :sub:`16` + - b\ :sub:`15` + - b\ :sub:`14` + - b\ :sub:`13` + - b\ :sub:`12` + - b\ :sub:`11` + - b\ :sub:`10` + - b\ :sub:`9` + - b\ :sub:`8` + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + +.. raw:: latex + + \endgroup + On LVDS buses, usually each sample is transferred serialized in seven time slots per pixel clock, on three (18-bit) or four (24-bit) or five (30-bit) differential data pairs at the same time. The remaining bits are used @@ -2649,7 +2817,7 @@ organization is given as an example for the first pixel only. \tiny \setlength{\tabcolsep}{2pt} -.. tabularcolumns:: |p{6.0cm}|p{0.7cm}|p{0.3cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| +.. tabularcolumns:: |p{6.0cm}|p{0.7cm}|p{0.3cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}|p{0.22cm}| .. _v4l2-mbus-pixelcode-bayer: @@ -2662,10 +2830,14 @@ organization is given as an example for the first pixel only. * - Identifier - Code - - - :cspan:`15` Data organization + - :cspan:`19` Data organization * - - - Bit + - 19 + - 18 + - 17 + - 16 - 15 - 14 - 13 @@ -2695,6 +2867,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`7` - b\ :sub:`6` - b\ :sub:`5` @@ -2716,6 +2892,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`7` - g\ :sub:`6` - g\ :sub:`5` @@ -2737,6 +2917,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`7` - g\ :sub:`6` - g\ :sub:`5` @@ -2758,6 +2942,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - r\ :sub:`7` - r\ :sub:`6` - r\ :sub:`5` @@ -2779,6 +2967,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`7` - b\ :sub:`6` - b\ :sub:`5` @@ -2800,6 +2992,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`7` - g\ :sub:`6` - g\ :sub:`5` @@ -2821,6 +3017,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`7` - g\ :sub:`6` - g\ :sub:`5` @@ -2842,6 +3042,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - r\ :sub:`7` - r\ :sub:`6` - r\ :sub:`5` @@ -2863,6 +3067,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`7` - b\ :sub:`6` - b\ :sub:`5` @@ -2884,6 +3092,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`7` - g\ :sub:`6` - g\ :sub:`5` @@ -2905,6 +3117,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`7` - g\ :sub:`6` - g\ :sub:`5` @@ -2926,6 +3142,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - r\ :sub:`7` - r\ :sub:`6` - r\ :sub:`5` @@ -2947,6 +3167,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - 0 - 0 - 0 @@ -2966,6 +3190,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`7` - b\ :sub:`6` - b\ :sub:`5` @@ -2987,6 +3215,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`7` - b\ :sub:`6` - b\ :sub:`5` @@ -3006,6 +3238,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - 0 - 0 - 0 @@ -3027,6 +3263,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`9` - b\ :sub:`8` - b\ :sub:`7` @@ -3046,6 +3286,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`1` - b\ :sub:`0` - 0 @@ -3067,6 +3311,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`1` - b\ :sub:`0` - 0 @@ -3086,6 +3334,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`9` - b\ :sub:`8` - b\ :sub:`7` @@ -3105,6 +3357,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`9` - b\ :sub:`8` - b\ :sub:`7` @@ -3126,6 +3382,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`9` - g\ :sub:`8` - g\ :sub:`7` @@ -3147,6 +3407,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`9` - g\ :sub:`8` - g\ :sub:`7` @@ -3168,6 +3432,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - r\ :sub:`9` - r\ :sub:`8` - r\ :sub:`7` @@ -3187,6 +3455,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`11` - b\ :sub:`10` - b\ :sub:`9` @@ -3208,6 +3480,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`11` - g\ :sub:`10` - g\ :sub:`9` @@ -3229,6 +3505,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`11` - g\ :sub:`10` - g\ :sub:`9` @@ -3250,6 +3530,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - r\ :sub:`11` - r\ :sub:`10` - r\ :sub:`9` @@ -3269,6 +3553,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - b\ :sub:`13` - b\ :sub:`12` - b\ :sub:`11` @@ -3290,6 +3578,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`13` - g\ :sub:`12` - g\ :sub:`11` @@ -3311,6 +3603,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - g\ :sub:`13` - g\ :sub:`12` - g\ :sub:`11` @@ -3332,6 +3628,10 @@ organization is given as an example for the first pixel only. - - - + - + - + - + - - r\ :sub:`13` - r\ :sub:`12` - r\ :sub:`11` @@ -3351,6 +3651,10 @@ organization is given as an example for the first pixel only. - MEDIA_BUS_FMT_SBGGR16_1X16 - 0x301d - + - + - + - + - - b\ :sub:`15` - b\ :sub:`14` - b\ :sub:`13` @@ -3372,6 +3676,10 @@ organization is given as an example for the first pixel only. - MEDIA_BUS_FMT_SGBRG16_1X16 - 0x301e - + - + - + - + - - g\ :sub:`15` - g\ :sub:`14` - g\ :sub:`13` @@ -3393,6 +3701,10 @@ organization is given as an example for the first pixel only. - MEDIA_BUS_FMT_SGRBG16_1X16 - 0x301f - + - + - + - + - - g\ :sub:`15` - g\ :sub:`14` - g\ :sub:`13` @@ -3414,6 +3726,110 @@ organization is given as an example for the first pixel only. - MEDIA_BUS_FMT_SRGGB16_1X16 - 0x3020 - + - + - + - + - + - r\ :sub:`15` + - r\ :sub:`14` + - r\ :sub:`13` + - r\ :sub:`12` + - r\ :sub:`11` + - r\ :sub:`10` + - r\ :sub:`9` + - r\ :sub:`8` + - r\ :sub:`7` + - r\ :sub:`6` + - r\ :sub:`5` + - r\ :sub:`4` + - r\ :sub:`3` + - r\ :sub:`2` + - r\ :sub:`1` + - r\ :sub:`0` + * .. _MEDIA-BUS-FMT-SBGGR20-1X20: + + - MEDIA_BUS_FMT_SBGGR20_1X20 + - 0x3021 + - + - b\ :sub:`19` + - b\ :sub:`18` + - b\ :sub:`17` + - b\ :sub:`16` + - b\ :sub:`15` + - b\ :sub:`14` + - b\ :sub:`13` + - b\ :sub:`12` + - b\ :sub:`11` + - b\ :sub:`10` + - b\ :sub:`9` + - b\ :sub:`8` + - b\ :sub:`7` + - b\ :sub:`6` + - b\ :sub:`5` + - b\ :sub:`4` + - b\ :sub:`3` + - b\ :sub:`2` + - b\ :sub:`1` + - b\ :sub:`0` + * .. _MEDIA-BUS-FMT-SGBRG20-1X20: + + - MEDIA_BUS_FMT_SGBRG20_1X20 + - 0x3022 + - + - g\ :sub:`19` + - g\ :sub:`18` + - g\ :sub:`17` + - g\ :sub:`16` + - g\ :sub:`15` + - g\ :sub:`14` + - g\ :sub:`13` + - g\ :sub:`12` + - g\ :sub:`11` + - g\ :sub:`10` + - g\ :sub:`9` + - g\ :sub:`8` + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + * .. _MEDIA-BUS-FMT-SGRBG20-1X20: + + - MEDIA_BUS_FMT_SGRBG20_1X20 + - 0x3023 + - + - g\ :sub:`19` + - g\ :sub:`18` + - g\ :sub:`17` + - g\ :sub:`16` + - g\ :sub:`15` + - g\ :sub:`14` + - g\ :sub:`13` + - g\ :sub:`12` + - g\ :sub:`11` + - g\ :sub:`10` + - g\ :sub:`9` + - g\ :sub:`8` + - g\ :sub:`7` + - g\ :sub:`6` + - g\ :sub:`5` + - g\ :sub:`4` + - g\ :sub:`3` + - g\ :sub:`2` + - g\ :sub:`1` + - g\ :sub:`0` + * .. _MEDIA-BUS-FMT-SRGGB20-1X20: + + - MEDIA_BUS_FMT_SRGGB20_1X20 + - 0x3024 + - + - r\ :sub:`19` + - r\ :sub:`18` + - r\ :sub:`17` + - r\ :sub:`16` - r\ :sub:`15` - r\ :sub:`14` - r\ :sub:`13` diff --git a/Documentation/userspace-api/media/v4l/v4l2-isp.rst b/Documentation/userspace-api/media/v4l/v4l2-isp.rst new file mode 100644 index 000000000000..facf6dba1ca7 --- /dev/null +++ b/Documentation/userspace-api/media/v4l/v4l2-isp.rst @@ -0,0 +1,67 @@ +.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later + +.. _v4l2-isp: + +************************ +Generic V4L2 ISP formats +************************ + +Generic ISP formats are metadata formats that define a mechanism to pass ISP +parameters and statistics between userspace and drivers in V4L2 buffers. They +are designed to allow extending them in a backward-compatible way. + +ISP parameters +============== + +The generic ISP configuration parameters format is realized by a defining a +single C structure that contains a header, followed by a binary buffer where +userspace programs a variable number of ISP configuration data block, one for +each supported ISP feature. + +The :c:type:`v4l2_isp_params_buffer` structure defines the buffer header which +is followed by a binary buffer of ISP configuration data. Userspace shall +correctly populate the buffer header with the generic parameters format version +and with the size (in bytes) of the binary data buffer where it will store the +ISP blocks configuration. + +Each *ISP configuration block* is preceded by an header implemented by the +:c:type:`v4l2_isp_params_block_header` structure, followed by the configuration +parameters for that specific block, defined by the ISP driver specific data +types. + +Userspace applications are responsible for correctly populating each block's +header fields (type, flags and size) and the block-specific parameters. + +ISP block enabling, disabling and configuration +----------------------------------------------- + +When userspace wants to configure and enable an ISP block it shall fully +populate the block configuration and set the V4L2_ISP_PARAMS_FL_BLOCK_ENABLE +bit in the block header's `flags` field. + +When userspace simply wants to disable an ISP block the +V4L2_ISP_PARAMS_FL_BLOCK_DISABLE bit should be set in block header's `flags` +field. Drivers accept a configuration parameters block with no additional +data after the header in this case. + +If the configuration of an already active ISP block has to be updated, +userspace shall fully populate the ISP block parameters and omit setting the +V4L2_ISP_PARAMS_FL_BLOCK_ENABLE and V4L2_ISP_PARAMS_FL_BLOCK_DISABLE bits in the +header's `flags` field. + +Setting both the V4L2_ISP_PARAMS_FL_BLOCK_ENABLE and +V4L2_ISP_PARAMS_FL_BLOCK_DISABLE bits in the flags field is not allowed and +returns an error. + +Extension to the parameters format can be implemented by adding new blocks +definition without invalidating the existing ones. + +ISP statistics +============== + +Support for generic statistics format is not yet implemented in Video4Linux2. + +V4L2 ISP uAPI data types +======================== + +.. kernel-doc:: include/uapi/linux/media/v4l2-isp.h diff --git a/Documentation/userspace-api/media/v4l/vidioc-remove-bufs.rst b/Documentation/userspace-api/media/v4l/vidioc-remove-bufs.rst index 1995b39af9ba..b498d60752d7 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-remove-bufs.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-remove-bufs.rst @@ -54,7 +54,7 @@ are invoked. - ``count`` - The number of buffers to be removed with indices 'index' until 'index + count - 1'. All buffers in this range must be valid and in DEQUEUED state. - :ref:`VIDIOC_REMOVE_BUFS` will always check the validity of ``type`, if it is + :ref:`VIDIOC_REMOVE_BUFS` will always check the validity of ``type``, if it is invalid it returns ``EINVAL`` error code. If count is set to 0 :ref:`VIDIOC_REMOVE_BUFS` will do nothing and return 0. * - __u32 |