[PATCH v4 0/4] Add Synopsys DesignWare HDMI RX Controller

[PATCH v4 0/4] Add Synopsys DesignWare HDMI RX Controller

[Shreeya Patel]

This series implements support for the Synopsys DesignWare
HDMI RX Controller, being compliant with standard HDMI 1.4b
and HDMI 2.0.

Features that are currently supported by the HDMI RX driver
have been tested on rock5b board using a HDMI to micro-HDMI cable.
It is recommended to use a good quality cable as there were
multiple issues seen during testing the driver.

Please note the below information :-
* While testing the driver on rock5b we noticed that the binary BL31
from Rockchip contains some unknown code to get the HDMI-RX PHY
access working without any errors.
With TF-A BL31, the HDMI-RX PHY also works fine but there were no
interrupts seen for rk_hdmirx-hdmi leading to some errors when
loading the driver [0]. It doesn't affect the functionality of the
driver though.
* We have tested the working of OBS studio with HDMIRX driver and
there were no issues seen.
* We also tested and verified the support for interlaced video.

[0] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/trusted-firmware-a/-/issues/1

To test the HDMI RX Controller driver, following example commands can be used :-

root@debian-rockchip-rock5b-rk3588:~# v4l2-ctl --verbose -d /dev/video0 \
--set-fmt-video=width=1920,height=1080,pixelformat='BGR3' --stream-mmap=4 \
--stream-skip=3 --stream-count=100 --stream-to=/home/hdmiin4k.raw --stream-poll

root@debian-rockchip-rock5b-rk3588:~# ffmpeg -f rawvideo -vcodec rawvideo \
-s 1920x1080 -r 60 -pix_fmt bgr24 -i /home/hdmiin4k.raw output.mkv

CEC compliance test results :-

* https://gitlab.collabora.com/-/snippets/381
* https://gitlab.collabora.com/-/snippets/380

Following is the v4l2-compliance test result :-

root@debian-rockchip-rock5b-rk3588:~# v4l2-compliance -d /dev/video0
v4l2-compliance 1.27.0-5220, 64 bits, 64-bit time_t
v4l2-compliance SHA: 8387e3673837 2024-07-01 11:09:32

Compliance test for snps_hdmirx device /dev/video0:

Driver Info:
	Driver name      : snps_hdmirx
	Card type        : snps_hdmirx
	Bus info         : platform:fdee0000.hdmi-receiver
	Driver version   : 6.10.0
	Capabilities     : 0x84201000
		Video Capture Multiplanar
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x04201000
		Video Capture Multiplanar
		Streaming
		Extended Pix Format

Required ioctls:
	test VIDIOC_QUERYCAP: OK
	test invalid ioctls: OK

Allow for multiple opens:
	test second /dev/video0 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

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
	test VIDIOC_G/S_AUDIO: OK (Not Supported)
	Inputs: 1 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
	test VIDIOC_DV_TIMINGS_CAP: OK
	test VIDIOC_G/S_EDID: OK

Control ioctls (Input 0):
	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: 3 Private Controls: 0

Format ioctls (Input 0):
	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
	test VIDIOC_G/S_PARM: OK
	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 (Input 0):
	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 (Input 0):
	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 snps_hdmirx device /dev/video0: 47, Succeeded: 47, Failed: 0, Warnings: 0

Changes in v4 :-
  - Remove DTS changes included in the device tree patch
  - Remove the hdmi rx pin info as it's already present
    in the rk3588-base-pinctrl.dtsi
  - Create a separate config option for selecting the EDID
    and enable it by default
  - Improve the comment related to DV timings and move it
    to the side of hdmirx_get_detected_timings
  - Add 100ms delay before pulling the HPD high
  - Do not return the detected timings from VIDIOC_G_DV_TIMINGS
  - Drop the bus info from hdmirx_querycap
  - If *num_planes != 0 then return 0 in hdmirx_queue_setup
  - Set queue->min_queued_buffers to 1
  - Drop q->allow_cache_hints = 0; as it's always 0 by default
  - Add a comment for q->dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
  - Drop .read = vb2_fop_read as it's not supported by driver
  - Remove redundant edid_init_data_600M
  - Make HPD low when driver is loaded
  - Add support for reading AVI Infoframe
  - Remove msg_len checks from hdmirx_cec_transmit
  - Add info about the CEC compliance test in the cover letter
  - Add arbitration lost status
  - Validate the physical address inside the EDID

Changes in v3 :-
  - Use v4l2-common helpers in the HDMIRX driver
  - Rename cma node and phandle names
  - Elaborate the comment to explain 160MiB calculation
  - Move &hdmi_receiver_cma to the rock5b dts file
  - Add information about interlaced video testing in the
    cover-letter

Changes in v2 :-
  - Fix checkpatch --strict warnings
  - Move the dt-binding include file changes in a separate patch
  - Add a description for the hardware in the dt-bindings file
  - Rename resets, vo1 grf and HPD properties
  - Add a proper description for grf and vo1-grf phandles in the
    bindings
  - Rename the HDMI RX node name to hdmi-receiver
  - Include gpio header file in binding example to fix the
    dt_binding_check failure
  - Move hdmirx_cma node to the rk3588.dtsi file
  - Add an entry to MAINTAINERS file for the HDMIRX driver

Shreeya Patel (4):
  MAINTAINERS: Add entry for Synopsys DesignWare HDMI RX Driver
  dt-bindings: media: Document bindings for HDMI RX Controller
  arm64: dts: rockchip: Add device tree support for HDMI RX Controller
  media: platform: synopsys: Add support for hdmi input driver

 .../bindings/media/snps,dw-hdmi-rx.yaml       |  132 +
 MAINTAINERS                                   |    8 +
 .../dts/rockchip/rk3588-base-pinctrl.dtsi     |   14 +
 .../arm64/boot/dts/rockchip/rk3588-extra.dtsi |   56 +
 drivers/media/platform/Kconfig                |    1 +
 drivers/media/platform/Makefile               |    1 +
 drivers/media/platform/synopsys/Kconfig       |    3 +
 drivers/media/platform/synopsys/Makefile      |    2 +
 .../media/platform/synopsys/hdmirx/Kconfig    |   27 +
 .../media/platform/synopsys/hdmirx/Makefile   |    4 +
 .../platform/synopsys/hdmirx/snps_hdmirx.c    | 2763 +++++++++++++++++
 .../platform/synopsys/hdmirx/snps_hdmirx.h    |  394 +++
 .../synopsys/hdmirx/snps_hdmirx_cec.c         |  285 ++
 .../synopsys/hdmirx/snps_hdmirx_cec.h         |   44 +
 14 files changed, 3734 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
 create mode 100644 drivers/media/platform/synopsys/Kconfig
 create mode 100644 drivers/media/platform/synopsys/Makefile
 create mode 100644 drivers/media/platform/synopsys/hdmirx/Kconfig
 create mode 100644 drivers/media/platform/synopsys/hdmirx/Makefile
 create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
 create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.h
 create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.c
 create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.h

-- 
2.39.2

[PATCH v4 1/4] MAINTAINERS: Add entry for Synopsys DesignWare HDMI RX Driver

[Shreeya Patel]

Add an entry for Synopsys DesignWare HDMI Receiver Controller
Driver.

Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
---

Changes in v4 :-
  - No change

Changes in v3 :-
  - No change

Changes in v2 :-
  - Add a patch for MAINTAINERS file changes

 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c87b471941c..0f0e1d58abff 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -22138,6 +22138,14 @@ F:	drivers/net/pcs/pcs-xpcs.c
 F:	drivers/net/pcs/pcs-xpcs.h
 F:	include/linux/pcs/pcs-xpcs.h
 
+SYNOPSYS DESIGNWARE HDMI RX CONTROLLER DRIVER
+M:	Shreeya Patel <shreeya.patel@collabora.com
+L:	linux-media@vger.kernel.org
+L:	kernel@collabora.com
+S:	Maintained
+F:	Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
+F:	drivers/media/platform/synopsys/hdmirx/*
+
 SYNOPSYS DESIGNWARE I2C DRIVER
 M:	Jarkko Nikula <jarkko.nikula@linux.intel.com>
 R:	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-- 
2.39.2

Re: [PATCH v4 1/4] MAINTAINERS: Add entry for Synopsys DesignWare HDMI RX Driver

[Christopher Obbard]

Hi Shreeya,

On Fri, 2024-07-19 at 18:10 +0530, Shreeya Patel wrote:
> Add an entry for Synopsys DesignWare HDMI Receiver Controller
> Driver.
> 
> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> ---
> 
> Changes in v4 :-
>   - No change
> 
> Changes in v3 :-
>   - No change
> 
> Changes in v2 :-
>   - Add a patch for MAINTAINERS file changes
> 
>  MAINTAINERS | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1c87b471941c..0f0e1d58abff 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -22138,6 +22138,14 @@ F:	drivers/net/pcs/pcs-xpcs.c
>  F:	drivers/net/pcs/pcs-xpcs.h
>  F:	include/linux/pcs/pcs-xpcs.h
>  
> +SYNOPSYS DESIGNWARE HDMI RX CONTROLLER DRIVER

Perhaps a more descriptive name could be "SYNOPSYS DESIGNWARE HDMI RECEIVER
DRIVER" to better match the IP name:
https://www.synopsys.com/dw/ipdir.php?ds=dwc_hdmi_20_csds_rx


> +M:	Shreeya Patel <shreeya.patel@collabora.com
Should this not be:
 Shreeya Patel <shreeya.patel@collabora.com>

You seem to be missing the final > at the end of the line ?


With the above fixed:
Reviewed-by: Christopher Obbard <chris.obbard@collabora.com>

> +L:	linux-media@vger.kernel.org
> +L:	kernel@collabora.com
> +S:	Maintained
> +F:	Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> +F:	drivers/media/platform/synopsys/hdmirx/*
> +
>  SYNOPSYS DESIGNWARE I2C DRIVER
>  M:	Jarkko Nikula <jarkko.nikula@linux.intel.com>
>  R:	Andy Shevchenko <andriy.shevchenko@linux.intel.com>

[PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Shreeya Patel]

Document bindings for the Synopsys DesignWare HDMI RX Controller.

Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
---

Changes in v4 :-
  - No change

Changes in v3 :-
  - Rename hdmirx_cma to hdmi_receiver_cma
  - Add a Reviewed-by tag

Changes in v2 :-
  - Add a description for the hardware
  - Rename resets, vo1 grf and HPD properties
  - Add a proper description for grf and vo1-grf phandles
  - Rename the HDMI Input node name to hdmi-receiver
  - Improve the subject line
  - Include gpio header file in example to fix dt_binding_check failure

 .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
 1 file changed, 132 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml

diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
new file mode 100644
index 000000000000..96ae1e2d2816
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
@@ -0,0 +1,132 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Device Tree bindings for Synopsys DesignWare HDMI RX Controller
+
+---
+$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare HDMI RX Controller
+
+maintainers:
+  - Shreeya Patel <shreeya.patel@collabora.com>
+
+description:
+  Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs
+  allowing devices to receive and decode high-resolution video streams
+  from external sources like media players, cameras, laptops, etc.
+
+properties:
+  compatible:
+    items:
+      - const: rockchip,rk3588-hdmirx-ctrler
+      - const: snps,dw-hdmi-rx
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 3
+
+  interrupt-names:
+    items:
+      - const: cec
+      - const: hdmi
+      - const: dma
+
+  clocks:
+    maxItems: 7
+
+  clock-names:
+    items:
+      - const: aclk
+      - const: audio
+      - const: cr_para
+      - const: pclk
+      - const: ref
+      - const: hclk_s_hdmirx
+      - const: hclk_vo1
+
+  power-domains:
+    maxItems: 1
+
+  resets:
+    maxItems: 4
+
+  reset-names:
+    items:
+      - const: axi
+      - const: apb
+      - const: ref
+      - const: biu
+
+  memory-region:
+    maxItems: 1
+
+  hpd-gpios:
+    description: GPIO specifier for HPD.
+    maxItems: 1
+
+  rockchip,grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      The phandle of the syscon node for the general register file
+      containing HDMIRX PHY status bits.
+
+  rockchip,vo1-grf:
+    $ref: /schemas/types.yaml#/definitions/phandle
+    description:
+      The phandle of the syscon node for the Video Output GRF register
+      to enable EDID transfer through SDAIN and SCLIN.
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - interrupt-names
+  - clocks
+  - clock-names
+  - power-domains
+  - resets
+  - pinctrl-0
+  - hpd-gpios
+
+additionalProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/clock/rockchip,rk3588-cru.h>
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/interrupt-controller/arm-gic.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    #include <dt-bindings/power/rk3588-power.h>
+    #include <dt-bindings/reset/rockchip,rk3588-cru.h>
+    hdmi_receiver: hdmi-receiver@fdee0000 {
+      compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
+      reg = <0xfdee0000 0x6000>;
+      interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
+                   <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
+                   <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
+      interrupt-names = "cec", "hdmi", "dma";
+      clocks = <&cru ACLK_HDMIRX>,
+               <&cru CLK_HDMIRX_AUD>,
+               <&cru CLK_CR_PARA>,
+               <&cru PCLK_HDMIRX>,
+               <&cru CLK_HDMIRX_REF>,
+               <&cru PCLK_S_HDMIRX>,
+               <&cru HCLK_VO1>;
+      clock-names = "aclk",
+                    "audio",
+                    "cr_para",
+                    "pclk",
+                    "ref",
+                    "hclk_s_hdmirx",
+                    "hclk_vo1";
+      power-domains = <&power RK3588_PD_VO1>;
+      resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
+               <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
+      reset-names = "axi", "apb", "ref", "biu";
+      memory-region = <&hdmi_receiver_cma>;
+      pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
+      pinctrl-names = "default";
+      hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
+    };
-- 
2.39.2

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Rob Herring (Arm)]

On Fri, 19 Jul 2024 18:10:30 +0530, Shreeya Patel wrote:
> Document bindings for the Synopsys DesignWare HDMI RX Controller.
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> ---
> 
> Changes in v4 :-
>   - No change
> 
> Changes in v3 :-
>   - Rename hdmirx_cma to hdmi_receiver_cma
>   - Add a Reviewed-by tag
> 
> Changes in v2 :-
>   - Add a description for the hardware
>   - Rename resets, vo1 grf and HPD properties
>   - Add a proper description for grf and vo1-grf phandles
>   - Rename the HDMI Input node name to hdmi-receiver
>   - Improve the subject line
>   - Include gpio header file in example to fix dt_binding_check failure
> 
>  .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
>  1 file changed, 132 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Error: Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.example.dts:53.38-39 syntax error
FATAL ERROR: Unable to parse input tree
make[2]: *** [scripts/Makefile.lib:427: Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.example.dtb] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2
make: *** [Makefile:240: __sub-make] Error 2

doc reference errors (make refcheckdocs):

See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240719124032.26852-3-shreeya.patel@collabora.com

The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Shreeya Patel]

On Saturday, July 20, 2024 03:40 IST, "Rob Herring (Arm)" <robh@kernel.org> wrote:

> 
> On Fri, 19 Jul 2024 18:10:30 +0530, Shreeya Patel wrote:
> > Document bindings for the Synopsys DesignWare HDMI RX Controller.
> > 
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> > ---
> > 
> > Changes in v4 :-
> >   - No change
> > 
> > Changes in v3 :-
> >   - Rename hdmirx_cma to hdmi_receiver_cma
> >   - Add a Reviewed-by tag
> > 
> > Changes in v2 :-
> >   - Add a description for the hardware
> >   - Rename resets, vo1 grf and HPD properties
> >   - Add a proper description for grf and vo1-grf phandles
> >   - Rename the HDMI Input node name to hdmi-receiver
> >   - Improve the subject line
> >   - Include gpio header file in example to fix dt_binding_check failure
> > 
> >  .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
> >  1 file changed, 132 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> > 
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> Error: Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.example.dts:53.38-39 syntax error
> FATAL ERROR: Unable to parse input tree
> make[2]: *** [scripts/Makefile.lib:427: Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.example.dtb] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [/builds/robherring/dt-review-ci/linux/Makefile:1430: dt_binding_check] Error 2
> make: *** [Makefile:240: __sub-make] Error 2
> 
> doc reference errors (make refcheckdocs):
> 
> See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240719124032.26852-3-shreeya.patel@collabora.com
> 
> The base for the series is generally the latest rc1. A different dependency
> should be noted in *this* patch.
> 

My HDMI RX patches are based on the linux-next/master branch.
Since the bot tested the patches on top of rc1, it resulted in some errors
due to missing reset ID patches.

I think the above statement means I should explicitly mention in this
patch that it is based on linux-next/master (something to keep in mind
for future :)


> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
> 
> _______________________________________________
> Kernel mailing list -- kernel@mailman.collabora.com
> To unsubscribe send an email to kernel-leave@mailman.collabora.com
> This list is managed by https://mailman.collabora.com

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Johan Jonker]

On 7/19/24 14:40, Shreeya Patel wrote:
> Document bindings for the Synopsys DesignWare HDMI RX Controller.
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> ---
> 
> Changes in v4 :-
>   - No change
> 
> Changes in v3 :-
>   - Rename hdmirx_cma to hdmi_receiver_cma
>   - Add a Reviewed-by tag
> 
> Changes in v2 :-
>   - Add a description for the hardware
>   - Rename resets, vo1 grf and HPD properties
>   - Add a proper description for grf and vo1-grf phandles
>   - Rename the HDMI Input node name to hdmi-receiver
>   - Improve the subject line
>   - Include gpio header file in example to fix dt_binding_check failure
> 
>  .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
>  1 file changed, 132 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> 
> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> new file mode 100644
> index 000000000000..96ae1e2d2816
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> @@ -0,0 +1,132 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Device Tree bindings for Synopsys DesignWare HDMI RX Controller
> +
> +---
> +$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Synopsys DesignWare HDMI RX Controller
> +
> +maintainers:
> +  - Shreeya Patel <shreeya.patel@collabora.com>
> +
> +description:
> +  Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs
> +  allowing devices to receive and decode high-resolution video streams
> +  from external sources like media players, cameras, laptops, etc.
> +
> +properties:
> +  compatible:
> +    items:
> +      - const: rockchip,rk3588-hdmirx-ctrler

> +      - const: snps,dw-hdmi-rx

1: Compatible strings must be SoC orientated.
2: In Linux there's no priority in which string will probed first. 
What's the point of having a fallback string when there's no common code, but instead only the first string is used?

+static const struct of_device_id hdmirx_id[] = {
+	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
+	{ },
+};

> +
> +  reg:
> +    maxItems: 1
> +
> +  interrupts:
> +    maxItems: 3
> +
> +  interrupt-names:
> +    items:
> +      - const: cec
> +      - const: hdmi
> +      - const: dma
> +
> +  clocks:
> +    maxItems: 7
> +
> +  clock-names:
> +    items:
> +      - const: aclk
> +      - const: audio
> +      - const: cr_para
> +      - const: pclk
> +      - const: ref
> +      - const: hclk_s_hdmirx
> +      - const: hclk_vo1
> +
> +  power-domains:
> +    maxItems: 1
> +
> +  resets:
> +    maxItems: 4
> +
> +  reset-names:
> +    items:
> +      - const: axi
> +      - const: apb
> +      - const: ref
> +      - const: biu
> +
> +  memory-region:
> +    maxItems: 1
> +
> +  hpd-gpios:
> +    description: GPIO specifier for HPD.
> +    maxItems: 1
> +
> +  rockchip,grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      The phandle of the syscon node for the general register file
> +      containing HDMIRX PHY status bits.
> +
> +  rockchip,vo1-grf:
> +    $ref: /schemas/types.yaml#/definitions/phandle
> +    description:
> +      The phandle of the syscon node for the Video Output GRF register
> +      to enable EDID transfer through SDAIN and SCLIN.
> +
> +required:
> +  - compatible
> +  - reg
> +  - interrupts
> +  - interrupt-names
> +  - clocks
> +  - clock-names
> +  - power-domains
> +  - resets
> +  - pinctrl-0
> +  - hpd-gpios
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> +    #include <dt-bindings/gpio/gpio.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/power/rk3588-power.h>
> +    #include <dt-bindings/reset/rockchip,rk3588-cru.h>
> +    hdmi_receiver: hdmi-receiver@fdee0000 {
> +      compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
> +      reg = <0xfdee0000 0x6000>;
> +      interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
> +                   <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
> +                   <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
> +      interrupt-names = "cec", "hdmi", "dma";
> +      clocks = <&cru ACLK_HDMIRX>,
> +               <&cru CLK_HDMIRX_AUD>,
> +               <&cru CLK_CR_PARA>,
> +               <&cru PCLK_HDMIRX>,
> +               <&cru CLK_HDMIRX_REF>,
> +               <&cru PCLK_S_HDMIRX>,
> +               <&cru HCLK_VO1>;
> +      clock-names = "aclk",
> +                    "audio",
> +                    "cr_para",
> +                    "pclk",
> +                    "ref",
> +                    "hclk_s_hdmirx",
> +                    "hclk_vo1";
> +      power-domains = <&power RK3588_PD_VO1>;
> +      resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
> +               <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
> +      reset-names = "axi", "apb", "ref", "biu";
> +      memory-region = <&hdmi_receiver_cma>;
> +      pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
> +      pinctrl-names = "default";
> +      hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
> +    };

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Shreeya Patel]

On Saturday, July 20, 2024 16:14 IST, Johan Jonker <jbx6244@yandex.com> wrote:

Hi Johan,

> 
> 
> On 7/19/24 14:40, Shreeya Patel wrote:
> > Document bindings for the Synopsys DesignWare HDMI RX Controller.
> > 
> > Reviewed-by: Rob Herring <robh@kernel.org>
> > Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> > ---
> > 
> > Changes in v4 :-
> >   - No change
> > 
> > Changes in v3 :-
> >   - Rename hdmirx_cma to hdmi_receiver_cma
> >   - Add a Reviewed-by tag
> > 
> > Changes in v2 :-
> >   - Add a description for the hardware
> >   - Rename resets, vo1 grf and HPD properties
> >   - Add a proper description for grf and vo1-grf phandles
> >   - Rename the HDMI Input node name to hdmi-receiver
> >   - Improve the subject line
> >   - Include gpio header file in example to fix dt_binding_check failure
> > 
> >  .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
> >  1 file changed, 132 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> > new file mode 100644
> > index 000000000000..96ae1e2d2816
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> > @@ -0,0 +1,132 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +# Device Tree bindings for Synopsys DesignWare HDMI RX Controller
> > +
> > +---
> > +$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Synopsys DesignWare HDMI RX Controller
> > +
> > +maintainers:
> > +  - Shreeya Patel <shreeya.patel@collabora.com>
> > +
> > +description:
> > +  Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs
> > +  allowing devices to receive and decode high-resolution video streams
> > +  from external sources like media players, cameras, laptops, etc.
> > +
> > +properties:
> > +  compatible:
> > +    items:
> > +      - const: rockchip,rk3588-hdmirx-ctrler
> 
> > +      - const: snps,dw-hdmi-rx
> 
> 1: Compatible strings must be SoC orientated.
> 2: In Linux there's no priority in which string will probed first. 
> What's the point of having a fallback string when there's no common code, but instead only the first string is used?
> 
> +static const struct of_device_id hdmirx_id[] = {
> +	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> +	{ },
> +};
> 

We believe the HDMIRX driver can be used for the Synopsys IP on other SoCs
in the future, which is why we have added snps,dw-hdmi-rx as the fallback compatible.
Currently, we have tested the driver only on the RK3588 Rock5B, so we are using the
rockchip,rk3588-hdmirx-ctrler compatible in the driver instead of the fallback one.


Thanks,
Shreeya Patel

> > +
> > +  reg:
> > +    maxItems: 1
> > +
> > +  interrupts:
> > +    maxItems: 3
> > +
> > +  interrupt-names:
> > +    items:
> > +      - const: cec
> > +      - const: hdmi
> > +      - const: dma
> > +
> > +  clocks:
> > +    maxItems: 7
> > +
> > +  clock-names:
> > +    items:
> > +      - const: aclk
> > +      - const: audio
> > +      - const: cr_para
> > +      - const: pclk
> > +      - const: ref
> > +      - const: hclk_s_hdmirx
> > +      - const: hclk_vo1
> > +
> > +  power-domains:
> > +    maxItems: 1
> > +
> > +  resets:
> > +    maxItems: 4
> > +
> > +  reset-names:
> > +    items:
> > +      - const: axi
> > +      - const: apb
> > +      - const: ref
> > +      - const: biu
> > +
> > +  memory-region:
> > +    maxItems: 1
> > +
> > +  hpd-gpios:
> > +    description: GPIO specifier for HPD.
> > +    maxItems: 1
> > +
> > +  rockchip,grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description:
> > +      The phandle of the syscon node for the general register file
> > +      containing HDMIRX PHY status bits.
> > +
> > +  rockchip,vo1-grf:
> > +    $ref: /schemas/types.yaml#/definitions/phandle
> > +    description:
> > +      The phandle of the syscon node for the Video Output GRF register
> > +      to enable EDID transfer through SDAIN and SCLIN.
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +  - interrupt-names
> > +  - clocks
> > +  - clock-names
> > +  - power-domains
> > +  - resets
> > +  - pinctrl-0
> > +  - hpd-gpios
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> > +    #include <dt-bindings/gpio/gpio.h>
> > +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> > +    #include <dt-bindings/interrupt-controller/irq.h>
> > +    #include <dt-bindings/power/rk3588-power.h>
> > +    #include <dt-bindings/reset/rockchip,rk3588-cru.h>
> > +    hdmi_receiver: hdmi-receiver@fdee0000 {
> > +      compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
> > +      reg = <0xfdee0000 0x6000>;
> > +      interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
> > +                   <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
> > +                   <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
> > +      interrupt-names = "cec", "hdmi", "dma";
> > +      clocks = <&cru ACLK_HDMIRX>,
> > +               <&cru CLK_HDMIRX_AUD>,
> > +               <&cru CLK_CR_PARA>,
> > +               <&cru PCLK_HDMIRX>,
> > +               <&cru CLK_HDMIRX_REF>,
> > +               <&cru PCLK_S_HDMIRX>,
> > +               <&cru HCLK_VO1>;
> > +      clock-names = "aclk",
> > +                    "audio",
> > +                    "cr_para",
> > +                    "pclk",
> > +                    "ref",
> > +                    "hclk_s_hdmirx",
> > +                    "hclk_vo1";
> > +      power-domains = <&power RK3588_PD_VO1>;
> > +      resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
> > +               <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
> > +      reset-names = "axi", "apb", "ref", "biu";
> > +      memory-region = <&hdmi_receiver_cma>;
> > +      pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
> > +      pinctrl-names = "default";
> > +      hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
> > +    };

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Johan Jonker]

On 7/22/24 15:53, Shreeya Patel wrote:
> On Saturday, July 20, 2024 16:14 IST, Johan Jonker <jbx6244@yandex.com> wrote:
> 
> Hi Johan,
> 
>>
>>
>> On 7/19/24 14:40, Shreeya Patel wrote:
>>> Document bindings for the Synopsys DesignWare HDMI RX Controller.
>>>

>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>

Remove to trigger a new review.

>>> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
>>> ---
>>>
>>> Changes in v4 :-
>>>   - No change
>>>
>>> Changes in v3 :-
>>>   - Rename hdmirx_cma to hdmi_receiver_cma
>>>   - Add a Reviewed-by tag
>>>
>>> Changes in v2 :-
>>>   - Add a description for the hardware
>>>   - Rename resets, vo1 grf and HPD properties
>>>   - Add a proper description for grf and vo1-grf phandles
>>>   - Rename the HDMI Input node name to hdmi-receiver
>>>   - Improve the subject line
>>>   - Include gpio header file in example to fix dt_binding_check failure
>>>
>>>  .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
>>>  1 file changed, 132 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>>> new file mode 100644
>>> index 000000000000..96ae1e2d2816
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>>> @@ -0,0 +1,132 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +# Device Tree bindings for Synopsys DesignWare HDMI RX Controller
>>> +
>>> +---
>>> +$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Synopsys DesignWare HDMI RX Controller
>>> +
>>> +maintainers:
>>> +  - Shreeya Patel <shreeya.patel@collabora.com>
>>> +
>>> +description:
>>> +  Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs
>>> +  allowing devices to receive and decode high-resolution video streams
>>> +  from external sources like media players, cameras, laptops, etc.
>>> +
>>> +properties:
>>> +  compatible:
>>> +    items:
>>> +      - const: rockchip,rk3588-hdmirx-ctrler
>>

>>> +      - const: snps,dw-hdmi-rx

remove

>>
>> 1: Compatible strings must be SoC orientated.
>> 2: In Linux there's no priority in which string will probed first. 
>> What's the point of having a fallback string when there's no common code, but instead only the first string is used?
>>
>> +static const struct of_device_id hdmirx_id[] = {
>> +	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
>> +	{ },
>> +};
>>
> 

> We believe the HDMIRX driver can be used for the Synopsys IP on other SoCs
> in the future, which is why we have added snps,dw-hdmi-rx as the fallback compatible.
> Currently, we have tested the driver only on the RK3588 Rock5B, so we are using the
> rockchip,rk3588-hdmirx-ctrler compatible in the driver instead of the fallback one.

The rule that compatible strings (for internal SoC components) must be SoC orientated also applies to the fallback string. "snps,xxxx" does not refer to an independent SoC.
Don't invent strings for devices that we don't know yet if it might or might not be compatible in the future.

Johan

> 
> 
> Thanks,
> Shreeya Patel
> 
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  interrupts:
>>> +    maxItems: 3
>>> +
>>> +  interrupt-names:
>>> +    items:
>>> +      - const: cec
>>> +      - const: hdmi
>>> +      - const: dma
>>> +
>>> +  clocks:
>>> +    maxItems: 7
>>> +
>>> +  clock-names:
>>> +    items:
>>> +      - const: aclk
>>> +      - const: audio
>>> +      - const: cr_para
>>> +      - const: pclk
>>> +      - const: ref
>>> +      - const: hclk_s_hdmirx
>>> +      - const: hclk_vo1
>>> +
>>> +  power-domains:
>>> +    maxItems: 1
>>> +
>>> +  resets:
>>> +    maxItems: 4
>>> +
>>> +  reset-names:
>>> +    items:
>>> +      - const: axi
>>> +      - const: apb
>>> +      - const: ref
>>> +      - const: biu
>>> +
>>> +  memory-region:
>>> +    maxItems: 1
>>> +
>>> +  hpd-gpios:
>>> +    description: GPIO specifier for HPD.
>>> +    maxItems: 1
>>> +
>>> +  rockchip,grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description:
>>> +      The phandle of the syscon node for the general register file
>>> +      containing HDMIRX PHY status bits.
>>> +
>>> +  rockchip,vo1-grf:
>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>> +    description:
>>> +      The phandle of the syscon node for the Video Output GRF register
>>> +      to enable EDID transfer through SDAIN and SCLIN.
>>> +
>>> +required:
>>> +  - compatible
>>> +  - reg
>>> +  - interrupts
>>> +  - interrupt-names
>>> +  - clocks
>>> +  - clock-names
>>> +  - power-domains
>>> +  - resets
>>> +  - pinctrl-0
>>> +  - hpd-gpios
>>> +
>>> +additionalProperties: false
>>> +
>>> +examples:
>>> +  - |
>>> +    #include <dt-bindings/clock/rockchip,rk3588-cru.h>
>>> +    #include <dt-bindings/gpio/gpio.h>
>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>> +    #include <dt-bindings/power/rk3588-power.h>
>>> +    #include <dt-bindings/reset/rockchip,rk3588-cru.h>
>>> +    hdmi_receiver: hdmi-receiver@fdee0000 {

>>> +      compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";

      compatible = "rockchip,rk3588-hdmirx-ctrler";

>>> +      reg = <0xfdee0000 0x6000>;
>>> +      interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
>>> +                   <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
>>> +                   <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
>>> +      interrupt-names = "cec", "hdmi", "dma";
>>> +      clocks = <&cru ACLK_HDMIRX>,
>>> +               <&cru CLK_HDMIRX_AUD>,
>>> +               <&cru CLK_CR_PARA>,
>>> +               <&cru PCLK_HDMIRX>,
>>> +               <&cru CLK_HDMIRX_REF>,
>>> +               <&cru PCLK_S_HDMIRX>,
>>> +               <&cru HCLK_VO1>;
>>> +      clock-names = "aclk",
>>> +                    "audio",
>>> +                    "cr_para",
>>> +                    "pclk",
>>> +                    "ref",
>>> +                    "hclk_s_hdmirx",
>>> +                    "hclk_vo1";
>>> +      power-domains = <&power RK3588_PD_VO1>;
>>> +      resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
>>> +               <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
>>> +      reset-names = "axi", "apb", "ref", "biu";
>>> +      memory-region = <&hdmi_receiver_cma>;
>>> +      pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
>>> +      pinctrl-names = "default";
>>> +      hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
>>> +    };
> 

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 10090 bytes --]

Hi,

On Tue, Jul 23, 2024 at 01:16:00PM GMT, Johan Jonker wrote:
> On 7/22/24 15:53, Shreeya Patel wrote:
> > On Saturday, July 20, 2024 16:14 IST, Johan Jonker <jbx6244@yandex.com> wrote:
> >> On 7/19/24 14:40, Shreeya Patel wrote:
> >>> Document bindings for the Synopsys DesignWare HDMI RX Controller.
> >>>
> 
> >>> Reviewed-by: Rob Herring <robh@kernel.org>
> >>> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> 
> Remove to trigger a new review.

Rob and Dmitry both already reviewed the version with the fallback
compatible. I don't think the rename of hdmirx_cma to hdmi_receiver_cma
warrant a new review. Also FWIW:

Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>

> >>> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> >>> ---
> >>>
> >>> Changes in v4 :-
> >>>   - No change
> >>>
> >>> Changes in v3 :-
> >>>   - Rename hdmirx_cma to hdmi_receiver_cma
> >>>   - Add a Reviewed-by tag
> >>>
> >>> Changes in v2 :-
> >>>   - Add a description for the hardware
> >>>   - Rename resets, vo1 grf and HPD properties
> >>>   - Add a proper description for grf and vo1-grf phandles
> >>>   - Rename the HDMI Input node name to hdmi-receiver
> >>>   - Improve the subject line
> >>>   - Include gpio header file in example to fix dt_binding_check failure
> >>>
> >>>  .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
> >>>  1 file changed, 132 insertions(+)
> >>>  create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> >>> new file mode 100644
> >>> index 000000000000..96ae1e2d2816
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> >>> @@ -0,0 +1,132 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>> +# Device Tree bindings for Synopsys DesignWare HDMI RX Controller
> >>> +
> >>> +---
> >>> +$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml#
> >>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>> +
> >>> +title: Synopsys DesignWare HDMI RX Controller
> >>> +
> >>> +maintainers:
> >>> +  - Shreeya Patel <shreeya.patel@collabora.com>
> >>> +
> >>> +description:
> >>> +  Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs
> >>> +  allowing devices to receive and decode high-resolution video streams
> >>> +  from external sources like media players, cameras, laptops, etc.
> >>> +
> >>> +properties:
> >>> +  compatible:
> >>> +    items:
> >>> +      - const: rockchip,rk3588-hdmirx-ctrler
> >>
> 
> >>> +      - const: snps,dw-hdmi-rx
> 
> remove
> 
> >>
> >> 1: Compatible strings must be SoC orientated.
> >> 2: In Linux there's no priority in which string will probed first. 
> >> What's the point of having a fallback string when there's no common code, but instead only the first string is used?
> >>
> >> +static const struct of_device_id hdmirx_id[] = {
> >> +	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> >> +	{ },
> >> +};
> >>
> > 
> 
> > We believe the HDMIRX driver can be used for the Synopsys IP on other SoCs
> > in the future, which is why we have added snps,dw-hdmi-rx as the fallback compatible.
> > Currently, we have tested the driver only on the RK3588 Rock5B, so we are using the
> > rockchip,rk3588-hdmirx-ctrler compatible in the driver instead of the fallback one.
> 
> The rule that compatible strings (for internal SoC components)
> must be SoC orientated also applies to the fallback string.
> "snps,xxxx" does not refer to an independent SoC. 

Where did you learn that? Having non-SoC specific generic fallback
compatibles is pretty much standard throughout the kernel. See for
example these RK3588 DesignWare compatibles:

Synopsys Serial Controller:
    Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
    compatible = "rockchip,rk3588-uart", "snps,dw-apb-uart";

Synopsys USB3 Controller:
    Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
    compatible = "rockchip,rk3588-dwc3", "snps,dwc3";

Synopsys Ethernet Controller:
    Documentation/devicetree/bindings/net/snps,dwmac.yaml
    compatible = "rockchip,rk3588-gmac", "snps,dwmac-4.20a";

Synsopsys SATA Controller:
    Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
    compatible = "rockchip,rk3588-dwc-ahci", "snps,dwc-ahci"

It's also not specific to Synopsys (but RK3588 has a lot of Synopsys
design incl. the HDMI-RX IP currently worked on by Shreeya). Here
are some other examples:

ARM Mali GPU:
    Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
    compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf";

Generic EHCI:
    Documentation/devicetree/bindings/usb/generic-ehci.yaml
    compatible = "rockchip,rk3588-ehci", "generic-ehci";

As you can see almost everything in RK3588 has a non SoC specific
fallback :) It's also not a Rockchip/RK3588 specific thing, but
I think you should be able to find enough references yourself by
looking into the kernel's DTS files.

> Don't invent strings for devices that we don't know yet if it
> might or might not be compatible in the future.

Right now it's a sensible assumption, that an operating system driver
for this hardware (i.e. not necessarily the one submitted by Shreeya
right now) can handle the Synopsys HDMI receiver hardware from different
SoCs just like it is the case for other Synopsys IP.

Whatever is being done now is set in stone, since DT is considered
ABI. So without the fallback compatible being available in DT from
the beginning we need to carry the RK3588 specific compatible in the
kernel driver forever. OTOH if we add the generic one now, the kernel
can switch to use the generic one at any point in time and ignore the
RK3588 specific one.

Greetings,

-- Sebastian

> Johan
> 
> > 
> > 
> > Thanks,
> > Shreeya Patel
> > 
> >>> +
> >>> +  reg:
> >>> +    maxItems: 1
> >>> +
> >>> +  interrupts:
> >>> +    maxItems: 3
> >>> +
> >>> +  interrupt-names:
> >>> +    items:
> >>> +      - const: cec
> >>> +      - const: hdmi
> >>> +      - const: dma
> >>> +
> >>> +  clocks:
> >>> +    maxItems: 7
> >>> +
> >>> +  clock-names:
> >>> +    items:
> >>> +      - const: aclk
> >>> +      - const: audio
> >>> +      - const: cr_para
> >>> +      - const: pclk
> >>> +      - const: ref
> >>> +      - const: hclk_s_hdmirx
> >>> +      - const: hclk_vo1
> >>> +
> >>> +  power-domains:
> >>> +    maxItems: 1
> >>> +
> >>> +  resets:
> >>> +    maxItems: 4
> >>> +
> >>> +  reset-names:
> >>> +    items:
> >>> +      - const: axi
> >>> +      - const: apb
> >>> +      - const: ref
> >>> +      - const: biu
> >>> +
> >>> +  memory-region:
> >>> +    maxItems: 1
> >>> +
> >>> +  hpd-gpios:
> >>> +    description: GPIO specifier for HPD.
> >>> +    maxItems: 1
> >>> +
> >>> +  rockchip,grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description:
> >>> +      The phandle of the syscon node for the general register file
> >>> +      containing HDMIRX PHY status bits.
> >>> +
> >>> +  rockchip,vo1-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description:
> >>> +      The phandle of the syscon node for the Video Output GRF register
> >>> +      to enable EDID transfer through SDAIN and SCLIN.
> >>> +
> >>> +required:
> >>> +  - compatible
> >>> +  - reg
> >>> +  - interrupts
> >>> +  - interrupt-names
> >>> +  - clocks
> >>> +  - clock-names
> >>> +  - power-domains
> >>> +  - resets
> >>> +  - pinctrl-0
> >>> +  - hpd-gpios
> >>> +
> >>> +additionalProperties: false
> >>> +
> >>> +examples:
> >>> +  - |
> >>> +    #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> >>> +    #include <dt-bindings/gpio/gpio.h>
> >>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> >>> +    #include <dt-bindings/interrupt-controller/irq.h>
> >>> +    #include <dt-bindings/power/rk3588-power.h>
> >>> +    #include <dt-bindings/reset/rockchip,rk3588-cru.h>
> >>> +    hdmi_receiver: hdmi-receiver@fdee0000 {
> 
> >>> +      compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
> 
>       compatible = "rockchip,rk3588-hdmirx-ctrler";
> 
> >>> +      reg = <0xfdee0000 0x6000>;
> >>> +      interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
> >>> +                   <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
> >>> +                   <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
> >>> +      interrupt-names = "cec", "hdmi", "dma";
> >>> +      clocks = <&cru ACLK_HDMIRX>,
> >>> +               <&cru CLK_HDMIRX_AUD>,
> >>> +               <&cru CLK_CR_PARA>,
> >>> +               <&cru PCLK_HDMIRX>,
> >>> +               <&cru CLK_HDMIRX_REF>,
> >>> +               <&cru PCLK_S_HDMIRX>,
> >>> +               <&cru HCLK_VO1>;
> >>> +      clock-names = "aclk",
> >>> +                    "audio",
> >>> +                    "cr_para",
> >>> +                    "pclk",
> >>> +                    "ref",
> >>> +                    "hclk_s_hdmirx",
> >>> +                    "hclk_vo1";
> >>> +      power-domains = <&power RK3588_PD_VO1>;
> >>> +      resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
> >>> +               <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
> >>> +      reset-names = "axi", "apb", "ref", "biu";
> >>> +      memory-region = <&hdmi_receiver_cma>;
> >>> +      pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
> >>> +      pinctrl-names = "default";
> >>> +      hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
> >>> +    };
> > 
> _______________________________________________
> Kernel mailing list -- kernel@mailman.collabora.com
> To unsubscribe send an email to kernel-leave@mailman.collabora.com
> This list is managed by https://mailman.collabora.com

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Johan Jonker]

On 7/23/24 19:28, Sebastian Reichel wrote:
> Hi,
>
> On Tue, Jul 23, 2024 at 01:16:00PM GMT, Johan Jonker wrote:
>> On 7/22/24 15:53, Shreeya Patel wrote:
>>> On Saturday, July 20, 2024 16:14 IST, Johan Jonker <jbx6244@yandex.com> wrote:
>>>> On 7/19/24 14:40, Shreeya Patel wrote:
>>>>> Document bindings for the Synopsys DesignWare HDMI RX Controller.
>>>>>
>>
>>>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>>>> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>
>> Remove to trigger a new review.
>
> Rob and Dmitry both already reviewed the version with the fallback
> compatible. I don't think the rename of hdmirx_cma to hdmi_receiver_cma
> warrant a new review. Also FWIW:
>

> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Please have a look at the comments below before you tag.

>
>>>>> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
>>>>> ---
>>>>>
>>>>> Changes in v4 :-
>>>>>   - No change
>>>>>
>>>>> Changes in v3 :-
>>>>>   - Rename hdmirx_cma to hdmi_receiver_cma
>>>>>   - Add a Reviewed-by tag
>>>>>
>>>>> Changes in v2 :-
>>>>>   - Add a description for the hardware
>>>>>   - Rename resets, vo1 grf and HPD properties
>>>>>   - Add a proper description for grf and vo1-grf phandles
>>>>>   - Rename the HDMI Input node name to hdmi-receiver
>>>>>   - Improve the subject line
>>>>>   - Include gpio header file in example to fix dt_binding_check failure
>>>>>
>>>>>  .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
>>>>>  1 file changed, 132 insertions(+)
>>>>>  create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>>>>> new file mode 100644
>>>>> index 000000000000..96ae1e2d2816
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>>>>> @@ -0,0 +1,132 @@
>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>> +# Device Tree bindings for Synopsys DesignWare HDMI RX Controller
>>>>> +
>>>>> +---
>>>>> +$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml#
>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>> +
>>>>> +title: Synopsys DesignWare HDMI RX Controller
>>>>> +
>>>>> +maintainers:
>>>>> +  - Shreeya Patel <shreeya.patel@collabora.com>
>>>>> +
>>>>> +description:
>>>>> +  Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs
>>>>> +  allowing devices to receive and decode high-resolution video streams
>>>>> +  from external sources like media players, cameras, laptops, etc.
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    items:
>>>>> +      - const: rockchip,rk3588-hdmirx-ctrler
>>>>
>>
>>>>> +      - const: snps,dw-hdmi-rx
>>
>> remove
>>
>>>>

Relevant compatible methods in use for Rockchip drivers:

===================================================================================================

Compatible method #1:
Probe is triggered by a SoC orientated string.

compatible = "rockchip,rk3588-hdmirx-ctrler";

If for example a new SoC rk3599 is released that has the same device properties
then the old string can be used as fallback string.

compatible = ""rockchip,rk3599-hdmirx-ctrler" , "rockchip,rk3588-hdmirx-ctrler";

The driver structure:
{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },

===================================================================================================
Compatible method #2:
Probe is triggered by a IP orientated fallback string.

compatible = "rockchip,rk3588-hdmirx-ctrler" , "snps,dw-hdmi-rx";

If for example a new SoC rk3599 is released that has the same device properties
then add the same fallback string.

compatible = ""rockchip,rk3599-hdmirx-ctrler" , "snps,dw-hdmi-rx";

The driver structure:
{ .compatible = "snps,dw-hdmi-rx" },

If for example a new SoC rk3599 is released that has NOT the same device properties
then use method #1.

The driver structure:
{ .compatible = "rockchip,rk3599-hdmirx-ctrler" .data = &rk3599_ops },
{ .compatible = "snps,dw-hdmi-rx" },

===================================================================================================

Compatible method #3:
Probe is triggered by a vendor orientated fallback string.

Special case only useful if the driver is written long after all SoCs are released.
The standalone IP has a version register and the driver can handle all the feature difference
inside the IP depending on the version register.

compatible = "rockchip,sfc";

The driver structure:
{ .compatible = "rockchip,sfc"},

===================================================================================================

The rules:

1: Compatible strings must be SoC orientated.
2: In Linux there's no priority in which string will probed first.
3: There is a commitment that old DT's should still work with newer kernels.

>>>> What's the point of having a fallback string when there's no common code, but instead only the first string is used?
>>>>
>>>> +static const struct of_device_id hdmirx_id[] = {
>>>> +	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
>>>> +	{ },
>>>> +};
>>>>

The consequence of the third rule is that drivers must continue to support this string once added and
can not be removed as suggested below.

If for example the fallback is added later it will trigger 2 probes and it breaks rule #2.
Only one of string is allowed to trigger a probe in the driver.

This is wrong:
compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";

{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
{ .compatible = "snps,dw-hdmi-rx" },

Ones a compatible method is chosen the driver must stick to it.

===================================================================================================

>>>
>>
>>> We believe the HDMIRX driver can be used for the Synopsys IP on other SoCs
>>> in the future, which is why we have added snps,dw-hdmi-rx as the fallback compatible.
>>> Currently, we have tested the driver only on the RK3588 Rock5B, so we are using the
>>> rockchip,rk3588-hdmirx-ctrler compatible in the driver instead of the fallback one.
>>
>> The rule that compatible strings (for internal SoC components)
>> must be SoC orientated also applies to the fallback string.
>> "snps,xxxx" does not refer to an independent SoC.

This refers to compatible method #1.

>
> Where did you learn that? Having non-SoC specific generic fallback
> compatibles is pretty much standard throughout the kernel. See for
> example these RK3588 DesignWare compatibles:
>
> Synopsys Serial Controller:
>     Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
>     compatible = "rockchip,rk3588-uart", "snps,dw-apb-uart";

Compatible method #2:
	{ .compatible = "snps,dw-apb-uart", .data = &dw8250_dw_apb },

>
> Synopsys USB3 Controller:
>     Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
>     compatible = "rockchip,rk3588-dwc3", "snps,dwc3";

Compatible method #2:
	{
		.compatible = "snps,dwc3"
	},

>
> Synopsys Ethernet Controller:
>     Documentation/devicetree/bindings/net/snps,dwmac.yaml
>     compatible = "rockchip,rk3588-gmac", "snps,dwmac-4.20a";

Compatible method #1:
	{ .compatible = "rockchip,rk3588-gmac", .data = &rk3588_ops },

	    of_device_is_compatible(np, "snps,dwmac-4.20a") ||

>
> Synsopsys SATA Controller:
>     Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
>     compatible = "rockchip,rk3588-dwc-ahci", "snps,dwc-ahci"

Compatible method #2:
	{ .compatible = "snps,dwc-ahci", &ahci_dwc_plat },

>
> It's also not specific to Synopsys (but RK3588 has a lot of Synopsys
> design incl. the HDMI-RX IP currently worked on by Shreeya). Here
> are some other examples:
>
> ARM Mali GPU:
>     Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>     compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf";

Should be compatible method #2:
	{ .compatible = "rockchip,rk3588-mali" },
	{ .compatible = "arm,mali-valhall-csf" },

This is wrong!
Each strings will trigger a probe.
The string "rockchip,rk3588-mali" should be removed.

Review was done by Collabora people and without including the Rockchip mail list.
https://patchwork.freedesktop.org/patch/msgid/20240229162230.2634044-12-boris.brezillon@collabora.com

Could someone look at this and test.

>
> Generic EHCI:
>     Documentation/devicetree/bindings/usb/generic-ehci.yaml
>     compatible = "rockchip,rk3588-ehci", "generic-ehci";

compatible method #2:
	{ .compatible = "generic-ehci", },

>
> As you can see almost everything in RK3588 has a non SoC specific
> fallback :) It's also not a Rockchip/RK3588 specific thing, but
> I think you should be able to find enough references yourself by
> looking into the kernel's DTS files.

You are mixing up 2 compatible methods.
The driver has compatible method #1 and the DT has method #2.

>
>> Don't invent strings for devices that we don't know yet if it
>> might or might not be compatible in the future.
>
> Right now it's a sensible assumption, that an operating system driver
> for this hardware (i.e. not necessarily the one submitted by Shreeya
> right now) can handle the Synopsys HDMI receiver hardware from different
> SoCs just like it is the case for other Synopsys IP.
>
> Whatever is being done now is set in stone, since DT is considered
> ABI. So without the fallback compatible being available in DT from
> the beginning we need to carry the RK3588 specific compatible in the

> kernel driver forever. OTOH if we add the generic one now, the kernel
> can switch to use the generic one at any point in time and ignore the
> RK3588 specific one.

Ignoring breaks rule #3 as explained above.

For you the task to select a compatible method:

If the IP device registers are guaranteed remain the same then choose compatible method #2 and fix the driver.
If in doubt choose compatible method #1 and fix the binding.

Johan

>
> Greetings,
>
> -- Sebastian
>
>> Johan
>>
>>>
>>>
>>> Thanks,
>>> Shreeya Patel
>>>
>>>>> +
>>>>> +  reg:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  interrupts:
>>>>> +    maxItems: 3
>>>>> +
>>>>> +  interrupt-names:
>>>>> +    items:
>>>>> +      - const: cec
>>>>> +      - const: hdmi
>>>>> +      - const: dma
>>>>> +
>>>>> +  clocks:
>>>>> +    maxItems: 7
>>>>> +
>>>>> +  clock-names:
>>>>> +    items:
>>>>> +      - const: aclk
>>>>> +      - const: audio
>>>>> +      - const: cr_para
>>>>> +      - const: pclk
>>>>> +      - const: ref
>>>>> +      - const: hclk_s_hdmirx
>>>>> +      - const: hclk_vo1
>>>>> +
>>>>> +  power-domains:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  resets:
>>>>> +    maxItems: 4
>>>>> +
>>>>> +  reset-names:
>>>>> +    items:
>>>>> +      - const: axi
>>>>> +      - const: apb
>>>>> +      - const: ref
>>>>> +      - const: biu
>>>>> +
>>>>> +  memory-region:
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  hpd-gpios:
>>>>> +    description: GPIO specifier for HPD.
>>>>> +    maxItems: 1
>>>>> +
>>>>> +  rockchip,grf:
>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>> +    description:
>>>>> +      The phandle of the syscon node for the general register file
>>>>> +      containing HDMIRX PHY status bits.
>>>>> +
>>>>> +  rockchip,vo1-grf:
>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>> +    description:
>>>>> +      The phandle of the syscon node for the Video Output GRF register
>>>>> +      to enable EDID transfer through SDAIN and SCLIN.
>>>>> +
>>>>> +required:
>>>>> +  - compatible
>>>>> +  - reg
>>>>> +  - interrupts
>>>>> +  - interrupt-names
>>>>> +  - clocks
>>>>> +  - clock-names
>>>>> +  - power-domains
>>>>> +  - resets
>>>>> +  - pinctrl-0
>>>>> +  - hpd-gpios
>>>>> +
>>>>> +additionalProperties: false
>>>>> +
>>>>> +examples:
>>>>> +  - |
>>>>> +    #include <dt-bindings/clock/rockchip,rk3588-cru.h>
>>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>>>> +    #include <dt-bindings/power/rk3588-power.h>
>>>>> +    #include <dt-bindings/reset/rockchip,rk3588-cru.h>
>>>>> +    hdmi_receiver: hdmi-receiver@fdee0000 {
>>
>>>>> +      compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
>>
>>       compatible = "rockchip,rk3588-hdmirx-ctrler";
>>
>>>>> +      reg = <0xfdee0000 0x6000>;
>>>>> +      interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
>>>>> +                   <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
>>>>> +                   <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
>>>>> +      interrupt-names = "cec", "hdmi", "dma";
>>>>> +      clocks = <&cru ACLK_HDMIRX>,
>>>>> +               <&cru CLK_HDMIRX_AUD>,
>>>>> +               <&cru CLK_CR_PARA>,
>>>>> +               <&cru PCLK_HDMIRX>,
>>>>> +               <&cru CLK_HDMIRX_REF>,
>>>>> +               <&cru PCLK_S_HDMIRX>,
>>>>> +               <&cru HCLK_VO1>;
>>>>> +      clock-names = "aclk",
>>>>> +                    "audio",
>>>>> +                    "cr_para",
>>>>> +                    "pclk",
>>>>> +                    "ref",
>>>>> +                    "hclk_s_hdmirx",
>>>>> +                    "hclk_vo1";
>>>>> +      power-domains = <&power RK3588_PD_VO1>;
>>>>> +      resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
>>>>> +               <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
>>>>> +      reset-names = "axi", "apb", "ref", "biu";
>>>>> +      memory-region = <&hdmi_receiver_cma>;
>>>>> +      pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
>>>>> +      pinctrl-names = "default";
>>>>> +      hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
>>>>> +    };
>>>
>> _______________________________________________
>> Kernel mailing list -- kernel@mailman.collabora.com
>> To unsubscribe send an email to kernel-leave@mailman.collabora.com
>> This list is managed by https://mailman.collabora.com

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Krzysztof Kozlowski]

On 24/07/2024 15:20, Johan Jonker wrote:
> 
>>
>> Where did you learn that? Having non-SoC specific generic fallback
>> compatibles is pretty much standard throughout the kernel. See for
>> example these RK3588 DesignWare compatibles:
>>
>> Synopsys Serial Controller:
>>     Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
>>     compatible = "rockchip,rk3588-uart", "snps,dw-apb-uart";
> 
> Compatible method #2:
> 	{ .compatible = "snps,dw-apb-uart", .data = &dw8250_dw_apb },
> 
>>
>> Synopsys USB3 Controller:
>>     Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
>>     compatible = "rockchip,rk3588-dwc3", "snps,dwc3";
> 
> Compatible method #2:
> 	{
> 		.compatible = "snps,dwc3"
> 	},
> 
>>
>> Synopsys Ethernet Controller:
>>     Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>     compatible = "rockchip,rk3588-gmac", "snps,dwmac-4.20a";
> 
> Compatible method #1:
> 	{ .compatible = "rockchip,rk3588-gmac", .data = &rk3588_ops },
> 
> 	    of_device_is_compatible(np, "snps,dwmac-4.20a") ||
> 
>>
>> Synsopsys SATA Controller:
>>     Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
>>     compatible = "rockchip,rk3588-dwc-ahci", "snps,dwc-ahci"
> 
> Compatible method #2:
> 	{ .compatible = "snps,dwc-ahci", &ahci_dwc_plat },
> 
>>
>> It's also not specific to Synopsys (but RK3588 has a lot of Synopsys
>> design incl. the HDMI-RX IP currently worked on by Shreeya). Here
>> are some other examples:
>>
>> ARM Mali GPU:
>>     Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>     compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf";
> 
> Should be compatible method #2:
> 	{ .compatible = "rockchip,rk3588-mali" },
> 	{ .compatible = "arm,mali-valhall-csf" },
> 
> This is wrong!

Except that it is pointless and redundant, why is it wrong? You did not
bring any argument, except "will trigger 2 probes" which is clearly false.

> Each strings will trigger a probe.

What? That's not true.

> The string "rockchip,rk3588-mali" should be removed.
> 
> Review was done by Collabora people and without including the Rockchip mail list.
> https://patchwork.freedesktop.org/patch/msgid/20240229162230.2634044-12-boris.brezillon@collabora.com
> 
> Could someone look at this and test.

No need, just read how device matching and probing works...




Best regards,
Krzysztof

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Krzysztof Kozlowski]

On 25/07/2024 08:35, Krzysztof Kozlowski wrote:
> On 24/07/2024 15:20, Johan Jonker wrote:
>>
>>>
>>> Where did you learn that? Having non-SoC specific generic fallback
>>> compatibles is pretty much standard throughout the kernel. See for
>>> example these RK3588 DesignWare compatibles:
>>>
>>> Synopsys Serial Controller:
>>>     Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
>>>     compatible = "rockchip,rk3588-uart", "snps,dw-apb-uart";
>>
>> Compatible method #2:
>> 	{ .compatible = "snps,dw-apb-uart", .data = &dw8250_dw_apb },
>>
>>>
>>> Synopsys USB3 Controller:
>>>     Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
>>>     compatible = "rockchip,rk3588-dwc3", "snps,dwc3";
>>
>> Compatible method #2:
>> 	{
>> 		.compatible = "snps,dwc3"
>> 	},
>>
>>>
>>> Synopsys Ethernet Controller:
>>>     Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>>     compatible = "rockchip,rk3588-gmac", "snps,dwmac-4.20a";
>>
>> Compatible method #1:
>> 	{ .compatible = "rockchip,rk3588-gmac", .data = &rk3588_ops },
>>
>> 	    of_device_is_compatible(np, "snps,dwmac-4.20a") ||
>>
>>>
>>> Synsopsys SATA Controller:
>>>     Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
>>>     compatible = "rockchip,rk3588-dwc-ahci", "snps,dwc-ahci"
>>
>> Compatible method #2:
>> 	{ .compatible = "snps,dwc-ahci", &ahci_dwc_plat },
>>
>>>
>>> It's also not specific to Synopsys (but RK3588 has a lot of Synopsys
>>> design incl. the HDMI-RX IP currently worked on by Shreeya). Here
>>> are some other examples:
>>>
>>> ARM Mali GPU:
>>>     Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>>     compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf";
>>
>> Should be compatible method #2:
>> 	{ .compatible = "rockchip,rk3588-mali" },
>> 	{ .compatible = "arm,mali-valhall-csf" },
>>
>> This is wrong!
> 
> Except that it is pointless and redundant, why is it wrong? You did not
> bring any argument, except "will trigger 2 probes" which is clearly false.
> 
>> Each strings will trigger a probe.
> 
> What? That's not true.

Although if you meant "any string will trigger one probe in total", then
it would be true, so maybe that's what you meant.

But then - what's wrong with this (except needless redundancy)? You did
not bring any argument but keep calling more than once "wrong". So what
is wrong?

Best regards,
Krzysztof

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[AngeloGioacchino Del Regno]

Il 24/07/24 15:20, Johan Jonker ha scritto:
> 
> 
> On 7/23/24 19:28, Sebastian Reichel wrote:
>> Hi,
>>
>> On Tue, Jul 23, 2024 at 01:16:00PM GMT, Johan Jonker wrote:
>>> On 7/22/24 15:53, Shreeya Patel wrote:
>>>> On Saturday, July 20, 2024 16:14 IST, Johan Jonker <jbx6244@yandex.com> wrote:
>>>>> On 7/19/24 14:40, Shreeya Patel wrote:
>>>>>> Document bindings for the Synopsys DesignWare HDMI RX Controller.
>>>>>>
>>>
>>>>>> Reviewed-by: Rob Herring <robh@kernel.org>
>>>>>> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
>>>
>>> Remove to trigger a new review.
>>
>> Rob and Dmitry both already reviewed the version with the fallback
>> compatible. I don't think the rename of hdmirx_cma to hdmi_receiver_cma
>> warrant a new review. Also FWIW:
>>
> 
>> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> 
> Please have a look at the comments below before you tag.
> 

I have checked the (mostly wrong) comments before tagging.

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

Regards,
Angelo

>>
>>>>>> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
>>>>>> ---
>>>>>>
>>>>>> Changes in v4 :-
>>>>>>    - No change
>>>>>>
>>>>>> Changes in v3 :-
>>>>>>    - Rename hdmirx_cma to hdmi_receiver_cma
>>>>>>    - Add a Reviewed-by tag
>>>>>>
>>>>>> Changes in v2 :-
>>>>>>    - Add a description for the hardware
>>>>>>    - Rename resets, vo1 grf and HPD properties
>>>>>>    - Add a proper description for grf and vo1-grf phandles
>>>>>>    - Rename the HDMI Input node name to hdmi-receiver
>>>>>>    - Improve the subject line
>>>>>>    - Include gpio header file in example to fix dt_binding_check failure
>>>>>>
>>>>>>   .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
>>>>>>   1 file changed, 132 insertions(+)
>>>>>>   create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>>>>>> new file mode 100644
>>>>>> index 000000000000..96ae1e2d2816
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>>>>>> @@ -0,0 +1,132 @@
>>>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>>>> +# Device Tree bindings for Synopsys DesignWare HDMI RX Controller
>>>>>> +
>>>>>> +---
>>>>>> +$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml#
>>>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>> +
>>>>>> +title: Synopsys DesignWare HDMI RX Controller
>>>>>> +
>>>>>> +maintainers:
>>>>>> +  - Shreeya Patel <shreeya.patel@collabora.com>
>>>>>> +
>>>>>> +description:
>>>>>> +  Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs
>>>>>> +  allowing devices to receive and decode high-resolution video streams
>>>>>> +  from external sources like media players, cameras, laptops, etc.
>>>>>> +
>>>>>> +properties:
>>>>>> +  compatible:
>>>>>> +    items:
>>>>>> +      - const: rockchip,rk3588-hdmirx-ctrler
>>>>>
>>>
>>>>>> +      - const: snps,dw-hdmi-rx
>>>
>>> remove
>>>
>>>>>
> 
> Relevant compatible methods in use for Rockchip drivers:
> 
> ===================================================================================================
> 
> Compatible method #1:
> Probe is triggered by a SoC orientated string.
> 
> compatible = "rockchip,rk3588-hdmirx-ctrler";
> 
> If for example a new SoC rk3599 is released that has the same device properties
> then the old string can be used as fallback string.
> 
> compatible = ""rockchip,rk3599-hdmirx-ctrler" , "rockchip,rk3588-hdmirx-ctrler";
> 
> The driver structure:
> { .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> 
> ===================================================================================================
> Compatible method #2:
> Probe is triggered by a IP orientated fallback string.
> 
> compatible = "rockchip,rk3588-hdmirx-ctrler" , "snps,dw-hdmi-rx";
> 
> If for example a new SoC rk3599 is released that has the same device properties
> then add the same fallback string.
> 
> compatible = ""rockchip,rk3599-hdmirx-ctrler" , "snps,dw-hdmi-rx";
> 
> The driver structure:
> { .compatible = "snps,dw-hdmi-rx" },
> 
> If for example a new SoC rk3599 is released that has NOT the same device properties
> then use method #1.
> 
> The driver structure:
> { .compatible = "rockchip,rk3599-hdmirx-ctrler" .data = &rk3599_ops },
> { .compatible = "snps,dw-hdmi-rx" },
> 
> ===================================================================================================
> 
> Compatible method #3:
> Probe is triggered by a vendor orientated fallback string.
> 
> Special case only useful if the driver is written long after all SoCs are released.
> The standalone IP has a version register and the driver can handle all the feature difference
> inside the IP depending on the version register.
> 
> compatible = "rockchip,sfc";
> 
> The driver structure:
> { .compatible = "rockchip,sfc"},
> 
> ===================================================================================================
> 
> The rules:
> 
> 1: Compatible strings must be SoC orientated.
> 2: In Linux there's no priority in which string will probed first.
> 3: There is a commitment that old DT's should still work with newer kernels.
> 
>>>>> What's the point of having a fallback string when there's no common code, but instead only the first string is used?
>>>>>
>>>>> +static const struct of_device_id hdmirx_id[] = {
>>>>> +	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
>>>>> +	{ },
>>>>> +};
>>>>>
> 
> The consequence of the third rule is that drivers must continue to support this string once added and
> can not be removed as suggested below.
> 
> If for example the fallback is added later it will trigger 2 probes and it breaks rule #2.
> Only one of string is allowed to trigger a probe in the driver.
> 
> This is wrong:
> compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
> 
> { .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> { .compatible = "snps,dw-hdmi-rx" },
> 
> Ones a compatible method is chosen the driver must stick to it.
> 
> ===================================================================================================
> 
>>>>
>>>
>>>> We believe the HDMIRX driver can be used for the Synopsys IP on other SoCs
>>>> in the future, which is why we have added snps,dw-hdmi-rx as the fallback compatible.
>>>> Currently, we have tested the driver only on the RK3588 Rock5B, so we are using the
>>>> rockchip,rk3588-hdmirx-ctrler compatible in the driver instead of the fallback one.
>>>
>>> The rule that compatible strings (for internal SoC components)
>>> must be SoC orientated also applies to the fallback string.
>>> "snps,xxxx" does not refer to an independent SoC.
> 
> This refers to compatible method #1.
> 
>>
>> Where did you learn that? Having non-SoC specific generic fallback
>> compatibles is pretty much standard throughout the kernel. See for
>> example these RK3588 DesignWare compatibles:
>>
>> Synopsys Serial Controller:
>>      Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml
>>      compatible = "rockchip,rk3588-uart", "snps,dw-apb-uart";
> 
> Compatible method #2:
> 	{ .compatible = "snps,dw-apb-uart", .data = &dw8250_dw_apb },
> 
>>
>> Synopsys USB3 Controller:
>>      Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml
>>      compatible = "rockchip,rk3588-dwc3", "snps,dwc3";
> 
> Compatible method #2:
> 	{
> 		.compatible = "snps,dwc3"
> 	},
> 
>>
>> Synopsys Ethernet Controller:
>>      Documentation/devicetree/bindings/net/snps,dwmac.yaml
>>      compatible = "rockchip,rk3588-gmac", "snps,dwmac-4.20a";
> 
> Compatible method #1:
> 	{ .compatible = "rockchip,rk3588-gmac", .data = &rk3588_ops },
> 
> 	    of_device_is_compatible(np, "snps,dwmac-4.20a") ||
> 
>>
>> Synsopsys SATA Controller:
>>      Documentation/devicetree/bindings/ata/rockchip,dwc-ahci.yaml
>>      compatible = "rockchip,rk3588-dwc-ahci", "snps,dwc-ahci"
> 
> Compatible method #2:
> 	{ .compatible = "snps,dwc-ahci", &ahci_dwc_plat },
> 
>>
>> It's also not specific to Synopsys (but RK3588 has a lot of Synopsys
>> design incl. the HDMI-RX IP currently worked on by Shreeya). Here
>> are some other examples:
>>
>> ARM Mali GPU:
>>      Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>      compatible = "rockchip,rk3588-mali", "arm,mali-valhall-csf";
> 
> Should be compatible method #2:
> 	{ .compatible = "rockchip,rk3588-mali" },
> 	{ .compatible = "arm,mali-valhall-csf" },
> 
> This is wrong!
> Each strings will trigger a probe.
> The string "rockchip,rk3588-mali" should be removed.
> 
> Review was done by Collabora people and without including the Rockchip mail list.
> https://patchwork.freedesktop.org/patch/msgid/20240229162230.2634044-12-boris.brezillon@collabora.com
> 
> Could someone look at this and test.
> 
>>
>> Generic EHCI:
>>      Documentation/devicetree/bindings/usb/generic-ehci.yaml
>>      compatible = "rockchip,rk3588-ehci", "generic-ehci";
> 
> compatible method #2:
> 	{ .compatible = "generic-ehci", },
> 
>>
>> As you can see almost everything in RK3588 has a non SoC specific
>> fallback :) It's also not a Rockchip/RK3588 specific thing, but
>> I think you should be able to find enough references yourself by
>> looking into the kernel's DTS files.
> 
> You are mixing up 2 compatible methods.
> The driver has compatible method #1 and the DT has method #2.
> 
>>
>>> Don't invent strings for devices that we don't know yet if it
>>> might or might not be compatible in the future.
>>
>> Right now it's a sensible assumption, that an operating system driver
>> for this hardware (i.e. not necessarily the one submitted by Shreeya
>> right now) can handle the Synopsys HDMI receiver hardware from different
>> SoCs just like it is the case for other Synopsys IP.
>>
>> Whatever is being done now is set in stone, since DT is considered
>> ABI. So without the fallback compatible being available in DT from
>> the beginning we need to carry the RK3588 specific compatible in the
> 
>> kernel driver forever. OTOH if we add the generic one now, the kernel
>> can switch to use the generic one at any point in time and ignore the
>> RK3588 specific one.
> 
> Ignoring breaks rule #3 as explained above.
> 
> For you the task to select a compatible method:
> 
> If the IP device registers are guaranteed remain the same then choose compatible method #2 and fix the driver.
> If in doubt choose compatible method #1 and fix the binding.
> 
> Johan
> 
>>
>> Greetings,
>>
>> -- Sebastian
>>
>>> Johan
>>>
>>>>
>>>>
>>>> Thanks,
>>>> Shreeya Patel
>>>>
>>>>>> +
>>>>>> +  reg:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  interrupts:
>>>>>> +    maxItems: 3
>>>>>> +
>>>>>> +  interrupt-names:
>>>>>> +    items:
>>>>>> +      - const: cec
>>>>>> +      - const: hdmi
>>>>>> +      - const: dma
>>>>>> +
>>>>>> +  clocks:
>>>>>> +    maxItems: 7
>>>>>> +
>>>>>> +  clock-names:
>>>>>> +    items:
>>>>>> +      - const: aclk
>>>>>> +      - const: audio
>>>>>> +      - const: cr_para
>>>>>> +      - const: pclk
>>>>>> +      - const: ref
>>>>>> +      - const: hclk_s_hdmirx
>>>>>> +      - const: hclk_vo1
>>>>>> +
>>>>>> +  power-domains:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  resets:
>>>>>> +    maxItems: 4
>>>>>> +
>>>>>> +  reset-names:
>>>>>> +    items:
>>>>>> +      - const: axi
>>>>>> +      - const: apb
>>>>>> +      - const: ref
>>>>>> +      - const: biu
>>>>>> +
>>>>>> +  memory-region:
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  hpd-gpios:
>>>>>> +    description: GPIO specifier for HPD.
>>>>>> +    maxItems: 1
>>>>>> +
>>>>>> +  rockchip,grf:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>>> +    description:
>>>>>> +      The phandle of the syscon node for the general register file
>>>>>> +      containing HDMIRX PHY status bits.
>>>>>> +
>>>>>> +  rockchip,vo1-grf:
>>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>>> +    description:
>>>>>> +      The phandle of the syscon node for the Video Output GRF register
>>>>>> +      to enable EDID transfer through SDAIN and SCLIN.
>>>>>> +
>>>>>> +required:
>>>>>> +  - compatible
>>>>>> +  - reg
>>>>>> +  - interrupts
>>>>>> +  - interrupt-names
>>>>>> +  - clocks
>>>>>> +  - clock-names
>>>>>> +  - power-domains
>>>>>> +  - resets
>>>>>> +  - pinctrl-0
>>>>>> +  - hpd-gpios
>>>>>> +
>>>>>> +additionalProperties: false
>>>>>> +
>>>>>> +examples:
>>>>>> +  - |
>>>>>> +    #include <dt-bindings/clock/rockchip,rk3588-cru.h>
>>>>>> +    #include <dt-bindings/gpio/gpio.h>
>>>>>> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>>> +    #include <dt-bindings/interrupt-controller/irq.h>
>>>>>> +    #include <dt-bindings/power/rk3588-power.h>
>>>>>> +    #include <dt-bindings/reset/rockchip,rk3588-cru.h>
>>>>>> +    hdmi_receiver: hdmi-receiver@fdee0000 {
>>>
>>>>>> +      compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
>>>
>>>        compatible = "rockchip,rk3588-hdmirx-ctrler";
>>>
>>>>>> +      reg = <0xfdee0000 0x6000>;
>>>>>> +      interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
>>>>>> +                   <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
>>>>>> +                   <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
>>>>>> +      interrupt-names = "cec", "hdmi", "dma";
>>>>>> +      clocks = <&cru ACLK_HDMIRX>,
>>>>>> +               <&cru CLK_HDMIRX_AUD>,
>>>>>> +               <&cru CLK_CR_PARA>,
>>>>>> +               <&cru PCLK_HDMIRX>,
>>>>>> +               <&cru CLK_HDMIRX_REF>,
>>>>>> +               <&cru PCLK_S_HDMIRX>,
>>>>>> +               <&cru HCLK_VO1>;
>>>>>> +      clock-names = "aclk",
>>>>>> +                    "audio",
>>>>>> +                    "cr_para",
>>>>>> +                    "pclk",
>>>>>> +                    "ref",
>>>>>> +                    "hclk_s_hdmirx",
>>>>>> +                    "hclk_vo1";
>>>>>> +      power-domains = <&power RK3588_PD_VO1>;
>>>>>> +      resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
>>>>>> +               <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
>>>>>> +      reset-names = "axi", "apb", "ref", "biu";
>>>>>> +      memory-region = <&hdmi_receiver_cma>;
>>>>>> +      pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
>>>>>> +      pinctrl-names = "default";
>>>>>> +      hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
>>>>>> +    };
>>>>
>>> _______________________________________________
>>> Kernel mailing list -- kernel@mailman.collabora.com
>>> To unsubscribe send an email to kernel-leave@mailman.collabora.com
>>> This list is managed by https://mailman.collabora.com
> _______________________________________________
> Kernel mailing list -- kernel@mailman.collabora.com
> To unsubscribe send an email to kernel-leave@mailman.collabora.com
> This list is managed by https://mailman.collabora.com

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 10759 bytes --]

Hi,

On Wed, Jul 24, 2024 at 03:20:28PM GMT, Johan Jonker wrote:
> 
> 
> On 7/23/24 19:28, Sebastian Reichel wrote:
> > Hi,
> >
> > On Tue, Jul 23, 2024 at 01:16:00PM GMT, Johan Jonker wrote:
> >> On 7/22/24 15:53, Shreeya Patel wrote:
> >>> On Saturday, July 20, 2024 16:14 IST, Johan Jonker <jbx6244@yandex.com> wrote:
> >>>> On 7/19/24 14:40, Shreeya Patel wrote:
> >>>>> Document bindings for the Synopsys DesignWare HDMI RX Controller.
> >>>>>
> >>
> >>>>> Reviewed-by: Rob Herring <robh@kernel.org>
> >>>>> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> >>
> >> Remove to trigger a new review.
> >
> > Rob and Dmitry both already reviewed the version with the fallback
> > compatible. I don't think the rename of hdmirx_cma to hdmi_receiver_cma
> > warrant a new review. Also FWIW:
> >
> 
> > Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> 
> Please have a look at the comments below before you tag.
> 
> >
> >>>>> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> >>>>> ---
> >>>>>
> >>>>> Changes in v4 :-
> >>>>>   - No change
> >>>>>
> >>>>> Changes in v3 :-
> >>>>>   - Rename hdmirx_cma to hdmi_receiver_cma
> >>>>>   - Add a Reviewed-by tag
> >>>>>
> >>>>> Changes in v2 :-
> >>>>>   - Add a description for the hardware
> >>>>>   - Rename resets, vo1 grf and HPD properties
> >>>>>   - Add a proper description for grf and vo1-grf phandles
> >>>>>   - Rename the HDMI Input node name to hdmi-receiver
> >>>>>   - Improve the subject line
> >>>>>   - Include gpio header file in example to fix dt_binding_check failure
> >>>>>
> >>>>>  .../bindings/media/snps,dw-hdmi-rx.yaml       | 132 ++++++++++++++++++
> >>>>>  1 file changed, 132 insertions(+)
> >>>>>  create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> >>>>> new file mode 100644
> >>>>> index 000000000000..96ae1e2d2816
> >>>>> --- /dev/null
> >>>>> +++ b/Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
> >>>>> @@ -0,0 +1,132 @@
> >>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> >>>>> +# Device Tree bindings for Synopsys DesignWare HDMI RX Controller
> >>>>> +
> >>>>> +---
> >>>>> +$id: http://devicetree.org/schemas/media/snps,dw-hdmi-rx.yaml#
> >>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>>> +
> >>>>> +title: Synopsys DesignWare HDMI RX Controller
> >>>>> +
> >>>>> +maintainers:
> >>>>> +  - Shreeya Patel <shreeya.patel@collabora.com>
> >>>>> +
> >>>>> +description:
> >>>>> +  Synopsys DesignWare HDMI Input Controller preset on RK3588 SoCs
> >>>>> +  allowing devices to receive and decode high-resolution video streams
> >>>>> +  from external sources like media players, cameras, laptops, etc.
> >>>>> +
> >>>>> +properties:
> >>>>> +  compatible:
> >>>>> +    items:
> >>>>> +      - const: rockchip,rk3588-hdmirx-ctrler
> >>>>
> >>
> >>>>> +      - const: snps,dw-hdmi-rx
> >>
> >> remove
> >>
> >>>>
> 
> Relevant compatible methods in use for Rockchip drivers:

You are arguing with kernel drivers. Drivers can be changed at any
point in time, but DT bindings cannot, because they define an ABI.

> ===================================================================================================
> 
> Compatible method #1:
> Probe is triggered by a SoC orientated string.
> 
> compatible = "rockchip,rk3588-hdmirx-ctrler";
> 
> If for example a new SoC rk3599 is released that has the same device properties
> then the old string can be used as fallback string.
> 
> compatible = ""rockchip,rk3599-hdmirx-ctrler" , "rockchip,rk3588-hdmirx-ctrler";
> 
> The driver structure:
> { .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> 
> ===================================================================================================
> Compatible method #2:
> Probe is triggered by a IP orientated fallback string.
> 
> compatible = "rockchip,rk3588-hdmirx-ctrler" , "snps,dw-hdmi-rx";
> 
> If for example a new SoC rk3599 is released that has the same device properties
> then add the same fallback string.
> 
> compatible = ""rockchip,rk3599-hdmirx-ctrler" , "snps,dw-hdmi-rx";
> 
> The driver structure:
> { .compatible = "snps,dw-hdmi-rx" },
> 
> If for example a new SoC rk3599 is released that has NOT the same device properties
> then use method #1.
> 
> The driver structure:
> { .compatible = "rockchip,rk3599-hdmirx-ctrler" .data = &rk3599_ops },
> { .compatible = "snps,dw-hdmi-rx" },

This is what is being used here. The only diference is, that the
driver currently uses the RK3588 specific compatible string instead
of the fallback string right now.

If another SoC vendor adds the same IP into their latest chip and
the driver has been proven to work with their hardware the driver
can be changed to bind against "snps,dw-hdmi-rx" instead of the
RK3588 specific compatible. Doing this change will keep
compatibility with existing DTs, if we add the fallback string now.
Until then we just carry it as an unused fallback.

> ===================================================================================================
> 
> Compatible method #3:
> Probe is triggered by a vendor orientated fallback string.
> 
> Special case only useful if the driver is written long after all SoCs are released.
> The standalone IP has a version register and the driver can handle all the feature difference
> inside the IP depending on the version register.
> 
> compatible = "rockchip,sfc";
> 
> The driver structure:
> { .compatible = "rockchip,sfc"},

FWIW I think _this_ is a bad example. It is missing the SoC specific
compatible making applying of quirks harder than necessary. Just
because no quirks are needed now, does not mean it will stay that
way. E.g. if an Errata gets released that SFC on RK3588 must not be
run at 1 MHz it would be super useful to have an "rockchip,rk3588-sfc"
to match against. That's the reason for the rule #1 in the following
list

> ===================================================================================================
> 
> The rules:
> 
> 1: Compatible strings must be SoC orientated.
> 2: In Linux there's no priority in which string will probed first.

I initially thought you mean the list in the driver, but after
reading your remaining mail - this is just wrong. There is a
priority. If DT specifies

compatible = "main", "fallback";

Linux will first try to bind against "main". If that does not
work it will try to bind against "fallback". To give you a
simple example from the subsystem I maintain:

DT binding: Documentation/devicetree/bindings/power/supply/sbs,sbs-battery.yaml
Linux Kernel Driver: drivers/power/supply/sbs-battery.c

Valid compatibles according to the DT binding:
 compatible = "ti,bq20z45", "sbs,sbs-battery";
 compatible = "ti,bq20z65", "sbs,sbs-battery";
 compatible = "ti,bq20z75", "sbs,sbs-battery";
 compatible = "sbs,sbs-battery";

The driver has these of_device_id entries:
 { .compatible = "sbs,sbs-battery" },
 { .compatible = "ti,bq20z65", QUIRKS },
 { .compatible = "ti,bq20z75", QUIRKS },

The driver will probe ONCE in all cases.

compatible = "ti,bq20z45", "sbs,sbs-battery"; => probe happens with fallback string
compatible = "ti,bq20z65", "sbs,sbs-battery"; => probe happens with main string (QUIRKS apply)
compatible = "ti,bq20z75", "sbs,sbs-battery"; => probe happens with main string (QUIRKS apply)
compatible = "sbs,sbs-battery"; => probe happens with main string

> 3: There is a commitment that old DT's should still work with newer kernels.

> >>>> What's the point of having a fallback string when there's no common code, but instead only the first string is used?
> >>>>
> >>>> +static const struct of_device_id hdmirx_id[] = {
> >>>> +	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> >>>> +	{ },
> >>>> +};
> >>>>
> 
> The consequence of the third rule is that drivers must continue to
> support this string once added and can not be removed as suggested
> below.

That's wrong. We can remove the "rockchip,rk3588-hdmirx-ctrler" from
the kernel driver and use the fallback string at any point in time
__IF__ we make it mandatory that rockchip,rk3588-hdmirx-ctrler must
always be followed by the fallback compatible in DT. Because then we
will keep working with old DTs, since the old DT also has the
fallback compatible.

> If for example the fallback is added later it will trigger 2 probes and it breaks rule #2.
> Only one of string is allowed to trigger a probe in the driver.
> 
> This is wrong:
> compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
> 
> { .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> { .compatible = "snps,dw-hdmi-rx" },
> 
> Ones a compatible method is chosen the driver must stick to it.

I don't know how you came to that conclusion, but it's simply wrong.
The above example will probe once using the "rockchip,rk3588-hdmirx-ctrler"
compatible. At that point the DT node is marked as processed, so
no other probe happens.

> ===================================================================================================
> 
> >>>
> >>
> >>> We believe the HDMIRX driver can be used for the Synopsys IP on other SoCs
> >>> in the future, which is why we have added snps,dw-hdmi-rx as the fallback compatible.
> >>> Currently, we have tested the driver only on the RK3588 Rock5B, so we are using the
> >>> rockchip,rk3588-hdmirx-ctrler compatible in the driver instead of the fallback one.
> >>
> >> The rule that compatible strings (for internal SoC components)
> >> must be SoC orientated also applies to the fallback string.
> >> "snps,xxxx" does not refer to an independent SoC.
> 
> This refers to compatible method #1.

Yeah, which is used when the IP is from the SoC vendor itself (or
unknown) or if its not possible to use the generic IP compatible
anyways.

> [...]
> If the IP device registers are guaranteed remain the same then
> choose compatible method #2 and fix the driver.

Adapting the driver is the plan, but it cannot be done right now
because lack of information. This requires either another SoC with
this IP or at least the Synopsys documentation. We only have the
Rockchip documentation.

But the driver can be fixed in the future and the DT binding is
ABI. Thus the DT binding is prepared now to allow the driver looking
like your method #2 in the future. Until then the extra compatible
will just be ignored.

-- Sebastian

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Krzysztof Kozlowski]

On 19/07/2024 14:40, Shreeya Patel wrote:
> Document bindings for the Synopsys DesignWare HDMI RX Controller.
> 
> Reviewed-by: Rob Herring <robh@kernel.org>
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>

If you are going to send a new version, then:

A nit, subject: drop second/last, redundant "Document bindings for". The
"dt-bindings" prefix is already stating that these are bindings and this
is documentation.
See also:
https://elixir.bootlin.com/linux/v6.7-rc8/source/Documentation/devicetree/bindings/submitting-patches.rst#L18


"Add Synopsys HDMI RX Controller".


Best regards,
Krzysztof

Re: [PATCH v4 2/4] dt-bindings: media: Document bindings for HDMI RX Controller

[Michael Riesch]

Hi Shreeya, hi all,

First of all thank you very much for your efforts and patches!

I have got more of a general question that came up during my recent work
on a HDMI RX companion chip driver. It may or may not be out of scope of
this initial submission for the Synopsys HDMI RX IP core, but anyway I
feel like I should ask it now:

On 7/19/24 14:40, Shreeya Patel wrote:
> [...]
> +examples:
> +  - |
> +    #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> +    #include <dt-bindings/gpio/gpio.h>
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/power/rk3588-power.h>
> +    #include <dt-bindings/reset/rockchip,rk3588-cru.h>
> +    hdmi_receiver: hdmi-receiver@fdee0000 {
> +      compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
> +      reg = <0xfdee0000 0x6000>;
> +      interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
> +                   <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
> +                   <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
> +      interrupt-names = "cec", "hdmi", "dma";
> +      clocks = <&cru ACLK_HDMIRX>,
> +               <&cru CLK_HDMIRX_AUD>,
> +               <&cru CLK_CR_PARA>,
> +               <&cru PCLK_HDMIRX>,
> +               <&cru CLK_HDMIRX_REF>,
> +               <&cru PCLK_S_HDMIRX>,
> +               <&cru HCLK_VO1>;
> +      clock-names = "aclk",
> +                    "audio",
> +                    "cr_para",
> +                    "pclk",
> +                    "ref",
> +                    "hclk_s_hdmirx",
> +                    "hclk_vo1";
> +      power-domains = <&power RK3588_PD_VO1>;
> +      resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
> +               <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
> +      reset-names = "axi", "apb", "ref", "biu";
> +      memory-region = <&hdmi_receiver_cma>;
> +      pinctrl-0 = <&hdmim1_rx_cec &hdmim1_rx_hpdin &hdmim1_rx_scl &hdmim1_rx_sda &hdmirx_5v_detection>;
> +      pinctrl-names = "default";
> +      hpd-gpios = <&gpio1 22 GPIO_ACTIVE_LOW>;
> +    };

Should HDMI RX connectors be described in the device tree?

It seems that V4L2 features support for svidio and composite connectors,
but newer standards such as HDMI never made it to e.g,
drivers/media/v4l2-core/v4l2-fwnode.c. The name of the corresponding DT
binding
Documentation/devicetree/bindings/display/connector/analog-tv-connector.yaml
somewhat confirms that only analog connectors are in the scope there.
This means that some initial discussion and effort on the framework
would be required.

However, this would enable some nice (although not exactly killer)
features: describing label, orientation, and connector (sub)type on DT
level, thus eliminating the need to know the HW description in the
higher SW layers.

If the notion of HDMI RX (or, in general, digital video input)
connectors in DT sounds reasonable to you all, there may be the chance
to rework the submission at hand accordingly to avoid any compatibility
issues with older/newer device trees. This is why I am bringing this up
right now.

What do you all think?

Best regards,
Michael

[PATCH v4 3/4] arm64: dts: rockchip: Add device tree support for HDMI RX Controller

[Shreeya Patel]

Add device tree support for Synopsys DesignWare HDMI RX
Controller.

Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Co-developed-by: Dingxian Wen <shawn.wen@rock-chips.com>
Signed-off-by: Dingxian Wen <shawn.wen@rock-chips.com>
Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
---

Changes in v4 :-
  - Remove DTS changes added to this patch
  - Remove the HDMI RX pin nodes as it's already present
    in the rk3588-base-pinctrl.dtsi

Changes in v3 :-
  - Rename cma node and phandle names
  - Elaborate the comment to explain 160MiB calculation
  - Move &hdmi_receiver_cma to the rock5b dts file

Changes in v2 :-
  - Fix some of the checkpatch errors and warnings
  - Rename resets, vo1-grf and HPD
  - Move hdmirx_cma node to the rk3588.dtsi file

 .../dts/rockchip/rk3588-base-pinctrl.dtsi     | 14 +++++
 .../arm64/boot/dts/rockchip/rk3588-extra.dtsi | 56 +++++++++++++++++++
 2 files changed, 70 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
index 30db12c4fc82..ca006f5a4c90 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base-pinctrl.dtsi
@@ -594,6 +594,20 @@ hdmim0_tx1_hpd: hdmim0-tx1-hpd {
 				/* hdmim0_tx1_hpd */
 				<1 RK_PA6 5 &pcfg_pull_none>;
 		};
+
+		/omit-if-no-ref/
+		hdmim1_rx: hdmim1-rx {
+			rockchip,pins =
+				/* hdmim1_rx_cec */
+				<3 RK_PD1 5 &pcfg_pull_none>,
+				/* hdmim1_rx_scl */
+				<3 RK_PD2 5 &pcfg_pull_none_smt>,
+				/* hdmim1_rx_sda */
+				<3 RK_PD3 5 &pcfg_pull_none_smt>,
+				/* hdmim1_rx_hpdin */
+				<3 RK_PD4 5 &pcfg_pull_none>;
+		};
+
 		/omit-if-no-ref/
 		hdmim1_rx_cec: hdmim1-rx-cec {
 			rockchip,pins =
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
index 0ce0934ec6b7..96f8ce91eaf4 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi
@@ -7,6 +7,29 @@
 #include "rk3588-extra-pinctrl.dtsi"
 
 / {
+	reserved-memory {
+		#address-cells = <2>;
+		#size-cells = <2>;
+		ranges;
+
+		/*
+		 * The 4k HDMI capture controller works only with 32bit
+		 * phys addresses and doesn't support IOMMU. HDMI RX CMA
+		 * must be reserved below 4GB.
+		 * The size of 160MB was determined as follows:
+		 * (3840 * 2160 pixels) * (4 bytes/pixel) * (2 frames/buffer) / 10^6 = 66MB
+		 * To ensure sufficient support for practical use-cases,
+		 * we doubled the 66MB value.
+		 */
+		hdmi_receiver_cma: hdmi-receiver-cma {
+			compatible = "shared-dma-pool";
+			alloc-ranges = <0x0 0x0 0x0 0xffffffff>;
+			size = <0x0 (160 * 0x100000)>; /* 160MiB */
+			no-map;
+			status = "disabled";
+		};
+	};
+
 	usb_host1_xhci: usb@fc400000 {
 		compatible = "rockchip,rk3588-dwc3", "snps,dwc3";
 		reg = <0x0 0xfc400000 0x0 0x400000>;
@@ -135,6 +158,39 @@ i2s10_8ch: i2s@fde00000 {
 		status = "disabled";
 	};
 
+	hdmi_receiver: hdmi_receiver@fdee0000 {
+		compatible = "rockchip,rk3588-hdmirx-ctrler", "snps,dw-hdmi-rx";
+		reg = <0x0 0xfdee0000 0x0 0x6000>;
+		power-domains = <&power RK3588_PD_VO1>;
+		rockchip,grf = <&sys_grf>;
+		rockchip,vo1-grf = <&vo1_grf>;
+		interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 436 IRQ_TYPE_LEVEL_HIGH 0>,
+			     <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH 0>;
+		interrupt-names = "cec", "hdmi", "dma";
+		clocks = <&cru ACLK_HDMIRX>,
+			 <&cru CLK_HDMIRX_AUD>,
+			 <&cru CLK_CR_PARA>,
+			 <&cru PCLK_HDMIRX>,
+			 <&cru CLK_HDMIRX_REF>,
+			 <&cru PCLK_S_HDMIRX>,
+			 <&cru HCLK_VO1>;
+		clock-names = "aclk",
+			      "audio",
+			      "cr_para",
+			      "pclk",
+			      "ref",
+			      "hclk_s_hdmirx",
+			      "hclk_vo1";
+		resets = <&cru SRST_A_HDMIRX>, <&cru SRST_P_HDMIRX>,
+			 <&cru SRST_HDMIRX_REF>, <&cru SRST_A_HDMIRX_BIU>;
+		reset-names = "axi", "apb", "ref", "biu";
+		memory-region = <&hdmi_receiver_cma>;
+		pinctrl-0 = <&hdmim1_rx>;
+		pinctrl-names = "default";
+		status = "disabled";
+	};
+
 	pcie3x4: pcie@fe150000 {
 		compatible = "rockchip,rk3588-pcie", "rockchip,rk3568-pcie";
 		#address-cells = <3>;
-- 
2.39.2

Re: [PATCH v4 4/4] media: platform: synopsys: Add support for hdmi input driver

[Johan Jonker]

On 7/19/24 14:40, Shreeya Patel wrote:
> Add initial support for the Synopsys DesignWare HDMI RX
> Controller Driver used by Rockchip RK3588. The driver
> supports:
>  - HDMI 1.4b and 2.0 modes (HDMI 4k@60Hz)
>  - RGB888, YUV422, YUV444 and YCC420 pixel formats
>  - CEC
>  - EDID configuration
> 
> The hardware also has Audio and HDCP capabilities, but these are
> not yet supported by the driver.
> 
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Co-developed-by: Dingxian Wen <shawn.wen@rock-chips.com>
> Signed-off-by: Dingxian Wen <shawn.wen@rock-chips.com>
> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> ---
> 
> Changes in v4 :-
>   - Create a separate config option for selecting the EDID
>     and enable it by default
>   - Improve the comment related to DV timings and move it
>     to the side of hdmirx_get_detected_timings
>   - Add 100ms delay before pulling the HPD high
>   - Do not return the detected timings from VIDIOC_G_DV_TIMINGS
>   - Drop the bus info from hdmirx_querycap
>   - If *num_planes != 0 then return 0 in hdmirx_queue_setup
>   - Set queue->min_queued_buffers to 1
>   - Drop q->allow_cache_hints = 0; as it's always 0 by default
>   - Add a comment for q->dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
>   - Drop .read = vb2_fop_read as it's not supported by driver
>   - Remove redundant edid_init_data_600M
>   - Make HPD low when driver is loaded
>   - Add support for reading AVI Infoframe
>   - Remove msg_len checks from hdmirx_cec_transmit
>   - Add info about the CEC compliance test in the cover letter
>   - Add arbitration lost status
>   - Validate the physical address inside the EDID
> 
> Changes in v3 :-
>   - Use v4l2-common helper functions
> 
> Changes in v2 :-
>   - Fix checkpatch --strict warnings
>   - Rename resets, vo1-grf and HPD node names as per the DT changes
> 
>  drivers/media/platform/Kconfig                |    1 +
>  drivers/media/platform/Makefile               |    1 +
>  drivers/media/platform/synopsys/Kconfig       |    3 +
>  drivers/media/platform/synopsys/Makefile      |    2 +
>  .../media/platform/synopsys/hdmirx/Kconfig    |   27 +
>  .../media/platform/synopsys/hdmirx/Makefile   |    4 +
>  .../platform/synopsys/hdmirx/snps_hdmirx.c    | 2763 +++++++++++++++++
>  .../platform/synopsys/hdmirx/snps_hdmirx.h    |  394 +++
>  .../synopsys/hdmirx/snps_hdmirx_cec.c         |  285 ++
>  .../synopsys/hdmirx/snps_hdmirx_cec.h         |   44 +
>  10 files changed, 3524 insertions(+)
>  create mode 100644 drivers/media/platform/synopsys/Kconfig
>  create mode 100644 drivers/media/platform/synopsys/Makefile
>  create mode 100644 drivers/media/platform/synopsys/hdmirx/Kconfig
>  create mode 100644 drivers/media/platform/synopsys/hdmirx/Makefile
>  create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
>  create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.h
>  create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.c
>  create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.h
> 
> diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> index 85d2627776b6..9287faafdce5 100644
> --- a/drivers/media/platform/Kconfig
> +++ b/drivers/media/platform/Kconfig
> @@ -85,6 +85,7 @@ source "drivers/media/platform/rockchip/Kconfig"
>  source "drivers/media/platform/samsung/Kconfig"
>  source "drivers/media/platform/st/Kconfig"
>  source "drivers/media/platform/sunxi/Kconfig"
> +source "drivers/media/platform/synopsys/Kconfig"
>  source "drivers/media/platform/ti/Kconfig"
>  source "drivers/media/platform/verisilicon/Kconfig"
>  source "drivers/media/platform/via/Kconfig"
> diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> index ace4e34483dd..6fd7db0541c7 100644
> --- a/drivers/media/platform/Makefile
> +++ b/drivers/media/platform/Makefile
> @@ -28,6 +28,7 @@ obj-y += rockchip/
>  obj-y += samsung/
>  obj-y += st/
>  obj-y += sunxi/
> +obj-y += synopsys/
>  obj-y += ti/
>  obj-y += verisilicon/
>  obj-y += via/
> diff --git a/drivers/media/platform/synopsys/Kconfig b/drivers/media/platform/synopsys/Kconfig
> new file mode 100644
> index 000000000000..4fd521f78425
> --- /dev/null
> +++ b/drivers/media/platform/synopsys/Kconfig
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +
> +source "drivers/media/platform/synopsys/hdmirx/Kconfig"
> diff --git a/drivers/media/platform/synopsys/Makefile b/drivers/media/platform/synopsys/Makefile
> new file mode 100644
> index 000000000000..3b12c574dd67
> --- /dev/null
> +++ b/drivers/media/platform/synopsys/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +obj-y += hdmirx/
> diff --git a/drivers/media/platform/synopsys/hdmirx/Kconfig b/drivers/media/platform/synopsys/hdmirx/Kconfig
> new file mode 100644
> index 000000000000..ab569e59300f
> --- /dev/null
> +++ b/drivers/media/platform/synopsys/hdmirx/Kconfig
> @@ -0,0 +1,27 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +config VIDEO_SYNOPSYS_HDMIRX
> +	tristate "Synopsys DesignWare HDMI Receiver driver"
> +	depends on VIDEO_DEV
> +	depends on ARCH_ROCKCHIP
> +	select MEDIA_CONTROLLER
> +	select VIDEO_V4L2_SUBDEV_API
> +	select VIDEOBUF2_DMA_CONTIG
> +	select CEC_CORE
> +	select CEC_NOTIFIER
> +	select HDMI
> +	help
> +	  Support for Synopsys HDMI HDMI RX Controller.
> +	  This driver supports HDMI 2.0 version.
> +
> +	  To compile this driver as a module, choose M here. The module
> +	  will be called synopsys_hdmirx.
> +
> +config HDMIRX_LOAD_DEFAULT_EDID
> +	bool "Load default EDID"
> +	depends on VIDEO_SYNOPSYS_HDMIRX
> +	default "y"
> +	help
> +	  Preload the default EDID (Extended Display Identification Data).
> +	  EDID contains information about the capabilities of the display,
> +	  such as supported resolutions, refresh rates, and audio formats.
> diff --git a/drivers/media/platform/synopsys/hdmirx/Makefile b/drivers/media/platform/synopsys/hdmirx/Makefile
> new file mode 100644
> index 000000000000..2fa2d9e25300
> --- /dev/null
> +++ b/drivers/media/platform/synopsys/hdmirx/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +synopsys-hdmirx-objs := snps_hdmirx.o snps_hdmirx_cec.o
> +
> +obj-$(CONFIG_VIDEO_SYNOPSYS_HDMIRX) += synopsys-hdmirx.o
> diff --git a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c

[..]

For FTRACE it is needed that all functions start with the same function prefix.

> +static bool tx_5v_power_present(struct snps_hdmirx_dev *hdmirx_dev)

> +static bool signal_not_lock(struct snps_hdmirx_dev *hdmirx_dev)

> +static bool port_no_link(struct snps_hdmirx_dev *hdmirx_dev)

> +static int wait_reg_bit_status(struct snps_hdmirx_dev *hdmirx_dev, u32 reg,
> +			       u32 bit_mask, u32 expect_val, bool is_grf,
> +			       u32 ms)

> +static void return_all_buffers(struct hdmirx_stream *stream,
> +			       enum vb2_buffer_state state)

> +static void process_signal_change(struct snps_hdmirx_dev *hdmirx_dev)

> +static void avpunit_0_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> +				  int status, bool *handled)

> +static void avpunit_1_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> +				  int status, bool *handled)

> +static void mainunit_0_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> +				   int status, bool *handled)

> +static void mainunit_2_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> +				   int status, bool *handled)

