* [PATCH v1 05/11] dt-bindings: media: Add nxp neoisp support
From: Antoine Bouyer @ 2026-04-13 16:03 UTC (permalink / raw)
To: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, michael.riesch, anthony.mcgivern
Cc: linux-media, linux-kernel, devicetree, imx, ai.luthra, paul.elder,
Antoine Bouyer
In-Reply-To: <20260413160331.2611829-1-antoine.bouyer@nxp.com>
Add the yaml binding for NXP's Neo Image Signal Processor (ISP).
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
---
.../bindings/media/nxp,imx95-neoisp.yaml | 62 +++++++++++++++++++
1 file changed, 62 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
diff --git a/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml b/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
new file mode 100644
index 000000000000..55ac10a065c1
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/nxp,neoisp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NXP NEOISP Image Signal Processing Pipeline
+
+maintainers:
+ - Antoine Bouyer <antoine.bouyer@nxp.com>
+
+description:
+ The NXP NEOISP performs a set of image processing tasks on the RAW camera
+ stream and provides RGB or YUV enhanced image.
+
+properties:
+ compatible:
+ enum:
+ - nxp,imx95-neoisp
+
+ reg:
+ items:
+ - description: The configuration registers
+ - description: ISP local memories
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ clock-names:
+ items:
+ - const: camcm0
+
+ power-domains:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+ - power-domains
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ isp@4ae00000 {
+ compatible = "nxp,neoisp-imx95-b0";
+ reg = <0x4ae00000 0x8000>,
+ <0x4afe0000 0x10000>;
+ interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-parent = <&gic>;
+ clocks = <&scmi_clk 64>; /* IMX95_CLK_CAMCM0 */
+ clock-names = "camcm0";
+ power-domains = <&scmi_devpd 3>; /* IMX95_PD_CAMERA */
+ };
--
2.51.0
^ permalink raw reply related
* [PATCH v1 04/11] media: Documentation: Add NXP neoisp driver documentation
From: Antoine Bouyer @ 2026-04-13 16:03 UTC (permalink / raw)
To: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, michael.riesch, anthony.mcgivern
Cc: linux-media, linux-kernel, devicetree, imx, ai.luthra, paul.elder,
Antoine Bouyer
In-Reply-To: <20260413160331.2611829-1-antoine.bouyer@nxp.com>
Document the NXP neoisp driver both in the admin-guide for neoisp IP
description, and in the userpace-api for neoisp interface description.
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
---
.../admin-guide/media/nxp-neoisp-diagram.dot | 22 +++
.../admin-guide/media/nxp-neoisp.dot | 16 ++
.../admin-guide/media/nxp-neoisp.rst | 179 ++++++++++++++++++
.../admin-guide/media/v4l-drivers.rst | 1 +
.../userspace-api/media/v4l/meta-formats.rst | 1 +
.../media/v4l/metafmt-nxp-neoisp.rst | 70 +++++++
6 files changed, 289 insertions(+)
create mode 100644 Documentation/admin-guide/media/nxp-neoisp-diagram.dot
create mode 100644 Documentation/admin-guide/media/nxp-neoisp.dot
create mode 100644 Documentation/admin-guide/media/nxp-neoisp.rst
create mode 100644 Documentation/userspace-api/media/v4l/metafmt-nxp-neoisp.rst
diff --git a/Documentation/admin-guide/media/nxp-neoisp-diagram.dot b/Documentation/admin-guide/media/nxp-neoisp-diagram.dot
new file mode 100644
index 000000000000..ac0d950bc1dc
--- /dev/null
+++ b/Documentation/admin-guide/media/nxp-neoisp-diagram.dot
@@ -0,0 +1,22 @@
+digraph G {
+ rankdir = "LR";
+ node [shape=rect];
+ splines = ortho;
+ label = "Neoisp pipeline diagram";
+ {In0, In1 } -> HC -> {HDR_decomp0, HDR_decomp1};
+ HDR_decomp0 -> OBWB0 -> HDR_merge;
+ HDR_decomp1 -> OBWB1 -> HDR_merge;
+ HDR_merge -> RGBIR -> IR_compression;
+ RGBIR -> Statistics;
+ RGBIR -> OBWB2 ->BNR -> Vignetting -> ColorTemp;
+ Vignetting -> Demosaic -> RGB2YUV -> DRC -> AF;
+ DRC-> NR -> EE -> DF -> Gamma -> Packetizer;
+ DRC -> DMAP -> DF[weight=2];
+ DRC -> CCONV -> CAS -> Gamma;
+ {rank = "same"; RGBIR, DRC}
+ {rank = "same"; AF, NR, DMAP}
+ {rank = "same"; IR_compression, Vignetting}
+ IR_compression -> AXIOutDMA;
+ Packetizer -> AXIOutDMA [weight=3];
+ AXIOutDMA -> {"Out0", "Out1"}
+}
diff --git a/Documentation/admin-guide/media/nxp-neoisp.dot b/Documentation/admin-guide/media/nxp-neoisp.dot
new file mode 100644
index 000000000000..abcc2dc9bb55
--- /dev/null
+++ b/Documentation/admin-guide/media/nxp-neoisp.dot
@@ -0,0 +1,16 @@
+digraph board {
+ rankdir=TB
+ n00000001 [label="{{<port0> 0 | <port1> 1 | <port2> 2} | neoisp\n | {<port3> 3 | <port4> 4 | <port5> 5}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000001:port3 -> n00000020 [style=dashed]
+ n00000001:port4 -> n00000022 [style=dashed]
+ n00000001:port5 -> n00000024 [style=dashed]
+ n0000000a [label="neoisp-input0\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
+ n0000000a -> n00000001:port0 [style=bold]
+ n00000010 [label="neoisp-input1\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
+ n00000010 -> n00000001:port1 [style=dashed]
+ n00000016 [label="neoisp-params\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
+ n00000016 -> n00000001:port2 [style=dashed]
+ n00000020 [label="neoisp-frame\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
+ n00000022 [label="neoisp-ir\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
+ n00000024 [label="neoisp-stats\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
+}
diff --git a/Documentation/admin-guide/media/nxp-neoisp.rst b/Documentation/admin-guide/media/nxp-neoisp.rst
new file mode 100644
index 000000000000..64876612065d
--- /dev/null
+++ b/Documentation/admin-guide/media/nxp-neoisp.rst
@@ -0,0 +1,179 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=======================================
+NXP Neo Image Signal Processor (neoisp)
+=======================================
+
+Introduction
+============
+
+Neoisp performs a set of image processing tasks on the RAW camera stream, where
+the input camera stream and Neoisp processed output image are stored in DDR or
+any system memory fast enough to keep up with Neoisp processing.
+The overall Neoisp operation is frame based, that is 1 complete image frame is
+read and output pixel by pixel, line by line wise.
+
+Revisions
+=========
+
+NXP Neoisp driver supports the Neoisp V2 hw revision, used in i.MX95 Soc family.
+
+Neoisp hardware
+===============
+
+The Neoisp registers and pipeline processing are documented in the NXP Image
+Signal Processor Specification document (under NDA).
+
+The NEO pipeline block diagram is shown below:
+
+.. kernel-figure:: nxp-neoisp-diagram.dot
+ :alt: Diagram of neoisp pipeline
+ :align: center
+
+It is composed by the following HW blocks:
+
+- a Head Color (HC) selection block,
+- two HDR decompression blocks, one for each input,
+- three Optical Black correction and White Balance (OBWB) blocks at different
+ stages in the pipeline,
+- a HDR merge block for HDR image capture from the 2 input lines,
+- a RGB-IR to RGGB converter,
+- a Bayer Noise Reduction (BNR) block,
+- a Vignetting block, aka Lens Shading Correction (LSC),
+- a Demosaic block for RAW image conversion to RGB,
+- a RGB Color Correction Matrix (CCM) and Color Space Converter aka CSC or
+ RGB2YUV,
+- a Dynamic Range Compression (DRC) block,
+- the Denoising pipeline (composed by multiple blocks for Noise Reduction, Edge
+ Enhancement, Gamma Compensation, etc),
+- a Packetizer used for UV sub-sampling or RGB packing.
+
+All these blocks are controlled by SW through registers. Some of these
+registers are accessible by the uAPI, so that usespace application and Image
+Processing Algorithms (IPA) can configure them through the parameters buffers.
+
+Neoisp driver
+=============
+
+Neoisp driver is located under drivers/media/platform/nxp/neoisp.
+It uses the `V4L2 API` and the `V4L2 subdev API` to register capture and output
+video devices in addition to a subdevice for neoisp that connects the video
+devices into a media graph realized using the `Media Controller (MC) API`.
+
+Driver provides a core registration API that allows registering the neoisp core
+media devices into an external media graph. In this case, the neoisp is fully
+integrated into a main media graph which could include other subdevices such as
+camera sensors, crossbar routing, etc. It also provides a module parameter to
+allow running in standalone mode. In such case, the neoisp registers its media
+devices into its own media graph.
+
+The media topology registered by Neoisp driver is represented below:
+
+.. kernel-figure:: nxp-neoisp.dot
+ :alt: Diagram of neoisp media device topology
+ :align: center
+
+
+The neoisp registers the following video device nodes:
+
+- neoisp-input0: output device for RAW frames to be submitted to the ISP for processing.
+- neoisp-input1: output device for RAW frames short capture in HDR merge mode.
+- neoisp-params: output meta device for parameters provided by user space 3A algorithms.
+- neoisp-frame: capture device for RGB/YUV pixels of the processed images.
+- neoisp-ir: capture device for the infra-red pixels of the processed images.
+- neoisp-stats: capture meta device for generated image statistics for user space 3A algorithms.
+
+neoisp-input0, neoisp-input1
+----------------------------
+
+Images to be processed by Neoisp are queued to the neoisp-input0 (and
+neoisp-input1 when in HDR mode) output device nodes. Supported image formats
+as input to the ISP are:
+
+- Raw bayer formats:
+
+ - 8 bits raw (V4L2_PIX_FMT_SRGGB8, V4L2_PIX_FMT_SBGGR8, V4L2_PIX_FMT_SGBRG8,
+ V4L2_PIX_FMT_SGRBG8)
+ - 10 bits raw (V4L2_PIX_FMT_SRGGB10, V4L2_PIX_FMT_SBGGR10,
+ V4L2_PIX_FMT_SGBRG10, V4L2_PIX_FMT_SGRBG10)
+ - 12 bits raw (V4L2_PIX_FMT_SRGGB12, V4L2_PIX_FMT_SBGGR12,
+ V4L2_PIX_FMT_SGBRG12, V4L2_PIX_FMT_SGRBG12)
+ - 14 bits raw (V4L2_PIX_FMT_SRGGB14, V4L2_PIX_FMT_SBGGR14,
+ V4L2_PIX_FMT_SGBRG14, V4L2_PIX_FMT_SGRBG14)
+ - 16 bits raw (V4L2_PIX_FMT_SRGGB16, V4L2_PIX_FMT_SBGGR16,
+ V4L2_PIX_FMT_SGBRG16, V4L2_PIX_FMT_SGRBG16)
+
+- Monochrome formats:
+
+ - 8 bits Monochrome (V4L2_PIX_FMT_GREY)
+ - 10 bits Monochrome (V4L2_PIX_FMT_Y10)
+ - 12 bits Monochrome (V4L2_PIX_FMT_Y12)
+ - 14 bits Monochrome (V4L2_PIX_FMT_Y14)
+ - 16 bits Monochrome (V4L2_PIX_FMT_Y16)
+
+.. note::
+ RGBIr camera sensors are supported as well, and can be used through user
+ space activation of the IR block.
+
+.. note::
+ neoisp-input1 link is mutable and should be enabled in case a short capture
+ image buffer is provided to the ISP for HDR merge.
+
+.. _neoisp_params:
+
+neoisp-params
+-------------
+
+The neoisp-params output meta device receives configuration data to be written
+to Neoisp registers and internal memory for desired input image processing.
+This v4l2 device accepts the generic `extensible parameters` format.
+
+In this format, the parameters buffer is defined by the generic
+:c:type:`v4l2_isp_params_buffer`, and userspace should set
+:ref:`V4L2_META_FMT_NEO_ISP_EXT_PARAMS <v4l2-meta-fmt-neo-isp-ext-params>`
+as dataformat.
+
+When the related media link is disabled, the image decoding will be done based
+on the default parameters of the ISP.
+
+neoisp-frame
+------------
+
+The capture device writes to memory the RGB or YUV pixels of the image processed
+by Neoisp when the media link is enabled. If the related media link is disabled,
+the processed image will be written to dummy buffer and not delivered to the
+neoisp-frame video device node.
+
+neoisp-ir
+---------
+
+The capture device writes to memory the RGBIr pixels of the image processed by
+Neoisp when the media link is enabled. If the related media link is disabled,
+the processed image will not be delivered to the neoisp-ir video device node.
+
+.. _neoisp_stats:
+
+neoisp-stats
+------------
+
+The neoisp-stats capture meta device provides statistics data generated by
+Neoisp hardware while processing the input image. This v4l2 device accepts the
+`extensible statistics` format.
+
+In this format, the statistics buffer is defined by the generic
+:c:type:`v4l2_isp_stats_buffer`, and userspace should set
+:ref:`V4L2_META_FMT_NEO_ISP_EXT_STATS <v4l2-meta-fmt-neo-isp-ext-stats>` as
+dataformat.
+
+When the related media link is disabled, the decoding statistics will not be
+delivered to the neoisp-stats meta device node.
+
+Control
+=======
+
+To support additional neoisp hardware revisions, the read-only bitmask control
+`V4L2_CID_NEOISP_SUPPORTED_PARAMS_BLOCKS` can be used to query the list of
+supported blocks. Each bit represents the availability of the corresponding
+entry from the :c:type:`neoisp_param_block_type_e` enum. In current driver
+version, default and max values represent the blocks supported by the i.MX95
+SoC.
diff --git a/Documentation/admin-guide/media/v4l-drivers.rst b/Documentation/admin-guide/media/v4l-drivers.rst
index d31da8e0a54f..445269f87b17 100644
--- a/Documentation/admin-guide/media/v4l-drivers.rst
+++ b/Documentation/admin-guide/media/v4l-drivers.rst
@@ -21,6 +21,7 @@ Video4Linux (V4L) driver-specific documentation
ivtv
mali-c55
mgb4
+ nxp-neoisp
omap3isp
philips
qcom_camss
diff --git a/Documentation/userspace-api/media/v4l/meta-formats.rst b/Documentation/userspace-api/media/v4l/meta-formats.rst
index 3e0cab153f0a..46268d955d3a 100644
--- a/Documentation/userspace-api/media/v4l/meta-formats.rst
+++ b/Documentation/userspace-api/media/v4l/meta-formats.rst
@@ -18,6 +18,7 @@ These formats are used for the :ref:`metadata` interface only.
metafmt-d4xx
metafmt-generic
metafmt-intel-ipu3
+ metafmt-nxp-neoisp
metafmt-pisp-be
metafmt-pisp-fe
metafmt-rkisp1
diff --git a/Documentation/userspace-api/media/v4l/metafmt-nxp-neoisp.rst b/Documentation/userspace-api/media/v4l/metafmt-nxp-neoisp.rst
new file mode 100644
index 000000000000..c412b1595205
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/metafmt-nxp-neoisp.rst
@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+*****************************************
+V4L2_META_FMT_NEO_ISP_EXT_PARAMS ('nnep')
+*****************************************
+
+The Neoisp image signal processor is configured by userspace through a buffer
+of parameters to :ref:`neoisp-params <neoisp_params>` output device node using
+the :c:type:`v4l2_meta_format` interface.
+
+The parameters buffer uses the generic `extensible parameters` configuration
+format.
+
+.. _v4l2-meta-fmt-neo-isp-ext-params:
+
+Extensible parameters configuration format
+==========================================
+
+When using the `extensible parameters` configuration format, parameters are
+passed to the :ref:`neoisp-params <neoisp_params>` metadata output video node
+using the `V4L2_META_FMT_NEO_ISP_EXT_PARAMS` meta format.
+
+The buffer contains a single instance of the C structure
+:c:type:`v4l2_isp_params_buffer` defined in ``v4l2-isp.h``. The
+:c:type:`v4l2_isp_params_buffer` structure is designed to allow userspace to
+populate the data buffer with only the configuration data for the Neoisp blocks
+it intends to configure. The extensible parameters format design allows
+developers to define new block types to support new configuration parameters,
+and defines a versioning scheme so that it can be extended and versioned
+without breaking compatibility with existing applications.
+
+****************************************
+V4L2_META_FMT_NEO_ISP_EXT_STATS ('nnes')
+****************************************
+
+The Neoisp image signal processor generates statistics data while processing an
+input image. These statistics are captured in a buffer and provided to
+userspace through the :ref:`neoisp-stats <neoisp_stats>` capture video node
+using the :c:type:`v4l2_meta_format` interface. The statistics data are
+processed by userspace application to produce the next Neoisp parameters.
+
+The statistics buffer uses the generic `extensible statistics` format.
+
+.. _v4l2-meta-fmt-neo-isp-ext-stats:
+
+Extensible statistics format
+============================
+
+When using the `extensible statistics` format, the statistics buffer is passed
+from the :ref:`neoisp-stats <neoisp_stats>` metadata capture video node using
+the `V4L2_META_FMT_NEO_ISP_EXT_STATS` meta format.
+
+The buffer contains a single instance of the C structure
+:c:type:`v4l2_isp_stats_buffer` defined in ``v4l2-isp.h``. The
+:c:type:`v4l2_isp_stats_buffer` structure is designed to allow future Neoisp
+driver versions to populate the statistics buffer with future blocks
+statistics, and defines a versioning scheme so that it can be extended and
+versioned without breaking compatibility with existing applications.
+
+**********************
+Neoisp uAPI data types
+**********************
+
+This chapter describes the data types exposed to userspace by Neoisp driver.
+
+Some structure members are in a fixed-point format, in this case the related
+description will be ended by a fixed-point definition between parenthesis.
+
+.. kernel-doc:: include/uapi/linux/media/nxp/nxp_neoisp.h
+
--
2.51.0
^ permalink raw reply related
* [PATCH v1 03/11] media: v4l2-isp: Add helper function to compute extended stats size
From: Antoine Bouyer @ 2026-04-13 16:03 UTC (permalink / raw)
To: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, michael.riesch, anthony.mcgivern
Cc: linux-media, linux-kernel, devicetree, imx, ai.luthra, paul.elder,
Antoine Bouyer
In-Reply-To: <20260413160331.2611829-1-antoine.bouyer@nxp.com>
v4l2-isp framework only supports extended buffer for generic ISP
configuration. This patch adds simple helper function to compute the
extended statistics buffer size, exactly the same as for extended
parameters, except that it uses the `v4l2_isp_stats_block_header`
structure definition to prevent conflict with the
`v4l2_isp_params_block_header` one.
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
---
include/media/v4l2-isp.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/media/v4l2-isp.h b/include/media/v4l2-isp.h
index f3a6d0edcb24..9a93a534e7b0 100644
--- a/include/media/v4l2-isp.h
+++ b/include/media/v4l2-isp.h
@@ -27,6 +27,19 @@ struct vb2_buffer;
#define v4l2_isp_params_buffer_size(max_params_size) \
(offsetof(struct v4l2_isp_params_buffer, data) + (max_params_size))
+/**
+ * v4l2_isp_stats_buffer_size - Calculate size of v4l2_isp_stats_buffer
+ * @max_stats_size: The total size of the ISP statistic blocks
+ *
+ * Users of the v4l2 extensible statistics buffers will have differing sized data
+ * arrays depending on their specific ISP blocks. Drivers and userspace will need
+ * to be able to calculate the appropriate size of the struct to accommodate all
+ * ISP statistics blocks provided by the platform.
+ * This macro provides a convenient tool for the calculation.
+ */
+#define v4l2_isp_stats_buffer_size(max_stats_size) \
+ (offsetof(struct v4l2_isp_stats_buffer, data) + (max_stats_size))
+
/**
* v4l2_isp_params_validate_buffer_size - Validate a V4L2 ISP buffer sizes
* @dev: the driver's device pointer
--
2.51.0
^ permalink raw reply related
* [PATCH v1 02/11] media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
From: Antoine Bouyer @ 2026-04-13 16:03 UTC (permalink / raw)
To: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, michael.riesch, anthony.mcgivern
Cc: linux-media, linux-kernel, devicetree, imx, ai.luthra, paul.elder,
Antoine Bouyer
In-Reply-To: <20260413160331.2611829-1-antoine.bouyer@nxp.com>
Extend the v4l2-isp extensible format introduced for isp parameters buffer
to the statistics buffer as well.
Like for ISP configuration purpose, that will help supporting various ISP
hardware versions reporting different statistics data with less impact on
userspace.
The `v4l2_isp_stats_buffer` reuses the `v4l2_isp_params_buffer` container
definitions, with similar header, versions and flags. V0 and V1 versions
are provided to match with params versions. On the other side, ENABLE and
DISABLE flags are not really meaningfull for statistics purpose. So VALID
and INVALID flags are introduced. Purpose is to force ISP driver to
validate a statistics buffer, before it is consumed by userspace.
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
---
include/uapi/linux/media/v4l2-isp.h | 148 +++++++++++++++++++---------
1 file changed, 100 insertions(+), 48 deletions(-)
diff --git a/include/uapi/linux/media/v4l2-isp.h b/include/uapi/linux/media/v4l2-isp.h
index 779168f9058e..e84476280d43 100644
--- a/include/uapi/linux/media/v4l2-isp.h
+++ b/include/uapi/linux/media/v4l2-isp.h
@@ -13,25 +13,33 @@
#include <linux/types.h>
/**
- * enum v4l2_isp_params_version - V4L2 ISP parameters versioning
+ * enum v4l2_isp_version - V4L2 ISP serialization format versioning
*
- * @V4L2_ISP_PARAMS_VERSION_V0: First version of the V4L2 ISP parameters format
- * (for compatibility)
- * @V4L2_ISP_PARAMS_VERSION_V1: First version of the V4L2 ISP parameters format
+ * @V4L2_ISP_VERSION_V0: First version of the V4L2 ISP serialization format
+ * (for compatibility)
+ * @V4L2_ISP_VERSION_V1: First version of the V4L2 ISP serialization format
*
* V0 and V1 are identical in order to support drivers compatible with the V4L2
- * ISP parameters format already upstreamed which use either 0 or 1 as their
- * versioning identifier. Both V0 and V1 refers to the first version of the
- * V4L2 ISP parameters format.
+ * ISP format already upstreamed which use either 0 or 1 as their versioning
+ * identifier. Both V0 and V1 refers to the first version of the V4L2 ISP
+ * serialization format.
*
- * Future revisions of the V4L2 ISP parameters format should start from the
+ * Future revisions of the V4L2 ISP serialization format should start from the
* value of 2.
*/
-enum v4l2_isp_params_version {
- V4L2_ISP_PARAMS_VERSION_V0 = 0,
- V4L2_ISP_PARAMS_VERSION_V1
+enum v4l2_isp_version {
+ V4L2_ISP_VERSION_V0 = 0,
+ V4L2_ISP_VERSION_V1
};
+/*
+ * Compatibility with existing users of v4l2_isp_params which pre-date the
+ * introduction of v4l2_isp_stats.
+ */
+#define v4l2_isp_params_version v4l2_isp_version
+#define V4L2_ISP_PARAMS_VERSION_V0 V4L2_ISP_VERSION_V0
+#define V4L2_ISP_PARAMS_VERSION_V1 V4L2_ISP_VERSION_V1
+
#define V4L2_ISP_PARAMS_FL_BLOCK_DISABLE (1U << 0)
#define V4L2_ISP_PARAMS_FL_BLOCK_ENABLE (1U << 1)
@@ -39,64 +47,108 @@ enum v4l2_isp_params_version {
* Reserve the first 8 bits for V4L2_ISP_PARAMS_FL_* flag.
*
* Driver-specific flags should be defined as:
- * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_PARAMS_FL_DRIVER_FLAGS(0))
- * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_PARAMS_FL_DRIVER_FLAGS(1))
+ * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_FL_DRIVER_FLAGS(0))
+ * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_FL_DRIVER_FLAGS(1))
*/
-#define V4L2_ISP_PARAMS_FL_DRIVER_FLAGS(n) ((n) + 8)
+#define V4L2_ISP_FL_DRIVER_FLAGS(n) ((n) + 8)
/**
- * struct v4l2_isp_params_block_header - V4L2 extensible parameters block header
- * @type: The parameters block type (driver-specific)
+ * struct v4l2_isp_block_header - V4L2 extensible block header
+ * @type: The parameters or statistics block type (driver-specific)
* @flags: A bitmask of block flags (driver-specific)
- * @size: Size (in bytes) of the parameters block, including this header
+ * @size: Size (in bytes) of the block, including this header
*
- * This structure represents the common part of all the ISP configuration
- * blocks. Each parameters block shall embed an instance of this structure type
- * as its first member, followed by the block-specific configuration data.
+ * This structure represents the common part of all the ISP configuration or
+ * statistic blocks. Each block shall embed an instance of this structure type
+ * as its first member, followed by the block-specific configuration or
+ * statistic data.
*
* The @type field is an ISP driver-specific value that identifies the block
- * type. The @size field specifies the size of the parameters block.
- *
- * The @flags field is a bitmask of per-block flags V4L2_PARAMS_ISP_FL_* and
- * driver-specific flags specified by the driver header.
+ * type. The @size field specifies the size of the block, including this
+ * header.
*/
-struct v4l2_isp_params_block_header {
+struct v4l2_isp_block_header {
__u16 type;
__u16 flags;
__u32 size;
} __attribute__((aligned(8)));
/**
- * struct v4l2_isp_params_buffer - V4L2 extensible parameters configuration
- * @version: The parameters buffer version (driver-specific)
- * @data_size: The configuration data effective size, excluding this header
- * @data: The configuration data
+ * v4l2_isp_params_block_header - V4L2 extensible parameters block header
*
- * This structure contains the configuration parameters of the ISP algorithms,
- * serialized by userspace into a data buffer. Each configuration parameter
- * block is represented by a block-specific structure which contains a
- * :c:type:`v4l2_isp_params_block_header` entry as first member. Userspace
- * populates the @data buffer with configuration parameters for the blocks that
- * it intends to configure. As a consequence, the data buffer effective size
- * changes according to the number of ISP blocks that userspace intends to
- * configure and is set by userspace in the @data_size field.
- *
- * The parameters buffer is versioned by the @version field to allow modifying
- * and extending its definition. Userspace shall populate the @version field to
- * inform the driver about the version it intends to use. The driver will parse
- * and handle the @data buffer according to the data layout specific to the
- * indicated version and return an error if the desired version is not
+ * This structure represents the common part of all the ISP configuration blocks
+ * and is identical to :c:type:`v4l2_isp_block_header`.
+ *
+ * The @flags field is a bitmask of per-block flags V4L2_ISP_PARAMS_FL_* and
+ * driver-specific flags specified by the driver header.
+ */
+#define v4l2_isp_params_block_header v4l2_isp_block_header
+
+/**
+ * v4l2_isp_stats_block_header - V4L2 extensible statistics block header
+ *
+ * This structure represents the common part of all the ISP statistics blocks
+ * and is identical to :c:type:`v4l2_isp_block_header`.
+ *
+ * The @flags field is a bitmask of driver-specific flags specified by the
+ * driver header, as there is no generic flags for statistics.
+ */
+#define v4l2_isp_stats_block_header v4l2_isp_block_header
+
+/**
+ * struct v4l2_isp_buffer - V4L2 extensible buffer
+ * @version: The extensible buffer version (driver-specific)
+ * @data_size: The data effective size, excluding this header
+ * @data: The configuration or statistics data
+ *
+ * This structure contains ISP configuration parameters or ISP hardware
+ * statistics serialized into a data buffer. Each block is represented by a
+ * block-specific structure which contains a :c:type:`v4l2_isp_block_header`
+ * entry as first member.
+ *
+ * For a parameters block, userspace populates the @data buffer with
+ * configuration parameters for the blocks that it intends to configure.
+ * As a consequence, the data buffer effective size changes according to the
+ * number of ISP blocks that userspace intends to configure and is set by
+ * userspace in the @data_size field.
+ *
+ * For a statistics block, behavior is the same as for parameters, except that
+ * buffer is filled by the ISP driver.
+ *
+ * The buffer is versioned by the @version field to allow modifying
+ * and extending its definition. The writer shall populate the @version field
+ * to inform the reader about the version it intends to use. The reader will
+ * parse and handle the @data buffer according to the data layout specific to
+ * the indicated version and return an error if the desired version is not
* supported.
*
- * For each ISP block that userspace wants to configure, a block-specific
- * structure is appended to the @data buffer, one after the other without gaps
- * in between. Userspace shall populate the @data_size field with the effective
- * size, in bytes, of the @data buffer.
+ * For each ISP block, a block-specific structure is appended to the @data
+ * buffer, one after the other without gaps in between. The writer shall
+ * populate the @data_size field with the effective size, in bytes, of the
+ * @data buffer.
*/
-struct v4l2_isp_params_buffer {
+struct v4l2_isp_buffer {
__u32 version;
__u32 data_size;
__u8 data[] __counted_by(data_size);
};
+/**
+ * v4l2_isp_params_buffer - V4L2 extensible parameters configuration
+ *
+ * This structure contains the configuration parameters of the ISP algorithms,
+ * serialized into a data buffer. It is identical to
+ * :c:type:`v4l2_isp_buffer`.
+ */
+#define v4l2_isp_params_buffer v4l2_isp_buffer
+
+/**
+ * v4l2_isp_stats_buffer - V4L2 extensible statistics buffer
+ *
+ * This structure contains the statistics data from the ISP hardware,
+ * serialized into a data buffer. It is identical to
+ * :c:type:`v4l2_isp_buffer`.
+ */
+#define v4l2_isp_stats_buffer v4l2_isp_buffer
+
#endif /* _UAPI_V4L2_ISP_H_ */
--
2.51.0
^ permalink raw reply related
* [PATCH v1 01/11] media: Documentation: uapi: Update V4L2 ISP for extensible stats
From: Antoine Bouyer @ 2026-04-13 16:03 UTC (permalink / raw)
To: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, michael.riesch, anthony.mcgivern
Cc: linux-media, linux-kernel, devicetree, imx, ai.luthra, paul.elder,
Antoine Bouyer
In-Reply-To: <20260413160331.2611829-1-antoine.bouyer@nxp.com>
Add driver documentation for V4L2 ISP generic statistics format, mainly
copied from the generic parameters one.
Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
---
.../userspace-api/media/v4l/v4l2-isp.rst | 39 +++++++++++++++++--
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/Documentation/userspace-api/media/v4l/v4l2-isp.rst b/Documentation/userspace-api/media/v4l/v4l2-isp.rst
index facf6dba1ca7..9e9c71bfc0df 100644
--- a/Documentation/userspace-api/media/v4l/v4l2-isp.rst
+++ b/Documentation/userspace-api/media/v4l/v4l2-isp.rst
@@ -24,7 +24,7 @@ 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
+Each *ISP configuration block* is preceded by a 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.
@@ -32,8 +32,8 @@ 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
------------------------------------------------
+ISP parameters 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
@@ -59,7 +59,38 @@ definition without invalidating the existing ones.
ISP statistics
==============
-Support for generic statistics format is not yet implemented in Video4Linux2.
+The generic ISP statistics format is similar to the generic ISP configuration
+parameters format. It is realized by defining a C structure that contains a
+header, followed by binary buffer where the ISP driver copies a variable number
+of ISP statistics block.
+
+The :c:type:`v4l2_isp_stats_buffer` structure defines the buffer header which
+is followed by a binary buffer of ISP statistics data. ISP drivers shall
+correctly populate the buffer header with the generic statistics format version
+and with the size (in bytes) of the binary data buffer where it will store the
+ISP statistics data.
+
+Each *ISP statistics block* is preceded by a header implemented by the
+:c:type:`v4l2_isp_stats_block_header` structure, followed by the statistics
+data for that specific block, defined by the ISP driver specific data types.
+
+Drivers are responsible for correctly populating each block's header fields
+(type and size) and the block-specific statistics data. The flags field can be
+left empty, it is not relevant for statistics data.
+
+ISP statistics block configuration
+----------------------------------
+
+When an ISP driver wants to share statistics from an ISP block, it shall fully
+populate the block statistics.
+
+When ISP driver wants userspace to ignore statistics from an ISP block, it can
+either simply omit the full block, or omit the additional data after header.
+In second case, block header's `size` shall be filled with header structure's
+size only.
+
+Extension to the statistics format can be implemented by adding new blocks
+definition without invalidating the existing ones.
V4L2 ISP uAPI data types
========================
--
2.51.0
^ permalink raw reply related
* [PATCH v1 00/11] media: Add iMX95 neoisp driver
From: Antoine Bouyer @ 2026-04-13 16:03 UTC (permalink / raw)
To: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, michael.riesch, anthony.mcgivern
Cc: linux-media, linux-kernel, devicetree, imx, ai.luthra, paul.elder,
Antoine Bouyer
Hello
This patch series introduces the NXP Neo Image Signal Processor (ISP)
driver, used in the NXP i.MX95 SoC and future devices in the i.MX9 family.
The series also includes updates to the generic v4l2-isp interface to
support extended statistics required by the Neo ISP.
The Neo ISP processes one or more camera streams, converting RAW formats
into YUV or RGB outputs. Its architecture is largely influenced by the
PISP driver. To limit the number of v4l2 devices, the driver supports only
one context, with three sink pads (main input, second input for HDR, and
parameter buffers) and three source pads (RGB output, IR output, and
statistics metadata).
The driver supports the generic extensible v4l2-isp framework for
parameters, similar to rkisp1 and mali-c55, and applies the same approach
to statistics buffers. The generic v4l2-isp framework is modified to
factorize structure definitions and versioning, so that both parameters
and statistics buffers share the same mechanisms.
The driver currently supports M2M operation; inline mode (CSI-to-ISP
streaming) is still under evaluation.
This series integrates several comments raised during RFC [1] review:
* The major change is that neoisp now provides the
`neoisp_core_media_register` API to register itself into an existing
media graph, instead of creating its own. The goal is to prepare for
supporting inline mode alongside M2M mode, and to allow userspace to
select between these modes at runtime (the 2 modes cannot run together
at same time because of hardware constraints).
* The driver now configures only one Neo ISP context, whereas the RFC
version prepared height contexts.
* A module parameter has been added to support a standalone mode. When
enabled, neoisp registers its own media graph. The goal is to allow
testing the Neo ISP IP without a camera or other subdevice drivers,
such as ISI, pixel formatter, etc.
* The legacy mode using fixed-size buffers for parameters and statistics
has been removed; only the generic extensible framework is supported.
* Support for hardware version 1 has also been removed.
A few checkpatch errors in v4l2-ioctl.c remain intentionally, to stay
consistent with the existing style in that file.
Testing was performed on the i.MX95 EVK using the media/next kernel in
standalone mode, with a vivid (Virtual Video Device) instance and a
libcamera neo pipeline handler. An engineering version of the libcamera
pipeline handler is under preparation, and can be shared as dedicated
branch if needed.
End-to-end camera-to-ISP capture, using a single media graph, has been
validated using the downstream NXP kernel, as some hardware dependencies
are not yet upstreamed.
Thanks,
Antoine
[1] RFC: https://lore.kernel.org/linux-media/20260123080938.3367348-1-antoine.bouyer@nxp.com/
-----
Here are v4l2-compliance test results (in standalone mode):
v4l2-compliance 1.28.1-5233, 64 bits, 64-bit time_t
v4l2-compliance SHA: fc15e229d9d3 2024-07-23 19:22:15
Compliance test for neoisp device /dev/media0:
Media Driver Info:
Driver name : neoisp
Model : neoisp
Serial :
Bus info : platform:4ae00000.isp
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Required ioctls:
test MEDIA_IOC_DEVICE_INFO: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/media0 open: OK
test MEDIA_IOC_DEVICE_INFO: OK
test for unlimited opens: OK
Media Controller ioctls:
test MEDIA_IOC_G_TOPOLOGY: OK
Entities: 7 Interfaces: 7 Pads: 12 Links: 13
test MEDIA_IOC_ENUM_ENTITIES/LINKS: OK
test MEDIA_IOC_SETUP_LINK: OK
Total for neoisp device /dev/media0: 8, Succeeded: 8, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for neoisp device /dev/video2:
Driver Info:
Driver name : neoisp
Card type : neoisp
Bus info : platform:4ae00000.isp
Driver version : 7.0.0
Capabilities : 0x8ca03000
Video Capture Multiplanar
Video Output Multiplanar
Metadata Capture
Metadata Output
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04202000
Video Output Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : neoisp
Model : neoisp
Serial :
Bus info : platform:4ae00000.isp
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300000a
Type : V4L Video
Entity Info:
ID : 0x00000008 (8)
Name : neoisp-input0
Function : V4L2 I/O
Pad 0x01000009 : 0: Source
Link 0x0200000c: to remote pad 0x1000002 of entity 'neoisp' (Image Signal Processor): Data, Enabled, Immutable
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video2 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK (Not Supported)
test Scaling: OK
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
Total for neoisp device /dev/video2: 48, Succeeded: 48, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for neoisp device /dev/video3:
Driver Info:
Driver name : neoisp
Card type : neoisp
Bus info : platform:4ae00000.isp
Driver version : 7.0.0
Capabilities : 0x8ca03000
Video Capture Multiplanar
Video Output Multiplanar
Metadata Capture
Metadata Output
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04202000
Video Output Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : neoisp
Model : neoisp
Serial :
Bus info : platform:4ae00000.isp
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x03000010
Type : V4L Video
Entity Info:
ID : 0x0000000e (14)
Name : neoisp-input1
Function : V4L2 I/O
Pad 0x0100000f : 0: Source
Link 0x02000012: to remote pad 0x1000003 of entity 'neoisp' (Image Signal Processor): Data
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video3 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK (Not Supported)
test Scaling: OK
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
Total for neoisp device /dev/video3: 48, Succeeded: 48, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for neoisp device /dev/video4:
Driver Info:
Driver name : neoisp
Card type : neoisp
Bus info : platform:4ae00000.isp
Driver version : 7.0.0
Capabilities : 0x8ca03000
Video Capture Multiplanar
Video Output Multiplanar
Metadata Capture
Metadata Output
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x0c200000
Metadata Output
Streaming
Extended Pix Format
Media Driver Info:
Driver name : neoisp
Model : neoisp
Serial :
Bus info : platform:4ae00000.isp
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x03000016
Type : V4L Video
Entity Info:
ID : 0x00000014 (20)
Name : neoisp-params
Function : V4L2 I/O
Pad 0x01000015 : 0: Source
Link 0x02000018: to remote pad 0x1000004 of entity 'neoisp' (Image Signal Processor): Data, Enabled
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video4 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
Total for neoisp device /dev/video4: 48, Succeeded: 48, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for neoisp device /dev/video5:
Driver Info:
Driver name : neoisp
Card type : neoisp
Bus info : platform:4ae00000.isp
Driver version : 7.0.0
Capabilities : 0x8ca03000
Video Capture Multiplanar
Video Output Multiplanar
Metadata Capture
Metadata Output
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04201000
Video Capture Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : neoisp
Model : neoisp
Serial :
Bus info : platform:4ae00000.isp
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300001c
Type : V4L Video
Entity Info:
ID : 0x0000001a (26)
Name : neoisp-frame
Function : V4L2 I/O
Pad 0x0100001b : 0: Sink
Link 0x0200001e: from remote pad 0x1000005 of entity 'neoisp' (Image Signal Processor): Data, Enabled
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video5 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
Total for neoisp device /dev/video5: 48, Succeeded: 48, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for neoisp device /dev/video6:
Driver Info:
Driver name : neoisp
Card type : neoisp
Bus info : platform:4ae00000.isp
Driver version : 7.0.0
Capabilities : 0x8ca03000
Video Capture Multiplanar
Video Output Multiplanar
Metadata Capture
Metadata Output
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04201000
Video Capture Multiplanar
Streaming
Extended Pix Format
Media Driver Info:
Driver name : neoisp
Model : neoisp
Serial :
Bus info : platform:4ae00000.isp
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x03000022
Type : V4L Video
Entity Info:
ID : 0x00000020 (32)
Name : neoisp-ir
Function : V4L2 I/O
Pad 0x01000021 : 0: Sink
Link 0x02000024: from remote pad 0x1000006 of entity 'neoisp' (Image Signal Processor): Data
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video6 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
Total for neoisp device /dev/video6: 48, Succeeded: 48, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for neoisp device /dev/video7:
Driver Info:
Driver name : neoisp
Card type : neoisp
Bus info : platform:4ae00000.isp
Driver version : 7.0.0
Capabilities : 0x8ca03000
Video Capture Multiplanar
Video Output Multiplanar
Metadata Capture
Metadata Output
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04a00000
Metadata Capture
Streaming
Extended Pix Format
Media Driver Info:
Driver name : neoisp
Model : neoisp
Serial :
Bus info : platform:4ae00000.isp
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x03000028
Type : V4L Video
Entity Info:
ID : 0x00000026 (38)
Name : neoisp-stats
Function : V4L2 I/O
Pad 0x01000027 : 0: Sink
Link 0x0200002a: from remote pad 0x1000007 of entity 'neoisp' (Image Signal Processor): Data, Enabled
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video7 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK (Not Supported)
test VIDIOC_QUERYCTRL: OK (Not Supported)
test VIDIOC_G/S_CTRL: OK (Not Supported)
test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported)
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported)
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 0 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
Total for neoisp device /dev/video7: 48, Succeeded: 48, Failed: 0, Warnings: 0
--------------------------------------------------------------------------------
Compliance test for neoisp device /dev/v4l-subdev0:
Driver Info:
Driver version : 7.0.0
Capabilities : 0x00000000
Client Capabilities: 0x0000000000000002
interval-uses-which Media Driver Info:
Driver name : neoisp
Model : neoisp
Serial :
Bus info : platform:4ae00000.isp
Media version : 7.0.0
Hardware revision: 0x00000000 (0)
Driver version : 7.0.0
Interface Info:
ID : 0x0300002c
Type : V4L Sub-Device
Entity Info:
ID : 0x00000001 (1)
Name : neoisp
Function : Image Signal Processor
Pad 0x01000002 : 0: Sink
Link 0x0200000c: from remote pad 0x1000009 of entity 'neoisp-input0' (V4L2 I/O): Data, Enabled, Immutable
Pad 0x01000003 : 1: Sink
Link 0x02000012: from remote pad 0x100000f of entity 'neoisp-input1' (V4L2 I/O): Data
Pad 0x01000004 : 2: Sink
Link 0x02000018: from remote pad 0x1000015 of entity 'neoisp-params' (V4L2 I/O): Data, Enabled
Pad 0x01000005 : 3: Source
Link 0x0200001e: to remote pad 0x100001b of entity 'neoisp-frame' (V4L2 I/O): Data, Enabled
Pad 0x01000006 : 4: Source
Link 0x02000024: to remote pad 0x1000021 of entity 'neoisp-ir' (V4L2 I/O): Data
Pad 0x01000007 : 5: Source
Link 0x0200002a: to remote pad 0x1000027 of entity 'neoisp-stats' (V4L2 I/O): Data, Enabled
Required ioctls:
test MC information (see 'Media Driver Info' above): OK
test VIDIOC_SUDBEV_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/v4l-subdev0 open: OK
test VIDIOC_SUBDEV_QUERYCAP: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Sub-Device ioctls (Sink Pad 0):
Try Stream 0
test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
Active Stream 0
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
Sub-Device ioctls (Sink Pad 1):
Try Stream 0
test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
Active Stream 0
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
Sub-Device ioctls (Sink Pad 2):
Try Stream 0
test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
Active Stream 0
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
Sub-Device ioctls (Source Pad 3):
Try Stream 0
test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
Active Stream 0
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
Sub-Device ioctls (Source Pad 4):
Try Stream 0
test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
Active Stream 0
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
Sub-Device ioctls (Source Pad 5):
Try Stream 0
test Try VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Try VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
Active Stream 0
test Active VIDIOC_SUBDEV_ENUM_MBUS_CODE/FRAME_SIZE/FRAME_INTERVAL: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FMT: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_SELECTION/CROP: OK (Not Supported)
test Active VIDIOC_SUBDEV_G/S_FRAME_INTERVAL: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 1 Private Controls: 1
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK (Not Supported)
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK (Not Supported)
test VIDIOC_TRY_FMT: OK (Not Supported)
test VIDIOC_S_FMT: OK (Not Supported)
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK (Not Supported)
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK (Not Supported)
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK (Not Supported)
test Requests: OK (Not Supported)
Total for neoisp device /dev/v4l-subdev0: 88, Succeeded: 88, Failed: 0, Warnings: 0
Grand Total for neoisp device /dev/media0: 384, Succeeded: 384, Failed: 0, Warnings: 0
-----
Antoine Bouyer (11):
media: Documentation: uapi: Update V4L2 ISP for extensible stats
media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
media: v4l2-isp: Add helper function to compute extended stats size
media: Documentation: Add NXP neoisp driver documentation
dt-bindings: media: Add nxp neoisp support
media: v4l2-ctrls: Add user control base for NXP neoisp controls
media: Add meta formats supported by NXP neoisp driver
media: uapi: Add NXP NEOISP user interface header file
media: platform: Add NXP Neoisp Image Signal Processor
media: platform: neoisp: Add debugfs support
arm64: dts: freescale: imx95: Add NXP neoisp device tree node
.../admin-guide/media/nxp-neoisp-diagram.dot | 22 +
.../admin-guide/media/nxp-neoisp.dot | 16 +
.../admin-guide/media/nxp-neoisp.rst | 179 ++
.../admin-guide/media/v4l-drivers.rst | 1 +
.../bindings/media/nxp,imx95-neoisp.yaml | 62 +
.../userspace-api/media/v4l/meta-formats.rst | 1 +
.../media/v4l/metafmt-nxp-neoisp.rst | 70 +
.../userspace-api/media/v4l/v4l2-isp.rst | 39 +-
MAINTAINERS | 9 +
.../boot/dts/freescale/imx95-19x19-evk.dts | 4 +
arch/arm64/boot/dts/freescale/imx95.dtsi | 11 +
drivers/media/platform/nxp/Kconfig | 1 +
drivers/media/platform/nxp/Makefile | 1 +
drivers/media/platform/nxp/neoisp/Kconfig | 15 +
drivers/media/platform/nxp/neoisp/Makefile | 8 +
drivers/media/platform/nxp/neoisp/neoisp.h | 263 ++
.../media/platform/nxp/neoisp/neoisp_core.h | 30 +
.../media/platform/nxp/neoisp/neoisp_ctx.c | 2630 +++++++++++++++++
.../media/platform/nxp/neoisp/neoisp_ctx.h | 78 +
.../platform/nxp/neoisp/neoisp_debugfs.c | 494 ++++
.../media/platform/nxp/neoisp/neoisp_fmt.h | 495 ++++
drivers/media/platform/nxp/neoisp/neoisp_hw.h | 557 ++++
.../media/platform/nxp/neoisp/neoisp_main.c | 1898 ++++++++++++
.../media/platform/nxp/neoisp/neoisp_nodes.h | 54 +
.../media/platform/nxp/neoisp/neoisp_regs.h | 2498 ++++++++++++++++
drivers/media/v4l2-core/v4l2-ioctl.c | 2 +
include/media/v4l2-isp.h | 13 +
include/uapi/linux/media/nxp/nxp_neoisp.h | 1761 +++++++++++
include/uapi/linux/media/v4l2-isp.h | 148 +-
include/uapi/linux/v4l2-controls.h | 6 +
include/uapi/linux/videodev2.h | 4 +
31 files changed, 11318 insertions(+), 52 deletions(-)
create mode 100644 Documentation/admin-guide/media/nxp-neoisp-diagram.dot
create mode 100644 Documentation/admin-guide/media/nxp-neoisp.dot
create mode 100644 Documentation/admin-guide/media/nxp-neoisp.rst
create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
create mode 100644 Documentation/userspace-api/media/v4l/metafmt-nxp-neoisp.rst
create mode 100644 drivers/media/platform/nxp/neoisp/Kconfig
create mode 100644 drivers/media/platform/nxp/neoisp/Makefile
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp.h
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_core.h
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_ctx.c
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_ctx.h
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_debugfs.c
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_fmt.h
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_hw.h
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_main.c
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_nodes.h
create mode 100644 drivers/media/platform/nxp/neoisp/neoisp_regs.h
create mode 100644 include/uapi/linux/media/nxp/nxp_neoisp.h
--
2.51.0
^ permalink raw reply
* Re: [PATCH v4 2/4] pwm: sun50i: Add H616 PWM support
From: Paul Kocialkowski @ 2026-04-13 15:58 UTC (permalink / raw)
To: bigunclemax
Cc: richard.genoud, conor+dt, devicetree, jernej.skrabec, joao,
jstultz, krzk+dt, linux-arm-kernel, linux-kernel, linux-pwm,
linux-sunxi, p.zabel, robh, samuel, thomas.petazzoni,
u.kleine-koenig, wens
In-Reply-To: <20260413123920.2459916-1-bigunclemax@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
Hi Maksim,
On Mon 13 Apr 26, 15:39, bigunclemax@gmail.com wrote:
> > +
> > +/* PWM Capture Fall Lock Register */
> > +#define H616_PWM_CFLR(x) (0x74 + (x) * 0x20)
> > +
> > +#define H616_PWM_PAIR_IDX(chan) ((chan) >> 2)
> > +
>
> It looks like there's a typo or a mistake in the PAIR_IDX calculation.
> It should be like ((chan) >> 1).
> For example, for the 5th channel the result will be 1, but it should be 2.
Had a quick look at it too and I agree with you. A right shift by 2 essentially
groups pwms by 4, not 2. So pwms 2 and 3 would also be reported as part of
index 0.
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/9] dt-bindings: mmc: spacemit,sdhci: add pinctrl support for voltage switching
From: Conor Dooley @ 2026-04-13 15:43 UTC (permalink / raw)
To: Iker Pedrosa
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Troy Mitchell, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel
In-Reply-To: <20260413-orangepi-sd-card-uhs-v7-1-16650f49c022@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 694 bytes --]
On Mon, Apr 13, 2026 at 09:24:43AM +0200, Iker Pedrosa wrote:
> Document pinctrl properties to support voltage-dependent pin
> configuration switching for UHS-I SD card modes.
>
> Add optional pinctrl-names property with two states:
> - "default": For 3.3V operation with standard drive strength
> - "state_uhs": For 1.8V operation with optimized drive strength
>
> These pinctrl states allow the SDHCI driver to coordinate voltage
> switching with pin configuration changes, ensuring proper signal
> integrity during UHS-I mode transitions.
>
> Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Conor Dooley @ 2026-04-13 15:42 UTC (permalink / raw)
To: Ronald Claveau
Cc: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-1-1002d90a0602@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]
On Mon, Apr 13, 2026 at 12:52:42PM +0200, Ronald Claveau wrote:
> Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
>
> Unlike existing variants which use a phandle to the ao-secure syscon,
> the T7 relies on a secure monitor interface described by a phandle and
> a sensor index argument.
>
> The T7 integrates multiple thermal sensors, all accessed through the
> same SMC call. The sensor index argument is required to identify which
> sensor's calibration data the secure monitor should return, as a single
> SM_THERMAL_CALIB_READ command serves all of them.
>
> Introduce the amlogic,secure-monitor property as a phandle-array and
> make amlogic,ao-secure or amlogic,secure-monitor conditionally required
> depending on the compatible.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../bindings/thermal/amlogic,thermal.yaml | 42 ++++++++++++++++++++--
> 1 file changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> index 70b273271754b..1c096116b2dda 100644
> --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> @@ -21,7 +21,9 @@ properties:
> - amlogic,g12a-cpu-thermal
> - amlogic,g12a-ddr-thermal
> - const: amlogic,g12a-thermal
> - - const: amlogic,a1-cpu-thermal
> + - enum:
> + - amlogic,a1-cpu-thermal
> + - amlogic,t7-thermal
>
> reg:
> maxItems: 1
> @@ -42,12 +44,39 @@ properties:
> '#thermal-sensor-cells':
> const: 0
>
> + amlogic,secure-monitor:
> + description: phandle to the secure monitor
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - items:
> + - description: phandle to the secure monitor
> + - description: sensor index to get specific calibration data
> +
> required:
> - compatible
> - reg
> - interrupts
> - clocks
> - - amlogic,ao-secure
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - amlogic,a1-cpu-thermal
> + - amlogic,g12a-thermal
> + then:
> + required:
> + - amlogic,ao-secure
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: amlogic,t7-thermal
This can just be replaced by a else I think.
> + then:
> + required:
> + - amlogic,secure-monitor
>
> unevaluatedProperties: false
>
> @@ -62,4 +91,13 @@ examples:
> #thermal-sensor-cells = <0>;
> amlogic,ao-secure = <&sec_AO>;
> };
> + - |
> + a73_tsensor: temperature-sensor@20000 {
Can drop the label here, it has no users.
Otherwise, seems fine.
Cheers,
Conor.
pw-bot: changes-requested
> + compatible = "amlogic,t7-thermal";
> + reg = <0x0 0x20000 0x0 0x50>;
> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc_periphs CLKID_TS>;
> + #thermal-sensor-cells = <0>;
> + amlogic,secure-monitor = <&sm 1>;
> + };
> ...
>
> --
> 2.49.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 RESEND 1/2] dt-bindings: phy: mediatek,xsphy: add property to set disconnect threshold
From: Conor Dooley @ 2026-04-13 15:40 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Vinod Koul, AngeloGioacchino Del Regno, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel
In-Reply-To: <20260413122836.4848-1-chunfeng.yun@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
On Mon, Apr 13, 2026 at 08:28:35PM +0800, Chunfeng Yun wrote:
> Add a property to tune usb2 phy's disconnect threshold.
> And add a compatible for mt8196.
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v2: change property name
> ---
> Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml
> index 0bed847bb4ad..9017a9c93eb9 100644
> --- a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml
> @@ -50,6 +50,7 @@ properties:
> - mediatek,mt3611-xsphy
> - mediatek,mt3612-xsphy
> - mediatek,mt7988-xsphy
> + - mediatek,mt8196-xsphy
> - const: mediatek,xsphy
>
> reg:
> @@ -130,6 +131,13 @@ patternProperties:
> minimum: 1
> maximum: 7
>
> + mediatek,disconnect-threshold:
> + description:
> + The selection of disconnect threshold (U2 phy)
Why is this unitless? What does the threshold represent? Time? Voltage?
Something else?
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 1
> + maximum: 15
> +
> mediatek,efuse-intr:
> description:
> The selection of Internal Resistor (U2/U3 phy)
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 20/21] dt-bindings: gpio: describe Waveshare GPIO controller
From: Conor Dooley @ 2026-04-13 15:39 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan, dri-devel,
devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260413-waveshare-dsi-touch-v3-20-3aeb53022c32@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
On Mon, Apr 13, 2026 at 05:05:43PM +0300, Dmitry Baryshkov wrote:
> The Waveshare DSI TOUCH family of panels has separate on-board GPIO
> controller, which controls power supplies to the panel and the touch
> screen and provides reset pins for both the panel and the touchscreen.
> Also it provides a simple PWM controller for panel backlight.
>
> Add bindings for these GPIO controllers. As overall integration might be
> not very obvious (and it differs significantly from the bindings used by
> the original drivers), provide complete example with the on-board
> regulators and the DSI panel.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] soc: qcom: llcc-qcom: Capitalize LLCC/EDAC in comments and diagnostics
From: Mukesh Ojha @ 2026-04-13 15:25 UTC (permalink / raw)
To: Francisco Munoz Ruiz
Cc: Bjorn Andersson, Konrad Dybcio, Krzysztof Kozlowski, Conor Dooley,
Jonathan Cameron, Rob Herring, Kees Cook, Gustavo A. R. Silva,
linux-arm-msm, devicetree, linux-kernel, linux-hardening,
Konrad Dybcio
In-Reply-To: <20260407-external_llcc_changes2set-v2-3-b5017ce2020b@oss.qualcomm.com>
On Tue, Apr 07, 2026 at 02:51:49PM -0700, Francisco Munoz Ruiz wrote:
> Capitalize occurrences of the acronym "LLCC" and "EDAC" in comments
> and diagnostic text to improve consistency and readability.
>
> Signed-off-by: Francisco Munoz Ruiz <francisco.ruiz@oss.qualcomm.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
This could have been sent alone..
Reviewed-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add SRAM node
From: Krzysztof Kozlowski @ 2026-04-13 15:23 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alim Akhtar
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260413-exynos850_sram-v1-1-7fda5b7fb7d4@linaro.org>
On 13/04/2026 16:52, Alexey Klimov wrote:
> SRAM is used by the ACPM protocol to retrieve the ACPM channels
> information and configuration data. Add the SRAM node.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> index cb55015c8dce..cf4a6168846c 100644
> --- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> @@ -910,6 +910,14 @@ spi_2: spi@11d20000 {
> };
> };
> };
> +
> + apm_sram: sram@2039000 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x2039000 0x40000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x2039000 0x40000>;
You miss here children.
Also, 'ranges' should be after 'reg'.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Mathieu Poirier @ 2026-04-13 15:10 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan (OSS), Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <PAXPR04MB84591BCD80728EE880CA2AD888262@PAXPR04MB8459.eurprd04.prod.outlook.com>
On Fri, 10 Apr 2026 at 21:01, Peng Fan <peng.fan@nxp.com> wrote:
>
> > Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
> > SM CPU/LMM reset vector
> >
> > On Thu, Apr 09, 2026 at 08:30:54AM +0800, Peng Fan wrote:
> > > On Wed, Apr 08, 2026 at 09:46:32AM -0600, Mathieu Poirier wrote:
> > > >On Wed, Apr 08, 2026 at 01:30:16AM +0000, Peng Fan wrote:
> > > >> > Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass
> > bootaddr
> > > >> > to SM CPU/LMM reset vector
> > > >> >
> > > >> [...]
> > > >> >
> > > >> > >
> > > >> > > Aligning the ELF entry point with the hardware reset base on
> > > >> > Cortex‑M
> > > >> > > systems is possible, but it comes with several risks.
> > > >> >
> > > >> > I'm not asking to align the ELF entry point with the hardware
> > reset base.
> > > >> > All I want is to have the correct start address embedded in the
> > > >> > ELF file to avoid having to use a mask.
> > > >>
> > > >> I see, per my understanding:
> > > >> FreeRTOS typically exposes __isr_vector, which corresponds to the
> > > >> hardware reset / vector table base.
> > > >> Zephyr (Cortex‑M) exposes _vector_table, which serves the same
> > purpose.
> > > >> I am not certain about other RTOSes, but the pattern seems
> > consistent:
> > > >> the vector table base is already available as a named ELF symbol.
> > > >>
> > > >> Given that, if the preferred approach is to parse the ELF and
> > > >> explicitly retrieve the hardware reset base, I can update the
> > implementation accordingly.
> > > >> If you prefer to parse the elf file to get the hardware reset base,
> > > >> I could update to use them.
> > > >>
> > > >> Options1: Something as below:
> > > >> 1. Include rproc_elf_find_symbol in remoteproc_elf_loader.c 2.
> > Use
> > > >> below in imx_rproc.c ret = rproc_elf_find_symbol(rproc, fw,
> > > >> "__isr_vector", &vector_base); if (ret)
> > > >> ret = rproc_elf_find_symbol(rproc, fw, "__vector_table",
> > > >> &vector_base);
> > > >>
> > > >> if (!ret)
> > > >> rproc->bootaddr = vector_base
> > > >> else
> > > >> dev_info(dev, "no __isr_vector or __vector_table\n")
> > > >
> > > >No
> > >
> > > If your concern is about rproc->bootaddr, I could introduce
> > > imx_rproc->vector_base for i.MX. Please help detail a bit.
> > >
> > > >
> > > >>
> > > >> This makes the hardware reset base explicit, avoids masking
> > e_entry.
> > > >>
> > > >> Option 2: User‑provided reset symbol via sysfs As an alternative,
> > > >> we could expose a sysfs attribute, e.g. reset_symbol, allowing
> > > >> users to specify the symbol name to be used as the reset base:
> > > >>
> > > >> echo __isr_vector >
> > /sys/class/remoteproc/remoteprocX/reset_symbol
> > > >>
> > > >
> > > >Definitely not.
> > > >
> > > >The definition of e_entry in the specification is clear, i.e "the
> > > >address of the entry point from where the process starts executing".
> > > >If masking is required because the tool that puts the image together
> > > >gets the wrong address, then it should be fixed.
> > >
> > > The hardware reset base is the address from which the hardware
> > fetches
> > > the initial stack pointer and program counter values and loads them
> > > into the SP and PC registers. In contrast, bootaddr (i.e. e_entry)
> > > represents the address at which the CPU starts executing code (the
> > PC
> > > value after reset). As you pointed out earlier, this distinction is clear.
> > >
> > > In our case, we need to obtain the hardware reset base and pass that
> > > value to the system firmware. However, e_entry should not be set to
> > > the hardware reset base. Doing so would introduce the issues I
> > > described in [1]. This means we should not modify the Zephyr or
> > > FreeRTOS build outputs to make e_entry equal to the hardware reset
> > base.
> >
> >
> > As I said earlier, I am _not_ suggesting to make e_entry equal to the
> > hardware reset base.
>
> Let me try to restate my understanding more precisely and please
> correct me if I am still missing the point.
>
> From your comment:
> "
> If masking is required because the tool that puts the image together gets the
> wrong address, then it should be fixed.
> "
>
> I understand this as saying that masking e_entry is not acceptable, because
> e_entry already has a clear and correct meaning: it is the execution entry
> address, and the kernel should not reinterpret or “fix up” that value.
> At the same time, we still need to provide the hardware reset vector base
> to the system firmware, and that value is distinct from e_entry.
>
> On i.MX94/5 platforms the reset base is software‑programmable, but that
> information is not represented by e_entry, nor is there currently a
> separate place in the remoteproc framework to convey a reset‑vector
> base independent of the execution entry point.
>
> Given these constraints, I see limited options on the kernel side.
>
> One conservative approach would be to rely on a fixed, platform‑defined
> reset base for the affected SoCs. And update RTOS linking script to put
> the vector to the location of fixed hardware reset base.
>
The problem with the current patchset is the overloading of
rproc->bootaddr in function rproc_fw_boot() [1]. After that point
rproc->bootaddr holds the hardware reset address communicated to the
remote processor's firmware and not the beginning of execution as
intended by the definition of e_entry. This is very confusing to
anyone reviewing the code without a clear understanding of the
context.
To fix this I suggest masking rproc->bootaddr in
imx_rproc_sm_cpu_start() and imx_rproc_sm_lmm_start() with a copious
amount of in-lined documentation.
[1]. https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/remoteproc/remoteproc_core.c#L1401
> Thanks,
> Peng
>
> >
> > We are going in circles here.
> >
> > >
> > > Given these constraints, the feasible solutions I can see are either:
> > > - option 1 (explicitly retrieving the hardware reset base), or
> > > - continuing to use masking.
> > >
> > > Please suggest.
> > >
> > > [1]
> > >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > lore
> > > .kernel.org%2Fall%2Facs2PAZq2k3zjmDW%40shlinux89%2F&data=0
> > 5%7C02%7Cpen
> > >
> > g.fan%40nxp.com%7C8a5ce35d492b4adb2d3b08de97192cbb%7C686
> > ea1d3bc2b4c6fa
> > >
> > 92cd99c5c301635%7C0%7C0%7C639114331565834960%7CUnknow
> > n%7CTWFpbGZsb3d8e
> > >
> > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> > kFOIjoiTWF
> > >
> > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Pnkirz3BMEuLsJU9
> > MHQNon84HIyMX
> > > 08x1wCK04dS7VU%3D&reserved=0
> > >
> > > Thanks,
> > > Peng
> > >
> > > >
> > > >> The remoteproc core would then resolve that symbol from the ELF
> > and
> > > >> set rproc->bootaddr accordingly.
> > > >> This provides maximum flexibility but does introduce a new
> > > >> user‑visible ABI, so I see it more as an opt‑in or fallback
> > mechanism.
> > > >>
> > > >> Please let me know which approach you prefer, and I will update
> > > >> this series accordingly in v3..
> > > >>
> > > >> Thanks,
> > > >> Peng.
> > > >>
> > > >>
> > > >> >
> > > >> > > 1, Semantic mismatch (ELF vs. hardware behavior) 2,
> > Debuggers
> > > >> > > may attempt to set breakpoints or start execution at the entry
> > > >> > > symbol
> > > >> > >
^ permalink raw reply
* Re: [PATCH v3 4/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Markus Schneider-Pargmann @ 2026-04-13 14:58 UTC (permalink / raw)
To: Vignesh Raghavendra, Markus Schneider-Pargmann, Bjorn Andersson,
Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Suman Anna, Nishanth Menon, Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <c35fea4e-dc22-4314-9c5c-bfa5b880864d@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3256 bytes --]
Hi Vignesh,
On Sat Apr 11, 2026 at 4:47 PM CEST, Vignesh Raghavendra wrote:
>
>
> On 10/04/26 19:12, Markus Schneider-Pargmann wrote:
>> Hi Vignesh,
>>
>> On Fri Apr 10, 2026 at 6:30 AM CEST, Vignesh Raghavendra wrote:
>>> Hi Markus
>>>
>>> On 18/03/26 20:43, Markus Schneider-Pargmann (TI) wrote:
>>>> Split the firmware memory region in more specific parts so it is better
>>>> described where to find which information. Specifically the LPM metadata
>>>> region is important as bootloader software like U-Boot has to know where
>>>> that data is to be able to read that data.
>>>>
>>>> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
>>>> ---
>>>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 40 +++++++++++++++++++++++++++++++--
>>>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..c381cc33064ec427751a9ac5bcdff745a9559a89 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> @@ -59,9 +59,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
>>>> no-map;
>>>> };
>>>>
>>>> - wkup_r5fss0_core0_memory_region: memory@9c900000 {
>>>> + wkup_r5fss0_core0_ipc_region: memory@9c900000 {
>>>
>>> There are still references to wkup_r5fss0_core0_memory_region in
>>> k3-am62a-ti-ipc-firmware.dtsi (same comment applies to next 2 patches as
>>> well)
>>>
>>> Dont those need to be updated too?
>>
>> I only updated the sk boards as these are the only ones that have IO+DDR
>> support that I know works and need the new memory region layout. But
>> thinking about this, updating the memory region structure shouldn't be a
>> problem for the other boards either, of course I can't tell if IO+DDR
>> would work on them, but the new memory region layout shouldn't break
>> anything.
>
> I am not talking about updating other boards, but specifically about
> k3-am62*-ti-ipc-firmware.dtsi which have a phandle reference to
> wkup_r5fss0_core0_memory_region. Therefore any dts trying to include
> this dtsi would fail to compile post this series.
I am not sure I understand why they would fail?
The current design is to have the k3-am62*-ti-ipc-firmware.dtsi files
reference the memory regions in the r5fss node, for example:
&wkup_r5fss0_core0 {
mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
<&wkup_r5fss0_core0_memory_region>;
memory-region-names = "dma", "firmware";
status = "okay";
};
But k3-am62*-ti-ipc-firmware.dtsi do not define these memory regions.
Instead it relies on the dts files to define them. That is done for
example in k3-am62a7-sk.dts and others.
This patch now changes the memory regions being used by r5fss0 as well
as the memory regions being defined but only in k3-am62a7-sk.dts. It
does not change the references or definitions in
k3-am62*-ti-ipc-firmware.dtsi.
So I think including the k3-am62*-ti-ipc-firmware.dtsi file should still
work as long as you have the memory regions defined in the dts file.
Best
Markus
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: exynos850: Add SRAM node
From: Alexey Klimov @ 2026-04-13 14:52 UTC (permalink / raw)
To: Sam Protsenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alim Akhtar
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Alexey Klimov
SRAM is used by the ACPM protocol to retrieve the ACPM channels
information and configuration data. Add the SRAM node.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
arch/arm64/boot/dts/exynos/exynos850.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
index cb55015c8dce..cf4a6168846c 100644
--- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
@@ -910,6 +910,14 @@ spi_2: spi@11d20000 {
};
};
};
+
+ apm_sram: sram@2039000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x2039000 0x40000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x2039000 0x40000>;
+ };
};
#include "exynos850-pinctrl.dtsi"
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260413-exynos850_sram-ca1200b99e82
Best regards,
--
Alexey Klimov <alexey.klimov@linaro.org>
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: Add SoCFPGA Agilex7M devkit
From: Dinh Nguyen @ 2026-04-13 14:45 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt; +Cc: dinguyen, devicetree, Niravkumar L Rabara
In-Reply-To: <20260413144553.132737-1-dinguyen@kernel.org>
The Agilex7-M SoCDK is largely compatible with the Agilex SoCDK.
Reuse the existing Agilex device tree while disabling the QSPI
controller, which is not present on Agilex7-M.
Signed-off-by: Niravkumar L Rabara <niravkumar.l.rabara@intel.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
arch/arm64/boot/dts/intel/Makefile | 1 +
.../boot/dts/intel/socfpga_agilex7m_socdk.dts | 15 +++++++++++++++
2 files changed, 16 insertions(+)
create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex7m_socdk.dts
diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
index 33fcc55d0cb9..088a03b89c99 100644
--- a/arch/arm64/boot/dts/intel/Makefile
+++ b/arch/arm64/boot/dts/intel/Makefile
@@ -8,5 +8,6 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
socfpga_agilex5_socdk_013b.dtb \
socfpga_agilex5_socdk_modular.dtb \
socfpga_agilex5_socdk_nand.dtb \
+ socfpga_agilex7m_socdk.dtb \
socfpga_n5x_socdk.dtb
dtb-$(CONFIG_ARCH_KEEMBAY) += keembay-evm.dtb
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex7m_socdk.dts b/arch/arm64/boot/dts/intel/socfpga_agilex7m_socdk.dts
new file mode 100644
index 000000000000..164556e0a785
--- /dev/null
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex7m_socdk.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+// Copyright (c) 2023 Intel Corporation
+
+#include "socfpga_agilex_socdk.dts"
+
+/ {
+ model = "Intel SoCFPGA Agilex7-M SoCDK";
+ compatible = "intel,socfpga-agilex7m-socdk",
+ "intel,socfpga-agilex7m",
+ "intel,socfpga-agilex";
+};
+
+&qspi {
+ status = "disabled";
+};
--
2.42.0.411.g813d9a9188
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: socfpga: Add the Agilex7 series SoC's
From: Dinh Nguyen @ 2026-04-13 14:45 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt; +Cc: dinguyen, devicetree
The Agilex7 is a series of devices from Altera that are derived from
the Agilex family.
The Agilex7F device supports PCIE 4.0 and DDR4. The Agilex7I device supports
PCIE 5.0 and DDR4, while the Agilex7M device supports DDR4, DDR5, LPDDR5
and PCIE 5.0.
All other peripherals from these devices are the same as the Agilex
device.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
Documentation/devicetree/bindings/arm/altera.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml
index 206686f3eebc..5ee09f8d4698 100644
--- a/Documentation/devicetree/bindings/arm/altera.yaml
+++ b/Documentation/devicetree/bindings/arm/altera.yaml
@@ -115,6 +115,16 @@ properties:
- intel,socfpga-agilex5-socdk-nand
- const: intel,socfpga-agilex5
+ - description: Agilex7 series F, I and M boards
+ items:
+ - enum:
+ - intel,socfpga-agilex7m-socdk
+ - enum:
+ - intel,socfpga-agilex7f
+ - intel,socfpga-agilex7i
+ - intel,socfpga-agilex7m
+ - const: intel,socfpga-agilex
+
- description: SoCFPGA VT
items:
- const: altr,socfpga-vt
--
2.42.0.411.g813d9a9188
^ permalink raw reply related
* Re: [PATCH 2/2] dt-bindings: arm: cpus: Add compatible qcom,oryon-1-5
From: Shawn Guo @ 2026-04-13 14:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Deepti Jaggi, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <cc08a091-9f2d-48de-9284-2f0c68fd343a@kernel.org>
On Mon, Apr 13, 2026 at 03:30:28PM +0200, Krzysztof Kozlowski wrote:
> On 13/04/2026 15:10, Shawn Guo wrote:
> > On Mon, Apr 13, 2026 at 02:40:18PM +0200, Krzysztof Kozlowski wrote:
> >>>> Please organize your patchset correctly.
> >>>
> >>> Are you asking for a big series that consists of all the new bindings
> >>> used by Nord DTS and DTS itself? Unless this big series gets applied as
> >>> one-go, there are still chances that bindings get into a kernel release
> >>> without any users, e.g. subsystem maintainers pick up bindgins being
> >>> reviewed, but DTS requires more iterations and thus misses the release.
> >>
> >> Please follow existing rules, communicated multiple times on the mailing
> >> list. Qualcomm also has internal guideline clarifying this.
> >>
> >> Below are some upstream discussion clarifying this:
> >> https://lore.kernel.org/linux-samsung-soc/CADrjBPq_0nUYRABKpskRF_dhHu+4K=duPVZX==0pr+cjSL_caQ@mail.gmail.com/T/#m2d9130a1342ab201ab49670fa6c858ee3724c83c
> >> https://lore.kernel.org/all/49258645-d4d8-44a5-a4fc-b403c926a5d1@kernel.org/
> >>
> >> And how to do it:
> >> https://lore.kernel.org/all/20231121-topic-sm8650-upstream-dt-v3-0-db9d0507ffd3@linaro.org/
> >
> > That's what I'm trying to do, posting bindings in prior to DTS, so that
>
> Hm? Nothing above claimed that. I am sorry, but which rule either
> communicated publicly or privately encouraged or even allowed that?
>
> > when posting DTS, either bindings is already merged or we can refer to
> > lore link of bindings.
> >
> > I still need to understand you comment "Bindings come with the user".
> > Are you saying that bindings and DTS in different series should be posted
> > at the same time to show bindings has an user?
>
> I am saying that you cannot post bindings alone where there is no user.
> Why do want even such binding? I see no point in having it in the
> kernel, unless you speak about very specific exception, but then please
> clarify that exception and why it applies to this work.
I think I'm getting what the requirement is now, but still not sure what
the point of the requirement is.
- Posting bindings and DTS at the same time doesn't guarantee they get
into the same release. It can often happen that bindings are merged
alone into a release. So it doesn't really help to avoid situation of
there is bindings in-tree with no users.
- From what I can see, there are always DTS patches coming after bindings
changes, sooner or later. No one would be bothered to submit a bindings
if the DTS using the bindings is only kept out of tree.
In short, there will be Nord DTS using the binding coming, and I do not
think posting them at the same time should be a requirement.
Shawn
^ permalink raw reply
* Re: [PATCH] dt-bindings: iio: light: Add PixArt PAJ7620 gesture sensor
From: David Lechner @ 2026-04-13 14:25 UTC (permalink / raw)
To: Harpreet Saini, jic23
Cc: Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Bjorn Andersson, Marek Vasut,
Kael D'Alcamo, Lad Prabhakar, linux-iio, devicetree,
linux-kernel
In-Reply-To: <20260413000308.7618-1-sainiharpreet29@yahoo.com>
On 4/12/26 7:02 PM, Harpreet Saini wrote:
> Signed-off-by: Harpreet Saini <sainiharpreet29@yahoo.com>
> ---
> This is part 1 of a 2-patch series proposing a driver for the PixArt
> PAJ7620 gesture sensor. This patch adds the Device Tree bindings and
Gesture sensor sounds like input subsystem, not IIO.
> registers the "pixart" vendor prefix. The driver patch will follow in
> a succeeding branch.
>
> .../bindings/iio/light/pixart,paj7620.yaml | 48 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> 2 files changed, 50 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/light/pixart,paj7620.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/light/pixart,paj7620.yaml b/Documentation/devicetree/bindings/iio/light/pixart,paj7620.yaml
> new file mode 100644
> index 000000000000..301816485fcc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/light/pixart,paj7620.yaml
> @@ -0,0 +1,48 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/light/pixart,paj7620.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: PixArt PAJ7620 Gesture Sensor
> +
> +maintainers:
> + - Harpreet Saini <sainiharpreet29@yahoo.com>
> +
> +description: |
> + The PixArt PAJ7620 is a gesture recognition sensor with an integrated
> + infrared LED and CMOS array. It communicates over an I2C interface and
> + provides gesture data via a dedicated interrupt pin.
> +
> +properties:
> + compatible:
> + const: pixart,paj7620
> +
> + reg:
> + maxItems: 1
> + description: The I2C address of the sensor.
> +
> + interrupts:
> + maxItems: 1
> + description: Interrupt mapping for the sensor's physical INT pin.
> +
missing power supplies:
vbus-supply: true
vled-supply: true
vdd-supply: true
Can also be GPIO controller (if not using SPI bus), so
gpio-controller: true
#gpio-cells:
const: 2
There is also a SPI bus, but it looks like SPI and I2C would be connected
at the same time (SPI for image data, I2C for register access). Bindings
for that could be complicated, so could wait to add that until there is an
actual user.
In general though, bindings should be as complete as possible even if the
driver doesn't implement some of the features, like gpio controller.
> +required:
> + - compatible
> + - reg
> + - interrupts
power supplies should be required.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + paj7620@73 {
> + compatible = "pixart,paj7620";
> + reg = <0x73>;
> + interrupts = <4 IRQ_TYPE_EDGE_FALLING>;
> + };
> + };
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index ee7fd3cfe203..d73a0bf62b62 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1273,6 +1273,8 @@ patternProperties:
> description: Pine64
> "^pineriver,.*":
> description: Shenzhen PineRiver Designs Co., Ltd.
> + "^pixart,.*":
> + description: PixArt Imaging Inc.
> "^pixcir,.*":
> description: PIXCIR MICROELECTRONICS Co., Ltd
> "^plantower,.*":
^ permalink raw reply
* [PATCH v3 21/21] gpio: add GPIO controller found on Waveshare DSI TOUCH panels
From: Dmitry Baryshkov @ 2026-04-13 14:05 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio, Riccardo Mereu
In-Reply-To: <20260413-waveshare-dsi-touch-v3-0-3aeb53022c32@oss.qualcomm.com>
The Waveshare DSI TOUCH family of panels has separate on-board GPIO
controller, which controls power supplies to the panel and the touch
screen and provides reset pins for both the panel and the touchscreen.
Also it provides a simple PWM controller for panel backlight. Add
support for this GPIO controller.
Tested-by: Riccardo Mereu <r.mereu@arduino.cc>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpio/Kconfig | 10 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-waveshare-dsi.c | 208 ++++++++++++++++++++++++++++++++++++++
3 files changed, 219 insertions(+)
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b45fb799e36c..e24ad7e32034 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -804,6 +804,16 @@ config GPIO_VISCONTI
help
Say yes here to support GPIO on Tohisba Visconti.
+config GPIO_WAVESHARE_DSI_TOUCH
+ tristate "Waveshare GPIO controller for DSI panels"
+ depends on BACKLIGHT_CLASS_DEVICE
+ depends on I2C
+ select REGMAP_I2C
+ help
+ Enable support for the GPIO and PWM controller found on Waveshare DSI
+ TOUCH panel kits. It provides GPIOs (used for regulator control and
+ resets) and backlight support.
+
config GPIO_WCD934X
tristate "Qualcomm Technologies Inc WCD9340/WCD9341 GPIO controller driver"
depends on MFD_WCD934X && OF_GPIO
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index c05f7d795c43..94f16f0f28d9 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -206,6 +206,7 @@ obj-$(CONFIG_GPIO_VIRTUSER) += gpio-virtuser.o
obj-$(CONFIG_GPIO_VIRTIO) += gpio-virtio.o
obj-$(CONFIG_GPIO_VISCONTI) += gpio-visconti.o
obj-$(CONFIG_GPIO_VX855) += gpio-vx855.o
+obj-$(CONFIG_GPIO_WAVESHARE_DSI_TOUCH) += gpio-waveshare-dsi.o
obj-$(CONFIG_GPIO_WCD934X) += gpio-wcd934x.o
obj-$(CONFIG_GPIO_WHISKEY_COVE) += gpio-wcove.o
obj-$(CONFIG_GPIO_WINBOND) += gpio-winbond.o
diff --git a/drivers/gpio/gpio-waveshare-dsi.c b/drivers/gpio/gpio-waveshare-dsi.c
new file mode 100644
index 000000000000..38f52351bb58
--- /dev/null
+++ b/drivers/gpio/gpio-waveshare-dsi.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 Waveshare International Limited
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/backlight.h>
+#include <linux/err.h>
+#include <linux/fb.h>
+#include <linux/gpio/driver.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/regmap.h>
+
+/* I2C registers of the microcontroller. */
+#define REG_TP 0x94
+#define REG_LCD 0x95
+#define REG_PWM 0x96
+#define REG_SIZE 0x97
+#define REG_ID 0x98
+#define REG_VERSION 0x99
+
+enum {
+ GPIO_AVDD = 0,
+ GPIO_PANEL_RESET = 1,
+ GPIO_BL_ENABLE = 2,
+ GPIO_IOVCC = 4,
+ GPIO_VCC = 8,
+ GPIO_TS_RESET = 9,
+};
+
+#define NUM_GPIO 16
+
+struct waveshare_gpio {
+ struct mutex dir_lock;
+ struct mutex pwr_lock;
+ struct regmap *regmap;
+ u16 poweron_state;
+
+ struct gpio_chip gc;
+};
+
+static const struct regmap_config waveshare_gpio_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = REG_VERSION,
+};
+
+static int waveshare_gpio_get(struct waveshare_gpio *state, unsigned int offset)
+{
+ u16 pwr_state;
+
+ guard(mutex)(&state->pwr_lock);
+ pwr_state = state->poweron_state & BIT(offset);
+
+ return !!pwr_state;
+}
+
+static int waveshare_gpio_set(struct waveshare_gpio *state, unsigned int offset, int value)
+{
+ u16 last_val;
+ int err;
+
+ guard(mutex)(&state->pwr_lock);
+
+ last_val = state->poweron_state;
+ if (value)
+ last_val |= BIT(offset);
+ else
+ last_val &= ~BIT(offset);
+
+ state->poweron_state = last_val;
+
+ err = regmap_write(state->regmap, REG_TP, last_val >> 8);
+ if (!err)
+ err = regmap_write(state->regmap, REG_LCD, last_val & 0xff);
+
+ return err;
+}
+
+static int waveshare_gpio_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
+{
+ return GPIO_LINE_DIRECTION_OUT;
+}
+
+static int waveshare_gpio_gpio_get(struct gpio_chip *gc, unsigned int offset)
+{
+ struct waveshare_gpio *state = gpiochip_get_data(gc);
+
+ return waveshare_gpio_get(state, offset);
+}
+
+static int waveshare_gpio_gpio_set(struct gpio_chip *gc, unsigned int offset, int value)
+{
+ struct waveshare_gpio *state = gpiochip_get_data(gc);
+
+ return waveshare_gpio_set(state, offset, value);
+}
+
+static int waveshare_gpio_update_status(struct backlight_device *bl)
+{
+ struct waveshare_gpio *state = bl_get_data(bl);
+ int brightness = backlight_get_brightness(bl);
+
+ waveshare_gpio_set(state, GPIO_BL_ENABLE, brightness);
+
+ return regmap_write(state->regmap, REG_PWM, brightness);
+}
+
+static const struct backlight_ops waveshare_gpio_bl = {
+ .update_status = waveshare_gpio_update_status,
+};
+
+static int waveshare_gpio_probe(struct i2c_client *i2c)
+{
+ struct backlight_properties props = {};
+ struct waveshare_gpio *state;
+ struct device *dev = &i2c->dev;
+ struct backlight_device *bl;
+ struct regmap *regmap;
+ unsigned int data;
+ int ret;
+
+ state = devm_kzalloc(dev, sizeof(*state), GFP_KERNEL);
+ if (!state)
+ return -ENOMEM;
+
+ ret = devm_mutex_init(dev, &state->dir_lock);
+ if (ret)
+ return ret;
+
+ ret = devm_mutex_init(dev, &state->pwr_lock);
+ if (ret)
+ return ret;
+
+ regmap = devm_regmap_init_i2c(i2c, &waveshare_gpio_regmap_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap), "Failed to allocate register map\n");
+
+ state->regmap = regmap;
+ i2c_set_clientdata(i2c, state);
+
+ ret = regmap_read(regmap, REG_ID, &data);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read register\n");
+
+ dev_dbg(dev, "waveshare panel hw id = 0x%x\n", data);
+
+ ret = regmap_read(regmap, REG_SIZE, &data);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read register\n");
+
+ dev_dbg(dev, "waveshare panel size = %d\n", data);
+
+ ret = regmap_read(regmap, REG_VERSION, &data);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "Failed to read register\n");
+
+ dev_dbg(dev, "waveshare panel mcu version = 0x%x\n", data);
+
+ ret = waveshare_gpio_set(state, GPIO_TS_RESET, 1);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to program GPIOs\n");
+
+ msleep(20);
+
+ state->gc.parent = dev;
+ state->gc.label = i2c->name;
+ state->gc.owner = THIS_MODULE;
+ state->gc.base = -1;
+ state->gc.ngpio = NUM_GPIO;
+
+ /* it is output only */
+ state->gc.get = waveshare_gpio_gpio_get;
+ state->gc.set = waveshare_gpio_gpio_set;
+ state->gc.get_direction = waveshare_gpio_gpio_get_direction;
+ state->gc.can_sleep = true;
+
+ ret = devm_gpiochip_add_data(dev, &state->gc, state);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to create gpiochip\n");
+
+ props.type = BACKLIGHT_RAW;
+ props.max_brightness = 255;
+ props.brightness = 255;
+ bl = devm_backlight_device_register(dev, dev_name(dev), dev, state,
+ &waveshare_gpio_bl, &props);
+ return PTR_ERR_OR_ZERO(bl);
+}
+
+static const struct of_device_id waveshare_gpio_dt_ids[] = {
+ { .compatible = "waveshare,dsi-touch-gpio" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, waveshare_gpio_dt_ids);
+
+static struct i2c_driver waveshare_gpio_regulator_driver = {
+ .driver = {
+ .name = "waveshare-regulator",
+ .of_match_table = of_match_ptr(waveshare_gpio_dt_ids),
+ },
+ .probe = waveshare_gpio_probe,
+};
+
+module_i2c_driver(waveshare_gpio_regulator_driver);
+
+MODULE_DESCRIPTION("GPIO controller driver for Waveshare DSI touch panels");
+MODULE_LICENSE("GPL");
--
2.47.3
^ permalink raw reply related
* [PATCH v3 20/21] dt-bindings: gpio: describe Waveshare GPIO controller
From: Dmitry Baryshkov @ 2026-04-13 14:05 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260413-waveshare-dsi-touch-v3-0-3aeb53022c32@oss.qualcomm.com>
The Waveshare DSI TOUCH family of panels has separate on-board GPIO
controller, which controls power supplies to the panel and the touch
screen and provides reset pins for both the panel and the touchscreen.
Also it provides a simple PWM controller for panel backlight.
Add bindings for these GPIO controllers. As overall integration might be
not very obvious (and it differs significantly from the bindings used by
the original drivers), provide complete example with the on-board
regulators and the DSI panel.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
.../bindings/gpio/waveshare,dsi-touch-gpio.yaml | 100 +++++++++++++++++++++
1 file changed, 100 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.yaml b/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.yaml
new file mode 100644
index 000000000000..410348fcda25
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/waveshare,dsi-touch-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Waveshare GPIO controller on DSI TOUCH panels
+
+maintainers:
+ - Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
+
+description:
+ Waveshare DSI TOUCH panel kits contain separate GPIO controller for toggling
+ power supplies and panel / touchscreen resets.
+
+properties:
+ compatible:
+ const: waveshare,dsi-touch-gpio
+
+ reg:
+ maxItems: 1
+
+ gpio-controller: true
+
+ '#gpio-cells':
+ const: 2
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wsgpio: gpio@45 {
+ compatible = "waveshare,dsi-touch-gpio";
+ reg = <0x45>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+
+ panel_avdd: regulator-panel-avdd {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-avdd";
+ gpios = <&wsgpio 0 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel_iovcc: regulator-panel-iovcc {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-iovcc";
+ gpios = <&wsgpio 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ panel_vcc: regulator-panel-vcc {
+ compatible = "regulator-fixed";
+ regulator-name = "panel-vcc";
+ gpios = <&wsgpio 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-always-on;
+ };
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ reg = <0>;
+ compatible = "waveshare,8.0-dsi-touch-a", "jadard,jd9365da-h3";
+ reset-gpios = <&wsgpio 1 GPIO_ACTIVE_LOW>;
+ vdd-supply = <&panel_avdd>;
+ vccio-supply = <&panel_iovcc>;
+ backlight = <&wsgpio>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ };
+ };
+ };
+
+ port {
+ dsi_out: endpoint {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
+...
--
2.47.3
^ permalink raw reply related
* [PATCH v3 19/21] drm/panel: add driver for Waveshare 8.8" DSI TOUCH-A panel
From: Dmitry Baryshkov @ 2026-04-13 14:05 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260413-waveshare-dsi-touch-v3-0-3aeb53022c32@oss.qualcomm.com>
Add driver for the panel found on Waveshare 8.8" DSI TOUCH-A kit. It
uses ota7290b IC as a controller.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/panel/Kconfig | 12 ++
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-focaltech-ota7290b.c | 226 +++++++++++++++++++++++
3 files changed, 239 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index ba527b4d7737..979109c27b9b 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -144,6 +144,18 @@ config DRM_PANEL_FEIYANG_FY07024DI26A30D
Say Y if you want to enable support for panels based on the
Feiyang FY07024DI26A30-D MIPI-DSI interface.
+config DRM_PANEL_FOCALTECH_OTA7290B
+ tristate "Focaltech OTA7290B"
+ depends on DRM_MIPI_DSI
+ depends on I2C
+ depends on BACKLIGHT_CLASS_DEVICE
+ select DRM_KMS_HELPER
+ help
+ Enable support for panels using OTA7290B as a controller (for
+ example, Waveshare 12.3" DSI TOUCH-A panel). Say Y here if you want
+ to enable support for this panel. To compile this driver as a module,
+ choose M here.
+
config DRM_PANEL_DSI_CM
tristate "Generic DSI command mode panels"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index a4291dc3905b..0d694acbfbb6 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_PANEL_EBBG_FT8719) += panel-ebbg-ft8719.o
obj-$(CONFIG_DRM_PANEL_ELIDA_KD35T133) += panel-elida-kd35t133.o
obj-$(CONFIG_DRM_PANEL_FEIXIN_K101_IM2BA02) += panel-feixin-k101-im2ba02.o
obj-$(CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D) += panel-feiyang-fy07024di26a30d.o
+obj-$(CONFIG_DRM_PANEL_FOCALTECH_OTA7290B) += panel-focaltech-ota7290b.o
obj-$(CONFIG_DRM_PANEL_HIMAX_HX8279) += panel-himax-hx8279.o
obj-$(CONFIG_DRM_PANEL_HIMAX_HX83102) += panel-himax-hx83102.o
obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112A) += panel-himax-hx83112a.o
diff --git a/drivers/gpu/drm/panel/panel-focaltech-ota7290b.c b/drivers/gpu/drm/panel/panel-focaltech-ota7290b.c
new file mode 100644
index 000000000000..8c135697a0fd
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-focaltech-ota7290b.c
@@ -0,0 +1,226 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2024 Waveshare International Limited
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+
+#include <linux/gpio/consumer.h>
+#include <linux/regulator/consumer.h>
+
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_probe_helper.h>
+
+struct ota7290b {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi;
+
+ struct regulator *power;
+ struct gpio_desc *reset;
+ struct regulator *avdd;
+ struct regulator *vdd;
+ struct regulator *vcc;
+
+ enum drm_panel_orientation orientation;
+};
+
+static inline struct ota7290b *panel_to_ota(struct drm_panel *panel)
+{
+ return container_of(panel, struct ota7290b, panel);
+}
+
+static int ota7290b_prepare(struct drm_panel *panel)
+{
+ struct ota7290b *ctx = panel_to_ota(panel);
+ struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
+ int ret;
+
+ if (ctx->vcc) {
+ ret = regulator_enable(ctx->vcc);
+ if (ret)
+ dev_err(panel->dev, "failed to enable VCC regulator: %d\n", ret);
+ }
+
+ if (ctx->reset) {
+ gpiod_set_value_cansleep(ctx->reset, 0);
+ msleep(60);
+ gpiod_set_value_cansleep(ctx->reset, 1);
+ msleep(60);
+ }
+
+ if (ctx->vdd) {
+ ret = regulator_enable(ctx->vdd);
+ if (ret)
+ dev_err(panel->dev, "failed to enable VDD regulator: %d\n", ret);
+ }
+
+ if (ctx->reset) {
+ gpiod_set_value_cansleep(ctx->reset, 0);
+ msleep(60);
+ }
+
+ if (ctx->avdd) {
+ ret = regulator_enable(ctx->avdd);
+ if (ret)
+ dev_err(panel->dev, "failed to enable AVDD regulator: %d\n", ret);
+ }
+
+ mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
+ mipi_dsi_msleep(&dsi_ctx, 120);
+ mipi_dsi_dcs_set_display_on_multi(&dsi_ctx);
+ mipi_dsi_msleep(&dsi_ctx, 50);
+
+ if (dsi_ctx.accum_err < 0)
+ dev_err(panel->dev, "failed to init panel: %d\n", dsi_ctx.accum_err);
+
+ return dsi_ctx.accum_err;
+}
+
+static int ota7290b_unprepare(struct drm_panel *panel)
+{
+ struct ota7290b *ctx = panel_to_ota(panel);
+ struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
+
+ mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
+ mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
+
+ if (ctx->avdd)
+ regulator_disable(ctx->avdd);
+
+ if (ctx->reset) {
+ gpiod_set_value_cansleep(ctx->reset, 1);
+ msleep(5);
+ }
+
+ if (ctx->vdd)
+ regulator_disable(ctx->vdd);
+
+ if (ctx->vcc)
+ regulator_disable(ctx->vcc);
+
+ return 0;
+}
+
+static const struct drm_display_mode waveshare_dsi_touch_8_8_a_mode = {
+ .clock = 75000,
+
+ .hdisplay = 480,
+ .hsync_start = 480 + 50,
+ .hsync_end = 480 + 50 + 50,
+ .htotal = 480 + 50 + 50 + 50,
+
+ .vdisplay = 1920,
+ .vsync_start = 1920 + 20,
+ .vsync_end = 1920 + 20 + 20,
+ .vtotal = 1920 + 20 + 20 + 20,
+
+ .width_mm = 68,
+ .height_mm = 219,
+ .type = DRM_MODE_TYPE_DRIVER,
+};
+
+static int ota7290b_get_modes(struct drm_panel *panel,
+ struct drm_connector *connector)
+{
+ return drm_connector_helper_get_modes_fixed(connector, &waveshare_dsi_touch_8_8_a_mode);
+}
+
+static enum drm_panel_orientation ota7290b_get_orientation(struct drm_panel *panel)
+{
+ struct ota7290b *ctx = panel_to_ota(panel);
+
+ return ctx->orientation;
+}
+
+static const struct drm_panel_funcs ota7290b_funcs = {
+ .prepare = ota7290b_prepare,
+ .unprepare = ota7290b_unprepare,
+ .get_modes = ota7290b_get_modes,
+ .get_orientation = ota7290b_get_orientation,
+};
+
+static int ota7290b_probe(struct mipi_dsi_device *dsi)
+{
+ struct ota7290b *ctx;
+ int ret;
+
+ ctx = devm_drm_panel_alloc(&dsi->dev, struct ota7290b, panel,
+ &ota7290b_funcs,
+ DRM_MODE_CONNECTOR_DSI);
+ if (!ctx)
+ return -ENOMEM;
+ mipi_dsi_set_drvdata(dsi, ctx);
+ ctx->dsi = dsi;
+
+ ctx->reset = devm_gpiod_get_optional(&dsi->dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->reset))
+ return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
+ "Couldn't get our reset GPIO\n");
+
+ ctx->vcc = devm_regulator_get_optional(&dsi->dev, "vcc");
+ if (IS_ERR(ctx->vcc))
+ return dev_err_probe(&dsi->dev, PTR_ERR(ctx->vcc),
+ "Couldn't get our VCC supply\n");
+
+ ctx->avdd = devm_regulator_get_optional(&dsi->dev, "avdd");
+ if (IS_ERR(ctx->avdd))
+ return dev_err_probe(&dsi->dev, PTR_ERR(ctx->avdd),
+ "Couldn't get our AVDD supply\n");
+
+ ctx->vdd = devm_regulator_get_optional(&dsi->dev, "vdd");
+ if (IS_ERR(ctx->vdd))
+ return dev_err_probe(&dsi->dev, PTR_ERR(ctx->vdd),
+ "Couldn't get our VDD supply\n");
+
+ ret = of_drm_get_panel_orientation(
+ dsi->dev.of_node, &ctx->orientation);
+ if (ret) {
+ dev_err(&dsi->dev, "%pOF: failed to get orientation: %d\n",
+ dsi->dev.of_node, ret);
+ return ret;
+ }
+
+ ret = drm_panel_of_backlight(&ctx->panel);
+ if (ret)
+ return ret;
+
+ ctx->panel.prepare_prev_first = true;
+
+ ret = devm_drm_panel_add(&dsi->dev, &ctx->panel);
+ if (ret)
+ return ret;
+
+ dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_HSE |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_CLOCK_NON_CONTINUOUS,
+ dsi->format = MIPI_DSI_FMT_RGB888,
+ dsi->lanes = 2;
+
+ return devm_mipi_dsi_attach(&dsi->dev, dsi);
+}
+
+static const struct of_device_id ota7290b_of_match[] = {
+ { .compatible = "waveshare,8.8-dsi-touch-a", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, ota7290b_of_match);
+
+static struct mipi_dsi_driver ota7290b_driver = {
+ .probe = ota7290b_probe,
+ .driver = {
+ .name = "focaltech-ota7290b",
+ .of_match_table = ota7290b_of_match,
+ },
+};
+module_mipi_dsi_driver(ota7290b_driver);
+
+MODULE_DESCRIPTION("Panel driver for Focaltech OTA7290B panels");
+MODULE_LICENSE("GPL");
--
2.47.3
^ permalink raw reply related
* [PATCH v3 18/21] drm/panel: add devm_drm_panel_add() helper
From: Dmitry Baryshkov @ 2026-04-13 14:05 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260413-waveshare-dsi-touch-v3-0-3aeb53022c32@oss.qualcomm.com>
Add devm_drm_panel_add(), devres-managed version of drm_panel_add().
It's not uncommon for the panel drivers to use devres functions for most
of the resources. Provide corresponding replacement for drm_panel_add().
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/drm_panel.c | 23 +++++++++++++++++++++++
include/drm/drm_panel.h | 1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index d1e6598ea3bc..a6029b699b73 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -101,6 +101,29 @@ void drm_panel_remove(struct drm_panel *panel)
}
EXPORT_SYMBOL(drm_panel_remove);
+static void drm_panel_add_release(void *data)
+{
+ drm_panel_remove(data);
+}
+
+/**
+ * devm_drm_panel_add - add a panel to the global registry using devres
+ * @panel: panel to add
+ *
+ * Add a panel to the global registry so that it can be looked
+ * up by display drivers. The panel to be added must have been
+ * allocated by devm_drm_panel_alloc(). Unlike drm_panel_add() with this
+ * function there is no need to call drm_panel_remove(), it will be called
+ * automatically.
+ */
+int devm_drm_panel_add(struct device *dev, struct drm_panel *panel)
+{
+ drm_panel_add(panel);
+
+ return devm_add_action_or_reset(dev, drm_panel_add_release, panel);
+}
+EXPORT_SYMBOL(devm_drm_panel_add);
+
/**
* drm_panel_prepare - power on a panel
* @panel: DRM panel
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 2407bfa60236..1fb9148dd095 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -329,6 +329,7 @@ void drm_panel_put(struct drm_panel *panel);
void drm_panel_add(struct drm_panel *panel);
void drm_panel_remove(struct drm_panel *panel);
+int devm_drm_panel_add(struct device *dev, struct drm_panel *panel);
void drm_panel_prepare(struct drm_panel *panel);
void drm_panel_unprepare(struct drm_panel *panel);
--
2.47.3
^ permalink raw reply related
* [PATCH v3 17/21] drm/panel: ilitek-ili9881c: support Waveshare 7.0" DSI panel
From: Dmitry Baryshkov @ 2026-04-13 14:05 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, Jie Gan
Cc: dri-devel, devicetree, linux-kernel, linux-gpio
In-Reply-To: <20260413-waveshare-dsi-touch-v3-0-3aeb53022c32@oss.qualcomm.com>
Enable support for Waveshare 7.0" DSI TOUCH-A panel. It requires
additional voltage regulator, iovcc.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 251 +++++++++++++++++++++++++-
1 file changed, 249 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 947b47841b01..0652cdb57d11 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -52,6 +52,7 @@ struct ili9881c {
const struct ili9881c_desc *desc;
struct regulator *power;
+ struct regulator *iovcc;
struct gpio_desc *reset;
enum drm_panel_orientation orientation;
@@ -1997,6 +1998,205 @@ static const struct ili9881c_instr bsd1218_a101kl68_init[] = {
ILI9881C_COMMAND_INSTR(0xd3, 0x3f),
};
+static const struct ili9881c_instr waveshare_7inch_a_init[] = {
+ ILI9881C_SWITCH_PAGE_INSTR(3),
+ ILI9881C_COMMAND_INSTR(0x01, 0x00),
+ ILI9881C_COMMAND_INSTR(0x02, 0x00),
+ ILI9881C_COMMAND_INSTR(0x03, 0x73),
+ ILI9881C_COMMAND_INSTR(0x04, 0x00),
+ ILI9881C_COMMAND_INSTR(0x05, 0x00),
+ ILI9881C_COMMAND_INSTR(0x06, 0x0a),
+ ILI9881C_COMMAND_INSTR(0x07, 0x00),
+ ILI9881C_COMMAND_INSTR(0x08, 0x00),
+ ILI9881C_COMMAND_INSTR(0x09, 0x61),
+ ILI9881C_COMMAND_INSTR(0x0a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0c, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0f, 0x61),
+ ILI9881C_COMMAND_INSTR(0x10, 0x61),
+ ILI9881C_COMMAND_INSTR(0x11, 0x00),
+ ILI9881C_COMMAND_INSTR(0x12, 0x00),
+ ILI9881C_COMMAND_INSTR(0x13, 0x00),
+ ILI9881C_COMMAND_INSTR(0x14, 0x00),
+ ILI9881C_COMMAND_INSTR(0x15, 0x00),
+ ILI9881C_COMMAND_INSTR(0x16, 0x00),
+ ILI9881C_COMMAND_INSTR(0x17, 0x00),
+ ILI9881C_COMMAND_INSTR(0x18, 0x00),
+ ILI9881C_COMMAND_INSTR(0x19, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1c, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1e, 0x40),
+ ILI9881C_COMMAND_INSTR(0x1f, 0x80),
+ ILI9881C_COMMAND_INSTR(0x20, 0x06),
+ ILI9881C_COMMAND_INSTR(0x21, 0x01),
+ ILI9881C_COMMAND_INSTR(0x22, 0x00),
+ ILI9881C_COMMAND_INSTR(0x23, 0x00),
+ ILI9881C_COMMAND_INSTR(0x24, 0x00),
+ ILI9881C_COMMAND_INSTR(0x25, 0x00),
+ ILI9881C_COMMAND_INSTR(0x26, 0x00),
+ ILI9881C_COMMAND_INSTR(0x27, 0x00),
+ ILI9881C_COMMAND_INSTR(0x28, 0x33),
+ ILI9881C_COMMAND_INSTR(0x29, 0x03),
+ ILI9881C_COMMAND_INSTR(0x2a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2c, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2f, 0x00),
+ ILI9881C_COMMAND_INSTR(0x30, 0x00),
+ ILI9881C_COMMAND_INSTR(0x31, 0x00),
+ ILI9881C_COMMAND_INSTR(0x32, 0x00),
+ ILI9881C_COMMAND_INSTR(0x33, 0x00),
+ ILI9881C_COMMAND_INSTR(0x34, 0x04),
+ ILI9881C_COMMAND_INSTR(0x35, 0x00),
+ ILI9881C_COMMAND_INSTR(0x36, 0x00),
+ ILI9881C_COMMAND_INSTR(0x37, 0x00),
+ ILI9881C_COMMAND_INSTR(0x38, 0x3c),
+ ILI9881C_COMMAND_INSTR(0x39, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3b, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3c, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3d, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3f, 0x00),
+ ILI9881C_COMMAND_INSTR(0x40, 0x00),
+ ILI9881C_COMMAND_INSTR(0x41, 0x00),
+ ILI9881C_COMMAND_INSTR(0x42, 0x00),
+ ILI9881C_COMMAND_INSTR(0x43, 0x00),
+ ILI9881C_COMMAND_INSTR(0x44, 0x00),
+ ILI9881C_COMMAND_INSTR(0x50, 0x10),
+ ILI9881C_COMMAND_INSTR(0x51, 0x32),
+ ILI9881C_COMMAND_INSTR(0x52, 0x54),
+ ILI9881C_COMMAND_INSTR(0x53, 0x76),
+ ILI9881C_COMMAND_INSTR(0x54, 0x98),
+ ILI9881C_COMMAND_INSTR(0x55, 0xba),
+ ILI9881C_COMMAND_INSTR(0x56, 0x10),
+ ILI9881C_COMMAND_INSTR(0x57, 0x32),
+ ILI9881C_COMMAND_INSTR(0x58, 0x54),
+ ILI9881C_COMMAND_INSTR(0x59, 0x76),
+ ILI9881C_COMMAND_INSTR(0x5a, 0x98),
+ ILI9881C_COMMAND_INSTR(0x5b, 0xba),
+ ILI9881C_COMMAND_INSTR(0x5c, 0xdc),
+ ILI9881C_COMMAND_INSTR(0x5d, 0xfe),
+ ILI9881C_COMMAND_INSTR(0x5e, 0x00),
+ ILI9881C_COMMAND_INSTR(0x5f, 0x0e),
+ ILI9881C_COMMAND_INSTR(0x60, 0x0f),
+ ILI9881C_COMMAND_INSTR(0x61, 0x0c),
+ ILI9881C_COMMAND_INSTR(0x62, 0x0d),
+ ILI9881C_COMMAND_INSTR(0x63, 0x06),
+ ILI9881C_COMMAND_INSTR(0x64, 0x07),
+ ILI9881C_COMMAND_INSTR(0x65, 0x02),
+ ILI9881C_COMMAND_INSTR(0x66, 0x02),
+ ILI9881C_COMMAND_INSTR(0x67, 0x02),
+ ILI9881C_COMMAND_INSTR(0x68, 0x02),
+ ILI9881C_COMMAND_INSTR(0x69, 0x01),
+ ILI9881C_COMMAND_INSTR(0x6a, 0x00),
+ ILI9881C_COMMAND_INSTR(0x6b, 0x02),
+ ILI9881C_COMMAND_INSTR(0x6c, 0x15),
+ ILI9881C_COMMAND_INSTR(0x6d, 0x14),
+ ILI9881C_COMMAND_INSTR(0x6e, 0x02),
+ ILI9881C_COMMAND_INSTR(0x6f, 0x02),
+ ILI9881C_COMMAND_INSTR(0x70, 0x02),
+ ILI9881C_COMMAND_INSTR(0x71, 0x02),
+ ILI9881C_COMMAND_INSTR(0x72, 0x02),
+ ILI9881C_COMMAND_INSTR(0x73, 0x02),
+ ILI9881C_COMMAND_INSTR(0x74, 0x02),
+ ILI9881C_COMMAND_INSTR(0x75, 0x0e),
+ ILI9881C_COMMAND_INSTR(0x76, 0x0f),
+ ILI9881C_COMMAND_INSTR(0x77, 0x0c),
+ ILI9881C_COMMAND_INSTR(0x78, 0x0d),
+ ILI9881C_COMMAND_INSTR(0x79, 0x06),
+ ILI9881C_COMMAND_INSTR(0x7a, 0x07),
+ ILI9881C_COMMAND_INSTR(0x7b, 0x02),
+ ILI9881C_COMMAND_INSTR(0x7c, 0x02),
+ ILI9881C_COMMAND_INSTR(0x7d, 0x02),
+ ILI9881C_COMMAND_INSTR(0x7e, 0x02),
+ ILI9881C_COMMAND_INSTR(0x7f, 0x01),
+ ILI9881C_COMMAND_INSTR(0x80, 0x00),
+ ILI9881C_COMMAND_INSTR(0x81, 0x02),
+ ILI9881C_COMMAND_INSTR(0x82, 0x14),
+ ILI9881C_COMMAND_INSTR(0x83, 0x15),
+ ILI9881C_COMMAND_INSTR(0x84, 0x02),
+ ILI9881C_COMMAND_INSTR(0x85, 0x02),
+ ILI9881C_COMMAND_INSTR(0x86, 0x02),
+ ILI9881C_COMMAND_INSTR(0x87, 0x02),
+ ILI9881C_COMMAND_INSTR(0x88, 0x02),
+ ILI9881C_COMMAND_INSTR(0x89, 0x02),
+ ILI9881C_COMMAND_INSTR(0x8a, 0x02),
+
+ ILI9881C_SWITCH_PAGE_INSTR(4),
+ ILI9881C_COMMAND_INSTR(0x38, 0x01),
+ ILI9881C_COMMAND_INSTR(0x39, 0x00),
+ ILI9881C_COMMAND_INSTR(0x6c, 0x15),
+ ILI9881C_COMMAND_INSTR(0x6e, 0x2a),
+ ILI9881C_COMMAND_INSTR(0x6f, 0x33),
+ ILI9881C_COMMAND_INSTR(0x3a, 0x94),
+ ILI9881C_COMMAND_INSTR(0x8d, 0x14),
+ ILI9881C_COMMAND_INSTR(0x87, 0xba),
+ ILI9881C_COMMAND_INSTR(0x26, 0x76),
+ ILI9881C_COMMAND_INSTR(0xb2, 0xd1),
+ ILI9881C_COMMAND_INSTR(0xb5, 0x06),
+ ILI9881C_COMMAND_INSTR(0x3b, 0x98),
+
+ ILI9881C_SWITCH_PAGE_INSTR(1),
+ ILI9881C_COMMAND_INSTR(0x22, 0x0a),
+ ILI9881C_COMMAND_INSTR(0x31, 0x00),
+ ILI9881C_COMMAND_INSTR(0x53, 0x71),
+ ILI9881C_COMMAND_INSTR(0x55, 0x8f),
+ ILI9881C_COMMAND_INSTR(0x40, 0x33),
+ ILI9881C_COMMAND_INSTR(0x50, 0x96),
+ ILI9881C_COMMAND_INSTR(0x51, 0x96),
+ ILI9881C_COMMAND_INSTR(0x60, 0x23),
+ ILI9881C_COMMAND_INSTR(0xa0, 0x08),
+ ILI9881C_COMMAND_INSTR(0xa1, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xa2, 0x2a),
+ ILI9881C_COMMAND_INSTR(0xa3, 0x10),
+ ILI9881C_COMMAND_INSTR(0xa4, 0x15),
+ ILI9881C_COMMAND_INSTR(0xa5, 0x28),
+ ILI9881C_COMMAND_INSTR(0xa6, 0x1c),
+ ILI9881C_COMMAND_INSTR(0xa7, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xa8, 0x7e),
+ ILI9881C_COMMAND_INSTR(0xa9, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xaa, 0x29),
+ ILI9881C_COMMAND_INSTR(0xab, 0x6b),
+ ILI9881C_COMMAND_INSTR(0xac, 0x1a),
+ ILI9881C_COMMAND_INSTR(0xad, 0x18),
+ ILI9881C_COMMAND_INSTR(0xae, 0x4b),
+ ILI9881C_COMMAND_INSTR(0xaf, 0x20),
+ ILI9881C_COMMAND_INSTR(0xb0, 0x27),
+ ILI9881C_COMMAND_INSTR(0xb1, 0x50),
+ ILI9881C_COMMAND_INSTR(0xb2, 0x64),
+ ILI9881C_COMMAND_INSTR(0xb3, 0x39),
+ ILI9881C_COMMAND_INSTR(0xc0, 0x08),
+ ILI9881C_COMMAND_INSTR(0xc1, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xc2, 0x2a),
+ ILI9881C_COMMAND_INSTR(0xc3, 0x10),
+ ILI9881C_COMMAND_INSTR(0xc4, 0x15),
+ ILI9881C_COMMAND_INSTR(0xc5, 0x28),
+ ILI9881C_COMMAND_INSTR(0xc6, 0x1c),
+ ILI9881C_COMMAND_INSTR(0xc7, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xc8, 0x7e),
+ ILI9881C_COMMAND_INSTR(0xc9, 0x1d),
+ ILI9881C_COMMAND_INSTR(0xca, 0x29),
+ ILI9881C_COMMAND_INSTR(0xcb, 0x6b),
+ ILI9881C_COMMAND_INSTR(0xcc, 0x1a),
+ ILI9881C_COMMAND_INSTR(0xcd, 0x18),
+ ILI9881C_COMMAND_INSTR(0xce, 0x4b),
+ ILI9881C_COMMAND_INSTR(0xcf, 0x20),
+ ILI9881C_COMMAND_INSTR(0xd0, 0x27),
+ ILI9881C_COMMAND_INSTR(0xd1, 0x50),
+ ILI9881C_COMMAND_INSTR(0xd2, 0x64),
+ ILI9881C_COMMAND_INSTR(0xd3, 0x39),
+
+ ILI9881C_SWITCH_PAGE_INSTR(0),
+ ILI9881C_COMMAND_INSTR(0x3a, 0x77),
+ ILI9881C_COMMAND_INSTR(0x36, 0x00),
+};
+
static inline struct ili9881c *panel_to_ili9881c(struct drm_panel *panel)
{
return container_of(panel, struct ili9881c, panel);
@@ -2035,9 +2235,19 @@ static int ili9881c_prepare(struct drm_panel *panel)
int ret;
/* Power the panel */
+ if (ctx->iovcc) {
+ ret = regulator_enable(ctx->iovcc);
+ if (ret)
+ return ret;
+ }
+
+ msleep(5);
ret = regulator_enable(ctx->power);
- if (ret)
- return ret;
+ if (ret) {
+ mctx.accum_err = ret;
+ goto disable_iovcc;
+ }
+
msleep(5);
/* And reset it */
@@ -2074,6 +2284,9 @@ static int ili9881c_prepare(struct drm_panel *panel)
disable_power:
regulator_disable(ctx->power);
+disable_iovcc:
+ if (ctx->iovcc)
+ regulator_disable(ctx->iovcc);
return mctx.accum_err;
}
@@ -2085,6 +2298,8 @@ static int ili9881c_unprepare(struct drm_panel *panel)
mipi_dsi_dcs_set_display_off_multi(&mctx);
mipi_dsi_dcs_enter_sleep_mode_multi(&mctx);
regulator_disable(ctx->power);
+ if (ctx->iovcc)
+ regulator_disable(ctx->iovcc);
gpiod_set_value_cansleep(ctx->reset, 1);
return 0;
@@ -2260,6 +2475,23 @@ static const struct drm_display_mode bsd1218_a101kl68_default_mode = {
.height_mm = 170,
};
+static const struct drm_display_mode waveshare_7inch_a_mode = {
+ .clock = 83333,
+
+ .hdisplay = 720,
+ .hsync_start = 720 + 120,
+ .hsync_end = 720 + 120 + 100,
+ .htotal = 720 + 120 + 100 + 100,
+
+ .vdisplay = 1280,
+ .vsync_start = 1280 + 10,
+ .vsync_end = 1280 + 10 + 10,
+ .vtotal = 1280 + 10 + 10 + 10,
+
+ .width_mm = 85,
+ .height_mm = 154,
+};
+
static int ili9881c_get_modes(struct drm_panel *panel,
struct drm_connector *connector)
{
@@ -2329,6 +2561,11 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
return dev_err_probe(&dsi->dev, PTR_ERR(ctx->power),
"Couldn't get our power regulator\n");
+ ctx->iovcc = devm_regulator_get_optional(&dsi->dev, "iovcc");
+ if (IS_ERR(ctx->iovcc))
+ return dev_err_probe(&dsi->dev, PTR_ERR(ctx->iovcc),
+ "Couldn't get our iovcc regulator\n");
+
ctx->reset = devm_gpiod_get_optional(&dsi->dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(ctx->reset))
return dev_err_probe(&dsi->dev, PTR_ERR(ctx->reset),
@@ -2454,6 +2691,15 @@ static const struct ili9881c_desc bsd1218_a101kl68_desc = {
.lanes = 4,
};
+static const struct ili9881c_desc waveshare_7inch_a_desc = {
+ .init = waveshare_7inch_a_init,
+ .init_length = ARRAY_SIZE(waveshare_7inch_a_init),
+ .mode = &waveshare_7inch_a_mode,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_HSE |
+ MIPI_DSI_MODE_LPM | MIPI_DSI_CLOCK_NON_CONTINUOUS,
+ .lanes = 2,
+};
+
static const struct of_device_id ili9881c_of_match[] = {
{ .compatible = "bananapi,lhr050h41", .data = &lhr050h41_desc },
{ .compatible = "bestar,bsd1218-a101kl68", .data = &bsd1218_a101kl68_desc },
@@ -2462,6 +2708,7 @@ static const struct of_device_id ili9881c_of_match[] = {
{ .compatible = "tdo,tl050hdv35", .data = &tl050hdv35_desc },
{ .compatible = "wanchanglong,w552946aaa", .data = &w552946aaa_desc },
{ .compatible = "wanchanglong,w552946aba", .data = &w552946aba_desc },
+ { .compatible = "waveshare,7.0-dsi-touch-a", .data = &waveshare_7inch_a_desc },
{ .compatible = "ampire,am8001280g", .data = &am8001280g_desc },
{ .compatible = "raspberrypi,dsi-5inch", &rpi_5inch_desc },
{ .compatible = "raspberrypi,dsi-7inch", &rpi_7inch_desc },
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox