linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC
@ 2020-03-25  8:50 Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 1/8] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression Neil Armstrong
                   ` (7 more replies)
  0 siblings, 8 replies; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25  8:50 UTC (permalink / raw)
  To: daniel, dri-devel
  Cc: mjourdan, Neil Armstrong, linux-kernel, ppaalanen, linux-amlogic,
	brian.starkey, linux-arm-kernel

Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.

It considerably reduces memory bandwidth while writing and reading
frames in memory.

The underlying storage is considered to be 3 components, 8bit or 10-bit
per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT

This modifier will be notably added to DMA-BUF frames imported from the V4L2
Amlogic VDEC decoder.

At least two layout are supported :
- Basic: composed of a body and a header
- Scatter: the buffer is filled with a IOMMU scatter table referring
  to the encoder current memory layout. This mode if more efficient in terms
  of memory allocation but frames are not dumpable and only valid during until
  the buffer is freed and back in control of the encoder

At least two options are supported :
- Memory saving: when the pixel bpp is 8b, the size of the superblock can
  be reduced, thus saving memory.

This serie adds the missing register, updated the FBC decoder registers
content to be committed by the crtc code.

The Amlogic FBC has been tested with compressed content from the Amlogic
HW VP9 decoder on S905X (GXL), S905D2 (G12A) and S905X3 (SM1) in 8bit
(Scatter+Mem Saving on G12A/SM1, Mem Saving on GXL) and 10bit
(Scatter on G12A/SM1, default on GXL).

It's expected to work as-is on GXM and G12B SoCs.

Changes since v3 at [3]:
- added dropped fourcc patch for scatter
- fixed build of last patch

Changes since v2 at [2]:
- Added "BASIC" layout and moved the SCATTER mode as layout, making
  BASIC and SCATTER layout exclusives
- Moved the Memory Saving at bit 8 for options fields
- Split fourcc and overlay patch to introduce basic, mem saving and then
  scatter in separate patches
- Added comment about "transferability" of the buffers

Changes since v1 at [1]:
- s/VD1_AXI_SEL_AFB/VD1_AXI_SEL_AFBC/ into meson_registers.h

[1] https://patchwork.freedesktop.org/series/73722/#rev1
[2] https://patchwork.freedesktop.org/series/73722/#rev2

Neil Armstrong (8):
  drm/fourcc: Add modifier definitions for describing Amlogic Video
    Framebuffer Compression
  drm/meson: add Amlogic Video FBC registers
  drm/meson: overlay: setup overlay for Amlogic FBC
  drm/meson: crtc: handle commit of Amlogic FBC frames
  drm/fourcc: amlogic: Add modifier definitions for Memory Saving option
  drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode
  drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
  drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory
    layout

 drivers/gpu/drm/meson/meson_crtc.c      | 118 ++++++++---
 drivers/gpu/drm/meson/meson_drv.h       |  16 ++
 drivers/gpu/drm/meson/meson_overlay.c   | 257 +++++++++++++++++++++++-
 drivers/gpu/drm/meson/meson_registers.h |  22 ++
 include/uapi/drm/drm_fourcc.h           |  66 ++++++
 5 files changed, 441 insertions(+), 38 deletions(-)

-- 
2.22.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* [PATCH v4 1/8] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression
  2020-03-25  8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
@ 2020-03-25  8:50 ` Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 2/8] drm/meson: add Amlogic Video FBC registers Neil Armstrong
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25  8:50 UTC (permalink / raw)
  To: daniel, dri-devel
  Cc: mjourdan, Neil Armstrong, Kevin Hilman, linux-kernel, ppaalanen,
	linux-amlogic, brian.starkey, linux-arm-kernel

Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.

It considerably reduces memory bandwidth while writing and reading
frames in memory.

The underlying storage is considered to be 3 components, 8bit or 10-bit
per component, YCbCr 420, single plane :
- DRM_FORMAT_YUV420_8BIT
- DRM_FORMAT_YUV420_10BIT

This modifier will be notably added to DMA-BUF frames imported from the V4L2
Amlogic VDEC decoder.

This introduces the basic layout composed of:
- a body content organized in 64x32 superblocks with 4096 bytes per
  superblock in default mode.
- a 32 bytes per 128x64 header block

This layout is tranferrable between Amlogic SoCs supporting this modifier.

Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 include/uapi/drm/drm_fourcc.h | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8bc0b31597d8..6564813d2f7a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -309,6 +309,7 @@ extern "C" {
 #define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
 #define DRM_FORMAT_MOD_VENDOR_ARM     0x08
 #define DRM_FORMAT_MOD_VENDOR_ALLWINNER 0x09
+#define DRM_FORMAT_MOD_VENDOR_AMLOGIC 0x0a
 
 /* add more to the end as needed */
 
@@ -804,6 +805,35 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_ALLWINNER_TILED fourcc_mod_code(ALLWINNER, 1)
 
+/*
+ * Amlogic Video Framebuffer Compression modifiers
+ *
+ * Amlogic uses a proprietary lossless image compression protocol and format
+ * for their hardware video codec accelerators, either video decoders or
+ * video input encoders.
+ *
+ * It considerably reduces memory bandwidth while writing and reading
+ * frames in memory.
+ *
+ * The underlying storage is considered to be 3 components, 8bit or 10-bit
+ * per component YCbCr 420, single plane :
+ * - DRM_FORMAT_YUV420_8BIT
+ * - DRM_FORMAT_YUV420_10BIT
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
+
+/*
+ * Amlogic FBC Basic Layout
+ *
+ * The basic layout is composed of:
+ * - a body content organized in 64x32 superblocks with 4096 bytes per
+ *   superblock in default mode.
+ * - a 32 bytes per 128x64 header block
+ *
+ * This layout is transferrable between Amlogic SoCs supporting this modifier.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC		(1ULL << 0)
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.22.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 2/8] drm/meson: add Amlogic Video FBC registers
  2020-03-25  8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 1/8] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression Neil Armstrong
@ 2020-03-25  8:50 ` Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 3/8] drm/meson: overlay: setup overlay for Amlogic FBC Neil Armstrong
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25  8:50 UTC (permalink / raw)
  To: daniel, dri-devel
  Cc: mjourdan, Neil Armstrong, Kevin Hilman, linux-kernel, ppaalanen,
	linux-amlogic, brian.starkey, linux-arm-kernel

Add the registers of the VPU VD1 Amlogic FBC decoder module, and routing
register.

Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/gpu/drm/meson/meson_registers.h | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/meson/meson_registers.h b/drivers/gpu/drm/meson/meson_registers.h
index 8ea00546cd4e..08631fdfe4b9 100644
--- a/drivers/gpu/drm/meson/meson_registers.h
+++ b/drivers/gpu/drm/meson/meson_registers.h
@@ -144,10 +144,15 @@
 #define		VIU_SW_RESET_OSD1               BIT(0)
 #define VIU_MISC_CTRL0 0x1a06
 #define		VIU_CTRL0_VD1_AFBC_MASK         0x170000
+#define		VIU_CTRL0_AFBC_TO_VD1		BIT(20)
 #define VIU_MISC_CTRL1 0x1a07
 #define		MALI_AFBC_MISC			GENMASK(15, 8)
 #define D2D3_INTF_LENGTH 0x1a08
 #define D2D3_INTF_CTRL0 0x1a09
+#define VD1_AFBCD0_MISC_CTRL 0x1a0a
+#define		VD1_AXI_SEL_AFBC		(1 << 12)
+#define		AFBC_VD1_SEL			(1 << 10)
+#define VD2_AFBCD1_MISC_CTRL 0x1a0b
 #define VIU_OSD1_CTRL_STAT 0x1a10
 #define		VIU_OSD1_OSD_BLK_ENABLE         BIT(0)
 #define		VIU_OSD1_OSD_MEM_MODE_LINEAR	BIT(2)
@@ -365,6 +370,23 @@
 #define VIU_OSD1_OETF_LUT_ADDR_PORT 0x1add
 #define VIU_OSD1_OETF_LUT_DATA_PORT 0x1ade
 #define AFBC_ENABLE 0x1ae0
+#define AFBC_MODE 0x1ae1
+#define AFBC_SIZE_IN 0x1ae2
+#define AFBC_DEC_DEF_COLOR 0x1ae3
+#define AFBC_CONV_CTRL 0x1ae4
+#define AFBC_LBUF_DEPTH 0x1ae5
+#define AFBC_HEAD_BADDR 0x1ae6
+#define AFBC_BODY_BADDR 0x1ae7
+#define AFBC_SIZE_OUT 0x1ae8
+#define AFBC_OUT_YSCOPE 0x1ae9
+#define AFBC_STAT 0x1aea
+#define AFBC_VD_CFMT_CTRL 0x1aeb
+#define AFBC_VD_CFMT_W 0x1aec
+#define AFBC_MIF_HOR_SCOPE 0x1aed
+#define AFBC_MIF_VER_SCOPE 0x1aee
+#define AFBC_PIXEL_HOR_SCOPE 0x1aef
+#define AFBC_PIXEL_VER_SCOPE 0x1af0
+#define AFBC_VD_CFMT_H 0x1af1
 
 /* vpp */
 #define VPP_DUMMY_DATA 0x1d00
-- 
2.22.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 3/8] drm/meson: overlay: setup overlay for Amlogic FBC
  2020-03-25  8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 1/8] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 2/8] drm/meson: add Amlogic Video FBC registers Neil Armstrong
@ 2020-03-25  8:50 ` Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 4/8] drm/meson: crtc: handle commit of Amlogic FBC frames Neil Armstrong
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25  8:50 UTC (permalink / raw)
  To: daniel, dri-devel
  Cc: mjourdan, Neil Armstrong, Kevin Hilman, linux-kernel, ppaalanen,
	linux-amlogic, brian.starkey, linux-arm-kernel

Setup the Amlogic FBC decoder for the VD1 video overlay plane.

The VD1 Amlogic FBC decoder is integrated in the pipeline like the
YUV pixel reading/formatter but used a direct memory address instead.

This adds support for the basic layout, and needs to calculate the content
body size since the header is allocated after.

Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/gpu/drm/meson/meson_drv.h     |  16 ++
 drivers/gpu/drm/meson/meson_overlay.c | 233 +++++++++++++++++++++++++-
 2 files changed, 241 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_drv.h b/drivers/gpu/drm/meson/meson_drv.h
index 04fdf3826643..da951964e988 100644
--- a/drivers/gpu/drm/meson/meson_drv.h
+++ b/drivers/gpu/drm/meson/meson_drv.h
@@ -80,6 +80,7 @@ struct meson_drm {
 
 		bool vd1_enabled;
 		bool vd1_commit;
+		bool vd1_afbc;
 		unsigned int vd1_planes;
 		uint32_t vd1_if0_gen_reg;
 		uint32_t vd1_if0_luma_x0;
@@ -105,6 +106,21 @@ struct meson_drm {
 		uint32_t vd1_height0;
 		uint32_t vd1_height1;
 		uint32_t vd1_height2;
+		uint32_t vd1_afbc_mode;
+		uint32_t vd1_afbc_en;
+		uint32_t vd1_afbc_head_addr;
+		uint32_t vd1_afbc_body_addr;
+		uint32_t vd1_afbc_conv_ctrl;
+		uint32_t vd1_afbc_dec_def_color;
+		uint32_t vd1_afbc_vd_cfmt_ctrl;
+		uint32_t vd1_afbc_vd_cfmt_w;
+		uint32_t vd1_afbc_vd_cfmt_h;
+		uint32_t vd1_afbc_mif_hor_scope;
+		uint32_t vd1_afbc_mif_ver_scope;
+		uint32_t vd1_afbc_size_out;
+		uint32_t vd1_afbc_pixel_hor_scope;
+		uint32_t vd1_afbc_pixel_ver_scope;
+		uint32_t vd1_afbc_size_in;
 		uint32_t vpp_pic_in_height;
 		uint32_t vpp_postblend_vd1_h_start_end;
 		uint32_t vpp_postblend_vd1_v_start_end;
diff --git a/drivers/gpu/drm/meson/meson_overlay.c b/drivers/gpu/drm/meson/meson_overlay.c
index 2468b0212d52..51fa038ad5d7 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -5,6 +5,7 @@
  * Copyright (C) 2015 Amlogic, Inc. All rights reserved.
  */
 
+#define DEBUG
 #include <linux/bitfield.h>
 
 #include <drm/drm_atomic.h>
@@ -76,6 +77,84 @@
 #define VD_REGION24_START(value)	FIELD_PREP(GENMASK(11, 0), value)
 #define VD_REGION13_END(value)		FIELD_PREP(GENMASK(27, 16), value)
 
+/* AFBC_ENABLE */
+#define AFBC_DEC_ENABLE			BIT(8)
+#define AFBC_FRM_START			BIT(0)
+
+/* AFBC_MODE */
+#define AFBC_HORZ_SKIP_UV(value)	FIELD_PREP(GENMASK(1, 0), value)
+#define AFBC_VERT_SKIP_UV(value)	FIELD_PREP(GENMASK(3, 2), value)
+#define AFBC_HORZ_SKIP_Y(value)		FIELD_PREP(GENMASK(5, 4), value)
+#define AFBC_VERT_SKIP_Y(value)		FIELD_PREP(GENMASK(7, 6), value)
+#define AFBC_COMPBITS_YUV(value)	FIELD_PREP(GENMASK(13, 8), value)
+#define AFBC_COMPBITS_8BIT		0
+#define AFBC_COMPBITS_10BIT		(2 | (2 << 2) | (2 << 4))
+#define AFBC_BURST_LEN(value)		FIELD_PREP(GENMASK(15, 14), value)
+#define AFBC_HOLD_LINE_NUM(value)	FIELD_PREP(GENMASK(22, 16), value)
+#define AFBC_MIF_URGENT(value)		FIELD_PREP(GENMASK(25, 24), value)
+#define AFBC_REV_MODE(value)		FIELD_PREP(GENMASK(27, 26), value)
+#define AFBC_BLK_MEM_MODE		BIT(28)
+#define AFBC_SCATTER_MODE		BIT(29)
+#define AFBC_SOFT_RESET			BIT(31)
+
+/* AFBC_SIZE_IN */
+#define AFBC_HSIZE_IN(value)		FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_IN(value)		FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_DEC_DEF_COLOR */
+#define AFBC_DEF_COLOR_Y(value)		FIELD_PREP(GENMASK(29, 20), value)
+#define AFBC_DEF_COLOR_U(value)		FIELD_PREP(GENMASK(19, 10), value)
+#define AFBC_DEF_COLOR_V(value)		FIELD_PREP(GENMASK(9, 0), value)
+
+/* AFBC_CONV_CTRL */
+#define AFBC_CONV_LBUF_LEN(value)	FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_LBUF_DEPTH */
+#define AFBC_DEC_LBUF_DEPTH(value)	FIELD_PREP(GENMASK(27, 16), value)
+#define AFBC_MIF_LBUF_DEPTH(value)	FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_OUT_XSCOPE/AFBC_SIZE_OUT */
+#define AFBC_HSIZE_OUT(value)		FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_VSIZE_OUT(value)		FIELD_PREP(GENMASK(12, 0), value)
+#define AFBC_OUT_HORZ_BGN(value)	FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_HORZ_END(value)	FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_OUT_YSCOPE */
+#define AFBC_OUT_VERT_BGN(value)	FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_OUT_VERT_END(value)	FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_VD_CFMT_CTRL */
+#define AFBC_HORZ_RPT_PIXEL0		BIT(23)
+#define AFBC_HORZ_Y_C_RATIO(value)	FIELD_PREP(GENMASK(22, 21), value)
+#define AFBC_HORZ_FMT_EN		BIT(20)
+#define AFBC_VERT_RPT_LINE0		BIT(16)
+#define AFBC_VERT_INITIAL_PHASE(value)	FIELD_PREP(GENMASK(11, 8), value)
+#define AFBC_VERT_PHASE_STEP(value)	FIELD_PREP(GENMASK(7, 1), value)
+#define AFBC_VERT_FMT_EN		BIT(0)
+
+/* AFBC_VD_CFMT_W */
+#define AFBC_VD_V_WIDTH(value)		FIELD_PREP(GENMASK(11, 0), value)
+#define AFBC_VD_H_WIDTH(value)		FIELD_PREP(GENMASK(27, 16), value)
+
+/* AFBC_MIF_HOR_SCOPE */
+#define AFBC_MIF_BLK_BGN_H(value)	FIELD_PREP(GENMASK(25, 16), value)
+#define AFBC_MIF_BLK_END_H(value)	FIELD_PREP(GENMASK(9, 0), value)
+
+/* AFBC_MIF_VER_SCOPE */
+#define AFBC_MIF_BLK_BGN_V(value)	FIELD_PREP(GENMASK(27, 16), value)
+#define AFBC_MIF_BLK_END_V(value)	FIELD_PREP(GENMASK(11, 0), value)
+
+/* AFBC_PIXEL_HOR_SCOPE */
+#define AFBC_DEC_PIXEL_BGN_H(value)	FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_DEC_PIXEL_END_H(value)	FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_PIXEL_VER_SCOPE */
+#define AFBC_DEC_PIXEL_BGN_V(value)	FIELD_PREP(GENMASK(28, 16), value)
+#define AFBC_DEC_PIXEL_END_V(value)	FIELD_PREP(GENMASK(12, 0), value)
+
+/* AFBC_VD_CFMT_H */
+#define AFBC_VD_HEIGHT(value)		FIELD_PREP(GENMASK(12, 0), value)
+
 struct meson_overlay {
 	struct drm_plane base;
 	struct meson_drm *priv;
@@ -157,6 +236,9 @@ static void meson_overlay_setup_scaler_params(struct meson_drm *priv,
 	unsigned int ratio_x, ratio_y;
 	int temp_height, temp_width;
 	unsigned int w_in, h_in;
+	int afbc_left, afbc_right;
+	int afbc_top_src, afbc_bottom_src;
+	int afbc_top, afbc_bottom;
 	int temp, start, end;
 
 	if (!crtc_state) {
@@ -169,7 +251,7 @@ static void meson_overlay_setup_scaler_params(struct meson_drm *priv,
 
 	w_in = fixed16_to_int(state->src_w);
 	h_in = fixed16_to_int(state->src_h);
-	crop_top = fixed16_to_int(state->src_x);
+	crop_top = fixed16_to_int(state->src_y);
 	crop_left = fixed16_to_int(state->src_x);
 
 	video_top = state->crtc_y;
@@ -243,6 +325,14 @@ static void meson_overlay_setup_scaler_params(struct meson_drm *priv,
 	DRM_DEBUG("vsc startp %d endp %d start_lines %d end_lines %d\n",
 		 vsc_startp, vsc_endp, vd_start_lines, vd_end_lines);
 
+	afbc_top = round_down(vd_start_lines, 4);
+	afbc_bottom = round_up(vd_end_lines + 1, 4);
+	afbc_top_src = 0;
+	afbc_bottom_src = round_up(h_in + 1, 4);
+
+	DRM_DEBUG("afbc top %d (src %d) bottom %d (src %d)\n",
+		  afbc_top, afbc_top_src, afbc_bottom, afbc_bottom_src);
+
 	/* Horizontal */
 
 	start = video_left + video_width / 2 - ((w_in << 17) / ratio_x);
@@ -278,6 +368,16 @@ static void meson_overlay_setup_scaler_params(struct meson_drm *priv,
 	DRM_DEBUG("hsc startp %d endp %d start_lines %d end_lines %d\n",
 		 hsc_startp, hsc_endp, hd_start_lines, hd_end_lines);
 
+	if (hd_start_lines > 0 || (hd_end_lines < w_in)) {
+		afbc_left = 0;
+		afbc_right = round_up(w_in, 32);
+	} else {
+		afbc_left = round_down(hd_start_lines, 32);
+		afbc_right = round_up(hd_end_lines + 1, 32);
+	}
+
+	DRM_DEBUG("afbc left %d right %d\n", afbc_left, afbc_right);
+
 	priv->viu.vpp_vsc_start_phase_step = ratio_y << 6;
 
 	priv->viu.vpp_vsc_ini_phase = vphase << 8;
@@ -293,6 +393,35 @@ static void meson_overlay_setup_scaler_params(struct meson_drm *priv,
 			VD_H_WIDTH(hd_end_lines - hd_start_lines + 1) |
 			VD_V_WIDTH(hd_end_lines/2 - hd_start_lines/2 + 1);
 
+	priv->viu.vd1_afbc_vd_cfmt_w =
+			AFBC_VD_H_WIDTH(afbc_right - afbc_left) |
+			AFBC_VD_V_WIDTH(afbc_right / 2 - afbc_left / 2);
+
+	priv->viu.vd1_afbc_vd_cfmt_h =
+			AFBC_VD_HEIGHT((afbc_bottom - afbc_top) / 2);
+
+	priv->viu.vd1_afbc_mif_hor_scope = AFBC_MIF_BLK_BGN_H(afbc_left / 32) |
+				AFBC_MIF_BLK_END_H((afbc_right / 32) - 1);
+
+	priv->viu.vd1_afbc_mif_ver_scope = AFBC_MIF_BLK_BGN_V(afbc_top / 4) |
+				AFBC_MIF_BLK_END_H((afbc_bottom / 4) - 1);
+
+	priv->viu.vd1_afbc_size_out =
+			AFBC_HSIZE_OUT(afbc_right - afbc_left) |
+			AFBC_VSIZE_OUT(afbc_bottom - afbc_top);
+
+	priv->viu.vd1_afbc_pixel_hor_scope =
+			AFBC_DEC_PIXEL_BGN_H(hd_start_lines - afbc_left) |
+			AFBC_DEC_PIXEL_END_H(hd_end_lines - afbc_left);
+
+	priv->viu.vd1_afbc_pixel_ver_scope =
+			AFBC_DEC_PIXEL_BGN_V(vd_start_lines - afbc_top) |
+			AFBC_DEC_PIXEL_END_V(vd_end_lines - afbc_top);
+
+	priv->viu.vd1_afbc_size_in =
+				AFBC_HSIZE_IN(afbc_right - afbc_left) |
+				AFBC_VSIZE_IN(afbc_bottom_src - afbc_top_src);
+
 	priv->viu.vd1_if0_luma_y0 = VD_Y_START(vd_start_lines) |
 				    VD_Y_END(vd_end_lines);
 
@@ -350,11 +479,57 @@ static void meson_overlay_atomic_update(struct drm_plane *plane,
 
 	spin_lock_irqsave(&priv->drm->event_lock, flags);
 
-	priv->viu.vd1_if0_gen_reg = VD_URGENT_CHROMA |
-				    VD_URGENT_LUMA |
-				    VD_HOLD_LINES(9) |
-				    VD_CHRO_RPT_LASTL_CTRL |
-				    VD_ENABLE;
+	if ((fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC(0)) ==
+			    DRM_FORMAT_MOD_AMLOGIC_FBC(0)) {
+		priv->viu.vd1_afbc = true;
+
+		priv->viu.vd1_afbc_mode = AFBC_MIF_URGENT(3) |
+					  AFBC_HOLD_LINE_NUM(8) |
+					  AFBC_BURST_LEN(2);
+
+		priv->viu.vd1_afbc_en = 0x1600 | AFBC_DEC_ENABLE;
+
+		priv->viu.vd1_afbc_conv_ctrl = AFBC_CONV_LBUF_LEN(256);
+
+		priv->viu.vd1_afbc_dec_def_color = AFBC_DEF_COLOR_Y(1023);
+
+		/* 420: horizontal / 2, vertical / 4 */
+		priv->viu.vd1_afbc_vd_cfmt_ctrl = AFBC_HORZ_RPT_PIXEL0 |
+						  AFBC_HORZ_Y_C_RATIO(1) |
+						  AFBC_HORZ_FMT_EN |
+						  AFBC_VERT_RPT_LINE0 |
+						  AFBC_VERT_INITIAL_PHASE(12) |
+						  AFBC_VERT_PHASE_STEP(8) |
+						  AFBC_VERT_FMT_EN;
+
+		switch (fb->format->format) {
+		/* AFBC Only formats */
+		case DRM_FORMAT_YUV420_10BIT:
+			priv->viu.vd1_afbc_mode |=
+				AFBC_COMPBITS_YUV(AFBC_COMPBITS_10BIT);
+			priv->viu.vd1_afbc_dec_def_color |=
+					AFBC_DEF_COLOR_U(512) |
+					AFBC_DEF_COLOR_V(512);
+			break;
+		case DRM_FORMAT_YUV420_8BIT:
+			priv->viu.vd1_afbc_dec_def_color |=
+					AFBC_DEF_COLOR_U(128) |
+					AFBC_DEF_COLOR_V(128);
+			break;
+		}
+
+		priv->viu.vd1_if0_gen_reg = 0;
+		priv->viu.vd1_if0_canvas0 = 0;
+		priv->viu.viu_vd1_fmt_ctrl = 0;
+	} else {
+		priv->viu.vd1_afbc = false;
+
+		priv->viu.vd1_if0_gen_reg = VD_URGENT_CHROMA |
+					    VD_URGENT_LUMA |
+					    VD_HOLD_LINES(9) |
+					    VD_CHRO_RPT_LASTL_CTRL |
+					    VD_ENABLE;
+	}
 
 	/* Setup scaler params */
 	meson_overlay_setup_scaler_params(priv, plane, interlace_mode);
@@ -370,6 +545,7 @@ static void meson_overlay_atomic_update(struct drm_plane *plane,
 	priv->viu.vd1_if0_gen_reg2 = 0;
 	priv->viu.viu_vd1_fmt_ctrl = 0;
 
+	/* None will match for AFBC Only formats */
 	switch (fb->format->format) {
 	/* TOFIX DRM_FORMAT_RGB888 should be supported */
 	case DRM_FORMAT_YUYV:
@@ -488,13 +664,28 @@ static void meson_overlay_atomic_update(struct drm_plane *plane,
 		priv->viu.vd1_stride0 = fb->pitches[0];
 		priv->viu.vd1_height0 =
 			drm_format_info_plane_height(fb->format,
-						fb->height, 0);
+						     fb->height, 0);
 		DRM_DEBUG("plane 0 addr 0x%x stride %d height %d\n",
 			 priv->viu.vd1_addr0,
 			 priv->viu.vd1_stride0,
 			 priv->viu.vd1_height0);
 	}
 
+	if (priv->viu.vd1_afbc) {
+		unsigned long body_size;
+
+		/* Default mode is 4k per superblock */
+		body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
+			    (ALIGN(priv->viu.vd1_height0, 32) / 32) *
+			    4096;
+
+		priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
+
+		/* Header is after body content */
+		priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
+						body_size) >> 4;
+	}
+
 	priv->viu.vd1_enabled = true;
 
 	spin_unlock_irqrestore(&priv->drm->event_lock, flags);
@@ -531,6 +722,23 @@ static const struct drm_plane_helper_funcs meson_overlay_helper_funcs = {
 	.prepare_fb	= drm_gem_fb_prepare_fb,
 };
 
+static bool meson_overlay_format_mod_supported(struct drm_plane *plane,
+					       u32 format, u64 modifier)
+{
+	if (modifier == DRM_FORMAT_MOD_LINEAR &&
+	    format != DRM_FORMAT_YUV420_8BIT &&
+	    format != DRM_FORMAT_YUV420_10BIT)
+		return true;
+
+	if ((modifier & DRM_FORMAT_MOD_AMLOGIC_FBC(0)) ==
+			DRM_FORMAT_MOD_AMLOGIC_FBC(0) &&
+	    (format == DRM_FORMAT_YUV420_8BIT ||
+	     format == DRM_FORMAT_YUV420_10BIT))
+		return true;
+
+	return false;
+}
+
 static const struct drm_plane_funcs meson_overlay_funcs = {
 	.update_plane		= drm_atomic_helper_update_plane,
 	.disable_plane		= drm_atomic_helper_disable_plane,
@@ -538,6 +746,7 @@ static const struct drm_plane_funcs meson_overlay_funcs = {
 	.reset			= drm_atomic_helper_plane_reset,
 	.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
 	.atomic_destroy_state	= drm_atomic_helper_plane_destroy_state,
+	.format_mod_supported   = meson_overlay_format_mod_supported,
 };
 
 static const uint32_t supported_drm_formats[] = {
@@ -549,6 +758,14 @@ static const uint32_t supported_drm_formats[] = {
 	DRM_FORMAT_YUV420,
 	DRM_FORMAT_YUV411,
 	DRM_FORMAT_YUV410,
+	DRM_FORMAT_YUV420_8BIT, /* Amlogic FBC Only */
+	DRM_FORMAT_YUV420_10BIT, /* Amlogic FBC Only */
+};
+
+static const uint64_t format_modifiers[] = {
+	DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC),
+	DRM_FORMAT_MOD_LINEAR,
+	DRM_FORMAT_MOD_INVALID,
 };
 
 int meson_overlay_create(struct meson_drm *priv)
@@ -570,7 +787,7 @@ int meson_overlay_create(struct meson_drm *priv)
 				 &meson_overlay_funcs,
 				 supported_drm_formats,
 				 ARRAY_SIZE(supported_drm_formats),
-				 NULL,
+				 format_modifiers,
 				 DRM_PLANE_TYPE_OVERLAY, "meson_overlay_plane");
 
 	drm_plane_helper_add(plane, &meson_overlay_helper_funcs);
-- 
2.22.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 4/8] drm/meson: crtc: handle commit of Amlogic FBC frames
  2020-03-25  8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
                   ` (2 preceding siblings ...)
  2020-03-25  8:50 ` [PATCH v4 3/8] drm/meson: overlay: setup overlay for Amlogic FBC Neil Armstrong
@ 2020-03-25  8:50 ` Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 5/8] drm/fourcc: amlogic: Add modifier definitions for Memory Saving option Neil Armstrong
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25  8:50 UTC (permalink / raw)
  To: daniel, dri-devel
  Cc: mjourdan, Neil Armstrong, Kevin Hilman, linux-kernel, ppaalanen,
	linux-amlogic, brian.starkey, linux-arm-kernel

Since the VD1 Amlogic FBC decoder is now configured by the overlay driver,
commit the right registers to decode the Amlogic FBC frame.

Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/gpu/drm/meson/meson_crtc.c | 118 +++++++++++++++++++++--------
 1 file changed, 88 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_crtc.c b/drivers/gpu/drm/meson/meson_crtc.c
index e66b6271ff58..d6dcfd654e9c 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -291,6 +291,10 @@ static void meson_crtc_enable_vd1(struct meson_drm *priv)
 			    VPP_VD1_PREBLEND | VPP_VD1_POSTBLEND |
 			    VPP_COLOR_MNG_ENABLE,
 			    priv->io_base + _REG(VPP_MISC));
+
+	writel_bits_relaxed(VIU_CTRL0_AFBC_TO_VD1,
+			    priv->viu.vd1_afbc ? VIU_CTRL0_AFBC_TO_VD1 : 0,
+			    priv->io_base + _REG(VIU_MISC_CTRL0));
 }
 
 static void meson_g12a_crtc_enable_vd1(struct meson_drm *priv)
@@ -300,6 +304,10 @@ static void meson_g12a_crtc_enable_vd1(struct meson_drm *priv)
 		       VD_BLEND_POSTBLD_SRC_VD1 |
 		       VD_BLEND_POSTBLD_PREMULT_EN,
 		       priv->io_base + _REG(VD1_BLEND_SRC_CTRL));