> +static void pkt_2_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> +			      int status, bool *handled)

> +static void scdc_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> +			     int status, bool *handled)

> +static void dma_idle_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> +				 bool *handled)

> +static void line_flag_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> +				  bool *handled)

[..]

> +static int hdmirx_setup_irq(struct snps_hdmirx_dev *hdmirx_dev,
> +			    struct platform_device *pdev)
> +{
> +	struct device *dev = hdmirx_dev->dev;
> +	int ret, irq;
> +
> +	irq = platform_get_irq_byname(pdev, "hdmi");
> +	if (irq < 0) {
> +		dev_err_probe(dev, irq, "failed to get hdmi irq\n");
> +		return irq;
> +	}
> +
> +	irq_set_status_flags(irq, IRQ_NOAUTOEN);
> +
> +	hdmirx_dev->hdmi_irq = irq;
> +	ret = devm_request_irq(dev, irq, hdmirx_hdmi_irq_handler, 0,
> +			       "rk_hdmirx-hdmi", hdmirx_dev);
> +	if (ret) {
> +		dev_err_probe(dev, ret, "failed to request hdmi irq\n");
> +		return ret;
> +	}
> +
> +	irq = platform_get_irq_byname(pdev, "dma");
> +	if (irq < 0) {
> +		dev_err_probe(dev, irq, "failed to get dma irq\n");
> +		return irq;
> +	}
> +
> +	irq_set_status_flags(irq, IRQ_NOAUTOEN);
> +
> +	hdmirx_dev->dma_irq = irq;
> +	ret = devm_request_threaded_irq(dev, irq, NULL, hdmirx_dma_irq_handler,
> +					IRQF_ONESHOT, "rk_hdmirx-dma",
> +					hdmirx_dev);
> +	if (ret) {
> +		dev_err_probe(dev, ret, "failed to request dma irq\n");
> +		return ret;
> +	}
> +
> +	irq = gpiod_to_irq(hdmirx_dev->detect_5v_gpio);
> +	if (irq < 0) {
> +		dev_err_probe(dev, irq, "failed to get hdmirx-5v irq\n");
> +		return irq;
> +	}
> +
> +	irq_set_status_flags(irq, IRQ_NOAUTOEN);
> +
> +	hdmirx_dev->det_irq = irq;
> +	ret = devm_request_irq(dev, irq, hdmirx_5v_det_irq_handler,
> +			       IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
> +			       "rk_hdmirx-5v", hdmirx_dev);
> +	if (ret) {
> +		dev_err_probe(dev, ret, "failed to request hdmirx-5v irq\n");
> +		return ret;
> +	}
> +
> +	return 0;
> +}
> +
> +static int hdmirx_register_cec(struct snps_hdmirx_dev *hdmirx_dev,
> +			       struct platform_device *pdev)
> +{
> +	struct device *dev = hdmirx_dev->dev;
> +	struct hdmirx_cec_data cec_data;
> +	int irq;
> +
> +	irq = platform_get_irq_byname(pdev, "cec");
> +	if (irq < 0) {
> +		dev_err_probe(dev, irq, "failed to get cec irq\n");
> +		return irq;
> +	}
> +
> +	hdmirx_dev->cec_notifier = cec_notifier_conn_register(dev, NULL, NULL);
> +	if (!hdmirx_dev->cec_notifier)
> +		return -EINVAL;
> +
> +	cec_data.hdmirx = hdmirx_dev;
> +	cec_data.dev = hdmirx_dev->dev;
> +	cec_data.ops = &hdmirx_cec_ops;
> +	cec_data.irq = irq;
> +
> +	hdmirx_dev->cec = snps_hdmirx_cec_register(&cec_data);
> +	if (!hdmirx_dev->cec) {
> +		cec_notifier_conn_unregister(hdmirx_dev->cec_notifier);
> +		return -EINVAL;
> +	}
> +
> +	return 0;
> +}
> +
> +static int hdmirx_probe(struct platform_device *pdev)
> +{
> +	struct snps_hdmirx_dev *hdmirx_dev;
> +	struct device *dev = &pdev->dev;
> +	struct v4l2_ctrl_handler *hdl;
> +	struct hdmirx_stream *stream;
> +	struct v4l2_device *v4l2_dev;
> +	int ret;
> +
> +	hdmirx_dev = devm_kzalloc(dev, sizeof(*hdmirx_dev), GFP_KERNEL);
> +	if (!hdmirx_dev)
> +		return -ENOMEM;
> +
> +	ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
> +	if (ret)
> +		return ret;
> +
> +	hdmirx_dev->dev = dev;
> +	dev_set_drvdata(dev, hdmirx_dev);
> +
> +	ret = hdmirx_parse_dt(hdmirx_dev);
> +	if (ret)
> +		return ret;
> +
> +	ret = hdmirx_setup_irq(hdmirx_dev, pdev);
> +	if (ret)
> +		return ret;
> +
> +	hdmirx_dev->regs = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(hdmirx_dev->regs))
> +		return dev_err_probe(dev, PTR_ERR(hdmirx_dev->regs),
> +				     "failed to remap regs resource\n");
> +
> +	mutex_init(&hdmirx_dev->stream_lock);
> +	mutex_init(&hdmirx_dev->work_lock);
> +	spin_lock_init(&hdmirx_dev->rst_lock);
> +
> +	init_completion(&hdmirx_dev->cr_write_done);
> +	init_completion(&hdmirx_dev->timer_base_lock);
> +	init_completion(&hdmirx_dev->avi_pkt_rcv);
> +
> +	INIT_WORK(&hdmirx_dev->work_wdt_config, hdmirx_work_wdt_config);
> +	INIT_DELAYED_WORK(&hdmirx_dev->delayed_work_hotplug,
> +			  hdmirx_delayed_work_hotplug);
> +	INIT_DELAYED_WORK(&hdmirx_dev->delayed_work_res_change,
> +			  hdmirx_delayed_work_res_change);
> +	INIT_DELAYED_WORK(&hdmirx_dev->delayed_work_heartbeat,
> +			  hdmirx_delayed_work_heartbeat);
> +
> +	hdmirx_dev->cur_fmt_fourcc = V4L2_PIX_FMT_BGR24;
> +	hdmirx_dev->timings = cea640x480;
> +
> +	hdmirx_enable(dev);
> +	hdmirx_init(hdmirx_dev);
> +
> +	v4l2_dev = &hdmirx_dev->v4l2_dev;
> +	strscpy(v4l2_dev->name, dev_name(dev), sizeof(v4l2_dev->name));
> +
> +	hdl = &hdmirx_dev->hdl;
> +	v4l2_ctrl_handler_init(hdl, 1);
> +
> +	hdmirx_dev->detect_tx_5v_ctrl = v4l2_ctrl_new_std(hdl, NULL,
> +							  V4L2_CID_DV_RX_POWER_PRESENT,
> +							  0, 1, 0, 0);
> +
> +	hdmirx_dev->rgb_range = v4l2_ctrl_new_std_menu(hdl, 0,
> +						       V4L2_CID_DV_RX_RGB_RANGE,
> +						       V4L2_DV_RGB_RANGE_FULL, 0,
> +						       V4L2_DV_RGB_RANGE_AUTO);
> +
> +	hdmirx_dev->rgb_range->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> +
> +	if (hdl->error) {
> +		dev_err(dev, "v4l2 ctrl handler init failed\n");
> +		ret = hdl->error;
> +		goto err_pm;
> +	}
> +	hdmirx_dev->v4l2_dev.ctrl_handler = hdl;
> +
> +	ret = v4l2_device_register(dev, &hdmirx_dev->v4l2_dev);
> +	if (ret < 0) {
> +		dev_err(dev, "register v4l2 device failed\n");
> +		goto err_hdl;
> +	}
> +
> +	stream = &hdmirx_dev->stream;
> +	stream->hdmirx_dev = hdmirx_dev;
> +	ret = hdmirx_register_stream_vdev(stream);
> +	if (ret < 0) {
> +		dev_err(dev, "register video device failed\n");
> +		goto err_unreg_v4l2_dev;
> +	}
> +
> +	ret = hdmirx_register_cec(hdmirx_dev, pdev);
> +	if (ret)
> +		goto err_unreg_video_dev;
> +
> +	hdmirx_load_default_edid(hdmirx_dev);
> +
> +	hdmirx_enable_irq(dev);
> +
> +	return 0;
> +
> +err_unreg_video_dev:
> +	video_unregister_device(&hdmirx_dev->stream.vdev);
> +err_unreg_v4l2_dev:
> +	v4l2_device_unregister(&hdmirx_dev->v4l2_dev);
> +err_hdl:
> +	v4l2_ctrl_handler_free(&hdmirx_dev->hdl);
> +err_pm:
> +	hdmirx_disable(dev);
> +
> +	return ret;
> +}
> +
> +static void hdmirx_remove(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct snps_hdmirx_dev *hdmirx_dev = dev_get_drvdata(dev);
> +
> +	snps_hdmirx_cec_unregister(hdmirx_dev->cec);
> +	cec_notifier_conn_unregister(hdmirx_dev->cec_notifier);
> +
> +	hdmirx_disable_irq(dev);
> +
> +	video_unregister_device(&hdmirx_dev->stream.vdev);
> +	v4l2_ctrl_handler_free(&hdmirx_dev->hdl);
> +	v4l2_device_unregister(&hdmirx_dev->v4l2_dev);
> +
> +	hdmirx_disable(dev);
> +
> +	reset_control_bulk_assert(HDMIRX_NUM_RST, hdmirx_dev->resets);
> +
> +	of_reserved_mem_device_release(dev);
> +}
> +
> +static const struct of_device_id hdmirx_id[] = {
> +	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> +	{ },
> +};
> +MODULE_DEVICE_TABLE(of, hdmirx_id);
> +
> +static struct platform_driver hdmirx_driver = {
> +	.probe = hdmirx_probe,
> +	.remove = hdmirx_remove,
> +	.driver = {
> +		.name = "snps_hdmirx",
> +		.of_match_table = hdmirx_id,
> +		.pm = &snps_hdmirx_pm_ops,
> +	}
> +};
> +module_platform_driver(hdmirx_driver);
> +
> +MODULE_DESCRIPTION("Rockchip HDMI Receiver Driver");

