Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1687869 > unrolled thread

[PATCH v2 0/6] Add Rockchip RGA V4l2 support

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/6] Add Rockchip RGA V4l2 support Jacob Chen <jacob-chen@iotwrt.com> - 2017-07-15 09:00 +0200
    [PATCH v2 1/6] [media] v4l: add blend modes controls Jacob Chen <jacob-chen@iotwrt.com> - 2017-07-15 09:00 +0200
      Re: [PATCH v2 1/6] [media] v4l: add blend modes controls Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-07-15 11:40 +0200
    [PATCH v2 3/6] ARM: dts: rockchip: add RGA device node for RK3288 Jacob Chen <jacob-chen@iotwrt.com> - 2017-07-15 09:00 +0200
      Re: [PATCH v2 3/6] ARM: dts: rockchip: add RGA device node for RK3288 Heiko Stuebner <heiko@sntech.de> - 2017-07-15 10:20 +0200
    [PATCH v2 6/6] dt-bindings: Document the Rockchip RGA bindings Jacob Chen <jacob-chen@iotwrt.com> - 2017-07-15 09:00 +0200
      Re: [PATCH v2 6/6] dt-bindings: Document the Rockchip RGA bindings Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-07-15 11:30 +0200
        Re: [PATCH v2 6/6] dt-bindings: Document the Rockchip RGA bindings Heiko Stuebner <heiko@sntech.de> - 2017-07-16 18:10 +0200
          Re: [PATCH v2 6/6] dt-bindings: Document the Rockchip RGA bindings Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-07-17 04:30 +0200
    [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices Jacob Chen <jacob-chen@iotwrt.com> - 2017-07-15 09:00 +0200
      Re: [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-07-15 11:20 +0200
        Re: [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices Jacob Chen <jacobchen110@gmail.com> - 2017-07-16 06:30 +0200
          Re: [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-07-17 04:30 +0200
            Re: [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices Jacob Chen <jacobchen110@gmail.com> - 2017-07-17 05:10 +0200
    [PATCH v2 4/6] ARM: dts: rockchip: add RGA device node for RK3399 Jacob Chen <jacob-chen@iotwrt.com> - 2017-07-15 09:10 +0200
    Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-07-15 11:50 +0200
      Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support Personnel <nicolas@ndufresne.ca> - 2017-07-15 18:50 +0200
        Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support Jacob Chen <jacobchen110@gmail.com> - 2017-07-16 06:20 +0200
          Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-07-17 04:50 +0200
            Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support Jacob Chen <jacobchen110@gmail.com> - 2017-07-17 05:50 +0200
        Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support Laurent Pinchart <laurent.pinchart@ideasonboard.com> - 2017-07-17 04:40 +0200
          Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support Nicolas Dufresne <nicolas@ndufresne.ca> - 2017-07-17 16:50 +0200

Page 1 of 2  [1] 2  Next page →

#1687869 — [PATCH v2 0/6] Add Rockchip RGA V4l2 support

This patch series add a v4l2 m2m drvier for rockchip RGA direct rendering based 2d graphics acceleration module.

change in V2:
- generalize the controls.
- map buffers (10-50 us) in every cmd-run rather than in buffer-import to avoid get_free_pages failed on
actively used systems.
- remove status in dt-bindings examples.


Jacob Chen (6):
  [media] v4l: add blend modes controls
  [media] rockchip/rga: v4l2 m2m support
  ARM: dts: rockchip: add RGA device node for RK3288
  ARM: dts: rockchip: add RGA device node for RK3399
  ARM: dts: rockchip: enable RGA for rk3288 devices
  dt-bindings: Document the Rockchip RGA bindings

 .../devicetree/bindings/media/rockchip-rga.txt     |  35 +
 arch/arm/boot/dts/rk3288-evb.dtsi                  |   4 +
 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi  |   4 +
 arch/arm/boot/dts/rk3288-firefly.dtsi              |   4 +
 arch/arm/boot/dts/rk3288-miqi.dts                  |   4 +
 arch/arm/boot/dts/rk3288-popmetal.dts              |   4 +
 arch/arm/boot/dts/rk3288-tinker.dts                |   4 +
 arch/arm/boot/dts/rk3288.dtsi                      |  13 +
 arch/arm64/boot/dts/rockchip/rk3399.dtsi           |  13 +
 drivers/media/platform/Kconfig                     |  11 +
 drivers/media/platform/Makefile                    |   2 +
 drivers/media/platform/rockchip-rga/Makefile       |   3 +
 drivers/media/platform/rockchip-rga/rga-buf.c      | 176 ++++
 drivers/media/platform/rockchip-rga/rga-hw.c       | 456 ++++++++++
 drivers/media/platform/rockchip-rga/rga-hw.h       | 434 +++++++++
 drivers/media/platform/rockchip-rga/rga.c          | 979 +++++++++++++++++++++
 drivers/media/platform/rockchip-rga/rga.h          | 133 +++
 drivers/media/v4l2-core/v4l2-ctrls.c               |  19 +
 include/uapi/linux/v4l2-controls.h                 |  18 +-
 19 files changed, 2315 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
 create mode 100644 drivers/media/platform/rockchip-rga/Makefile
 create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
 create mode 100644 drivers/media/platform/rockchip-rga/rga.c
 create mode 100644 drivers/media/platform/rockchip-rga/rga.h

-- 
2.7.4

[toc] | [next] | [standalone]

#1687870 — [PATCH v2 1/6] [media] v4l: add blend modes controls

At peresent, we don't have a control for Compositing and Blend.
All drivers are just doing copies while actually many hardwares
supports more functions.

So Adding V4L2 controls for Compositing and Blend, used for for
composting streams.

The values are based on porter duff operations.
Defined in below links.
https://developer.xamarin.com/api/type/Android.Graphics.PorterDuff+Mode/

Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
Suggested-by: Nicolas Dufresne <nicolas@ndufresne.ca>
---
 drivers/media/v4l2-core/v4l2-ctrls.c | 19 +++++++++++++++++++
 include/uapi/linux/v4l2-controls.h   | 18 +++++++++++++++++-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index b9e08e3..8a235fd 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -216,6 +216,21 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
 		"Private Packet, IVTV Format",
 		NULL
 	};
+	static const char * const blend_modes[] = {
+		"Source",
+		"Source Top",
+		"Source In",
+		"Source Out",
+		"Source Over",
+		"Destination",
+		"Destination Top",
+		"Destination In",
+		"Destination Out",
+		"Destination Over",
+		"Add",
+		"Clear",
+		NULL
+	};
 	static const char * const camera_power_line_frequency[] = {
 		"Disabled",
 		"50 Hz",
@@ -522,6 +537,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
 		return camera_exposure_metering;
 	case V4L2_CID_AUTO_FOCUS_RANGE:
 		return camera_auto_focus_range;
+	case V4L2_CID_BLEND:
+		return blend_modes;
 	case V4L2_CID_COLORFX:
 		return colorfx;
 	case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE:
@@ -655,6 +672,7 @@ const char *v4l2_ctrl_get_name(u32 id)
 	case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:	return "Min Number of Output Buffers";
 	case V4L2_CID_ALPHA_COMPONENT:		return "Alpha Component";
 	case V4L2_CID_COLORFX_CBCR:		return "Color Effects, CbCr";
+	case V4L2_CID_BLEND:			return "Compositing and Blend Modes";
 
 	/* Codec controls */
 	/* The MPEG controls are applicable to all codec controls
@@ -1033,6 +1051,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
 	case V4L2_CID_MPEG_STREAM_VBI_FMT:
 	case V4L2_CID_EXPOSURE_AUTO:
 	case V4L2_CID_AUTO_FOCUS_RANGE:
+	case V4L2_CID_BLEND:
 	case V4L2_CID_COLORFX:
 	case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE:
 	case V4L2_CID_TUNE_PREEMPHASIS:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 0d2e1e0..019fdca 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -140,8 +140,24 @@ enum v4l2_colorfx {
 #define V4L2_CID_ALPHA_COMPONENT		(V4L2_CID_BASE+41)
 #define V4L2_CID_COLORFX_CBCR			(V4L2_CID_BASE+42)
 
+#define V4L2_CID_BLEND				(V4L2_CID_BASE+43)
+enum v4l2_blend_mode {
+	V4L2_BLEND_SRC				= 0,
+	V4L2_BLEND_SRCATOP			= 1,
+	V4L2_BLEND_SRCIN			= 2,
+	V4L2_BLEND_SRCOUT			= 3,
+	V4L2_BLEND_SRCOVER			= 4,
+	V4L2_BLEND_DST				= 5,
+	V4L2_BLEND_DSTATOP			= 6,
+	V4L2_BLEND_DSTIN			= 7,
+	V4L2_BLEND_DSTOUT			= 8,
+	V4L2_BLEND_DSTOVER			= 9,
+	V4L2_BLEND_ADD				= 10,
+	V4L2_BLEND_CLEAR			= 11,
+};
+
 /* last CID + 1 */
-#define V4L2_CID_LASTP1                         (V4L2_CID_BASE+43)
+#define V4L2_CID_LASTP1                         (V4L2_CID_BASE+44)
 
 /* USER-class private control IDs */
 
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1687903 — Re: [PATCH v2 1/6] [media] v4l: add blend modes controls

Hi Jacob,

Thank you for the patch.

On Saturday 15 Jul 2017 14:58:35 Jacob Chen wrote:
> At peresent, we don't have a control for Compositing and Blend.
> All drivers are just doing copies while actually many hardwares
> supports more functions.
> 
> So Adding V4L2 controls for Compositing and Blend, used for for
> composting streams.
> 
> The values are based on porter duff operations.
> Defined in below links.
> https://developer.xamarin.com/api/type/Android.Graphics.PorterDuff+Mode/

According to http://ssp.impulsetrain.com/porterduff.html,

"Despite being referred to as alpha blending and despite alpha often being 
used to model opacity, in concept Porter/Duff is not a way to blend the source 
and destination shapes. It is way to overlay, combine and trim them as if they 
were pieces of cardboard."

It then goes on defining blend modes that are a better match for the 
definition of blend. You might thus want to rename this control.

> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> Suggested-by: Nicolas Dufresne <nicolas@ndufresne.ca>
> ---
>  drivers/media/v4l2-core/v4l2-ctrls.c | 19 +++++++++++++++++++
>  include/uapi/linux/v4l2-controls.h   | 18 +++++++++++++++++-

Controls need to be documented in Documentation/media/uapi/v4l/control.rst or 
Documentation/media/uapi/v4l/extended-controls.rst.

>  2 files changed, 36 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
> b/drivers/media/v4l2-core/v4l2-ctrls.c index b9e08e3..8a235fd 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -216,6 +216,21 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>  		"Private Packet, IVTV Format",
>  		NULL
>  	};
> +	static const char * const blend_modes[] = {
> +		"Source",
> +		"Source Top",
> +		"Source In",
> +		"Source Out",
> +		"Source Over",
> +		"Destination",
> +		"Destination Top",
> +		"Destination In",
> +		"Destination Out",
> +		"Destination Over",
> +		"Add",
> +		"Clear",
> +		NULL
> +	};
>  	static const char * const camera_power_line_frequency[] = {
>  		"Disabled",
>  		"50 Hz",
> @@ -522,6 +537,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
>  		return camera_exposure_metering;
>  	case V4L2_CID_AUTO_FOCUS_RANGE:
>  		return camera_auto_focus_range;
> +	case V4L2_CID_BLEND:
> +		return blend_modes;
>  	case V4L2_CID_COLORFX:
>  		return colorfx;
>  	case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE:
> @@ -655,6 +672,7 @@ const char *v4l2_ctrl_get_name(u32 id)
>  	case V4L2_CID_MIN_BUFFERS_FOR_OUTPUT:	return "Min Number of Output
> Buffers"; case V4L2_CID_ALPHA_COMPONENT:		return "Alpha 
Component";
>  	case V4L2_CID_COLORFX_CBCR:		return "Color Effects, CbCr";
> +	case V4L2_CID_BLEND:			return "Compositing and Blend 
Modes";
> 
>  	/* Codec controls */
>  	/* The MPEG controls are applicable to all codec controls
> @@ -1033,6 +1051,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
> v4l2_ctrl_type *type, case V4L2_CID_MPEG_STREAM_VBI_FMT:
>  	case V4L2_CID_EXPOSURE_AUTO:
>  	case V4L2_CID_AUTO_FOCUS_RANGE:
> +	case V4L2_CID_BLEND:
>  	case V4L2_CID_COLORFX:
>  	case V4L2_CID_AUTO_N_PRESET_WHITE_BALANCE:
>  	case V4L2_CID_TUNE_PREEMPHASIS:
> diff --git a/include/uapi/linux/v4l2-controls.h
> b/include/uapi/linux/v4l2-controls.h index 0d2e1e0..019fdca 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -140,8 +140,24 @@ enum v4l2_colorfx {
>  #define V4L2_CID_ALPHA_COMPONENT		(V4L2_CID_BASE+41)
>  #define V4L2_CID_COLORFX_CBCR			(V4L2_CID_BASE+42)
> 
> +#define V4L2_CID_BLEND				(V4L2_CID_BASE+43)

The image processing class (V4L2_CTRL_CLASS_IMAGE_PROC) would seem like a 
better fit than the base class for this control.

> +enum v4l2_blend_mode {
> +	V4L2_BLEND_SRC				= 0,
> +	V4L2_BLEND_SRCATOP			= 1,
> +	V4L2_BLEND_SRCIN			= 2,
> +	V4L2_BLEND_SRCOUT			= 3,
> +	V4L2_BLEND_SRCOVER			= 4,
> +	V4L2_BLEND_DST				= 5,
> +	V4L2_BLEND_DSTATOP			= 6,
> +	V4L2_BLEND_DSTIN			= 7,
> +	V4L2_BLEND_DSTOUT			= 8,
> +	V4L2_BLEND_DSTOVER			= 9,
> +	V4L2_BLEND_ADD				= 10,
> +	V4L2_BLEND_CLEAR			= 11,
> +};
> + 
>  /* last CID + 1 */
> -#define V4L2_CID_LASTP1                         (V4L2_CID_BASE+43)
> +#define V4L2_CID_LASTP1                         (V4L2_CID_BASE+44)
> 
>  /* USER-class private control IDs */

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1687871 — [PATCH v2 3/6] ARM: dts: rockchip: add RGA device node for RK3288

This patch add the RGA dt config of rk3288 SoC.

Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
---
 arch/arm/boot/dts/rk3288.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 1efc2f2..83d025d 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -945,6 +945,19 @@
 		status = "okay";
 	};
 
+	rga: rga@ff920000 {
+		compatible = "rockchip,rk3288-rga";
+		reg = <0xff920000 0x180>;
+		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "rga";
+		clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru SCLK_RGA>;
+		clock-names = "aclk", "hclk", "sclk";
+		power-domains = <&power RK3288_PD_VIO>;
+		resets = <&cru SRST_RGA_CORE>, <&cru SRST_RGA_AXI>, <&cru SRST_RGA_AHB>;
+		reset-names = "core", "axi", "ahb";
+		status = "disabled";
+	};
+
 	vopb: vop@ff930000 {
 		compatible = "rockchip,rk3288-vop";
 		reg = <0xff930000 0x19c>;
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1687891 — Re: [PATCH v2 3/6] ARM: dts: rockchip: add RGA device node for RK3288

Hi Jacob,

Am Samstag, 15. Juli 2017, 14:58:37 CEST schrieb Jacob Chen:
> This patch add the RGA dt config of rk3288 SoC.
> 
> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>

from the Signed-off it looks like Yakir was te original author of the
patch. So please fix the authorship or drop the top Signed-off by.

Same for other patches like this.


Thanks
Heiko

> ---
>  arch/arm/boot/dts/rk3288.dtsi | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 1efc2f2..83d025d 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -945,6 +945,19 @@
>  		status = "okay";
>  	};
>  
> +	rga: rga@ff920000 {
> +		compatible = "rockchip,rk3288-rga";
> +		reg = <0xff920000 0x180>;
> +		interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-names = "rga";
> +		clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru SCLK_RGA>;
> +		clock-names = "aclk", "hclk", "sclk";
> +		power-domains = <&power RK3288_PD_VIO>;
> +		resets = <&cru SRST_RGA_CORE>, <&cru SRST_RGA_AXI>, <&cru SRST_RGA_AHB>;
> +		reset-names = "core", "axi", "ahb";
> +		status = "disabled";
> +	};
> +
>  	vopb: vop@ff930000 {
>  		compatible = "rockchip,rk3288-vop";
>  		reg = <0xff930000 0x19c>;
> 

[toc] | [prev] | [next] | [standalone]

#1687872 — [PATCH v2 6/6] dt-bindings: Document the Rockchip RGA bindings

Add DT bindings documentation for Rockchip RGA

Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
---
 .../devicetree/bindings/media/rockchip-rga.txt     | 35 ++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt

diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt b/Documentation/devicetree/bindings/media/rockchip-rga.txt
new file mode 100644
index 0000000..966eba0
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt
@@ -0,0 +1,35 @@
+device-tree bindings for rockchip 2D raster graphic acceleration controller (RGA)
+
+RGA is a separate 2D raster graphic acceleration unit. It accelerates 2D
+graphics operations, such as point/line drawing, image scaling, rotation,
+BitBLT, alpha blending and image blur/sharpness.
+
+Required properties:
+- compatible: value should be one of the following
+		"rockchip,rk3228-rga";
+		"rockchip,rk3288-rga";
+		"rockchip,rk3399-rga";
+
+- interrupts: RGA interrupt number.
+
+- clocks: phandle to RGA sclk/hclk/aclk clocks
+
+- clock-names: should be "aclk" "hclk" and "sclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: should be "core" "axi" and "ahb"
+
+Example:
+SoC specific DT entry:
+	rga: rga@ff680000 {
+		compatible = "rockchip,rk3399-rga";
+		reg = <0xff680000 0x10000>;
+		interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "rga";
+		clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru SCLK_RGA_CORE>;
+		clock-names = "aclk", "hclk", "sclk";
+
+		resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru SRST_H_RGA>;
+		reset-names = "core, "axi", "ahb";
+	};
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1687902 — Re: [PATCH v2 6/6] dt-bindings: Document the Rockchip RGA bindings

Hi Jacob,

Thank you for the patch.

On Saturday 15 Jul 2017 14:58:40 Jacob Chen wrote:
> Add DT bindings documentation for Rockchip RGA
> 
> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> ---
>  .../devicetree/bindings/media/rockchip-rga.txt     | 35 +++++++++++++++++++
>  1 file changed, 35 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt
> b/Documentation/devicetree/bindings/media/rockchip-rga.txt new file mode
> 100644
> index 0000000..966eba0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt
> @@ -0,0 +1,35 @@
> +device-tree bindings for rockchip 2D raster graphic acceleration controller
> (RGA)
> +
> +RGA is a separate 2D raster graphic acceleration unit. It accelerates 2D

"Separate" from what ? Do you mean "standalone" ?

> +graphics operations, such as point/line drawing, image scaling, rotation,
> +BitBLT, alpha blending and image blur/sharpness.
> +
> +Required properties:
> +- compatible: value should be one of the following
> +		"rockchip,rk3228-rga";
> +		"rockchip,rk3288-rga";
> +		"rockchip,rk3399-rga";

The driver in patch 2/6 has match entry for rk3328, which is missing from this 
list.

As the implementation of the driver doesn't seem to discriminate between the 
four SoCs, wouldn't it make sense to create a generic compatible string on 
which the driver would match ? You can have both the generic and SoC-specific 
compatible strings in DT if there are differences between the IP core in those 
SoCs that might need to be handled later by the driver.

> +- interrupts: RGA interrupt number.

This is an "interrupt specifier", not just an "interrupt number" (as you can 
see in the example below there are three numbers)

> +
> +- clocks: phandle to RGA sclk/hclk/aclk clocks
> +
> +- clock-names: should be "aclk" "hclk" and "sclk"

Nitpicking, there should be a comma after "aclk".

> +
> +- resets: Must contain an entry for each entry in reset-names.
> +  See ../reset/reset.txt for details.
> +- reset-names: should be "core" "axi" and "ahb"

And a comma after "core".

> +
> +Example:
> +SoC specific DT entry:

s/SoC specific/SoC-specific/

> +	rga: rga@ff680000 {
> +		compatible = "rockchip,rk3399-rga";
> +		reg = <0xff680000 0x10000>;
> +		interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> +		interrupt-names = "rga";

The interrupt-names property is not described above. Do you really need it ?

> +		clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru 
SCLK_RGA_CORE>;
> +		clock-names = "aclk", "hclk", "sclk";
> +
> +		resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru 
SRST_H_RGA>;
> +		reset-names = "core, "axi", "ahb";
> +	};

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1688504 — Re: [PATCH v2 6/6] dt-bindings: Document the Rockchip RGA bindings

Hi Laurent,

Am Samstag, 15. Juli 2017, 12:23:12 CEST schrieb Laurent Pinchart:
> On Saturday 15 Jul 2017 14:58:40 Jacob Chen wrote:
> > Add DT bindings documentation for Rockchip RGA
> > 
> > Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> > Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> > ---
> >  .../devicetree/bindings/media/rockchip-rga.txt     | 35 +++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/media/rockchip-rga.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt
> > b/Documentation/devicetree/bindings/media/rockchip-rga.txt new file mode
> > 100644
> > index 0000000..966eba0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt
> > @@ -0,0 +1,35 @@
> > +device-tree bindings for rockchip 2D raster graphic acceleration controller
> > (RGA)
> > +
> > +RGA is a separate 2D raster graphic acceleration unit. It accelerates 2D
> 
> "Separate" from what ? Do you mean "standalone" ?
> 
> > +graphics operations, such as point/line drawing, image scaling, rotation,
> > +BitBLT, alpha blending and image blur/sharpness.
> > +
> > +Required properties:
> > +- compatible: value should be one of the following
> > +		"rockchip,rk3228-rga";
> > +		"rockchip,rk3288-rga";
> > +		"rockchip,rk3399-rga";
> 
> The driver in patch 2/6 has match entry for rk3328, which is missing from this 
> list.
> 
> As the implementation of the driver doesn't seem to discriminate between the 
> four SoCs, wouldn't it make sense to create a generic compatible string on 
> which the driver would match ? You can have both the generic and SoC-specific 
> compatible strings in DT if there are differences between the IP core in those 
> SoCs that might need to be handled later by the driver.

I think the block is named something like RGA2 in some kernel trees, but
am not sure if that is an actual name, or someone just added a number.
From short glances at vendor rga-code in the past, it looks like there are
currently 2 basic versions of the in existence I.e. older Rockchip socs
(like the rk3188 or so) use something older.

I think everywhere else we do have only (or at least mostly) soc-specifc
compatibles, but I guess that is more a question what Rob prefers.


Heiko

> > +- interrupts: RGA interrupt number.
> 
> This is an "interrupt specifier", not just an "interrupt number" (as you can 
> see in the example below there are three numbers)
> 
> > +
> > +- clocks: phandle to RGA sclk/hclk/aclk clocks
> > +
> > +- clock-names: should be "aclk" "hclk" and "sclk"
> 
> Nitpicking, there should be a comma after "aclk".
> 
> > +
> > +- resets: Must contain an entry for each entry in reset-names.
> > +  See ../reset/reset.txt for details.
> > +- reset-names: should be "core" "axi" and "ahb"
> 
> And a comma after "core".
> 
> > +
> > +Example:
> > +SoC specific DT entry:
> 
> s/SoC specific/SoC-specific/
> 
> > +	rga: rga@ff680000 {
> > +		compatible = "rockchip,rk3399-rga";
> > +		reg = <0xff680000 0x10000>;
> > +		interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> > +		interrupt-names = "rga";
> 
> The interrupt-names property is not described above. Do you really need it ?
> 
> > +		clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru 
> SCLK_RGA_CORE>;
> > +		clock-names = "aclk", "hclk", "sclk";
> > +
> > +		resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru 
> SRST_H_RGA>;
> > +		reset-names = "core, "axi", "ahb";
> > +	};
> 
> 

[toc] | [prev] | [next] | [standalone]

#1688608 — Re: [PATCH v2 6/6] dt-bindings: Document the Rockchip RGA bindings

Hi Heiko,

On Sunday 16 Jul 2017 18:07:58 Heiko Stuebner wrote:
> Am Samstag, 15. Juli 2017, 12:23:12 CEST schrieb Laurent Pinchart:
> > On Saturday 15 Jul 2017 14:58:40 Jacob Chen wrote:
> >> Add DT bindings documentation for Rockchip RGA
> >> 
> >> Signed-off-by: Yakir Yang <ykk@rock-chips.com>
> >> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> >> ---
> >> 
> >>  .../devicetree/bindings/media/rockchip-rga.txt     | 35 +++++++++++++++
> >>  1 file changed, 35 insertions(+)
> >>  create mode 100644
> >>  Documentation/devicetree/bindings/media/rockchip-rga.txt
> >> 
> >> diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.txt
> >> b/Documentation/devicetree/bindings/media/rockchip-rga.txt new file mode
> >> 100644
> >> index 0000000..966eba0
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/rockchip-rga.txt
> >> @@ -0,0 +1,35 @@
> >> +device-tree bindings for rockchip 2D raster graphic acceleration
> >> controller (RGA)
> >> +
> >> +RGA is a separate 2D raster graphic acceleration unit. It accelerates
> >> 2D
> > 
> > "Separate" from what ? Do you mean "standalone" ?
> > 
> >> +graphics operations, such as point/line drawing, image scaling,
> >> rotation,
> >> +BitBLT, alpha blending and image blur/sharpness.
> >> +
> >> +Required properties:
> >> +- compatible: value should be one of the following
> >> +		"rockchip,rk3228-rga";
> >> +		"rockchip,rk3288-rga";
> >> +		"rockchip,rk3399-rga";
> > 
> > The driver in patch 2/6 has match entry for rk3328, which is missing from
> > this list.
> > 
> > As the implementation of the driver doesn't seem to discriminate between
> > the four SoCs, wouldn't it make sense to create a generic compatible
> > string on which the driver would match ? You can have both the generic
> > and SoC-specific compatible strings in DT if there are differences
> > between the IP core in those SoCs that might need to be handled later by
> > the driver.
> 
> I think the block is named something like RGA2 in some kernel trees, but
> am not sure if that is an actual name, or someone just added a number.
> From short glances at vendor rga-code in the past, it looks like there are
> currently 2 basic versions of the in existence I.e. older Rockchip socs
> (like the rk3188 or so) use something older.
> 
> I think everywhere else we do have only (or at least mostly) soc-specifc
> compatibles, but I guess that is more a question what Rob prefers.

Many SoC vendors use SoC-specific compatible string, often in addition to more 
generic ones. When a more generic compatible string is available, drivers can 
match against it, which avoid having to update drivers every time a new SoC 
integrates the same version of the IP core. The SoC-specific compatible string 
is still specified in DT, "just in case" we later realize that the IP core 
integrated in the SoC is slightly different than the other ones and requires 
specific handling in the driver.

I'm not completely happy with that scheme, as it's really a workaround for 
defective communication with the hardware team (or possibly defective hardware 
development...), but that's the best compromise we have so far.

> >> +- interrupts: RGA interrupt number.
> > 
> > This is an "interrupt specifier", not just an "interrupt number" (as you
> > can see in the example below there are three numbers)
> > 
> >> +
> >> +- clocks: phandle to RGA sclk/hclk/aclk clocks
> >> +
> >> +- clock-names: should be "aclk" "hclk" and "sclk"
> > 
> > Nitpicking, there should be a comma after "aclk".
> > 
> >> +
> >> +- resets: Must contain an entry for each entry in reset-names.
> >> +  See ../reset/reset.txt for details.
> >> +- reset-names: should be "core" "axi" and "ahb"
> > 
> > And a comma after "core".
> > 
> >> +
> >> +Example:
> >> +SoC specific DT entry:
> >
> > s/SoC specific/SoC-specific/
> > 
> >> +	rga: rga@ff680000 {
> >> +		compatible = "rockchip,rk3399-rga";
> >> +		reg = <0xff680000 0x10000>;
> >> +		interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
> >> +		interrupt-names = "rga";
> > 
> > The interrupt-names property is not described above. Do you really need it
> > ?
> >
> >> +		clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru
> >> SCLK_RGA_CORE>;
> >> +		clock-names = "aclk", "hclk", "sclk";
> >> +
> >> +		resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru
> >> SRST_H_RGA>;
> >> +		reset-names = "core, "axi", "ahb";
> >> +	};

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1687873 — [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices

Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
---
 arch/arm/boot/dts/rk3288-evb.dtsi                 | 4 ++++
 arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 4 ++++
 arch/arm/boot/dts/rk3288-firefly.dtsi             | 4 ++++
 arch/arm/boot/dts/rk3288-miqi.dts                 | 4 ++++
 arch/arm/boot/dts/rk3288-popmetal.dts             | 4 ++++
 arch/arm/boot/dts/rk3288-tinker.dts               | 4 ++++
 6 files changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi b/arch/arm/boot/dts/rk3288-evb.dtsi
index 4905760..ec12162 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -379,6 +379,10 @@
 	};
 };
 
+&rga {
+	status = "okay";
+};
+
 &usbphy {
 	status = "okay";
 };
diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
index 8134966..fffa92e2 100644
--- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
@@ -283,6 +283,10 @@
 	};
 };
 
+&rga {
+	status = "okay";
+};
+
 &tsadc {
 	rockchip,hw-tshut-mode = <0>;
 	rockchip,hw-tshut-polarity = <0>;
diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi b/arch/arm/boot/dts/rk3288-firefly.dtsi
index f520589..74a6ce5 100644
--- a/arch/arm/boot/dts/rk3288-firefly.dtsi
+++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
@@ -500,6 +500,10 @@
 	};
 };
 
+&rga {
+	status = "okay";
+};
+
 &saradc {
 	vref-supply = <&vcc_18>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/rk3288-miqi.dts b/arch/arm/boot/dts/rk3288-miqi.dts
index 21326f3..dc5e6bd 100644
--- a/arch/arm/boot/dts/rk3288-miqi.dts
+++ b/arch/arm/boot/dts/rk3288-miqi.dts
@@ -401,6 +401,10 @@
 	};
 };
 
+&rga {
+	status = "okay";
+};
+
 &saradc {
 	vref-supply = <&vcc_18>;
 	status = "okay";
diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts b/arch/arm/boot/dts/rk3288-popmetal.dts
index aa1f9ec..362e5aa 100644
--- a/arch/arm/boot/dts/rk3288-popmetal.dts
+++ b/arch/arm/boot/dts/rk3288-popmetal.dts
@@ -490,6 +490,10 @@
 	};
 };
 
+&rga {
+	status = "okay";
+};
+
 &tsadc {
 	rockchip,hw-tshut-mode = <0>;
 	rockchip,hw-tshut-polarity = <0>;
diff --git a/arch/arm/boot/dts/rk3288-tinker.dts b/arch/arm/boot/dts/rk3288-tinker.dts
index 525b0e5..1a8c149 100644
--- a/arch/arm/boot/dts/rk3288-tinker.dts
+++ b/arch/arm/boot/dts/rk3288-tinker.dts
@@ -460,6 +460,10 @@
 	status = "okay";
 };
 
+&rga {
+	status = "okay";
+};
+
 &saradc {
 	vref-supply = <&vcc18_ldo1>;
 	status ="okay";
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1687899 — Re: [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices

Hi Jacob,

Thank you for the patch.

On Saturday 15 Jul 2017 14:58:39 Jacob Chen wrote:
> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> ---
>  arch/arm/boot/dts/rk3288-evb.dtsi                 | 4 ++++
>  arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 4 ++++
>  arch/arm/boot/dts/rk3288-firefly.dtsi             | 4 ++++
>  arch/arm/boot/dts/rk3288-miqi.dts                 | 4 ++++
>  arch/arm/boot/dts/rk3288-popmetal.dts             | 4 ++++
>  arch/arm/boot/dts/rk3288-tinker.dts               | 4 ++++

Some boards are missing from this list (Fennec, Phycore, ...) What criteria 
have you used to decide on which ones to enable the RGA ? That should be 
explained in the commit message.

>  6 files changed, 24 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
> b/arch/arm/boot/dts/rk3288-evb.dtsi index 4905760..ec12162 100644
> --- a/arch/arm/boot/dts/rk3288-evb.dtsi
> +++ b/arch/arm/boot/dts/rk3288-evb.dtsi
> @@ -379,6 +379,10 @@
>  	};
>  };
> 
> +&rga {
> +	status = "okay";
> +};
> +
>  &usbphy {
>  	status = "okay";
>  };
> diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi index 8134966..fffa92e2
> 100644
> --- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> +++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> @@ -283,6 +283,10 @@
>  	};
>  };
> 
> +&rga {
> +	status = "okay";
> +};
> +
>  &tsadc {
>  	rockchip,hw-tshut-mode = <0>;
>  	rockchip,hw-tshut-polarity = <0>;
> diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
> b/arch/arm/boot/dts/rk3288-firefly.dtsi index f520589..74a6ce5 100644
> --- a/arch/arm/boot/dts/rk3288-firefly.dtsi
> +++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
> @@ -500,6 +500,10 @@
>  	};
>  };
> 
> +&rga {
> +	status = "okay";
> +};
> +
>  &saradc {
>  	vref-supply = <&vcc_18>;
>  	status = "okay";
> diff --git a/arch/arm/boot/dts/rk3288-miqi.dts
> b/arch/arm/boot/dts/rk3288-miqi.dts index 21326f3..dc5e6bd 100644
> --- a/arch/arm/boot/dts/rk3288-miqi.dts
> +++ b/arch/arm/boot/dts/rk3288-miqi.dts
> @@ -401,6 +401,10 @@
>  	};
>  };
> 
> +&rga {
> +	status = "okay";
> +};
> +
>  &saradc {
>  	vref-supply = <&vcc_18>;
>  	status = "okay";
> diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts
> b/arch/arm/boot/dts/rk3288-popmetal.dts index aa1f9ec..362e5aa 100644
> --- a/arch/arm/boot/dts/rk3288-popmetal.dts
> +++ b/arch/arm/boot/dts/rk3288-popmetal.dts
> @@ -490,6 +490,10 @@
>  	};
>  };
> 
> +&rga {
> +	status = "okay";
> +};
> +
>  &tsadc {
>  	rockchip,hw-tshut-mode = <0>;
>  	rockchip,hw-tshut-polarity = <0>;
> diff --git a/arch/arm/boot/dts/rk3288-tinker.dts
> b/arch/arm/boot/dts/rk3288-tinker.dts index 525b0e5..1a8c149 100644
> --- a/arch/arm/boot/dts/rk3288-tinker.dts
> +++ b/arch/arm/boot/dts/rk3288-tinker.dts
> @@ -460,6 +460,10 @@
>  	status = "okay";
>  };
> 
> +&rga {
> +	status = "okay";
> +};
> +
>  &saradc {
>  	vref-supply = <&vcc18_ldo1>;
>  	status ="okay";

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1688113 — Re: [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices

Hi Laurent,

2017-07-15 17:16 GMT+08:00 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Jacob,
>
> Thank you for the patch.
>
> On Saturday 15 Jul 2017 14:58:39 Jacob Chen wrote:
>> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
>> ---
>>  arch/arm/boot/dts/rk3288-evb.dtsi                 | 4 ++++
>>  arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 4 ++++
>>  arch/arm/boot/dts/rk3288-firefly.dtsi             | 4 ++++
>>  arch/arm/boot/dts/rk3288-miqi.dts                 | 4 ++++
>>  arch/arm/boot/dts/rk3288-popmetal.dts             | 4 ++++
>>  arch/arm/boot/dts/rk3288-tinker.dts               | 4 ++++
>
> Some boards are missing from this list (Fennec, Phycore, ...) What criteria
> have you used to decide on which ones to enable the RGA ? That should be
> explained in the commit message.
>

Ok.

I just enable the boards i have tested, because i can't make sure it
won't break the other board
because of clocks or power-domains.

>>  6 files changed, 24 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
>> b/arch/arm/boot/dts/rk3288-evb.dtsi index 4905760..ec12162 100644
>> --- a/arch/arm/boot/dts/rk3288-evb.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-evb.dtsi
>> @@ -379,6 +379,10 @@
>>       };
>>  };
>>
>> +&rga {
>> +     status = "okay";
>> +};
>> +
>>  &usbphy {
>>       status = "okay";
>>  };
>> diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
>> b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi index 8134966..fffa92e2
>> 100644
>> --- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
>> @@ -283,6 +283,10 @@
>>       };
>>  };
>>
>> +&rga {
>> +     status = "okay";
>> +};
>> +
>>  &tsadc {
>>       rockchip,hw-tshut-mode = <0>;
>>       rockchip,hw-tshut-polarity = <0>;
>> diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi
>> b/arch/arm/boot/dts/rk3288-firefly.dtsi index f520589..74a6ce5 100644
>> --- a/arch/arm/boot/dts/rk3288-firefly.dtsi
>> +++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
>> @@ -500,6 +500,10 @@
>>       };
>>  };
>>
>> +&rga {
>> +     status = "okay";
>> +};
>> +
>>  &saradc {
>>       vref-supply = <&vcc_18>;
>>       status = "okay";
>> diff --git a/arch/arm/boot/dts/rk3288-miqi.dts
>> b/arch/arm/boot/dts/rk3288-miqi.dts index 21326f3..dc5e6bd 100644
>> --- a/arch/arm/boot/dts/rk3288-miqi.dts
>> +++ b/arch/arm/boot/dts/rk3288-miqi.dts
>> @@ -401,6 +401,10 @@
>>       };
>>  };
>>
>> +&rga {
>> +     status = "okay";
>> +};
>> +
>>  &saradc {
>>       vref-supply = <&vcc_18>;
>>       status = "okay";
>> diff --git a/arch/arm/boot/dts/rk3288-popmetal.dts
>> b/arch/arm/boot/dts/rk3288-popmetal.dts index aa1f9ec..362e5aa 100644
>> --- a/arch/arm/boot/dts/rk3288-popmetal.dts
>> +++ b/arch/arm/boot/dts/rk3288-popmetal.dts
>> @@ -490,6 +490,10 @@
>>       };
>>  };
>>
>> +&rga {
>> +     status = "okay";
>> +};
>> +
>>  &tsadc {
>>       rockchip,hw-tshut-mode = <0>;
>>       rockchip,hw-tshut-polarity = <0>;
>> diff --git a/arch/arm/boot/dts/rk3288-tinker.dts
>> b/arch/arm/boot/dts/rk3288-tinker.dts index 525b0e5..1a8c149 100644
>> --- a/arch/arm/boot/dts/rk3288-tinker.dts
>> +++ b/arch/arm/boot/dts/rk3288-tinker.dts
>> @@ -460,6 +460,10 @@
>>       status = "okay";
>>  };
>>
>> +&rga {
>> +     status = "okay";
>> +};
>> +
>>  &saradc {
>>       vref-supply = <&vcc18_ldo1>;
>>       status ="okay";
>
> --
> Regards,
>
> Laurent Pinchart
>

[toc] | [prev] | [next] | [standalone]

#1688606 — Re: [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices

Hi Jacob,

On Sunday 16 Jul 2017 12:23:02 Jacob Chen wrote:
> 2017-07-15 17:16 GMT+08:00 Laurent Pinchart:
> > On Saturday 15 Jul 2017 14:58:39 Jacob Chen wrote:
> >> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> >> ---
> >> 
> >>  arch/arm/boot/dts/rk3288-evb.dtsi                 | 4 ++++
> >>  arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 4 ++++
> >>  arch/arm/boot/dts/rk3288-firefly.dtsi             | 4 ++++
> >>  arch/arm/boot/dts/rk3288-miqi.dts                 | 4 ++++
> >>  arch/arm/boot/dts/rk3288-popmetal.dts             | 4 ++++
> >>  arch/arm/boot/dts/rk3288-tinker.dts               | 4 ++++
> > 
> > Some boards are missing from this list (Fennec, Phycore, ...) What
> > criteria have you used to decide on which ones to enable the RGA ? That
> > should be explained in the commit message.
> 
> Ok.
> 
> I just enable the boards i have tested, because i can't make sure it
> won't break the other board because of clocks or power-domains.

Given the clocks and power domains shouldn't be board-specific, would it make 
sense to try and get the change tested on the remaining boards ? You could 
then enable the device in the SoC .dtsi file, which would be much simpler.

> >>  6 files changed, 24 insertions(+)

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1688616 — Re: [PATCH v2 5/6] ARM: dts: rockchip: enable RGA for rk3288 devices

Hi Laurent,

2017-07-17 10:28 GMT+08:00 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Jacob,
>
> On Sunday 16 Jul 2017 12:23:02 Jacob Chen wrote:
>> 2017-07-15 17:16 GMT+08:00 Laurent Pinchart:
>> > On Saturday 15 Jul 2017 14:58:39 Jacob Chen wrote:
>> >> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
>> >> ---
>> >>
>> >>  arch/arm/boot/dts/rk3288-evb.dtsi                 | 4 ++++
>> >>  arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 4 ++++
>> >>  arch/arm/boot/dts/rk3288-firefly.dtsi             | 4 ++++
>> >>  arch/arm/boot/dts/rk3288-miqi.dts                 | 4 ++++
>> >>  arch/arm/boot/dts/rk3288-popmetal.dts             | 4 ++++
>> >>  arch/arm/boot/dts/rk3288-tinker.dts               | 4 ++++
>> >
>> > Some boards are missing from this list (Fennec, Phycore, ...) What
>> > criteria have you used to decide on which ones to enable the RGA ? That
>> > should be explained in the commit message.
>>
>> Ok.
>>
>> I just enable the boards i have tested, because i can't make sure it
>> won't break the other board because of clocks or power-domains.
>
> Given the clocks and power domains shouldn't be board-specific, would it make
> sense to try and get the change tested on the remaining boards ? You could

Not all drivers have handle power domains and clocks appropriately, It
may triggers bugs,
but since it's a V4l2 driver not DRM driver, i will enable it for all
rk3288 boards.
(DRM device will try to probe in very eraly stage and update
clocks/power-domains...)


> then enable the device in the SoC .dtsi file, which would be much simpler.
>

We have many different version RGA drivers in rockchip downstream kernel.
To keep consistent, i didn't enable it in .dtsi.


>> >>  6 files changed, 24 insertions(+)
>
> --
> Regards,
>
> Laurent Pinchart
>

[toc] | [prev] | [next] | [standalone]

#1687874 — [PATCH v2 4/6] ARM: dts: rockchip: add RGA device node for RK3399

This patch add the RGA dt config of RK3399 SoC.

Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
---
 arch/arm64/boot/dts/rockchip/rk3399.dtsi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
index 8e6d1bd..fc33ce5 100644
--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
@@ -1056,6 +1056,19 @@
 		status = "disabled";
 	};
 
+	rga: rga@ff680000 {
+		compatible = "rockchip,rk3399-rga";
+		reg = <0x0 0xff680000 0x0 0x10000>;
+		interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH 0>;
+		interrupt-names = "rga";
+		clocks = <&cru ACLK_RGA>, <&cru HCLK_RGA>, <&cru SCLK_RGA_CORE>;
+		clock-names = "aclk", "hclk", "sclk";
+		resets = <&cru SRST_RGA_CORE>, <&cru SRST_A_RGA>, <&cru SRST_H_RGA>;
+		reset-names = "core", "axi", "ahb";
+		power-domains = <&power RK3399_PD_RGA>;
+		status = "disabled";
+	};
+
 	efuse0: efuse@ff690000 {
 		compatible = "rockchip,rk3399-efuse";
 		reg = <0x0 0xff690000 0x0 0x80>;
-- 
2.7.4

[toc] | [prev] | [next] | [standalone]

#1687905 — Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support

Hi Jacob,

Thank you for the patch.

On Saturday 15 Jul 2017 14:58:36 Jacob Chen wrote:
> Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> accelerates 2D graphics operations, such as point/line drawing, image
> scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
> 
> The drvier is mostly based on s5p-g2d v4l2 m2m driver.
> And supports various operations from the rendering pipeline.
>  - copy
>  - fast solid color fill
>  - rotation
>  - flip
>  - alpha blending

I notice that you don't support the drawing operations. How do you plan to 
support them later through the V4L2 M2M API ? I hate stating the obvious, but 
wouldn't the DRM API be better fit for a graphic accelerator ?

Additionally, V4L2 M2M has one source and one destination. How do you 
implement alpha blending in that case, which by definition requires at least 
two sources ?

> The code in rga-hw.c is used to configure regs accroding to operations.
> 
> The code in rga-buf.c is used to create private mmu table for RGA.
> The tables is stored in a list, and be removed when buffer is cleanup.

Looking at the implementation it seems to be a scatter-gather list, not an 
MMU. Is that right ? Does the hardware documentation refer to it as an MMU ?

> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> ---
>  drivers/media/platform/Kconfig                |  11 +
>  drivers/media/platform/Makefile               |   2 +
>  drivers/media/platform/rockchip-rga/Makefile  |   3 +
>  drivers/media/platform/rockchip-rga/rga-buf.c | 122 ++++
>  drivers/media/platform/rockchip-rga/rga-hw.c  | 652 ++++++++++++++++++
>  drivers/media/platform/rockchip-rga/rga-hw.h  | 437 ++++++++++++
>  drivers/media/platform/rockchip-rga/rga.c     | 958 +++++++++++++++++++++++
>  drivers/media/platform/rockchip-rga/rga.h     | 111 +++
>  8 files changed, 2296 insertions(+)
>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1687967 — Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support

Le samedi 15 juillet 2017 à 12:42 +0300, Laurent Pinchart a écrit :
> Hi Jacob,
> 
> Thank you for the patch.
> 
> On Saturday 15 Jul 2017 14:58:36 Jacob Chen wrote:
> > Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> > accelerates 2D graphics operations, such as point/line drawing, image
> > scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
> > 
> > The drvier is mostly based on s5p-g2d v4l2 m2m driver.
> > And supports various operations from the rendering pipeline.
> >  - copy
> >  - fast solid color fill
> >  - rotation
> >  - flip
> >  - alpha blending
> 
> I notice that you don't support the drawing operations. How do you plan to 
> support them later through the V4L2 M2M API ? I hate stating the obvious, but 
> wouldn't the DRM API be better fit for a graphic accelerator ?

It could fit, maybe, but it really lacks some framework. Also, DRM is
not really meant for M2M operation, and it's also not great for multi-
process. Until recently, there was competing drivers for Exynos, both
implemented in V4L2 and DRM, for similar rational, all DRM ones are
being deprecated/removed.

I think 2D blitters in V4L2 are fine, but they terribly lack something
to differentiate them from converters/scalers when looking up the HW
list. Could be as simple as a capability flag, if I can suggest. For
the reference, the 2D blitter on IMX6 has been used to implement a live
video mixer in GStreamer.

https://bugzilla.gnome.org/show_bug.cgi?id=772766

> 
> Additionally, V4L2 M2M has one source and one destination. How do you 
> implement alpha blending in that case, which by definition requires at least 
> two sources ?

This type of HW only do in-place blits. When using such a node, the
buffer queued on the V4L2_CAPTURE contains the destination image, and
the buffer queued on the V4L2_OUTPUT is the source image.

> 
> > The code in rga-hw.c is used to configure regs accroding to operations.
> > 
> > The code in rga-buf.c is used to create private mmu table for RGA.
> > The tables is stored in a list, and be removed when buffer is cleanup.
> 
> Looking at the implementation it seems to be a scatter-gather list, not an 
> MMU. Is that right ? Does the hardware documentation refer to it as an MMU ?
> 
> > Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> > ---
> >  drivers/media/platform/Kconfig                |  11 +
> >  drivers/media/platform/Makefile               |   2 +
> >  drivers/media/platform/rockchip-rga/Makefile  |   3 +
> >  drivers/media/platform/rockchip-rga/rga-buf.c | 122 ++++
> >  drivers/media/platform/rockchip-rga/rga-hw.c  | 652 ++++++++++++++++++
> >  drivers/media/platform/rockchip-rga/rga-hw.h  | 437 ++++++++++++
> >  drivers/media/platform/rockchip-rga/rga.c     | 958 +++++++++++++++++++++++
> >  drivers/media/platform/rockchip-rga/rga.h     | 111 +++
> >  8 files changed, 2296 insertions(+)
> >  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
> >  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
> >  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
> >  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
> >  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
> >  create mode 100644 drivers/media/platform/rockchip-rga/rga.h
> 
> 

[toc] | [prev] | [next] | [standalone]

#1688105 — Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support

Hi all,

2017-07-16 0:49 GMT+08:00 Personnel <nicolas@ndufresne.ca>:
> Le samedi 15 juillet 2017 à 12:42 +0300, Laurent Pinchart a écrit :
>> Hi Jacob,
>>
>> Thank you for the patch.
>>
>> On Saturday 15 Jul 2017 14:58:36 Jacob Chen wrote:
>> > Rockchip RGA is a separate 2D raster graphic acceleration unit. It
>> > accelerates 2D graphics operations, such as point/line drawing, image
>> > scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
>> >
>> > The drvier is mostly based on s5p-g2d v4l2 m2m driver.
>> > And supports various operations from the rendering pipeline.
>> >  - copy
>> >  - fast solid color fill
>> >  - rotation
>> >  - flip
>> >  - alpha blending
>>
>> I notice that you don't support the drawing operations. How do you plan to
>> support them later through the V4L2 M2M API ? I hate stating the obvious, but
>> wouldn't the DRM API be better fit for a graphic accelerator ?
>
> It could fit, maybe, but it really lacks some framework. Also, DRM is
> not really meant for M2M operation, and it's also not great for multi-
> process. Until recently, there was competing drivers for Exynos, both
> implemented in V4L2 and DRM, for similar rational, all DRM ones are
> being deprecated/removed.
>
> I think 2D blitters in V4L2 are fine, but they terribly lack something
> to differentiate them from converters/scalers when looking up the HW
> list. Could be as simple as a capability flag, if I can suggest. For
> the reference, the 2D blitter on IMX6 has been used to implement a live
> video mixer in GStreamer.
>
> https://bugzilla.gnome.org/show_bug.cgi?id=772766
>

We have write a drm RGA driver.
https://patchwork.kernel.org/patch/8630841/

Here are the reasons that why i rewrite it to V4l2 M2M.
1. V4l2 have a better buffer framework. If it use DRM-GEM to handle buffers,
there will be much redundant cache flush, and we have to add much hack code
to workaround.
2. This driver will be used in rockchip linux project. We mostly use it to
scale/colorconvert/rotate/mix video/camera stream.
A V4L2 M2M drvier can be directly used in gstreamer.

The disadvantages of V4l2 M2M API is that it's not stateless.
It's inconvenient if user change size frequently, but it's OK,
we have not yet need this and I think it's possible to extend. ; )


>>
>> Additionally, V4L2 M2M has one source and one destination. How do you
>> implement alpha blending in that case, which by definition requires at least
>> two sources ?
>
> This type of HW only do in-place blits. When using such a node, the
> buffer queued on the V4L2_CAPTURE contains the destination image, and
> the buffer queued on the V4L2_OUTPUT is the source image.
>

Yep.

>>
>> > The code in rga-hw.c is used to configure regs accroding to operations.
>> >
>> > The code in rga-buf.c is used to create private mmu table for RGA.
>> > The tables is stored in a list, and be removed when buffer is cleanup.
>>
>> Looking at the implementation it seems to be a scatter-gather list, not an
>> MMU. Is that right ? Does the hardware documentation refer to it as an MMU ?
>>

It's a 1-level MMU... We use it like a scatter-gather list,
It's also the reason why we don't use RGA with DRM API.


>> > Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
>> > ---
>> >  drivers/media/platform/Kconfig                |  11 +
>> >  drivers/media/platform/Makefile               |   2 +
>> >  drivers/media/platform/rockchip-rga/Makefile  |   3 +
>> >  drivers/media/platform/rockchip-rga/rga-buf.c | 122 ++++
>> >  drivers/media/platform/rockchip-rga/rga-hw.c  | 652 ++++++++++++++++++
>> >  drivers/media/platform/rockchip-rga/rga-hw.h  | 437 ++++++++++++
>> >  drivers/media/platform/rockchip-rga/rga.c     | 958 +++++++++++++++++++++++
>> >  drivers/media/platform/rockchip-rga/rga.h     | 111 +++
>> >  8 files changed, 2296 insertions(+)
>> >  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>> >  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>> >  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>> >  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>> >  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>> >  create mode 100644 drivers/media/platform/rockchip-rga/rga.h
>>
>>

[toc] | [prev] | [next] | [standalone]

#1688614 — Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support

Hi Jacob,

On Sunday 16 Jul 2017 12:19:41 Jacob Chen wrote:
> 2017-07-16 0:49 GMT+08:00 Personnel:
> > Le samedi 15 juillet 2017 à 12:42 +0300, Laurent Pinchart a écrit :
> >> On Saturday 15 Jul 2017 14:58:36 Jacob Chen wrote:
> >> > Rockchip RGA is a separate 2D raster graphic acceleration unit. It
> >> > accelerates 2D graphics operations, such as point/line drawing, image
> >> > scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
> >> > 
> >> > The drvier is mostly based on s5p-g2d v4l2 m2m driver.
> >> > And supports various operations from the rendering pipeline.
> >> > 
> >> >  - copy
> >> >  - fast solid color fill
> >> >  - rotation
> >> >  - flip
> >> >  - alpha blending
> >> 
> >> I notice that you don't support the drawing operations. How do you plan
> >> to support them later through the V4L2 M2M API ? I hate stating the
> >> obvious, but wouldn't the DRM API be better fit for a graphic accelerator
> >> ?
> > 
> > It could fit, maybe, but it really lacks some framework. Also, DRM is
> > not really meant for M2M operation, and it's also not great for multi-
> > process. Until recently, there was competing drivers for Exynos, both
> > implemented in V4L2 and DRM, for similar rational, all DRM ones are
> > being deprecated/removed.
> > 
> > I think 2D blitters in V4L2 are fine, but they terribly lack something
> > to differentiate them from converters/scalers when looking up the HW
> > list. Could be as simple as a capability flag, if I can suggest. For
> > the reference, the 2D blitter on IMX6 has been used to implement a live
> > video mixer in GStreamer.
> > 
> > https://bugzilla.gnome.org/show_bug.cgi?id=772766
> 
> We have write a drm RGA driver.
> https://patchwork.kernel.org/patch/8630841/
> 
> Here are the reasons that why i rewrite it to V4l2 M2M.
> 1. V4l2 have a better buffer framework. If it use DRM-GEM to handle buffers,
> there will be much redundant cache flush, and we have to add much hack code
> to workaround.

I'm glad to hear that you find buffer handling easy in V4L2 :-)

> 2. This driver will be used in rockchip linux project. We mostly use it to
> scale/colorconvert/rotate/mix video/camera stream.
> A V4L2 M2M drvier can be directly used in gstreamer.
> 
> The disadvantages of V4l2 M2M API is that it's not stateless.
> It's inconvenient if user change size frequently, but it's OK,
> we have not yet need this and I think it's possible to extend. ;)

CC'ing Alexandre Courbot. Alex, how's the request API going ? :-)

> >> Additionally, V4L2 M2M has one source and one destination. How do you
> >> implement alpha blending in that case, which by definition requires at
> >> least two sources ?
> > 
> > This type of HW only do in-place blits. When using such a node, the
> > buffer queued on the V4L2_CAPTURE contains the destination image, and
> > the buffer queued on the V4L2_OUTPUT is the source image.
> 
> Yep.

So the device performs bi-directional DMA on the capture queue buffers ? 
Interesting, does videobuf2 support that properly ?

> >>> The code in rga-hw.c is used to configure regs accroding to operations.
> >>> 
> >>> The code in rga-buf.c is used to create private mmu table for RGA.
> >>> The tables is stored in a list, and be removed when buffer is cleanup.
> >> 
> >> Looking at the implementation it seems to be a scatter-gather list, not
> >> an MMU. Is that right ? Does the hardware documentation refer to it as an
> >> MMU ?
> 
> It's a 1-level MMU... We use it like a scatter-gather list,
> It's also the reason why we don't use RGA with DRM API.

You might want to explain this in the code, otherwise someone will ask you why 
you don't implement support for the MMU through the IOMMU API. Calling it 
scatter-gather would solve that problem, but if the hardware manual calls it 
an MMU, there's no reason not to use that name in the code.

> >>> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
> >>> ---
> >>> 
> >>>  drivers/media/platform/Kconfig                |  11 +
> >>>  drivers/media/platform/Makefile               |   2 +
> >>>  drivers/media/platform/rockchip-rga/Makefile  |   3 +
> >>>  drivers/media/platform/rockchip-rga/rga-buf.c | 122 ++++
> >>>  drivers/media/platform/rockchip-rga/rga-hw.c  | 652 ++++++++++++++++++
> >>>  drivers/media/platform/rockchip-rga/rga-hw.h  | 437 ++++++++++++
> >>>  drivers/media/platform/rockchip-rga/rga.c     | 958 ++++++++++++++++++
> >>>  drivers/media/platform/rockchip-rga/rga.h     | 111 +++
> >>>  8 files changed, 2296 insertions(+)
> >>>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h

-- 
Regards,

Laurent Pinchart

[toc] | [prev] | [next] | [standalone]

#1688630 — Re: [PATCH v2 2/6] [media] rockchip/rga: v4l2 m2m support

Hi,

2017-07-17 10:43 GMT+08:00 Laurent Pinchart <laurent.pinchart@ideasonboard.com>:
> Hi Jacob,
>
> On Sunday 16 Jul 2017 12:19:41 Jacob Chen wrote:
>> 2017-07-16 0:49 GMT+08:00 Personnel:
>> > Le samedi 15 juillet 2017 à 12:42 +0300, Laurent Pinchart a écrit :
>> >> On Saturday 15 Jul 2017 14:58:36 Jacob Chen wrote:
>> >> > Rockchip RGA is a separate 2D raster graphic acceleration unit. It
>> >> > accelerates 2D graphics operations, such as point/line drawing, image
>> >> > scaling, rotation, BitBLT, alpha blending and image blur/sharpness.
>> >> >
>> >> > The drvier is mostly based on s5p-g2d v4l2 m2m driver.
>> >> > And supports various operations from the rendering pipeline.
>> >> >
>> >> >  - copy
>> >> >  - fast solid color fill
>> >> >  - rotation
>> >> >  - flip
>> >> >  - alpha blending
>> >>
>> >> I notice that you don't support the drawing operations. How do you plan
>> >> to support them later through the V4L2 M2M API ? I hate stating the
>> >> obvious, but wouldn't the DRM API be better fit for a graphic accelerator
>> >> ?
>> >
>> > It could fit, maybe, but it really lacks some framework. Also, DRM is
>> > not really meant for M2M operation, and it's also not great for multi-
>> > process. Until recently, there was competing drivers for Exynos, both
>> > implemented in V4L2 and DRM, for similar rational, all DRM ones are
>> > being deprecated/removed.
>> >
>> > I think 2D blitters in V4L2 are fine, but they terribly lack something
>> > to differentiate them from converters/scalers when looking up the HW
>> > list. Could be as simple as a capability flag, if I can suggest. For
>> > the reference, the 2D blitter on IMX6 has been used to implement a live
>> > video mixer in GStreamer.
>> >
>> > https://bugzilla.gnome.org/show_bug.cgi?id=772766
>>
>> We have write a drm RGA driver.
>> https://patchwork.kernel.org/patch/8630841/
>>
>> Here are the reasons that why i rewrite it to V4l2 M2M.
>> 1. V4l2 have a better buffer framework. If it use DRM-GEM to handle buffers,
>> there will be much redundant cache flush, and we have to add much hack code
>> to workaround.
>
> I'm glad to hear that you find buffer handling easy in V4L2 :-)
>
>> 2. This driver will be used in rockchip linux project. We mostly use it to
>> scale/colorconvert/rotate/mix video/camera stream.
>> A V4L2 M2M drvier can be directly used in gstreamer.
>>
>> The disadvantages of V4l2 M2M API is that it's not stateless.
>> It's inconvenient if user change size frequently, but it's OK,
>> we have not yet need this and I think it's possible to extend. ;)
>
> CC'ing Alexandre Courbot. Alex, how's the request API going ? :-)
>
>> >> Additionally, V4L2 M2M has one source and one destination. How do you
>> >> implement alpha blending in that case, which by definition requires at
>> >> least two sources ?
>> >
>> > This type of HW only do in-place blits. When using such a node, the
>> > buffer queued on the V4L2_CAPTURE contains the destination image, and
>> > the buffer queued on the V4L2_OUTPUT is the source image.
>>
>> Yep.
>
> So the device performs bi-directional DMA on the capture queue buffers ?
> Interesting, does videobuf2 support that properly ?
>