+
+	writel_relaxed(priv->viu.vd1_afbc ?
+		       (VD1_AXI_SEL_AFBC | AFBC_VD1_SEL) : 0,
+		       priv->io_base + _REG(VD1_AFBCD0_MISC_CTRL));
 }
 
 void meson_crtc_irq(struct meson_drm *priv)
@@ -383,36 +391,86 @@ void meson_crtc_irq(struct meson_drm *priv)
 	/* Update the VD1 registers */
 	if (priv->viu.vd1_enabled && priv->viu.vd1_commit) {
 
-		switch (priv->viu.vd1_planes) {
-		case 3:
-			meson_canvas_config(priv->canvas,
-					    priv->canvas_id_vd1_2,
-					    priv->viu.vd1_addr2,
-					    priv->viu.vd1_stride2,
-					    priv->viu.vd1_height2,
-					    MESON_CANVAS_WRAP_NONE,
-					    MESON_CANVAS_BLKMODE_LINEAR,
-					    MESON_CANVAS_ENDIAN_SWAP64);
-		/* fallthrough */
-		case 2:
-			meson_canvas_config(priv->canvas,
-					    priv->canvas_id_vd1_1,
-					    priv->viu.vd1_addr1,
-					    priv->viu.vd1_stride1,
-					    priv->viu.vd1_height1,
-					    MESON_CANVAS_WRAP_NONE,
-					    MESON_CANVAS_BLKMODE_LINEAR,
-					    MESON_CANVAS_ENDIAN_SWAP64);
-		/* fallthrough */
-		case 1:
-			meson_canvas_config(priv->canvas,
-					    priv->canvas_id_vd1_0,
-					    priv->viu.vd1_addr0,
-					    priv->viu.vd1_stride0,
-					    priv->viu.vd1_height0,
-					    MESON_CANVAS_WRAP_NONE,
-					    MESON_CANVAS_BLKMODE_LINEAR,
-					    MESON_CANVAS_ENDIAN_SWAP64);
+		if (priv->viu.vd1_afbc) {
+			writel_relaxed(priv->viu.vd1_afbc_head_addr,
+				       priv->io_base +
+				       _REG(AFBC_HEAD_BADDR));
+			writel_relaxed(priv->viu.vd1_afbc_body_addr,
+				       priv->io_base +
+				       _REG(AFBC_BODY_BADDR));
+			writel_relaxed(priv->viu.vd1_afbc_en,
+				       priv->io_base +
+				       _REG(AFBC_ENABLE));
+			writel_relaxed(priv->viu.vd1_afbc_mode,
+				       priv->io_base +
+				       _REG(AFBC_MODE));
+			writel_relaxed(priv->viu.vd1_afbc_size_in,
+				       priv->io_base +
+				       _REG(AFBC_SIZE_IN));
+			writel_relaxed(priv->viu.vd1_afbc_dec_def_color,
+				       priv->io_base +
+				       _REG(AFBC_DEC_DEF_COLOR));
+			writel_relaxed(priv->viu.vd1_afbc_conv_ctrl,
+				       priv->io_base +
+				       _REG(AFBC_CONV_CTRL));
+			writel_relaxed(priv->viu.vd1_afbc_size_out,
+				       priv->io_base +
+				       _REG(AFBC_SIZE_OUT));
+			writel_relaxed(priv->viu.vd1_afbc_vd_cfmt_ctrl,
+				       priv->io_base +
+				       _REG(AFBC_VD_CFMT_CTRL));
+			writel_relaxed(priv->viu.vd1_afbc_vd_cfmt_w,
+				       priv->io_base +
+				       _REG(AFBC_VD_CFMT_W));
+			writel_relaxed(priv->viu.vd1_afbc_mif_hor_scope,
+				       priv->io_base +
+				       _REG(AFBC_MIF_HOR_SCOPE));
+			writel_relaxed(priv->viu.vd1_afbc_mif_ver_scope,
+				       priv->io_base +
+				       _REG(AFBC_MIF_VER_SCOPE));
+			writel_relaxed(priv->viu.vd1_afbc_pixel_hor_scope,
+				       priv->io_base+
+				       _REG(AFBC_PIXEL_HOR_SCOPE));
+			writel_relaxed(priv->viu.vd1_afbc_pixel_ver_scope,
+				       priv->io_base +
+				       _REG(AFBC_PIXEL_VER_SCOPE));
+			writel_relaxed(priv->viu.vd1_afbc_vd_cfmt_h,
+				       priv->io_base +
+				       _REG(AFBC_VD_CFMT_H));
+		} else {
+			switch (priv->viu.vd1_planes) {
+			case 3:
+				meson_canvas_config(priv->canvas,
+						    priv->canvas_id_vd1_2,
+						    priv->viu.vd1_addr2,
+						    priv->viu.vd1_stride2,
+						    priv->viu.vd1_height2,
+						    MESON_CANVAS_WRAP_NONE,
+						    MESON_CANVAS_BLKMODE_LINEAR,
+						    MESON_CANVAS_ENDIAN_SWAP64);
+			/* fallthrough */
+			case 2:
+				meson_canvas_config(priv->canvas,
+						    priv->canvas_id_vd1_1,
+						    priv->viu.vd1_addr1,
+						    priv->viu.vd1_stride1,
+						    priv->viu.vd1_height1,
+						    MESON_CANVAS_WRAP_NONE,
+						    MESON_CANVAS_BLKMODE_LINEAR,
+						    MESON_CANVAS_ENDIAN_SWAP64);
+			/* fallthrough */
+			case 1:
+				meson_canvas_config(priv->canvas,
+						    priv->canvas_id_vd1_0,
+						    priv->viu.vd1_addr0,
+						    priv->viu.vd1_stride0,
+						    priv->viu.vd1_height0,
+						    MESON_CANVAS_WRAP_NONE,
+						    MESON_CANVAS_BLKMODE_LINEAR,
+						    MESON_CANVAS_ENDIAN_SWAP64);
+			}
+
+			writel_relaxed(0, priv->io_base + _REG(AFBC_ENABLE));
 		}
 
 		writel_relaxed(priv->viu.vd1_if0_gen_reg,
-- 
2.22.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 5/8] drm/fourcc: amlogic: Add modifier definitions for Memory Saving option
  2020-03-25  8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
                   ` (3 preceding siblings ...)
  2020-03-25  8:50 ` [PATCH v4 4/8] drm/meson: crtc: handle commit of Amlogic FBC frames Neil Armstrong
@ 2020-03-25  8:50 ` Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 6/8] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode Neil Armstrong
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25  8:50 UTC (permalink / raw)
  To: daniel, dri-devel
  Cc: mjourdan, Neil Armstrong, Kevin Hilman, linux-kernel, ppaalanen,
	linux-amlogic, brian.starkey, linux-arm-kernel

Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.

An option exist changing the layout superblock size to save memory when
using 8bit components pixels size.

The layout options starts at the 8th bit, keeping the first 8bits of the
modifiers bits to define the layout.

Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 include/uapi/drm/drm_fourcc.h | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 6564813d2f7a..84edc5d69613 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -819,6 +819,12 @@ extern "C" {
  * per component YCbCr 420, single plane :
  * - DRM_FORMAT_YUV420_8BIT
  * - DRM_FORMAT_YUV420_10BIT
+ *
+ * The first 8 bits of the mode defines the layout, then the following 8 bits
+ * defined the options changing the layout.
+ *
+ * Not all combinations are valid, and different SoCs may support different
+ * combinations of layout and options.
  */
 #define DRM_FORMAT_MOD_AMLOGIC_FBC(__modes) fourcc_mod_code(AMLOGIC, __modes)
 
@@ -834,6 +840,22 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC		(1ULL << 0)
 
+/*
+ * Amlogic FBC Layout Options
+ */
+
+/*
+ * Amlogic FBC Memory Saving mode
+ *
+ * Indicates the storage is packed when pixel size is multiple of word
+ * boudaries, i.e. 8bit should be stored in this mode to save allocation
+ * memory.
+ *
+ * This mode reduces body layout to 3072 bytes per 64x32 superblock with
+ * the basic layout.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING	(1ULL << 8)
+
 #if defined(__cplusplus)
 }
 #endif
-- 
2.22.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 6/8] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode
  2020-03-25  8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
                   ` (4 preceding siblings ...)
  2020-03-25  8:50 ` [PATCH v4 5/8] drm/fourcc: amlogic: Add modifier definitions for Memory Saving option Neil Armstrong
@ 2020-03-25  8:50 ` Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout Neil Armstrong
  2020-03-25  8:50 ` [PATCH v4 8/8] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout Neil Armstrong
  7 siblings, 0 replies; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25  8:50 UTC (permalink / raw)
  To: daniel, dri-devel
  Cc: mjourdan, Neil Armstrong, Kevin Hilman, linux-kernel, ppaalanen,
	linux-amlogic, brian.starkey, linux-arm-kernel

Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
a different superblock size for the Memory Saving mode.

Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/gpu/drm/meson/meson_overlay.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_overlay.c b/drivers/gpu/drm/meson/meson_overlay.c
index 51fa038ad5d7..8b9d4984b2a7 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -487,6 +487,9 @@ static void meson_overlay_atomic_update(struct drm_plane *plane,
 					  AFBC_HOLD_LINE_NUM(8) |
 					  AFBC_BURST_LEN(2);
 
+		if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING)
+			priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
+
 		priv->viu.vd1_afbc_en = 0x1600 | AFBC_DEC_ENABLE;
 
 		priv->viu.vd1_afbc_conv_ctrl = AFBC_CONV_LBUF_LEN(256);
@@ -672,12 +675,17 @@ static void meson_overlay_atomic_update(struct drm_plane *plane,
 	}
 
 	if (priv->viu.vd1_afbc) {
+		/* Default mode is 4k per superblock */
+		unsigned long block_size = 4096;
 		unsigned long body_size;
 
-		/* Default mode is 4k per superblock */
+		/* 8bit mem saving mode is 3072bytes per superblock */
+		if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+			block_size = 3072;
+
 		body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
 			    (ALIGN(priv->viu.vd1_height0, 32) / 32) *
-			    4096;
+			    block_size;
 
 		priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
 
@@ -763,6 +771,8 @@ static const uint32_t supported_drm_formats[] = {
 };
 
 static const uint64_t format_modifiers[] = {
+	DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC |
+				   DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
 	DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC),
 	DRM_FORMAT_MOD_LINEAR,
 	DRM_FORMAT_MOD_INVALID,
-- 
2.22.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
  2020-03-25  8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
                   ` (5 preceding siblings ...)
  2020-03-25  8:50 ` [PATCH v4 6/8] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode Neil Armstrong
@ 2020-03-25  8:50 ` Neil Armstrong
  2020-03-25  9:04   ` Simon Ser
  2020-03-25  8:50 ` [PATCH v4 8/8] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout Neil Armstrong
  7 siblings, 1 reply; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25  8:50 UTC (permalink / raw)
  To: daniel, dri-devel
  Cc: mjourdan, Neil Armstrong, Kevin Hilman, linux-kernel, ppaalanen,
	linux-amlogic, brian.starkey, linux-arm-kernel

Amlogic uses a proprietary lossless image compression protocol and format
for their hardware video codec accelerators, either video decoders or
video input encoders.

This introduces the Scatter Memory layout, means the header contains IOMMU
references to the compressed frames content to optimize memory access
and layout.

In this mode, only the header memory address is needed, thus the content
memory organization is tied to the current producer execution and cannot
be saved/dumped neither transferrable between Amlogic SoCs supporting this
modifier.

Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 include/uapi/drm/drm_fourcc.h | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 84edc5d69613..b49f1d45e1b4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -840,6 +840,19 @@ extern "C" {
  */
 #define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC		(1ULL << 0)
 
+/*
+ * Amlogic FBC Scatter Memory layout
+ *
+ * Indicates the header contains IOMMU references to the compressed
+ * frames content to optimize memory access and layout.
+ *
+ * In this mode, only the header memory address is needed, thus the
+ * content memory organization is tied to the current producer
+ * execution and cannot be saved/dumped neither transferrable between
+ * Amlogic SoCs supporting this modifier.
+ */
+#define DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER	(2ULL << 0)
+
 /*
  * Amlogic FBC Layout Options
  */
@@ -852,7 +865,8 @@ extern "C" {
  * memory.
  *
  * This mode reduces body layout to 3072 bytes per 64x32 superblock with
- * the basic layout.
+ * the basic layout and 3200 bytes per 64x32 superblock combined with
+ * the scatter layout.
  */
 #define DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING	(1ULL << 8)
 
-- 
2.22.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* [PATCH v4 8/8] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout
  2020-03-25  8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
                   ` (6 preceding siblings ...)
  2020-03-25  8:50 ` [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout Neil Armstrong
@ 2020-03-25  8:50 ` Neil Armstrong
  7 siblings, 0 replies; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25  8:50 UTC (permalink / raw)
  To: daniel, dri-devel
  Cc: mjourdan, Neil Armstrong, Kevin Hilman, linux-kernel, ppaalanen,
	linux-amlogic, brian.starkey, linux-arm-kernel

Setup the Amlogic FBC decoder for the VD1 video overlay plane to use
read the FBC header as Scatter Memory layout reference.

Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
 drivers/gpu/drm/meson/meson_overlay.c | 48 +++++++++++++++++----------
 1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/meson/meson_overlay.c b/drivers/gpu/drm/meson/meson_overlay.c
index 8b9d4984b2a7..3c54135f53a0 100644
--- a/drivers/gpu/drm/meson/meson_overlay.c
+++ b/drivers/gpu/drm/meson/meson_overlay.c
@@ -487,6 +487,9 @@ static void meson_overlay_atomic_update(struct drm_plane *plane,
 					  AFBC_HOLD_LINE_NUM(8) |
 					  AFBC_BURST_LEN(2);
 
+		if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER)
+			priv->viu.vd1_afbc_mode |= AFBC_SCATTER_MODE;
+
 		if (fb->modifier & DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING)
 			priv->viu.vd1_afbc_mode |= AFBC_BLK_MEM_MODE;
 
@@ -675,23 +678,32 @@ static void meson_overlay_atomic_update(struct drm_plane *plane,
 	}
 
 	if (priv->viu.vd1_afbc) {
-		/* Default mode is 4k per superblock */
-		unsigned long block_size = 4096;
-		unsigned long body_size;
-
-		/* 8bit mem saving mode is 3072bytes per superblock */
-		if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
-			block_size = 3072;
-
-		body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
-			    (ALIGN(priv->viu.vd1_height0, 32) / 32) *
-			    block_size;
-
-		priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
-
-		/* Header is after body content */
-		priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
-						body_size) >> 4;
+		if (priv->viu.vd1_afbc_mode & AFBC_SCATTER_MODE) {
+			/*
+			 * In Scatter mode, the header contains the physical
+			 * body content layout, thus the body content
+			 * size isn't needed.
+			 */
+			priv->viu.vd1_afbc_head_addr = priv->viu.vd1_addr0 >> 4;
+			priv->viu.vd1_afbc_body_addr = 0;
+		} else {
+			/* Default mode is 4k per superblock */
+			unsigned long block_size = 4096;
+			unsigned long body_size;
+
+			/* 8bit mem saving mode is 3072bytes per superblock */
+			if (priv->viu.vd1_afbc_mode & AFBC_BLK_MEM_MODE)
+				block_size = 3072;
+
+			body_size = (ALIGN(priv->viu.vd1_stride0, 64) / 64) *
+				    (ALIGN(priv->viu.vd1_height0, 32) / 32) *
+				    block_size;
+
+			priv->viu.vd1_afbc_body_addr = priv->viu.vd1_addr0 >> 4;
+			/* Header is after body content */
+			priv->viu.vd1_afbc_head_addr = (priv->viu.vd1_addr0 +
+							body_size) >> 4;
+		}
 	}
 
 	priv->viu.vd1_enabled = true;
@@ -771,6 +783,8 @@ static const uint32_t supported_drm_formats[] = {
 };
 
 static const uint64_t format_modifiers[] = {
+	DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER |
+				   DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
 	DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC |
 				   DRM_FORMAT_MOD_AMLOGIC_FBC_MEM_SAVING),
 	DRM_FORMAT_MOD_AMLOGIC_FBC(DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_BASIC),
-- 
2.22.0


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
  2020-03-25  8:50 ` [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout Neil Armstrong
@ 2020-03-25  9:04   ` Simon Ser
  2020-03-25 10:24     ` Neil Armstrong
  0 siblings, 1 reply; 16+ messages in thread
From: Simon Ser @ 2020-03-25  9:04 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: mjourdan, Kevin Hilman, linux-kernel, dri-devel, daniel,
	linux-amlogic, linux-arm-kernel

On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:

> Amlogic uses a proprietary lossless image compression protocol and format
> for their hardware video codec accelerators, either video decoders or
> video input encoders.
>
> This introduces the Scatter Memory layout, means the header contains IOMMU
> references to the compressed frames content to optimize memory access
> and layout.
>
> In this mode, only the header memory address is needed, thus the content
> memory organization is tied to the current producer execution and cannot
> be saved/dumped neither transferrable between Amlogic SoCs supporting this
> modifier.

I don't think this is suitable for modifiers. User-space relies on
being able to copy a buffer from one machine to another over the
network. It would be pretty annoying for user-space to have a blacklist
of modifiers that don't work this way.

Example of such user-space:
https://gitlab.freedesktop.org/mstoeckl/waypipe/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
  2020-03-25  9:04   ` Simon Ser
@ 2020-03-25 10:24     ` Neil Armstrong
  2020-03-25 13:49       ` Pekka Paalanen
  0 siblings, 1 reply; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25 10:24 UTC (permalink / raw)
  To: Simon Ser
  Cc: mjourdan, Kevin Hilman, linux-kernel, dri-devel, daniel,
	linux-amlogic, linux-arm-kernel

Hi,

On 25/03/2020 10:04, Simon Ser wrote:
> On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> 
>> Amlogic uses a proprietary lossless image compression protocol and format
>> for their hardware video codec accelerators, either video decoders or
>> video input encoders.
>>
>> This introduces the Scatter Memory layout, means the header contains IOMMU
>> references to the compressed frames content to optimize memory access
>> and layout.
>>
>> In this mode, only the header memory address is needed, thus the content
>> memory organization is tied to the current producer execution and cannot
>> be saved/dumped neither transferrable between Amlogic SoCs supporting this
>> modifier.
> 
> I don't think this is suitable for modifiers. User-space relies on
> being able to copy a buffer from one machine to another over the
> network. It would be pretty annoying for user-space to have a blacklist
> of modifiers that don't work this way.
> 
> Example of such user-space:
> https://gitlab.freedesktop.org/mstoeckl/waypipe/
> 

I really understand your point, but this is one of the use-cases we need solve.
This is why I split the fourcc patch and added an explicit comment.

Please point me a way to display such buffer, the HW exists, works like that and
it's a fact and can't change.

It will be the same for secure zero-copy buffers we can't map from userspace, but
only the HW decoder can read/write and HW display can read.

We need a solution for those if we want embedded and secure products to be supported
upstream, otherwise they will stay in an obscure off-tree linux tree and for example
AOSP support (which will support these secure video buffers) will use these vendor
specific hacks.

Neil

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
  2020-03-25 10:24     ` Neil Armstrong
@ 2020-03-25 13:49       ` Pekka Paalanen
  2020-03-25 16:18         ` Neil Armstrong
  0 siblings, 1 reply; 16+ messages in thread
From: Pekka Paalanen @ 2020-03-25 13:49 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: mjourdan, Simon Ser, linux-kernel, dri-devel, Kevin Hilman,
	linux-amlogic, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 2114 bytes --]

On Wed, 25 Mar 2020 11:24:15 +0100
Neil Armstrong <narmstrong@baylibre.com> wrote:

> Hi,
> 
> On 25/03/2020 10:04, Simon Ser wrote:
> > On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> >   
> >> Amlogic uses a proprietary lossless image compression protocol and format
> >> for their hardware video codec accelerators, either video decoders or
> >> video input encoders.
> >>
> >> This introduces the Scatter Memory layout, means the header contains IOMMU
> >> references to the compressed frames content to optimize memory access
> >> and layout.
> >>
> >> In this mode, only the header memory address is needed, thus the content
> >> memory organization is tied to the current producer execution and cannot
> >> be saved/dumped neither transferrable between Amlogic SoCs supporting this
> >> modifier.  
> > 
> > I don't think this is suitable for modifiers. User-space relies on
> > being able to copy a buffer from one machine to another over the
> > network. It would be pretty annoying for user-space to have a blacklist
> > of modifiers that don't work this way.
> > 
> > Example of such user-space:
> > https://gitlab.freedesktop.org/mstoeckl/waypipe/
> >   
> 
> I really understand your point, but this is one of the use-cases we need solve.
> This is why I split the fourcc patch and added an explicit comment.
> 
> Please point me a way to display such buffer, the HW exists, works like that and
> it's a fact and can't change.
> 
> It will be the same for secure zero-copy buffers we can't map from userspace, but
> only the HW decoder can read/write and HW display can read.

The comparison to secure buffers is a good one.

Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier
meaningfully mmappable to CPU always / sometimes / never /
varies-and-cannot-know?

Maybe this type should be handled similar to secure buffers, with the
exception that they are not actually secured but only mostly
inaccessible. Then again, I haven't looked at any of the secure buffer
proposals.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
  2020-03-25 13:49       ` Pekka Paalanen
@ 2020-03-25 16:18         ` Neil Armstrong
  2020-03-26  9:36           ` Pekka Paalanen
  0 siblings, 1 reply; 16+ messages in thread
From: Neil Armstrong @ 2020-03-25 16:18 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: mjourdan, Simon Ser, linux-kernel, dri-devel, Kevin Hilman,
	linux-amlogic, linux-arm-kernel


[-- Attachment #1.1.1: Type: text/plain, Size: 2638 bytes --]

Hi,

On 25/03/2020 14:49, Pekka Paalanen wrote:
> On Wed, 25 Mar 2020 11:24:15 +0100
> Neil Armstrong <narmstrong@baylibre.com> wrote:
> 
>> Hi,
>>
>> On 25/03/2020 10:04, Simon Ser wrote:
>>> On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>   
>>>> Amlogic uses a proprietary lossless image compression protocol and format
>>>> for their hardware video codec accelerators, either video decoders or
>>>> video input encoders.
>>>>
>>>> This introduces the Scatter Memory layout, means the header contains IOMMU
>>>> references to the compressed frames content to optimize memory access
>>>> and layout.
>>>>
>>>> In this mode, only the header memory address is needed, thus the content
>>>> memory organization is tied to the current producer execution and cannot
>>>> be saved/dumped neither transferrable between Amlogic SoCs supporting this
>>>> modifier.  
>>>
>>> I don't think this is suitable for modifiers. User-space relies on
>>> being able to copy a buffer from one machine to another over the
>>> network. It would be pretty annoying for user-space to have a blacklist
>>> of modifiers that don't work this way.
>>>
>>> Example of such user-space:
>>> https://gitlab.freedesktop.org/mstoeckl/waypipe/
>>>   
>>
>> I really understand your point, but this is one of the use-cases we need solve.
>> This is why I split the fourcc patch and added an explicit comment.
>>
>> Please point me a way to display such buffer, the HW exists, works like that and
>> it's a fact and can't change.
>>
>> It will be the same for secure zero-copy buffers we can't map from userspace, but
>> only the HW decoder can read/write and HW display can read.
> 
> The comparison to secure buffers is a good one.
> 
> Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier
> meaningfully mmappable to CPU always / sometimes / never /
> varies-and-cannot-know?

mmappable, yes in our WIP V4L2 driver in non-secure path, meaningful, absolutely never.

So yeah, these should not be mmappable since not meaningful.

> 
> Maybe this type should be handled similar to secure buffers, with the
> exception that they are not actually secured but only mostly
> inaccessible. Then again, I haven't looked at any of the secure buffer
> proposals.

Actually, the Amlogic platforms offers secure video path using these exact
modifiers, AFAIK it doesn't support the NV12 dual-write output in secure.

AFAIK last submission is from AMD, and it doesn't talk at all about mmapability
of the secure BOs.

Neil

> 
> 
> Thanks,
> pq
> 



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
  2020-03-25 16:18         ` Neil Armstrong
@ 2020-03-26  9:36           ` Pekka Paalanen
  2020-03-27 14:14             ` Neil Armstrong
  0 siblings, 1 reply; 16+ messages in thread
From: Pekka Paalanen @ 2020-03-26  9:36 UTC (permalink / raw)
  To: Neil Armstrong
  Cc: mjourdan, Simon Ser, linux-kernel, dri-devel, Kevin Hilman,
	linux-amlogic, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 4323 bytes --]

On Wed, 25 Mar 2020 17:18:15 +0100
Neil Armstrong <narmstrong@baylibre.com> wrote:

> Hi,
> 
> On 25/03/2020 14:49, Pekka Paalanen wrote:
> > On Wed, 25 Mar 2020 11:24:15 +0100
> > Neil Armstrong <narmstrong@baylibre.com> wrote:
> >   
> >> Hi,
> >>
> >> On 25/03/2020 10:04, Simon Ser wrote:  
> >>> On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> >>>     
> >>>> Amlogic uses a proprietary lossless image compression protocol and format
> >>>> for their hardware video codec accelerators, either video decoders or
> >>>> video input encoders.
> >>>>
> >>>> This introduces the Scatter Memory layout, means the header contains IOMMU
> >>>> references to the compressed frames content to optimize memory access
> >>>> and layout.
> >>>>
> >>>> In this mode, only the header memory address is needed, thus the content
> >>>> memory organization is tied to the current producer execution and cannot
> >>>> be saved/dumped neither transferrable between Amlogic SoCs supporting this
> >>>> modifier.    
> >>>
> >>> I don't think this is suitable for modifiers. User-space relies on
> >>> being able to copy a buffer from one machine to another over the
> >>> network. It would be pretty annoying for user-space to have a blacklist
> >>> of modifiers that don't work this way.
> >>>
> >>> Example of such user-space:
> >>> https://gitlab.freedesktop.org/mstoeckl/waypipe/
> >>>     
> >>
> >> I really understand your point, but this is one of the use-cases we need solve.
> >> This is why I split the fourcc patch and added an explicit comment.
> >>
> >> Please point me a way to display such buffer, the HW exists, works like that and
> >> it's a fact and can't change.
> >>
> >> It will be the same for secure zero-copy buffers we can't map from userspace, but
> >> only the HW decoder can read/write and HW display can read.  
> > 
> > The comparison to secure buffers is a good one.
> > 
> > Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier
> > meaningfully mmappable to CPU always / sometimes / never /
> > varies-and-cannot-know?  
> 
> mmappable, yes in our WIP V4L2 driver in non-secure path, meaningful, absolutely never.
> 
> So yeah, these should not be mmappable since not meaningful.

Ok. So we have a modifier that means there is no point in even trying to
mmap the buffer.

Not being able to mmap automatically makes things like waypipe not be
able to work on the buffer, so the buffer cannot be replicated over a
network, hence there is no compatibility issue. However, it still
leaves the problem that, since waypipe is "just" a message relay that
does not participate in the protocol really, the two end points might
still negotiate to use a modifier that waypipe cannot handle.

Secure buffers have the same problem: by definition, one must not be
able to replicate the buffer elsewhere.

To me it seems there needs to be a way to identify buffers that cannot
be mmapped. mmap() failing is obvious, but in waypipe's case it is too
late - the end points have already negotiated the formats and modifiers
and they cannot handle failures afterwards.

> > 
> > Maybe this type should be handled similar to secure buffers, with the
> > exception that they are not actually secured but only mostly
> > inaccessible. Then again, I haven't looked at any of the secure buffer
> > proposals.  
> 
> Actually, the Amlogic platforms offers secure video path using these exact
> modifiers, AFAIK it doesn't support the NV12 dual-write output in secure.
> 
> AFAIK last submission is from AMD, and it doesn't talk at all about mmapability
> of the secure BOs.

To me, a secure buffer concept automatically implies that there cannot
be CPU access to it. The CPU is not trusted, right? Not even the kernel.
I would assume secure implies no mmap. So I wonder, how does the secure
buffers proposal manage userspace like waypipe?

Or, is the secure buffer proposal allowing mmap, but the content is
indecipherable? Maybe they shouldn't allow mmap?

I think much of the criticism against this modifier should also be
presented to a secure buffers proposal and see how that turns out. If
they have the same problem, maybe you could use their solution?


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
  2020-03-26  9:36           ` Pekka Paalanen
@ 2020-03-27 14:14             ` Neil Armstrong
  2020-03-30 14:41               ` Pekka Paalanen
  0 siblings, 1 reply; 16+ messages in thread
From: Neil Armstrong @ 2020-03-27 14:14 UTC (permalink / raw)
  To: Pekka Paalanen
  Cc: mjourdan, Simon Ser, linux-kernel, dri-devel, Kevin Hilman,
	linux-amlogic, linux-arm-kernel


[-- Attachment #1.1.1: Type: text/plain, Size: 5304 bytes --]

Hi,

On 26/03/2020 10:36, Pekka Paalanen wrote:
> On Wed, 25 Mar 2020 17:18:15 +0100
> Neil Armstrong <narmstrong@baylibre.com> wrote:
> 
>> Hi,
>>
>> On 25/03/2020 14:49, Pekka Paalanen wrote:
>>> On Wed, 25 Mar 2020 11:24:15 +0100
>>> Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>   
>>>> Hi,
>>>>
>>>> On 25/03/2020 10:04, Simon Ser wrote:  
>>>>> On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
>>>>>     
>>>>>> Amlogic uses a proprietary lossless image compression protocol and format
>>>>>> for their hardware video codec accelerators, either video decoders or
>>>>>> video input encoders.
>>>>>>
>>>>>> This introduces the Scatter Memory layout, means the header contains IOMMU
>>>>>> references to the compressed frames content to optimize memory access
>>>>>> and layout.
>>>>>>
>>>>>> In this mode, only the header memory address is needed, thus the content
>>>>>> memory organization is tied to the current producer execution and cannot
>>>>>> be saved/dumped neither transferrable between Amlogic SoCs supporting this
>>>>>> modifier.    
>>>>>
>>>>> I don't think this is suitable for modifiers. User-space relies on
>>>>> being able to copy a buffer from one machine to another over the
>>>>> network. It would be pretty annoying for user-space to have a blacklist
>>>>> of modifiers that don't work this way.
>>>>>
>>>>> Example of such user-space:
>>>>> https://gitlab.freedesktop.org/mstoeckl/waypipe/
>>>>>     
>>>>
>>>> I really understand your point, but this is one of the use-cases we need solve.
>>>> This is why I split the fourcc patch and added an explicit comment.
>>>>
>>>> Please point me a way to display such buffer, the HW exists, works like that and
>>>> it's a fact and can't change.
>>>>
>>>> It will be the same for secure zero-copy buffers we can't map from userspace, but
>>>> only the HW decoder can read/write and HW display can read.  
>>>
>>> The comparison to secure buffers is a good one.
>>>
>>> Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier
>>> meaningfully mmappable to CPU always / sometimes / never /
>>> varies-and-cannot-know?  
>>
>> mmappable, yes in our WIP V4L2 driver in non-secure path, meaningful, absolutely never.
>>
>> So yeah, these should not be mmappable since not meaningful.
> 
> Ok. So we have a modifier that means there is no point in even trying to
> mmap the buffer.
> 
> Not being able to mmap automatically makes things like waypipe not be
> able to work on the buffer, so the buffer cannot be replicated over a
> network, hence there is no compatibility issue. However, it still
> leaves the problem that, since waypipe is "just" a message relay that
> does not participate in the protocol really, the two end points might
> still negotiate to use a modifier that waypipe cannot handle.

Not mmapable won't be limited to this kind of buffer, or secure, any DMA-BUF
provider can decide to disable mmaping, so waypipe should work with this
whatever this discussion goes to.

> 
> Secure buffers have the same problem: by definition, one must not be
> able to replicate the buffer elsewhere.
> 
> To me it seems there needs to be a way to identify buffers that cannot
> be mmapped. mmap() failing is obvious, but in waypipe's case it is too
> late - the end points have already negotiated the formats and modifiers
> and they cannot handle failures afterwards.

The AFAIK last open question was on this thread:
https://lore.kernel.org/dri-devel/d6f8092d-9f90-d5ff-2ab3-b1867f8f5700@ti.com/
But it was more like, how the consumer driver knows the buffer is secure.

Daniel, is there something new ?

> 
>>>
>>> Maybe this type should be handled similar to secure buffers, with the
>>> exception that they are not actually secured but only mostly
>>> inaccessible. Then again, I haven't looked at any of the secure buffer
>>> proposals.  
>>
>> Actually, the Amlogic platforms offers secure video path using these exact
>> modifiers, AFAIK it doesn't support the NV12 dual-write output in secure.
>>
>> AFAIK last submission is from AMD, and it doesn't talk at all about mmapability
>> of the secure BOs.
> 
> To me, a secure buffer concept automatically implies that there cannot
> be CPU access to it. The CPU is not trusted, right? Not even the kernel.
> I would assume secure implies no mmap. So I wonder, how does the secure
> buffers proposal manage userspace like waypipe?

None, as I said, waypipe whould handle non mmapable buffers, by asking
for a different modifier set, or sending a gray buffer with a llama
instead.

> 
> Or, is the secure buffer proposal allowing mmap, but the content is
> indecipherable? Maybe they shouldn't allow mmap?

Definitely, you'll have an HW bus error if you access a secure buffer,
otherwise the security is weak. A bus firewall is the common way to handle
such secure buffers.

> 
> I think much of the criticism against this modifier should also be
> presented to a secure buffers proposal and see how that turns out. If
> they have the same problem, maybe you could use their solution?

Sure, but seems there is no consensus for the compositor side.

Neil

> 
> 
> Thanks,
> pq
> 



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
  2020-03-27 14:14             ` Neil Armstrong
@ 2020-03-30 14:41               ` Pekka Paalanen
  0 siblings, 0 replies; 16+ messages in thread
From: Pekka Paalanen @ 2020-03-30 14:41 UTC (permalink / raw)
  To: Neil Armstrong, code
  Cc: mjourdan, Simon Ser, linux-kernel, dri-devel, Daniel Vetter,
	Kevin Hilman, linux-amlogic, linux-arm-kernel


[-- Attachment #1.1: Type: text/plain, Size: 5616 bytes --]

On Fri, 27 Mar 2020 15:14:46 +0100
Neil Armstrong <narmstrong@baylibre.com> wrote:

> Hi,
> 
> On 26/03/2020 10:36, Pekka Paalanen wrote:
> > On Wed, 25 Mar 2020 17:18:15 +0100
> > Neil Armstrong <narmstrong@baylibre.com> wrote:
> >   
> >> Hi,
> >>
> >> On 25/03/2020 14:49, Pekka Paalanen wrote:  
> >>> On Wed, 25 Mar 2020 11:24:15 +0100
> >>> Neil Armstrong <narmstrong@baylibre.com> wrote:
> >>>     
> >>>> Hi,
> >>>>
> >>>> On 25/03/2020 10:04, Simon Ser wrote:    
> >>>>> On Wednesday, March 25, 2020 9:50 AM, Neil Armstrong <narmstrong@baylibre.com> wrote:
> >>>>>       
> >>>>>> Amlogic uses a proprietary lossless image compression protocol and format
> >>>>>> for their hardware video codec accelerators, either video decoders or
> >>>>>> video input encoders.
> >>>>>>
> >>>>>> This introduces the Scatter Memory layout, means the header contains IOMMU
> >>>>>> references to the compressed frames content to optimize memory access
> >>>>>> and layout.
> >>>>>>
> >>>>>> In this mode, only the header memory address is needed, thus the content
> >>>>>> memory organization is tied to the current producer execution and cannot
> >>>>>> be saved/dumped neither transferrable between Amlogic SoCs supporting this
> >>>>>> modifier.      
> >>>>>
> >>>>> I don't think this is suitable for modifiers. User-space relies on
> >>>>> being able to copy a buffer from one machine to another over the
> >>>>> network. It would be pretty annoying for user-space to have a blacklist
> >>>>> of modifiers that don't work this way.
> >>>>>
> >>>>> Example of such user-space:
> >>>>> https://gitlab.freedesktop.org/mstoeckl/waypipe/
> >>>>>       
> >>>>
> >>>> I really understand your point, but this is one of the use-cases we need solve.
> >>>> This is why I split the fourcc patch and added an explicit comment.
> >>>>
> >>>> Please point me a way to display such buffer, the HW exists, works like that and
> >>>> it's a fact and can't change.
> >>>>
> >>>> It will be the same for secure zero-copy buffers we can't map from userspace, but
> >>>> only the HW decoder can read/write and HW display can read.    
> >>>
> >>> The comparison to secure buffers is a good one.
> >>>
> >>> Are buffers with the DRM_FORMAT_MOD_AMLOGIC_FBC_LAYOUT_SCATTER modifier
> >>> meaningfully mmappable to CPU always / sometimes / never /
> >>> varies-and-cannot-know?    
> >>
> >> mmappable, yes in our WIP V4L2 driver in non-secure path, meaningful, absolutely never.
> >>
> >> So yeah, these should not be mmappable since not meaningful.  
> > 
> > Ok. So we have a modifier that means there is no point in even trying to
> > mmap the buffer.
> > 
> > Not being able to mmap automatically makes things like waypipe not be
> > able to work on the buffer, so the buffer cannot be replicated over a
> > network, hence there is no compatibility issue. However, it still
> > leaves the problem that, since waypipe is "just" a message relay that
> > does not participate in the protocol really, the two end points might
> > still negotiate to use a modifier that waypipe cannot handle.  
> 
> Not mmapable won't be limited to this kind of buffer, or secure, any DMA-BUF
> provider can decide to disable mmaping, so waypipe should work with this
> whatever this discussion goes to.
> 
> > 
> > Secure buffers have the same problem: by definition, one must not be
> > able to replicate the buffer elsewhere.
> > 
> > To me it seems there needs to be a way to identify buffers that cannot
> > be mmapped. mmap() failing is obvious, but in waypipe's case it is too
> > late - the end points have already negotiated the formats and modifiers
> > and they cannot handle failures afterwards.  
> 
> The AFAIK last open question was on this thread:
> https://lore.kernel.org/dri-devel/d6f8092d-9f90-d5ff-2ab3-b1867f8f5700@ti.com/
> But it was more like, how the consumer driver knows the buffer is secure.
> 
> Daniel, is there something new ?
> 
> >   
> >>>
> >>> Maybe this type should be handled similar to secure buffers, with the
> >>> exception that they are not actually secured but only mostly
> >>> inaccessible. Then again, I haven't looked at any of the secure buffer
> >>> proposals.    
> >>
> >> Actually, the Amlogic platforms offers secure video path using these exact
> >> modifiers, AFAIK it doesn't support the NV12 dual-write output in secure.
> >>
> >> AFAIK last submission is from AMD, and it doesn't talk at all about mmapability
> >> of the secure BOs.  
> > 
> > To me, a secure buffer concept automatically implies that there cannot
> > be CPU access to it. The CPU is not trusted, right? Not even the kernel.
> > I would assume secure implies no mmap. So I wonder, how does the secure
> > buffers proposal manage userspace like waypipe?  
> 
> None, as I said, waypipe whould handle non mmapable buffers, by asking
> for a different modifier set, or sending a gray buffer with a llama
> instead.

Hi,

the only thing waypipe can do, is not forward some of the modifiers
during negotiation, before any buffers are created. That is, assuming
Waypipe actually understands the protocol it shovels through
(libwayland does not understand Wayland, in comparison).

Or disconnect when mmap() fails.

I'm having second thoughts here on the feasibility of the waypipe use
case. It seems to be simply mutually exclusive with secure buffers and
this modifier here.

Manuel, could you check through this thread and let us know what you
think? Maybe I have misassumed something.


Thanks,
pq

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2020-03-30 14:41 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-25  8:50 [PATCH v4 0/8] drm/meson: add support for Amlogic Video FBC Neil Armstrong
2020-03-25  8:50 ` [PATCH v4 1/8] drm/fourcc: Add modifier definitions for describing Amlogic Video Framebuffer Compression Neil Armstrong
2020-03-25  8:50 ` [PATCH v4 2/8] drm/meson: add Amlogic Video FBC registers Neil Armstrong
2020-03-25  8:50 ` [PATCH v4 3/8] drm/meson: overlay: setup overlay for Amlogic FBC Neil Armstrong
2020-03-25  8:50 ` [PATCH v4 4/8] drm/meson: crtc: handle commit of Amlogic FBC frames Neil Armstrong
2020-03-25  8:50 ` [PATCH v4 5/8] drm/fourcc: amlogic: Add modifier definitions for Memory Saving option Neil Armstrong
2020-03-25  8:50 ` [PATCH v4 6/8] drm/meson: overlay: setup overlay for Amlogic FBC Memory Saving mode Neil Armstrong
2020-03-25  8:50 ` [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout Neil Armstrong
2020-03-25  9:04   ` Simon Ser
2020-03-25 10:24     ` Neil Armstrong
2020-03-25 13:49       ` Pekka Paalanen
2020-03-25 16:18         ` Neil Armstrong
2020-03-26  9:36           ` Pekka Paalanen
2020-03-27 14:14             ` Neil Armstrong
2020-03-30 14:41               ` Pekka Paalanen
2020-03-25  8:50 ` [PATCH v4 8/8] drm/meson: overlay: setup overlay for Amlogic FBC Scatter Memory layout Neil Armstrong

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).