While the file is called snps_hdmirx.c and the driver name is "snps_hdmirx" the module description calls it a Rockchip driver.
This patch serie somewhat hints at the use of multiple SoCs and possible multiple brands then a more clear separation between common snps and Rockchip (rk3588) SoC specific is needed?

Johan

> +MODULE_AUTHOR("Dingxian Wen <shawn.wen@rock-chips.com>");
> +MODULE_AUTHOR("Shreeya Patel <shreeya.patel@collabora.com>");
> +MODULE_LICENSE("GPL");

Re: [PATCH v4 4/4] media: platform: synopsys: Add support for hdmi input driver

[Shreeya Patel]

On Saturday, July 20, 2024 17:03 IST, Johan Jonker <jbx6244@yandex.com> wrote:

Hi Johan,

Please see my response below.

> 
> 
> On 7/19/24 14:40, Shreeya Patel wrote:
> > Add initial support for the Synopsys DesignWare HDMI RX
> > Controller Driver used by Rockchip RK3588. The driver
> > supports:
> >  - HDMI 1.4b and 2.0 modes (HDMI 4k@60Hz)
> >  - RGB888, YUV422, YUV444 and YCC420 pixel formats
> >  - CEC
> >  - EDID configuration
> > 
> > The hardware also has Audio and HDCP capabilities, but these are
> > not yet supported by the driver.
> > 
> > Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > Co-developed-by: Dingxian Wen <shawn.wen@rock-chips.com>
> > Signed-off-by: Dingxian Wen <shawn.wen@rock-chips.com>
> > Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> > ---
> > 
> > Changes in v4 :-
> >   - Create a separate config option for selecting the EDID
> >     and enable it by default
> >   - Improve the comment related to DV timings and move it
> >     to the side of hdmirx_get_detected_timings
> >   - Add 100ms delay before pulling the HPD high
> >   - Do not return the detected timings from VIDIOC_G_DV_TIMINGS
> >   - Drop the bus info from hdmirx_querycap
> >   - If *num_planes != 0 then return 0 in hdmirx_queue_setup
> >   - Set queue->min_queued_buffers to 1
> >   - Drop q->allow_cache_hints = 0; as it's always 0 by default
> >   - Add a comment for q->dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
> >   - Drop .read = vb2_fop_read as it's not supported by driver
> >   - Remove redundant edid_init_data_600M
> >   - Make HPD low when driver is loaded
> >   - Add support for reading AVI Infoframe
> >   - Remove msg_len checks from hdmirx_cec_transmit
> >   - Add info about the CEC compliance test in the cover letter
> >   - Add arbitration lost status
> >   - Validate the physical address inside the EDID
> > 
> > Changes in v3 :-
> >   - Use v4l2-common helper functions
> > 
> > Changes in v2 :-
> >   - Fix checkpatch --strict warnings
> >   - Rename resets, vo1-grf and HPD node names as per the DT changes
> > 
> >  drivers/media/platform/Kconfig                |    1 +
> >  drivers/media/platform/Makefile               |    1 +
> >  drivers/media/platform/synopsys/Kconfig       |    3 +
> >  drivers/media/platform/synopsys/Makefile      |    2 +
> >  .../media/platform/synopsys/hdmirx/Kconfig    |   27 +
> >  .../media/platform/synopsys/hdmirx/Makefile   |    4 +
> >  .../platform/synopsys/hdmirx/snps_hdmirx.c    | 2763 +++++++++++++++++
> >  .../platform/synopsys/hdmirx/snps_hdmirx.h    |  394 +++
> >  .../synopsys/hdmirx/snps_hdmirx_cec.c         |  285 ++
> >  .../synopsys/hdmirx/snps_hdmirx_cec.h         |   44 +
> >  10 files changed, 3524 insertions(+)
> >  create mode 100644 drivers/media/platform/synopsys/Kconfig
> >  create mode 100644 drivers/media/platform/synopsys/Makefile
> >  create mode 100644 drivers/media/platform/synopsys/hdmirx/Kconfig
> >  create mode 100644 drivers/media/platform/synopsys/hdmirx/Makefile
> >  create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> >  create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.h
> >  create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.c
> >  create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.h
> > 
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index 85d2627776b6..9287faafdce5 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -85,6 +85,7 @@ source "drivers/media/platform/rockchip/Kconfig"
> >  source "drivers/media/platform/samsung/Kconfig"
> >  source "drivers/media/platform/st/Kconfig"
> >  source "drivers/media/platform/sunxi/Kconfig"
> > +source "drivers/media/platform/synopsys/Kconfig"
> >  source "drivers/media/platform/ti/Kconfig"
> >  source "drivers/media/platform/verisilicon/Kconfig"
> >  source "drivers/media/platform/via/Kconfig"
> > diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
> > index ace4e34483dd..6fd7db0541c7 100644
> > --- a/drivers/media/platform/Makefile
> > +++ b/drivers/media/platform/Makefile
> > @@ -28,6 +28,7 @@ obj-y += rockchip/
> >  obj-y += samsung/
> >  obj-y += st/
> >  obj-y += sunxi/
> > +obj-y += synopsys/
> >  obj-y += ti/
> >  obj-y += verisilicon/
> >  obj-y += via/
> > diff --git a/drivers/media/platform/synopsys/Kconfig b/drivers/media/platform/synopsys/Kconfig
> > new file mode 100644
> > index 000000000000..4fd521f78425
> > --- /dev/null
> > +++ b/drivers/media/platform/synopsys/Kconfig
> > @@ -0,0 +1,3 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +
> > +source "drivers/media/platform/synopsys/hdmirx/Kconfig"
> > diff --git a/drivers/media/platform/synopsys/Makefile b/drivers/media/platform/synopsys/Makefile
> > new file mode 100644
> > index 000000000000..3b12c574dd67
> > --- /dev/null
> > +++ b/drivers/media/platform/synopsys/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +obj-y += hdmirx/
> > diff --git a/drivers/media/platform/synopsys/hdmirx/Kconfig b/drivers/media/platform/synopsys/hdmirx/Kconfig
> > new file mode 100644
> > index 000000000000..ab569e59300f
> > --- /dev/null
> > +++ b/drivers/media/platform/synopsys/hdmirx/Kconfig
> > @@ -0,0 +1,27 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +config VIDEO_SYNOPSYS_HDMIRX
> > +	tristate "Synopsys DesignWare HDMI Receiver driver"
> > +	depends on VIDEO_DEV
> > +	depends on ARCH_ROCKCHIP
> > +	select MEDIA_CONTROLLER
> > +	select VIDEO_V4L2_SUBDEV_API
> > +	select VIDEOBUF2_DMA_CONTIG
> > +	select CEC_CORE
> > +	select CEC_NOTIFIER
> > +	select HDMI
> > +	help
> > +	  Support for Synopsys HDMI HDMI RX Controller.
> > +	  This driver supports HDMI 2.0 version.
> > +
> > +	  To compile this driver as a module, choose M here. The module
> > +	  will be called synopsys_hdmirx.
> > +
> > +config HDMIRX_LOAD_DEFAULT_EDID
> > +	bool "Load default EDID"
> > +	depends on VIDEO_SYNOPSYS_HDMIRX
> > +	default "y"
> > +	help
> > +	  Preload the default EDID (Extended Display Identification Data).
> > +	  EDID contains information about the capabilities of the display,
> > +	  such as supported resolutions, refresh rates, and audio formats.
> > diff --git a/drivers/media/platform/synopsys/hdmirx/Makefile b/drivers/media/platform/synopsys/hdmirx/Makefile
> > new file mode 100644
> > index 000000000000..2fa2d9e25300
> > --- /dev/null
> > +++ b/drivers/media/platform/synopsys/hdmirx/Makefile
> > @@ -0,0 +1,4 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +synopsys-hdmirx-objs := snps_hdmirx.o snps_hdmirx_cec.o
> > +
> > +obj-$(CONFIG_VIDEO_SYNOPSYS_HDMIRX) += synopsys-hdmirx.o
> > diff --git a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> 
> [..]
> 
> For FTRACE it is needed that all functions start with the same function prefix.
> 
> > +static bool tx_5v_power_present(struct snps_hdmirx_dev *hdmirx_dev)
> 
> > +static bool signal_not_lock(struct snps_hdmirx_dev *hdmirx_dev)
> 
> > +static bool port_no_link(struct snps_hdmirx_dev *hdmirx_dev)
> 
> > +static int wait_reg_bit_status(struct snps_hdmirx_dev *hdmirx_dev, u32 reg,
> > +			       u32 bit_mask, u32 expect_val, bool is_grf,
> > +			       u32 ms)
> 
> > +static void return_all_buffers(struct hdmirx_stream *stream,
> > +			       enum vb2_buffer_state state)
> 
> > +static void process_signal_change(struct snps_hdmirx_dev *hdmirx_dev)
> 
> > +static void avpunit_0_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> > +				  int status, bool *handled)
> 
> > +static void avpunit_1_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> > +				  int status, bool *handled)
> 
> > +static void mainunit_0_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> > +				   int status, bool *handled)
> 
> > +static void mainunit_2_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> > +				   int status, bool *handled)
> 
> > +static void pkt_2_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> > +			      int status, bool *handled)
> 
> > +static void scdc_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> > +			     int status, bool *handled)
> 
> > +static void dma_idle_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> > +				 bool *handled)
> 
> > +static void line_flag_int_handler(struct snps_hdmirx_dev *hdmirx_dev,
> > +				  bool *handled)
> 
> [..]
> 
> > +static int hdmirx_setup_irq(struct snps_hdmirx_dev *hdmirx_dev,
> > +			    struct platform_device *pdev)
> > +{
> > +	struct device *dev = hdmirx_dev->dev;
> > +	int ret, irq;
> > +
> > +	irq = platform_get_irq_byname(pdev, "hdmi");
> > +	if (irq < 0) {
> > +		dev_err_probe(dev, irq, "failed to get hdmi irq\n");
> > +		return irq;
> > +	}
> > +
> > +	irq_set_status_flags(irq, IRQ_NOAUTOEN);
> > +
> > +	hdmirx_dev->hdmi_irq = irq;
> > +	ret = devm_request_irq(dev, irq, hdmirx_hdmi_irq_handler, 0,
> > +			       "rk_hdmirx-hdmi", hdmirx_dev);
> > +	if (ret) {
> > +		dev_err_probe(dev, ret, "failed to request hdmi irq\n");
> > +		return ret;
> > +	}
> > +
> > +	irq = platform_get_irq_byname(pdev, "dma");
> > +	if (irq < 0) {
> > +		dev_err_probe(dev, irq, "failed to get dma irq\n");
> > +		return irq;
> > +	}
> > +
> > +	irq_set_status_flags(irq, IRQ_NOAUTOEN);
> > +
> > +	hdmirx_dev->dma_irq = irq;
> > +	ret = devm_request_threaded_irq(dev, irq, NULL, hdmirx_dma_irq_handler,
> > +					IRQF_ONESHOT, "rk_hdmirx-dma",
> > +					hdmirx_dev);
> > +	if (ret) {
> > +		dev_err_probe(dev, ret, "failed to request dma irq\n");
> > +		return ret;
> > +	}
> > +
> > +	irq = gpiod_to_irq(hdmirx_dev->detect_5v_gpio);
> > +	if (irq < 0) {
> > +		dev_err_probe(dev, irq, "failed to get hdmirx-5v irq\n");
> > +		return irq;
> > +	}
> > +
> > +	irq_set_status_flags(irq, IRQ_NOAUTOEN);
> > +
> > +	hdmirx_dev->det_irq = irq;
> > +	ret = devm_request_irq(dev, irq, hdmirx_5v_det_irq_handler,
> > +			       IRQF_TRIGGER_FALLING | IRQF_TRIGGER_RISING,
> > +			       "rk_hdmirx-5v", hdmirx_dev);
> > +	if (ret) {
> > +		dev_err_probe(dev, ret, "failed to request hdmirx-5v irq\n");
> > +		return ret;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int hdmirx_register_cec(struct snps_hdmirx_dev *hdmirx_dev,
> > +			       struct platform_device *pdev)
> > +{
> > +	struct device *dev = hdmirx_dev->dev;
> > +	struct hdmirx_cec_data cec_data;
> > +	int irq;
> > +
> > +	irq = platform_get_irq_byname(pdev, "cec");
> > +	if (irq < 0) {
> > +		dev_err_probe(dev, irq, "failed to get cec irq\n");
> > +		return irq;
> > +	}
> > +
> > +	hdmirx_dev->cec_notifier = cec_notifier_conn_register(dev, NULL, NULL);
> > +	if (!hdmirx_dev->cec_notifier)
> > +		return -EINVAL;
> > +
> > +	cec_data.hdmirx = hdmirx_dev;
> > +	cec_data.dev = hdmirx_dev->dev;
> > +	cec_data.ops = &hdmirx_cec_ops;
> > +	cec_data.irq = irq;
> > +
> > +	hdmirx_dev->cec = snps_hdmirx_cec_register(&cec_data);
> > +	if (!hdmirx_dev->cec) {
> > +		cec_notifier_conn_unregister(hdmirx_dev->cec_notifier);
> > +		return -EINVAL;
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int hdmirx_probe(struct platform_device *pdev)
> > +{
> > +	struct snps_hdmirx_dev *hdmirx_dev;
> > +	struct device *dev = &pdev->dev;
> > +	struct v4l2_ctrl_handler *hdl;
> > +	struct hdmirx_stream *stream;
> > +	struct v4l2_device *v4l2_dev;
> > +	int ret;
> > +
> > +	hdmirx_dev = devm_kzalloc(dev, sizeof(*hdmirx_dev), GFP_KERNEL);
> > +	if (!hdmirx_dev)
> > +		return -ENOMEM;
> > +
> > +	ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
> > +	if (ret)
> > +		return ret;
> > +
> > +	hdmirx_dev->dev = dev;
> > +	dev_set_drvdata(dev, hdmirx_dev);
> > +
> > +	ret = hdmirx_parse_dt(hdmirx_dev);
> > +	if (ret)
> > +		return ret;
> > +
> > +	ret = hdmirx_setup_irq(hdmirx_dev, pdev);
> > +	if (ret)
> > +		return ret;
> > +
> > +	hdmirx_dev->regs = devm_platform_ioremap_resource(pdev, 0);
> > +	if (IS_ERR(hdmirx_dev->regs))
> > +		return dev_err_probe(dev, PTR_ERR(hdmirx_dev->regs),
> > +				     "failed to remap regs resource\n");
> > +
> > +	mutex_init(&hdmirx_dev->stream_lock);
> > +	mutex_init(&hdmirx_dev->work_lock);
> > +	spin_lock_init(&hdmirx_dev->rst_lock);
> > +
> > +	init_completion(&hdmirx_dev->cr_write_done);
> > +	init_completion(&hdmirx_dev->timer_base_lock);
> > +	init_completion(&hdmirx_dev->avi_pkt_rcv);
> > +
> > +	INIT_WORK(&hdmirx_dev->work_wdt_config, hdmirx_work_wdt_config);
> > +	INIT_DELAYED_WORK(&hdmirx_dev->delayed_work_hotplug,
> > +			  hdmirx_delayed_work_hotplug);
> > +	INIT_DELAYED_WORK(&hdmirx_dev->delayed_work_res_change,
> > +			  hdmirx_delayed_work_res_change);
> > +	INIT_DELAYED_WORK(&hdmirx_dev->delayed_work_heartbeat,
> > +			  hdmirx_delayed_work_heartbeat);
> > +
> > +	hdmirx_dev->cur_fmt_fourcc = V4L2_PIX_FMT_BGR24;
> > +	hdmirx_dev->timings = cea640x480;
> > +
> > +	hdmirx_enable(dev);
> > +	hdmirx_init(hdmirx_dev);
> > +
> > +	v4l2_dev = &hdmirx_dev->v4l2_dev;
> > +	strscpy(v4l2_dev->name, dev_name(dev), sizeof(v4l2_dev->name));
> > +
> > +	hdl = &hdmirx_dev->hdl;
> > +	v4l2_ctrl_handler_init(hdl, 1);
> > +
> > +	hdmirx_dev->detect_tx_5v_ctrl = v4l2_ctrl_new_std(hdl, NULL,
> > +							  V4L2_CID_DV_RX_POWER_PRESENT,
> > +							  0, 1, 0, 0);
> > +
> > +	hdmirx_dev->rgb_range = v4l2_ctrl_new_std_menu(hdl, 0,
> > +						       V4L2_CID_DV_RX_RGB_RANGE,
> > +						       V4L2_DV_RGB_RANGE_FULL, 0,
> > +						       V4L2_DV_RGB_RANGE_AUTO);
> > +
> > +	hdmirx_dev->rgb_range->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > +
> > +	if (hdl->error) {
> > +		dev_err(dev, "v4l2 ctrl handler init failed\n");
> > +		ret = hdl->error;
> > +		goto err_pm;
> > +	}
> > +	hdmirx_dev->v4l2_dev.ctrl_handler = hdl;
> > +
> > +	ret = v4l2_device_register(dev, &hdmirx_dev->v4l2_dev);
> > +	if (ret < 0) {
> > +		dev_err(dev, "register v4l2 device failed\n");
> > +		goto err_hdl;
> > +	}
> > +
> > +	stream = &hdmirx_dev->stream;
> > +	stream->hdmirx_dev = hdmirx_dev;
> > +	ret = hdmirx_register_stream_vdev(stream);
> > +	if (ret < 0) {
> > +		dev_err(dev, "register video device failed\n");
> > +		goto err_unreg_v4l2_dev;
> > +	}
> > +
> > +	ret = hdmirx_register_cec(hdmirx_dev, pdev);
> > +	if (ret)
> > +		goto err_unreg_video_dev;
> > +
> > +	hdmirx_load_default_edid(hdmirx_dev);
> > +
> > +	hdmirx_enable_irq(dev);
> > +
> > +	return 0;
> > +
> > +err_unreg_video_dev:
> > +	video_unregister_device(&hdmirx_dev->stream.vdev);
> > +err_unreg_v4l2_dev:
> > +	v4l2_device_unregister(&hdmirx_dev->v4l2_dev);
> > +err_hdl:
> > +	v4l2_ctrl_handler_free(&hdmirx_dev->hdl);
> > +err_pm:
> > +	hdmirx_disable(dev);
> > +
> > +	return ret;
> > +}
> > +
> > +static void hdmirx_remove(struct platform_device *pdev)
> > +{
> > +	struct device *dev = &pdev->dev;
> > +	struct snps_hdmirx_dev *hdmirx_dev = dev_get_drvdata(dev);
> > +
> > +	snps_hdmirx_cec_unregister(hdmirx_dev->cec);
> > +	cec_notifier_conn_unregister(hdmirx_dev->cec_notifier);
> > +
> > +	hdmirx_disable_irq(dev);
> > +
> > +	video_unregister_device(&hdmirx_dev->stream.vdev);
> > +	v4l2_ctrl_handler_free(&hdmirx_dev->hdl);
> > +	v4l2_device_unregister(&hdmirx_dev->v4l2_dev);
> > +
> > +	hdmirx_disable(dev);
> > +
> > +	reset_control_bulk_assert(HDMIRX_NUM_RST, hdmirx_dev->resets);
> > +
> > +	of_reserved_mem_device_release(dev);
> > +}
> > +
> > +static const struct of_device_id hdmirx_id[] = {
> > +	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, hdmirx_id);
> > +
> > +static struct platform_driver hdmirx_driver = {
> > +	.probe = hdmirx_probe,
> > +	.remove = hdmirx_remove,
> > +	.driver = {
> > +		.name = "snps_hdmirx",
> > +		.of_match_table = hdmirx_id,
> > +		.pm = &snps_hdmirx_pm_ops,
> > +	}
> > +};
> > +module_platform_driver(hdmirx_driver);
> > +
> > +MODULE_DESCRIPTION("Rockchip HDMI Receiver Driver");
> 
> While the file is called snps_hdmirx.c and the driver name is "snps_hdmirx" the module description calls it a Rockchip driver.
> This patch serie somewhat hints at the use of multiple SoCs and possible multiple brands then a more clear separation between common snps and Rockchip (rk3588) SoC specific is needed?
> 

This driver was originally developed by Rockchip, and we fixed a few issues
and cleaned it up. As I said, the driver has only been tested on the Rock5B so far,
but we believe it could also work with the Synopsys IP on other SoCs in the future.
Hence, I renamed almost everything from rockchip to synopsys.

However, I missed changing the MODULE_DESCRIPTION here, and it should be
"Synopsys HDMI RX Controller Driver." I'll make the change in v5.


Thanks,
Shreeya Patel

> Johan
> 
> > +MODULE_AUTHOR("Dingxian Wen <shawn.wen@rock-chips.com>");
> > +MODULE_AUTHOR("Shreeya Patel <shreeya.patel@collabora.com>");
> > +MODULE_LICENSE("GPL");

Re: [PATCH v4 4/4] media: platform: synopsys: Add support for hdmi input driver

[George Stark]

Hello everybody

On 7/19/24 15:40, Shreeya Patel wrote:
> Add initial support for the Synopsys DesignWare HDMI RX
> Controller Driver used by Rockchip RK3588. The driver
> supports:
>   - HDMI 1.4b and 2.0 modes (HDMI 4k@60Hz)
>   - RGB888, YUV422, YUV444 and YCC420 pixel formats
>   - CEC
>   - EDID configuration
> 
> The hardware also has Audio and HDCP capabilities, but these are
> not yet supported by the driver.
> 
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Co-developed-by: Dingxian Wen <shawn.wen@rock-chips.com>
> Signed-off-by: Dingxian Wen <shawn.wen@rock-chips.com>
> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> ---
> 
> Changes in v4 :-
>    - Create a separate config option for selecting the EDID
>      and enable it by default
>    - Improve the comment related to DV timings and move it
>      to the side of hdmirx_get_detected_timings
>    - Add 100ms delay before pulling the HPD high
>    - Do not return the detected timings from VIDIOC_G_DV_TIMINGS
>    - Drop the bus info from hdmirx_querycap
>    - If *num_planes != 0 then return 0 in hdmirx_queue_setup
>    - Set queue->min_queued_buffers to 1
>    - Drop q->allow_cache_hints = 0; as it's always 0 by default
>    - Add a comment for q->dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
>    - Drop .read = vb2_fop_read as it's not supported by driver
>    - Remove redundant edid_init_data_600M
>    - Make HPD low when driver is loaded
>    - Add support for reading AVI Infoframe
>    - Remove msg_len checks from hdmirx_cec_transmit
>    - Add info about the CEC compliance test in the cover letter
>    - Add arbitration lost status
>    - Validate the physical address inside the EDID
> 
> Changes in v3 :-
>    - Use v4l2-common helper functions
> 
> Changes in v2 :-
>    - Fix checkpatch --strict warnings
>    - Rename resets, vo1-grf and HPD node names as per the DT changes
> 
>   drivers/media/platform/Kconfig                |    1 +
>   drivers/media/platform/Makefile               |    1 +
>   drivers/media/platform/synopsys/Kconfig       |    3 +
>   drivers/media/platform/synopsys/Makefile      |    2 +
>   .../media/platform/synopsys/hdmirx/Kconfig    |   27 +
>   .../media/platform/synopsys/hdmirx/Makefile   |    4 +
>   .../platform/synopsys/hdmirx/snps_hdmirx.c    | 2763 +++++++++++++++++
>   .../platform/synopsys/hdmirx/snps_hdmirx.h    |  394 +++
>   .../synopsys/hdmirx/snps_hdmirx_cec.c         |  285 ++
>   .../synopsys/hdmirx/snps_hdmirx_cec.h         |   44 +
>   10 files changed, 3524 insertions(+)
>   create mode 100644 drivers/media/platform/synopsys/Kconfig
>   create mode 100644 drivers/media/platform/synopsys/Makefile
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/Kconfig
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/Makefile
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.h
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.c
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.h
> 
...
> diff --git a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> new file mode 100644
> index 000000000000..1dfecf256393
> --- /dev/null
> +++ b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> @@ -0,0 +1,2763 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*

...

> +}
> +
> +static int hdmirx_probe(struct platform_device *pdev)
> +{
> +	struct snps_hdmirx_dev *hdmirx_dev;
> +	struct device *dev = &pdev->dev;
> +	struct v4l2_ctrl_handler *hdl;
> +	struct hdmirx_stream *stream;
> +	struct v4l2_device *v4l2_dev;
> +	int ret;
> +
> +	hdmirx_dev = devm_kzalloc(dev, sizeof(*hdmirx_dev), GFP_KERNEL);
> +	if (!hdmirx_dev)
> +		return -ENOMEM;
> +
> +	ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(32));
> +	if (ret)
> +		return ret;
> +
> +	hdmirx_dev->dev = dev;
> +	dev_set_drvdata(dev, hdmirx_dev);
> +
> +	ret = hdmirx_parse_dt(hdmirx_dev);
> +	if (ret)
> +		return ret;
> +
> +	ret = hdmirx_setup_irq(hdmirx_dev, pdev);
> +	if (ret)
> +		return ret;
> +
> +	hdmirx_dev->regs = devm_platform_ioremap_resource(pdev, 0);
> +	if (IS_ERR(hdmirx_dev->regs))
> +		return dev_err_probe(dev, PTR_ERR(hdmirx_dev->regs),
> +				     "failed to remap regs resource\n");
> +
> +	mutex_init(&hdmirx_dev->stream_lock);
> +	mutex_init(&hdmirx_dev->work_lock);


AFAIK there's no unified opinion on droping mutex_destroy.
Is it so accepted in media subsystem or should we used devm_mutex_init?


 > +	spin_lock_init(&hdmirx_dev->rst_lock);
 > +
 > +	init_completion(&hdmirx_dev->cr_write_done);
 > +	init_completion(&hdmirx_dev->timer_base_lock);
 > +	init_completion(&hdmirx_dev->avi_pkt_rcv);
 > +
 > +	INIT_WORK(&hdmirx_dev->work_wdt_config, hdmirx_work_wdt_config);
 > +	INIT_DELAYED_WORK(&hdmirx_dev->delayed_work_hotplug,
 > +			  hdmirx_delayed_work_hotplug);
 > +	INIT_DELAYED_WORK(&hdmirx_dev->delayed_work_res_change,
 > +			  hdmirx_delayed_work_res_change);
 > +	INIT_DELAYED_WORK(&hdmirx_dev->delayed_work_heartbeat,
 > +			  hdmirx_delayed_work_heartbeat);
 > +
 > +	hdmirx_dev->cur_fmt_fourcc = V4L2_PIX_FMT_BGR24;
 > +	hdmirx_dev->timings = cea640x480;
 > +
 > +	hdmirx_enable(dev);
 > +	hdmirx_init(hdmirx_dev);
 > +
 > +	v4l2_dev = &hdmirx_dev->v4l2_dev;
 > +	strscpy(v4l2_dev->name, dev_name(dev), sizeof(v4l2_dev->name));
 > +
 > +	hdl = &hdmirx_dev->hdl;
 > +	v4l2_ctrl_handler_init(hdl, 1);
 > +
 > +	hdmirx_dev->detect_tx_5v_ctrl = v4l2_ctrl_new_std(hdl, NULL,
 > +							  V4L2_CID_DV_RX_POWER_PRESENT,
 > +							  0, 1, 0, 0);
 > +
 > +	hdmirx_dev->rgb_range = v4l2_ctrl_new_std_menu(hdl, 0,
 > +						       V4L2_CID_DV_RX_RGB_RANGE,
 > +						       V4L2_DV_RGB_RANGE_FULL, 0,
 > +						       V4L2_DV_RGB_RANGE_AUTO);
 > +
 > +	hdmirx_dev->rgb_range->flags |= V4L2_CTRL_FLAG_READ_ONLY;
 > +
 > +	if (hdl->error) {
 > +		dev_err(dev, "v4l2 ctrl handler init failed\n");
 > +		ret = hdl->error;
 > +		goto err_pm;
 > +	}
 > +	hdmirx_dev->v4l2_dev.ctrl_handler = hdl;
 > +
 > +	ret = v4l2_device_register(dev, &hdmirx_dev->v4l2_dev);
 > +	if (ret < 0) {
 > +		dev_err(dev, "register v4l2 device failed\n");
 > +		goto err_hdl;
 > +	}
 > +
 > +	stream = &hdmirx_dev->stream;
 > +	stream->hdmirx_dev = hdmirx_dev;
 > +	ret = hdmirx_register_stream_vdev(stream);
 > +	if (ret < 0) {
 > +		dev_err(dev, "register video device failed\n");
 > +		goto err_unreg_v4l2_dev;
 > +	}
 > +
 > +	ret = hdmirx_register_cec(hdmirx_dev, pdev);
 > +	if (ret)
 > +		goto err_unreg_video_dev;
 > +
 > +	hdmirx_load_default_edid(hdmirx_dev);
 > +
 > +	hdmirx_enable_irq(dev);
 > +
 > +	return 0;
 > +
 > +err_unreg_video_dev:
 > +	video_unregister_device(&hdmirx_dev->stream.vdev);
 > +err_unreg_v4l2_dev:
 > +	v4l2_device_unregister(&hdmirx_dev->v4l2_dev);
 > +err_hdl:
 > +	v4l2_ctrl_handler_free(&hdmirx_dev->hdl);
 > +err_pm:
 > +	hdmirx_disable(dev);
 > +
 > +	return ret;
 > +}

...

-- 
Best regards
George

Re: [PATCH v4 4/4] media: platform: synopsys: Add support for hdmi input driver

[Hans Verkuil]

On 19/07/2024 14:40, Shreeya Patel wrote:
> Add initial support for the Synopsys DesignWare HDMI RX
> Controller Driver used by Rockchip RK3588. The driver
> supports:
>  - HDMI 1.4b and 2.0 modes (HDMI 4k@60Hz)
>  - RGB888, YUV422, YUV444 and YCC420 pixel formats
>  - CEC
>  - EDID configuration
> 
> The hardware also has Audio and HDCP capabilities, but these are
> not yet supported by the driver.

FYI: if you want to add HDCP support, then please contact me. I have code
available for that (i.e. the public API part), although it is out of date.

But if you want to enable HDCP in this driver, then I would be very happy
to clean it up and post patches for that. It is something we (i.e. Cisco)
have been using for several years now in out-of-tree drivers.

I will try to review this patch in the next few days.

Regards,

	Hans

Re: [PATCH v4 4/4] media: platform: synopsys: Add support for hdmi input driver

[Shreeya Patel]

On Sunday, July 21, 2024 14:21 IST, Hans Verkuil <hverkuil@xs4all.nl> wrote:

Hi Hans,

> On 19/07/2024 14:40, Shreeya Patel wrote:
> > Add initial support for the Synopsys DesignWare HDMI RX
> > Controller Driver used by Rockchip RK3588. The driver
> > supports:
> >  - HDMI 1.4b and 2.0 modes (HDMI 4k@60Hz)
> >  - RGB888, YUV422, YUV444 and YCC420 pixel formats
> >  - CEC
> >  - EDID configuration
> > 
> > The hardware also has Audio and HDCP capabilities, but these are
> > not yet supported by the driver.
> 
> FYI: if you want to add HDCP support, then please contact me. I have code
> available for that (i.e. the public API part), although it is out of date.
> 
> But if you want to enable HDCP in this driver, then I would be very happy
> to clean it up and post patches for that. It is something we (i.e. Cisco)
> have been using for several years now in out-of-tree drivers.
> 

Currently we do not have any plans to work on the HDCP support.
But in case the requirement arises in future, we will definitely reach
out to you.

Thanks,
Shreeya Patel

> I will try to review this patch in the next few days.
> 
> Regards,
> 
> 	Hans

Re: [PATCH v4 4/4] media: platform: synopsys: Add support for hdmi input driver

[Markus Elfring]

…
> +++ b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> @@ -0,0 +1,2763 @@
…
> +static void hdmirx_writel(struct snps_hdmirx_dev *hdmirx_dev, int reg, u32 val)
> +{
…
> +	spin_lock_irqsave(&hdmirx_dev->rst_lock, lock_flags);
> +	writel(val, hdmirx_dev->regs + reg);
> +	spin_unlock_irqrestore(&hdmirx_dev->rst_lock, lock_flags);
> +}
…

Under which circumstances would you become interested to apply a statement
like “guard(spinlock_irqsave)(&hdmirx_dev->rst_lock);”?
https://elixir.bootlin.com/linux/v6.10/source/include/linux/spinlock.h#L574

Regards,
Markus

Re: [PATCH v4 4/4] media: platform: synopsys: Add support for hdmi input driver

[Dmitry Osipenko]

On 7/23/24 11:48, Hans Verkuil wrote:
>> +static u8 edid_init_data_340M[] = {
> This should be under #ifdef CONFIG_HDMIRX_LOAD_DEFAULT_EDID, since there is
> no point to have this if you are not using it.

No need to use #ifdef since EDID array will be compiled out at a build
time. Kernel doesn't support old compilers that can't eliminate dead code.

#ifdef makes code less readable and adds requirement to build-test all
variants with/without the #ifdef, we don't want either of these.

-- 
Best regards,
Dmitry

Re: [PATCH v4 4/4] media: platform: synopsys: Add support for hdmi input driver

[Dmitry Osipenko]

On 7/23/24 11:48, Hans Verkuil wrote:
>> +	val = hdmirx_readl(hdmirx_dev, DMA_STATUS11);
>> +	field_type = (val & HDMIRX_TYPE_MASK) >> 7;
>> +	hdmirx_get_pix_fmt(hdmirx_dev);
> Hold on, this changes the pixel format based on the detected video format.
> Does that mean this hardware does not have a colorspace conversion block?
> All the HDMI receiver hardware I have seen always had a CSC matrix and
> could convert between 4:4:4, 4:2:2 and 4:2:0.

TRM doesn't mention that CSC is supported.

-- 
Best regards,
Dmitry

Re: [PATCH v4 4/4] media: platform: synopsys: Add support for hdmi input driver

[Shreeya Patel]

On Tuesday, July 23, 2024 01:09 IST, hoff.benjamin.k@gmail.com wrote:

Hi Benjamin,

> > Add initial support for the Synopsys DesignWare HDMI RX
> > Controller Driver used by Rockchip RK3588. The driver
> > supports:
> >  - HDMI 1.4b and 2.0 modes (HDMI 4k@60Hz)
> >  - RGB888, YUV422, YUV444 and YCC420 pixel formats
> >  - CEC
> >  - EDID configuration
> >
> > The hardware also has Audio and HDCP capabilities, but these are
> > not yet supported by the driver.
> >
> > Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> > Co-developed-by: Dingxian Wen <shawn.wen@rock-chips.com>
> > Signed-off-by: Dingxian Wen <shawn.wen@rock-chips.com>
> > Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> > ---
> >
...
> > +
> > +static const struct of_device_id hdmirx_id[] = {
> > +	{ .compatible = "rockchip,rk3588-hdmirx-ctrler" },
> > +	{ },
> > +};
> > +MODULE_DEVICE_TABLE(of, hdmirx_id);
> >
> >
> According to the platform_driver struct, they like the `remove_new` over remove. 
> When I was compiling for Armbian, I was getting a type mismatch that prevented compililng
> 
> See here: https://github.com/torvalds/linux/blob/933069701c1b507825b514317d4edd5d3fd9d417/include/linux/platform_device.h#L236
> 

This patch series is based on linux-next and there seems to be some recent changes
related to .remove and .remove_new. New drivers are supposed to use .remove()

See the reason here :-
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/include/linux/platform_device.h?h=next-20240722#n239

If you apply the patches on top of linux-next then there shouldn't be any
compilation error.

> >
> > +
> > +static struct platform_driver hdmirx_driver = {
> > +	.probe = hdmirx_probe,
> > +	.remove = hdmirx_remove,
> > +	.driver = {
> > +		.name = "snps_hdmirx",
> > +		.of_match_table = hdmirx_id,
> > +		.pm = &snps_hdmirx_pm_ops,
> > +	}
> > +};
> > +module_platform_driver(hdmirx_driver);
> > +
> > +MODULE_DESCRIPTION("Rockchip HDMI Receiver Driver");
> > +MODULE_AUTHOR("Dingxian Wen <shawn.wen@rock-chips.com>");
> > +MODULE_AUTHOR("Shreeya Patel <shreeya.patel@collabora.com>");
> > +MODULE_LICENSE("GPL");

Re: [PATCH v4 0/4] Add Synopsys DesignWare HDMI RX Controller

[Tim Surber]

Hi Shreeya,

I tested your patch and noticed problems when using 3840x2160 resolution 
at  60fps.

For my testing I connected an HDMI source and set it to 4k60fps. I 
verified that this source and the cables work on a screen at this 
resolution.

Using
'v4l2-ctl --verbose -d /dev/video1 
--set-fmt-video=width=3840,height=2160,pixelformat='NV12' 
--stream-mmap=4 --stream-skip=3 --stream-count=100 --stream-poll'
I get the video format output, but not the periodic output which shows 
the fps.

Using
'GST_DEBUG=4 gst-launch-1.0 -v v4l2src device=/dev/video1 ! 
fpsdisplaysink text-overlay=false video-sink="fakevideosink"'
I get the following error message:

(gst-launch-1.0:3231): GStreamer-CRITICAL **: 01:34:39.137: 
gst_memory_resize: assertion 'size + mem->offset + offset <= 
mem->maxsize' failed
0:00:03.489382529  3231 0xffffa0000b90 WARN  v4l2bufferpool 
gstv4l2bufferpool.c:2209:gst_v4l2_buffer_pool_process:<v4l2src0:pool0:src> 
Dropping truncated buffer, this is likely a driver bug.
0:00:03.489421906  3231 0xffffa0000b90 WARN  bufferpool 
gstbufferpool.c:1252:default_reset_buffer:<v4l2src0:pool0:src> Buffer 
0xffff98008e80 without the memory tag has maxsize (8294400) that is 
smaller than the configured buffer pool size (12441600). The buffer will 
be not be reused. This is most likely a bug in this GstBufferPool subclass


Everything works with 4k30fps or 1080p 60fps. The hardware should 
support 4k60fps.

Best regards,
Tim

On 19.07.24 14:40, Shreeya Patel wrote:
> This series implements support for the Synopsys DesignWare
> HDMI RX Controller, being compliant with standard HDMI 1.4b
> and HDMI 2.0.
>
> Features that are currently supported by the HDMI RX driver
> have been tested on rock5b board using a HDMI to micro-HDMI cable.
> It is recommended to use a good quality cable as there were
> multiple issues seen during testing the driver.
>
> Please note the below information :-
> * While testing the driver on rock5b we noticed that the binary BL31
> from Rockchip contains some unknown code to get the HDMI-RX PHY
> access working without any errors.
> With TF-A BL31, the HDMI-RX PHY also works fine but there were no
> interrupts seen for rk_hdmirx-hdmi leading to some errors when
> loading the driver [0]. It doesn't affect the functionality of the
> driver though.
> * We have tested the working of OBS studio with HDMIRX driver and
> there were no issues seen.
> * We also tested and verified the support for interlaced video.
>
> [0] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/trusted-firmware-a/-/issues/1
>
> To test the HDMI RX Controller driver, following example commands can be used :-
>
> root@debian-rockchip-rock5b-rk3588:~# v4l2-ctl --verbose -d /dev/video0 \
> --set-fmt-video=width=1920,height=1080,pixelformat='BGR3' --stream-mmap=4 \
> --stream-skip=3 --stream-count=100 --stream-to=/home/hdmiin4k.raw --stream-poll
>
> root@debian-rockchip-rock5b-rk3588:~# ffmpeg -f rawvideo -vcodec rawvideo \
> -s 1920x1080 -r 60 -pix_fmt bgr24 -i /home/hdmiin4k.raw output.mkv
>
> CEC compliance test results :-
>
> * https://gitlab.collabora.com/-/snippets/381
> * https://gitlab.collabora.com/-/snippets/380
>
> Following is the v4l2-compliance test result :-
>
> root@debian-rockchip-rock5b-rk3588:~# v4l2-compliance -d /dev/video0
> v4l2-compliance 1.27.0-5220, 64 bits, 64-bit time_t
> v4l2-compliance SHA: 8387e3673837 2024-07-01 11:09:32
>
> Compliance test for snps_hdmirx device /dev/video0:
>
> Driver Info:
> 	Driver name      : snps_hdmirx
> 	Card type        : snps_hdmirx
> 	Bus info         : platform:fdee0000.hdmi-receiver
> 	Driver version   : 6.10.0
> 	Capabilities     : 0x84201000
> 		Video Capture Multiplanar
> 		Streaming
> 		Extended Pix Format
> 		Device Capabilities
> 	Device Caps      : 0x04201000
> 		Video Capture Multiplanar
> 		Streaming
> 		Extended Pix Format
>
> Required ioctls:
> 	test VIDIOC_QUERYCAP: OK
> 	test invalid ioctls: OK
>
> Allow for multiple opens:
> 	test second /dev/video0 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
>
> 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
> 	test VIDIOC_G/S_AUDIO: OK (Not Supported)
> 	Inputs: 1 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
> 	test VIDIOC_DV_TIMINGS_CAP: OK
> 	test VIDIOC_G/S_EDID: OK
>
> Control ioctls (Input 0):
> 	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: 3 Private Controls: 0
>
> Format ioctls (Input 0):
> 	test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> 	test VIDIOC_G/S_PARM: OK
> 	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 (Input 0):
> 	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 (Input 0):
> 	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 snps_hdmirx device /dev/video0: 47, Succeeded: 47, Failed: 0, Warnings: 0
>
> Changes in v4 :-
>    - Remove DTS changes included in the device tree patch
>    - Remove the hdmi rx pin info as it's already present
>      in the rk3588-base-pinctrl.dtsi
>    - Create a separate config option for selecting the EDID
>      and enable it by default
>    - Improve the comment related to DV timings and move it
>      to the side of hdmirx_get_detected_timings
>    - Add 100ms delay before pulling the HPD high
>    - Do not return the detected timings from VIDIOC_G_DV_TIMINGS
>    - Drop the bus info from hdmirx_querycap
>    - If *num_planes != 0 then return 0 in hdmirx_queue_setup
>    - Set queue->min_queued_buffers to 1
>    - Drop q->allow_cache_hints = 0; as it's always 0 by default
>    - Add a comment for q->dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
>    - Drop .read = vb2_fop_read as it's not supported by driver
>    - Remove redundant edid_init_data_600M
>    - Make HPD low when driver is loaded
>    - Add support for reading AVI Infoframe
>    - Remove msg_len checks from hdmirx_cec_transmit
>    - Add info about the CEC compliance test in the cover letter
>    - Add arbitration lost status
>    - Validate the physical address inside the EDID
>
> Changes in v3 :-
>    - Use v4l2-common helpers in the HDMIRX driver
>    - Rename cma node and phandle names
>    - Elaborate the comment to explain 160MiB calculation
>    - Move &hdmi_receiver_cma to the rock5b dts file
>    - Add information about interlaced video testing in the
>      cover-letter
>
> Changes in v2 :-
>    - Fix checkpatch --strict warnings
>    - Move the dt-binding include file changes in a separate patch
>    - Add a description for the hardware in the dt-bindings file
>    - Rename resets, vo1 grf and HPD properties
>    - Add a proper description for grf and vo1-grf phandles in the
>      bindings
>    - Rename the HDMI RX node name to hdmi-receiver
>    - Include gpio header file in binding example to fix the
>      dt_binding_check failure
>    - Move hdmirx_cma node to the rk3588.dtsi file
>    - Add an entry to MAINTAINERS file for the HDMIRX driver
>
> Shreeya Patel (4):
>    MAINTAINERS: Add entry for Synopsys DesignWare HDMI RX Driver
>    dt-bindings: media: Document bindings for HDMI RX Controller
>    arm64: dts: rockchip: Add device tree support for HDMI RX Controller
>    media: platform: synopsys: Add support for hdmi input driver
>
>   .../bindings/media/snps,dw-hdmi-rx.yaml       |  132 +
>   MAINTAINERS                                   |    8 +
>   .../dts/rockchip/rk3588-base-pinctrl.dtsi     |   14 +
>   .../arm64/boot/dts/rockchip/rk3588-extra.dtsi |   56 +
>   drivers/media/platform/Kconfig                |    1 +
>   drivers/media/platform/Makefile               |    1 +
>   drivers/media/platform/synopsys/Kconfig       |    3 +
>   drivers/media/platform/synopsys/Makefile      |    2 +
>   .../media/platform/synopsys/hdmirx/Kconfig    |   27 +
>   .../media/platform/synopsys/hdmirx/Makefile   |    4 +
>   .../platform/synopsys/hdmirx/snps_hdmirx.c    | 2763 +++++++++++++++++
>   .../platform/synopsys/hdmirx/snps_hdmirx.h    |  394 +++
>   .../synopsys/hdmirx/snps_hdmirx_cec.c         |  285 ++
>   .../synopsys/hdmirx/snps_hdmirx_cec.h         |   44 +
>   14 files changed, 3734 insertions(+)
>   create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>   create mode 100644 drivers/media/platform/synopsys/Kconfig
>   create mode 100644 drivers/media/platform/synopsys/Makefile
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/Kconfig
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/Makefile
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.h
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.c
>   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.h
>

Re: [PATCH v4 0/4] Add Synopsys DesignWare HDMI RX Controller

[Tim Surber]

Here are the results of some more debugging.
I see that in the first example the pixel format is set to RGB888 and in 
the second to NV12, I was not able to successfully change this on my 
source, nevertheless the HDMI RX should work I think.

###source set to 4k30fps####
---------------------------
v4l2-ctl --verbose -d /dev/video1 
--set-fmt-video=width=3840,height=2160,pixelformat='NV12' 
--stream-mmap=4 --stream-skip=3 --stream-count=100 --stream-poll
---------------------------
VIDIOC_QUERYCAP: ok
VIDIOC_G_FMT: ok
The pixelformat 'NV12' is invalid
New timings found
         VIDIOC_REQBUFS returned 0 (Success)
         VIDIOC_CREATE_BUFS returned 0 (Success)
         VIDIOC_QUERYBUF returned 0 (Success)
         VIDIOC_QUERYBUF returned 0 (Success)
         VIDIOC_QUERYBUF returned 0 (Success)
         VIDIOC_QUERYBUF returned 0 (Success)
         VIDIOC_G_FMT returned 0 (Success)
         VIDIOC_QBUF returned 0 (Success)
         VIDIOC_QBUF returned 0 (Success)
         VIDIOC_QBUF returned 0 (Success)
         VIDIOC_QBUF returned 0 (Success)
         VIDIOC_STREAMON returned 0 (Success)
cap dqbuf: 0 seq:      0 bytesused: 8294400 ts: 536.006261 field: Any 
(ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      1 bytesused: 8294400 ts: 536.039574 delta: 33.313 
ms field: Any (ts-monotonic, ts-src-eof)
cap dqbuf: 2 seq:      2 bytesused: 8294400 ts: 536.072906 delta: 33.332 
ms field: Any (ts-monotonic, ts-src-eof)
cap dqbuf: 3 seq:      3 bytesused: 8294400 ts: 536.106239 delta: 33.333 
ms field: Any (ts-monotonic, ts-src-eof)
cap dqbuf: 0 seq:      4 bytesused: 8294400 ts: 536.139571 delta: 33.332 
ms fps: 30.01 field: Any (ts-monotonic, ts-src-eof)
cap dqbuf: 1 seq:      5 bytesused: 8294400 ts: 536.172903 delta: 33.332 
ms fps: 30.00 field: Any (ts-monotonic, ts-src-eof)
[...]

---------------------------
dmesg
---------------------------
[  529.266804] fdee0000.hdmi_receiver: hb
[  530.280073] fdee0000.hdmi_receiver: hb
[  531.293412] fdee0000.hdmi_receiver: hb
[  532.306716] fdee0000.hdmi_receiver: hb
[  533.319906] fdee0000.hdmi_receiver: hb
[  534.333263] fdee0000.hdmi_receiver: hb
[  535.346616] fdee0000.hdmi_receiver: hb
[  535.739795] fdee0000.hdmi_receiver: C-Plane 0 size: 24883200, Total 
imagesize: 24883200
[  535.747733] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[  535.747750] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: RGB888
[  535.747760] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[  535.747780] fdee0000.hdmi_receiver: get timings from dma
[  535.747787] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:30, pixclk:297016000
[  535.747799] fdee0000.hdmi_receiver: hfp:172, hs:92, hbp:296, vfp:8, 
vs:10, vbp:72
[  535.747809] fdee0000.hdmi_receiver: tmds_clk:297016000
[  535.747816] fdee0000.hdmi_receiver: interlace:0, fmt:0, vic:127, 
color:24, mode:hdmi
[  535.747825] fdee0000.hdmi_receiver: deframer_st:0x11
[  535.747833] fdee0000.hdmi_receiver: query_dv_timings: 3840x2160p30.00 
(4400x2250)
[  535.747854] fdee0000.hdmi_receiver: s_dv_timings: 3840x2160p30.00 
(4400x2250)
[  535.747875] fdee0000.hdmi_receiver: hdmirx_s_dv_timings: no change
[  535.747924] fdee0000.hdmi_receiver: vid-cap-mplane: count 4, size 8294400
[  535.752754] fdee0000.hdmi_receiver: C-Plane 0 size: 24883200, Total 
imagesize: 24883200
[  535.752884] fdee0000.hdmi_receiver: C-Plane 0 size: 24883200, Total 
imagesize: 24883200
[  535.752904] fdee0000.hdmi_receiver: hdmirx_start_streaming: 
start_stream cur_buf y_addr:0xe0ea5000, uv_addr:0xe168e000
[  535.752920] fdee0000.hdmi_receiver: hdmirx_start_streaming: enable dma
[  535.780112] fdee0000.hdmi_receiver: dma_irq st1:0x100, st13:1085
[  535.780128] fdee0000.hdmi_receiver: line_flag_int_handler: last have 
no dma_idle_irq
[  535.796093] fdee0000.hdmi_receiver: dma_irq st1:0x80, st13:2160
[  535.813435] fdee0000.hdmi_receiver: dma_irq st1:0x100, st13:1085
[  535.829423] fdee0000.hdmi_receiver: dma_irq st1:0x80, st13:2160
[...]
---------------------------

###source set to 4k60fps####
---------------------------
v4l2-ctl --verbose -d /dev/video1 
--set-fmt-video=width=3840,height=2160,pixelformat='NV12' 
--stream-mmap=4 --stream-skip=3 --stream-count=100 --stream-poll
---------------------------
VIDIOC_QUERYCAP: ok
VIDIOC_G_FMT: ok
VIDIOC_S_FMT: ok
Format Video Capture Multiplanar:
     Width/Height      : 3840/2160
     Pixel Format      : 'NV12' (Y/UV 4:2:0)
     Field             : None
     Number of planes  : 1
     Flags             :
     Colorspace        : sRGB
     Transfer Function : Default
     YCbCr/HSV Encoding: Default
     Quantization      : Default
     Plane 0           :
        Bytes per Line : 3840
        Size Image     : 8294400
[stuck here, have to end with ctrl c]


---------------------------
dmesg
---------------------------
[ 1520.198123] fdee0000.hdmi_receiver: hb
[ 1521.211383] fdee0000.hdmi_receiver: hb
[ 1522.224680] fdee0000.hdmi_receiver: hb
[ 1523.237936] fdee0000.hdmi_receiver: hb
[ 1524.251313] fdee0000.hdmi_receiver: hb
[ 1525.264606] fdee0000.hdmi_receiver: hb
[ 1526.277937] fdee0000.hdmi_receiver: hb
[ 1526.427540] fdee0000.hdmi_receiver: C-Plane 0 size: 8294400, Total 
imagesize: 8294400
[ 1526.427587] fdee0000.hdmi_receiver: C-Plane 0 size: 8294400, Total 
imagesize: 8294400
[ 1526.427598] fdee0000.hdmi_receiver: hdmirx_set_fmt: req(3840, 2160), 
out(3840, 2160), fmt:0x3231564e
[ 1526.435569] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1526.435588] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1526.435597] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1526.435618] fdee0000.hdmi_receiver: get timings from dma
[ 1526.435626] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1526.435637] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1526.435648] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1526.435656] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1526.435665] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1527.291212] fdee0000.hdmi_receiver: hb
[ 1527.443533] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1527.443550] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1527.443560] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1527.443579] fdee0000.hdmi_receiver: get timings from dma
[ 1527.443586] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1527.443597] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1527.443608] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1527.443615] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1527.443625] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1528.304515] fdee0000.hdmi_receiver: hb
[ 1528.451543] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1528.451560] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1528.451569] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1528.451588] fdee0000.hdmi_receiver: get timings from dma
[ 1528.451595] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1528.451606] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1528.451617] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1528.451624] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1528.451634] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1529.317814] fdee0000.hdmi_receiver: hb
[ 1529.459549] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1529.459566] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1529.459575] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1529.459593] fdee0000.hdmi_receiver: get timings from dma
[ 1529.459601] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1529.459612] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1529.459623] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1529.459630] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1529.459640] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1530.331085] fdee0000.hdmi_receiver: hb
[ 1530.467555] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1530.467571] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1530.467580] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1530.467599] fdee0000.hdmi_receiver: get timings from dma
[ 1530.467606] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1530.467618] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1530.467628] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1530.467635] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1530.467664] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1531.344437] fdee0000.hdmi_receiver: hb
[ 1531.475649] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1531.475665] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1531.475674] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1531.475693] fdee0000.hdmi_receiver: get timings from dma
[ 1531.475700] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1531.475711] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1531.475722] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1531.475729] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1531.475739] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1532.357695] fdee0000.hdmi_receiver: hb
[ 1532.483716] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1532.483733] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1532.483742] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1532.483761] fdee0000.hdmi_receiver: get timings from dma
[ 1532.483768] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1532.483780] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1532.483790] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1532.483797] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1532.483807] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1533.370994] fdee0000.hdmi_receiver: hb
[ 1533.491726] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1533.491743] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1533.491752] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1533.491770] fdee0000.hdmi_receiver: get timings from dma
[ 1533.491778] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1533.491789] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1533.491800] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1533.491807] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1533.491816] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1534.384324] fdee0000.hdmi_receiver: hb
[ 1534.499888] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1534.499904] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1534.499913] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1534.499932] fdee0000.hdmi_receiver: get timings from dma
[ 1534.499939] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1534.499950] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1534.499960] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1534.499968] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1534.499977] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1535.397596] fdee0000.hdmi_receiver: hb
[ 1535.507961] fdee0000.hdmi_receiver: tx_5v_power_present: 1
[ 1535.507977] fdee0000.hdmi_receiver: hdmirx_get_pix_fmt: pix_fmt: YUV420
[ 1535.507986] fdee0000.hdmi_receiver: hdmirx_get_colordepth: 
color_depth: 24, reg_val:4
[ 1535.508005] fdee0000.hdmi_receiver: get timings from dma
[ 1535.508012] fdee0000.hdmi_receiver: act:3840x2160, total:4400x2250, 
fps:60, pixclk:297008000
[ 1535.508023] fdee0000.hdmi_receiver: hfp:4294965460, hs:48, hbp:148, 
vfp:8, vs:10, vbp:72
[ 1535.508034] fdee0000.hdmi_receiver: tmds_clk:297008000
[ 1535.508041] fdee0000.hdmi_receiver: interlace:0, fmt:3, vic:127, 
color:24, mode:hdmi
[ 1535.508051] fdee0000.hdmi_receiver: deframer_st:0x11
[ 1536.410933] fdee0000.hdmi_receiver: hb
[ 1537.424223] fdee0000.hdmi_receiver: hb
[ 1538.437523] fdee0000.hdmi_receiver: hb
[ 1539.450848] fdee0000.hdmi_receiver: hb