From the code, I think V4L2_CAPTURE and V4L2_OUTPUT are handled
in the same way. In my test, it work properly.


>> >>> The code in rga-hw.c is used to configure regs accroding to operations.
>> >>>
>> >>> The code in rga-buf.c is used to create private mmu table for RGA.
>> >>> The tables is stored in a list, and be removed when buffer is cleanup.
>> >>
>> >> Looking at the implementation it seems to be a scatter-gather list, not
>> >> an MMU. Is that right ? Does the hardware documentation refer to it as an
>> >> MMU ?
>>
>> It's a 1-level MMU... We use it like a scatter-gather list,
>> It's also the reason why we don't use RGA with DRM API.
>
> You might want to explain this in the code, otherwise someone will ask you why
> you don't implement support for the MMU through the IOMMU API. Calling it
> scatter-gather would solve that problem, but if the hardware manual calls it
> an MMU, there's no reason not to use that name in the code.
>

ok, i will add comments

>> >>> Signed-off-by: Jacob Chen <jacob-chen@iotwrt.com>
>> >>> ---
>> >>>
>> >>>  drivers/media/platform/Kconfig                |  11 +
>> >>>  drivers/media/platform/Makefile               |   2 +
>> >>>  drivers/media/platform/rockchip-rga/Makefile  |   3 +
>> >>>  drivers/media/platform/rockchip-rga/rga-buf.c | 122 ++++
>> >>>  drivers/media/platform/rockchip-rga/rga-hw.c  | 652 ++++++++++++++++++
>> >>>  drivers/media/platform/rockchip-rga/rga-hw.h  | 437 ++++++++++++
>> >>>  drivers/media/platform/rockchip-rga/rga.c     | 958 ++++++++++++++++++
>> >>>  drivers/media/platform/rockchip-rga/rga.h     | 111 +++
>> >>>  8 files changed, 2296 insertions(+)
>> >>>  create mode 100644 drivers/media/platform/rockchip-rga/Makefile
>> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga-buf.c
>> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.c
>> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga-hw.h
>> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga.c
>> >>>  create mode 100644 drivers/media/platform/rockchip-rga/rga.h
>
> --
> Regards,
>
> Laurent Pinchart
>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web