Best regards
Tim

On 06.08.24 13:58, Dmitry Osipenko wrote:
> On 8/4/24 02:57, Tim Surber wrote:
>> Hi Shreeya,
>>
>> I tested your patch and noticed problems when using 3840x2160 resolution
>> at  60fps.
>>
>> For my testing I connected an HDMI source and set it to 4k60fps. I
>> verified that this source and the cables work on a screen at this
>> resolution.
>>
>> Using
>> 'v4l2-ctl --verbose -d /dev/video1
>> --set-fmt-video=width=3840,height=2160,pixelformat='NV12'
>> --stream-mmap=4 --stream-skip=3 --stream-count=100 --stream-poll'
>> I get the video format output, but not the periodic output which shows
>> the fps.
>>
>> Using
>> 'GST_DEBUG=4 gst-launch-1.0 -v v4l2src device=/dev/video1 !
>> fpsdisplaysink text-overlay=false video-sink="fakevideosink"'
>> I get the following error message:
>>
>> (gst-launch-1.0:3231): GStreamer-CRITICAL **: 01:34:39.137:
>> gst_memory_resize: assertion 'size + mem->offset + offset <=
>> mem->maxsize' failed
>> 0:00:03.489382529  3231 0xffffa0000b90 WARN  v4l2bufferpool
>> gstv4l2bufferpool.c:2209:gst_v4l2_buffer_pool_process:<v4l2src0:pool0:src> Dropping truncated buffer, this is likely a driver bug.
>> 0:00:03.489421906  3231 0xffffa0000b90 WARN  bufferpool
>> gstbufferpool.c:1252:default_reset_buffer:<v4l2src0:pool0:src> Buffer
>> 0xffff98008e80 without the memory tag has maxsize (8294400) that is
>> smaller than the configured buffer pool size (12441600). The buffer will
>> be not be reused. This is most likely a bug in this GstBufferPool subclass
>>
>>
>> Everything works with 4k30fps or 1080p 60fps. The hardware should
>> support 4k60fps.
> Please do `echo 3 > /sys/module/synopsys_hdmirx/parameters/debug` and
> show the kernel log of capturing 4k@60 with v4l2-ctl.
>

Re: [PATCH v4 0/4] Add Synopsys DesignWare HDMI RX Controller

[Tim Surber]

Hi Shreeya,

On 14.08.24 12:22, Shreeya Patel wrote:
> If you'd like to try it yourself then following is the command to get the new EDID
>
> v4l2-ctl --show-edid type=hdmi-4k-600mhz
>
> You will have to replace the EDID in the driver with the EDID you get the from the above
> command in HEX format.

I updated the EDID with

v4l2-ctl --show-edid type=hdmi-4k-600mhz

and this seems to fix the issue for me.


Best regards,

Tim

Re: [PATCH v4 0/4] Add Synopsys DesignWare HDMI RX Controller

[Tim Surber]

Hi Shreeya,

another hint:

Changing the EDID like you described fixed the 4k60fps BGR3 input.

But still for NV16/NV24 (I can't output NV12 for some reason) there is 
the error which Nicolas described.

The output from v4l2-ctl for NV16/NV24 is:

Plane 0           :
        Bytes per Line : 3840
        Size Image     : 8294400

According to Nicolas there should be an additional plane/more memory 
reserved.

This leads to errors when trying to read the device using for example 
gstreamer:

  gst_memory_resize: assertion 'size + mem->offset + offset <= 
mem->maxsize' failed


This seems to always happen using the  NV16/NV24 formats regardless of 
resolution/fps.


Best regards,

Tim

On 14.08.24 12:22, Shreeya Patel wrote:
>   ---- On Sun, 04 Aug 2024 05:27:08 +0530  Tim Surber  wrote ---
>   > Hi Shreeya,
>   >
>
> Hi Tim,
>
>
>   > I tested your patch and noticed problems when using 3840x2160 resolution
>   > at  60fps.
>   >
>   > For my testing I connected an HDMI source and set it to 4k60fps. I
>   > verified that this source and the cables work on a screen at this
>   > resolution.
>   >
>   > Using
>   > 'v4l2-ctl --verbose -d /dev/video1
>   > --set-fmt-video=width=3840,height=2160,pixelformat='NV12'
>   > --stream-mmap=4 --stream-skip=3 --stream-count=100 --stream-poll'
>   > I get the video format output, but not the periodic output which shows
>   > the fps.
>   >
>   > Using
>   > 'GST_DEBUG=4 gst-launch-1.0 -v v4l2src device=/dev/video1 !
>   > fpsdisplaysink text-overlay=false video-sink="fakevideosink"'
>   > I get the following error message:
>   >
>   > (gst-launch-1.0:3231): GStreamer-CRITICAL **: 01:34:39.137:
>   > gst_memory_resize: assertion 'size + mem->offset + offset <=
>   > mem->maxsize' failed
>   > 0:00:03.489382529  3231 0xffffa0000b90 WARN  v4l2bufferpool
>   > gstv4l2bufferpool.c:2209:gst_v4l2_buffer_pool_process:
>   > Dropping truncated buffer, this is likely a driver bug.
>   > 0:00:03.489421906  3231 0xffffa0000b90 WARN  bufferpool
>   > gstbufferpool.c:1252:default_reset_buffer: Buffer
>   > 0xffff98008e80 without the memory tag has maxsize (8294400) that is
>   > smaller than the configured buffer pool size (12441600). The buffer will
>   > be not be reused. This is most likely a bug in this GstBufferPool subclass
>   >
>   >
>   > Everything works with 4k30fps or 1080p 60fps. The hardware should
>   > support 4k60fps.
>   >
>
>
> Sorry for the delayed response, I've been trying to reproduce this on my side
> and to also fix it.
>
> It seems you are right, 4K@60 fps doesn't work with the latest version of HDMIRX.
> We found out that it could be because of the current EDID which shows some failures.
>
> Though I wasn't able to test the following on my side since my device doesn't support
> 4K, one of my colleague tried to replace the EDID and 4K@60 fps worked fine after that.
>
> If you'd like to try it yourself then following is the command to get the new EDID
>
> v4l2-ctl --show-edid type=hdmi-4k-600mhz
>
> You will have to replace the EDID in the driver with the EDID you get the from the above
> command in HEX format.
>
> Thanks for reporting this, I will soon send v5 with this change included in it.
>
>
> Thanks,
> Shreeya Patel
>
>
>   > Best regards,
>   > Tim
>   >
>   > On 19.07.24 14:40, Shreeya Patel wrote:
>   > > This series implements support for the Synopsys DesignWare
>   > > HDMI RX Controller, being compliant with standard HDMI 1.4b
>   > > and HDMI 2.0.
>   > >
>   > > Features that are currently supported by the HDMI RX driver
>   > > have been tested on rock5b board using a HDMI to micro-HDMI cable.
>   > > It is recommended to use a good quality cable as there were
>   > > multiple issues seen during testing the driver.
>   > >
>   > > Please note the below information :-
>   > > * While testing the driver on rock5b we noticed that the binary BL31
>   > > from Rockchip contains some unknown code to get the HDMI-RX PHY
>   > > access working without any errors.
>   > > With TF-A BL31, the HDMI-RX PHY also works fine but there were no
>   > > interrupts seen for rk_hdmirx-hdmi leading to some errors when
>   > > loading the driver [0]. It doesn't affect the functionality of the
>   > > driver though.
>   > > * We have tested the working of OBS studio with HDMIRX driver and
>   > > there were no issues seen.
>   > > * We also tested and verified the support for interlaced video.
>   > >
>   > > [0] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/trusted-firmware-a/-/issues/1
>   > >
>   > > To test the HDMI RX Controller driver, following example commands can be used :-
>   > >
>   > > root@debian-rockchip-rock5b-rk3588:~# v4l2-ctl --verbose -d /dev/video0 \
>   > > --set-fmt-video=width=1920,height=1080,pixelformat='BGR3' --stream-mmap=4 \
>   > > --stream-skip=3 --stream-count=100 --stream-to=/home/hdmiin4k.raw --stream-poll
>   > >
>   > > root@debian-rockchip-rock5b-rk3588:~# ffmpeg -f rawvideo -vcodec rawvideo \
>   > > -s 1920x1080 -r 60 -pix_fmt bgr24 -i /home/hdmiin4k.raw output.mkv
>   > >
>   > > CEC compliance test results :-
>   > >
>   > > * https://gitlab.collabora.com/-/snippets/381
>   > > * https://gitlab.collabora.com/-/snippets/380
>   > >
>   > > Following is the v4l2-compliance test result :-
>   > >
>   > > root@debian-rockchip-rock5b-rk3588:~# v4l2-compliance -d /dev/video0
>   > > v4l2-compliance 1.27.0-5220, 64 bits, 64-bit time_t
>   > > v4l2-compliance SHA: 8387e3673837 2024-07-01 11:09:32
>   > >
>   > > Compliance test for snps_hdmirx device /dev/video0:
>   > >
>   > > Driver Info:
>   > >     Driver name      : snps_hdmirx
>   > >     Card type        : snps_hdmirx
>   > >     Bus info         : platform:fdee0000.hdmi-receiver
>   > >     Driver version   : 6.10.0
>   > >     Capabilities     : 0x84201000
>   > >         Video Capture Multiplanar
>   > >         Streaming
>   > >         Extended Pix Format
>   > >         Device Capabilities
>   > >     Device Caps      : 0x04201000
>   > >         Video Capture Multiplanar
>   > >         Streaming
>   > >         Extended Pix Format
>   > >
>   > > Required ioctls:
>   > >     test VIDIOC_QUERYCAP: OK
>   > >     test invalid ioctls: OK
>   > >
>   > > Allow for multiple opens:
>   > >     test second /dev/video0 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
>   > >
>   > > 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
>   > >     test VIDIOC_G/S_AUDIO: OK (Not Supported)
>   > >     Inputs: 1 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
>   > >     test VIDIOC_DV_TIMINGS_CAP: OK
>   > >     test VIDIOC_G/S_EDID: OK
>   > >
>   > > Control ioctls (Input 0):
>   > >     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: 3 Private Controls: 0
>   > >
>   > > Format ioctls (Input 0):
>   > >     test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
>   > >     test VIDIOC_G/S_PARM: OK
>   > >     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 (Input 0):
>   > >     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 (Input 0):
>   > >     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 snps_hdmirx device /dev/video0: 47, Succeeded: 47, Failed: 0, Warnings: 0
>   > >
>   > > Changes in v4 :-
>   > >    - Remove DTS changes included in the device tree patch
>   > >    - Remove the hdmi rx pin info as it's already present
>   > >      in the rk3588-base-pinctrl.dtsi
>   > >    - Create a separate config option for selecting the EDID
>   > >      and enable it by default
>   > >    - Improve the comment related to DV timings and move it
>   > >      to the side of hdmirx_get_detected_timings
>   > >    - Add 100ms delay before pulling the HPD high
>   > >    - Do not return the detected timings from VIDIOC_G_DV_TIMINGS
>   > >    - Drop the bus info from hdmirx_querycap
>   > >    - If *num_planes != 0 then return 0 in hdmirx_queue_setup
>   > >    - Set queue->min_queued_buffers to 1
>   > >    - Drop q->allow_cache_hints = 0; as it's always 0 by default
>   > >    - Add a comment for q->dma_attrs = DMA_ATTR_FORCE_CONTIGUOUS;
>   > >    - Drop .read = vb2_fop_read as it's not supported by driver
>   > >    - Remove redundant edid_init_data_600M
>   > >    - Make HPD low when driver is loaded
>   > >    - Add support for reading AVI Infoframe
>   > >    - Remove msg_len checks from hdmirx_cec_transmit
>   > >    - Add info about the CEC compliance test in the cover letter
>   > >    - Add arbitration lost status
>   > >    - Validate the physical address inside the EDID
>   > >
>   > > Changes in v3 :-
>   > >    - Use v4l2-common helpers in the HDMIRX driver
>   > >    - Rename cma node and phandle names
>   > >    - Elaborate the comment to explain 160MiB calculation
>   > >    - Move &hdmi_receiver_cma to the rock5b dts file
>   > >    - Add information about interlaced video testing in the
>   > >      cover-letter
>   > >
>   > > Changes in v2 :-
>   > >    - Fix checkpatch --strict warnings
>   > >    - Move the dt-binding include file changes in a separate patch
>   > >    - Add a description for the hardware in the dt-bindings file
>   > >    - Rename resets, vo1 grf and HPD properties
>   > >    - Add a proper description for grf and vo1-grf phandles in the
>   > >      bindings
>   > >    - Rename the HDMI RX node name to hdmi-receiver
>   > >    - Include gpio header file in binding example to fix the
>   > >      dt_binding_check failure
>   > >    - Move hdmirx_cma node to the rk3588.dtsi file
>   > >    - Add an entry to MAINTAINERS file for the HDMIRX driver
>   > >
>   > > Shreeya Patel (4):
>   > >    MAINTAINERS: Add entry for Synopsys DesignWare HDMI RX Driver
>   > >    dt-bindings: media: Document bindings for HDMI RX Controller
>   > >    arm64: dts: rockchip: Add device tree support for HDMI RX Controller
>   > >    media: platform: synopsys: Add support for hdmi input driver
>   > >
>   > >   .../bindings/media/snps,dw-hdmi-rx.yaml       |  132 +
>   > >   MAINTAINERS                                   |    8 +
>   > >   .../dts/rockchip/rk3588-base-pinctrl.dtsi     |   14 +
>   > >   .../arm64/boot/dts/rockchip/rk3588-extra.dtsi |   56 +
>   > >   drivers/media/platform/Kconfig                |    1 +
>   > >   drivers/media/platform/Makefile               |    1 +
>   > >   drivers/media/platform/synopsys/Kconfig       |    3 +
>   > >   drivers/media/platform/synopsys/Makefile      |    2 +
>   > >   .../media/platform/synopsys/hdmirx/Kconfig    |   27 +
>   > >   .../media/platform/synopsys/hdmirx/Makefile   |    4 +
>   > >   .../platform/synopsys/hdmirx/snps_hdmirx.c    | 2763 +++++++++++++++++
>   > >   .../platform/synopsys/hdmirx/snps_hdmirx.h    |  394 +++
>   > >   .../synopsys/hdmirx/snps_hdmirx_cec.c         |  285 ++
>   > >   .../synopsys/hdmirx/snps_hdmirx_cec.h         |   44 +
>   > >   14 files changed, 3734 insertions(+)
>   > >   create mode 100644 Documentation/devicetree/bindings/media/snps,dw-hdmi-rx.yaml
>   > >   create mode 100644 drivers/media/platform/synopsys/Kconfig
>   > >   create mode 100644 drivers/media/platform/synopsys/Makefile
>   > >   create mode 100644 drivers/media/platform/synopsys/hdmirx/Kconfig
>   > >   create mode 100644 drivers/media/platform/synopsys/hdmirx/Makefile
>   > >   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
>   > >   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx.h
>   > >   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.c
>   > >   create mode 100644 drivers/media/platform/synopsys/hdmirx/snps_hdmirx_cec.h
>   > >
>   >

Re: [PATCH v4 0/4] Add Synopsys DesignWare HDMI RX Controller

[Nicolas Dufresne]

Hi Shreya,

Le jeudi 29 août 2024 à 15:33 +0530, Shreeya Patel a écrit :
>  ---- On Thu, 29 Aug 2024 03:43:40 +0530  Tim Surber  wrote --- 
>  > Hi Shreeya,
>  > 
>  > another hint:
>  > 
>  > Changing the EDID like you described fixed the 4k60fps BGR3 input.
>  > 
>  > But still for NV16/NV24 (I can't output NV12 for some reason) there is 
>  > the error which Nicolas described.
>  > 
>  > The output from v4l2-ctl for NV16/NV24 is:
>  > 
>  > Plane 0           :
>  >         Bytes per Line : 3840
>  >         Size Image     : 8294400
>  > 
>  > According to Nicolas there should be an additional plane/more memory 
>  > reserved.
>  > 
> 
> Yes, it could be possible that the imagesize is incorrect as we made some
> modifications related to it in v4. I'll increase this as required by the NV12/24
> and see if that fixes the issue.


Sorry for the slow feedback, just noticed this message. Please make sure to us
v4l2-common, these exists exactly because no one can get strides and image size
right on first go.

Nicolas