[PATCH v1, 2/3] dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8186
Adds decoder dt-bindings for mt8186. Signed-off-by: Yunfei Dong --- .../bindings/media/mediatek,vcodec-subdev-decoder.yaml| 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml index d587fc3e39fb..6415c9f29130 100644 --- a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -47,7 +47,9 @@ description: | properties: compatible: -const: mediatek,mt8192-vcodec-dec +enum: + - mediatek,mt8192-vcodec-dec + - mediatek,mt8186-vcodec-dec reg: maxItems: 1 -- 2.25.1
[PATCH v1, 3/3] mtk-vcodec: add h264 decoder driver for mt8186
Add h264 decode driver to support mt8186. For the architecture
is single core, need to add new interface to decode.
Signed-off-by: Yunfei Dong
---
.../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 164 ++
.../media/platform/mtk-vcodec/vdec_drv_if.c | 5 +-
.../media/platform/mtk-vcodec/vdec_drv_if.h | 1 +
3 files changed, 169 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
index 1567dbc63e95..5541edbafed2 100644
--- a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
@@ -137,6 +137,9 @@ struct vdec_h264_slice_share_info {
* @vsi : vsi used for lat
* @vsi_core: vsi used for core
*
+ * @vsi_ctx : Local VSI data for this decoding context
+ * @h264_slice_param : the parameters that hardware use to decode
+ *
* @resolution_changed : resolution changed
* @realloc_mv_buf : reallocate mv buffer
* @cap_num_planes : number of capture queue plane
@@ -152,6 +155,9 @@ struct vdec_h264_slice_inst {
struct vdec_h264_slice_vsi *vsi;
struct vdec_h264_slice_vsi *vsi_core;
+ struct vdec_h264_slice_vsi vsi_ctx;
+ struct vdec_h264_slice_lat_dec_param h264_slice_param;
+
unsigned int resolution_changed;
unsigned int realloc_mv_buf;
unsigned int cap_num_planes;
@@ -196,6 +202,61 @@ static int vdec_h264_slice_fill_decode_parameters(struct
vdec_h264_slice_inst *i
return 0;
}
+static int get_vdec_sig_decode_parameters(struct vdec_h264_slice_inst *inst)
+{
+ const struct v4l2_ctrl_h264_decode_params *dec_params;
+ const struct v4l2_ctrl_h264_sps *sps;
+ const struct v4l2_ctrl_h264_pps *pps;
+ const struct v4l2_ctrl_h264_scaling_matrix *scaling_matrix;
+ struct vdec_h264_slice_lat_dec_param *slice_param =
>h264_slice_param;
+ struct v4l2_h264_reflist_builder reflist_builder;
+ u8 *p0_reflist = slice_param->decode_params.ref_pic_list_p0;
+ u8 *b0_reflist = slice_param->decode_params.ref_pic_list_b0;
+ u8 *b1_reflist = slice_param->decode_params.ref_pic_list_b1;
+
+ dec_params =
+ mtk_vdec_h264_get_ctrl_ptr(inst->ctx,
V4L2_CID_STATELESS_H264_DECODE_PARAMS);
+ if (IS_ERR(dec_params))
+ return PTR_ERR(dec_params);
+
+ sps = mtk_vdec_h264_get_ctrl_ptr(inst->ctx,
V4L2_CID_STATELESS_H264_SPS);
+ if (IS_ERR(sps))
+ return PTR_ERR(sps);
+
+ pps = mtk_vdec_h264_get_ctrl_ptr(inst->ctx,
V4L2_CID_STATELESS_H264_PPS);
+ if (IS_ERR(pps))
+ return PTR_ERR(pps);
+
+ scaling_matrix =
+ mtk_vdec_h264_get_ctrl_ptr(inst->ctx,
V4L2_CID_STATELESS_H264_SCALING_MATRIX);
+ if (IS_ERR(scaling_matrix))
+ return PTR_ERR(scaling_matrix);
+
+ mtk_vdec_h264_update_dpb(dec_params, inst->dpb);
+
+ mtk_vdec_h264_copy_sps_params(_param->sps, sps);
+ mtk_vdec_h264_copy_pps_params(_param->pps, pps);
+ mtk_vdec_h264_copy_scaling_matrix(_param->scaling_matrix,
scaling_matrix);
+
+ mtk_vdec_h264_copy_decode_params(_param->decode_params,
dec_params, inst->dpb);
+ mtk_vdec_h264_fill_dpb_info(inst->ctx, _param->decode_params,
+ slice_param->h264_dpb_info);
+
+ /* Build the reference lists */
+ v4l2_h264_init_reflist_builder(_builder, dec_params, sps,
inst->dpb);
+ v4l2_h264_build_p_ref_list(_builder, p0_reflist);
+
+ v4l2_h264_build_b_ref_lists(_builder, b0_reflist, b1_reflist);
+ /* Adapt the built lists to the firmware's expectations */
+ mtk_vdec_h264_fixup_ref_list(p0_reflist, reflist_builder.num_valid);
+ mtk_vdec_h264_fixup_ref_list(b0_reflist, reflist_builder.num_valid);
+ mtk_vdec_h264_fixup_ref_list(b1_reflist, reflist_builder.num_valid);
+ memcpy(>vsi_ctx.h264_slice_params, slice_param,
+ sizeof(inst->vsi_ctx.h264_slice_params));
+
+ return 0;
+}
+
static void vdec_h264_slice_fill_decode_reflist(struct vdec_h264_slice_inst
*inst,
struct
vdec_h264_slice_lat_dec_param *slice_param,
struct
vdec_h264_slice_share_info *share_info)
@@ -584,6 +645,102 @@ static int vdec_h264_slice_decode(void *h_vdec, struct
mtk_vcodec_mem *bs,
return err;
}
+static int vdec_h264_slice_single_decode(void *h_vdec, struct mtk_vcodec_mem
*bs,
+struct vdec_fb *unused, bool *res_chg)
+{
+ struct vdec_h264_slice_inst *inst = (struct vdec_h264_slice_inst
*)h_vdec;
+ struct vdec_vpu_inst *vpu = >vpu;
+ struct mtk_video_dec_buf *src_buf_info, *dst_buf_info;
+ struct vdec_fb *fb;
+ unsigned char *buf;
+ unsigned int nal_start_idx,
[PATCH v1, 0/3] support mt8186 decoder
Firstly, add mt8186 compatible and private data, then add document for compatible "mediatek,mt8186-vcodec-dec". For mt8186 is single core architecture, need to add new interface for h264 hardware decoder. Patche 1 add mt8186 compatible and private data. Patche 2 add mt8186 compatible document. Patche 3 add h264 single core driver. --- This patch depends on "support for MT8192 decoder"[1] [1] https://patchwork.kernel.org/project/linux-mediatek/patch/20220122035316.18179-1-yunfei.d...@mediatek.com/ --- Yunfei Dong (3): mtk-vcodec: Support MT8186 dt-bindings: media: mtk-vcodec: Adds decoder dt-bindings for mt8186 mtk-vcodec: add h264 decoder driver for mt8186 .../media/mediatek,vcodec-subdev-decoder.yaml | 4 +- .../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 + .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4 + .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 19 ++ .../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 164 ++ .../media/platform/mtk-vcodec/vdec_drv_if.c | 5 +- .../media/platform/mtk-vcodec/vdec_drv_if.h | 1 + 7 files changed, 196 insertions(+), 2 deletions(-) -- 2.25.1
[PATCH v1, 1/3] mtk-vcodec: Support MT8186
Adds MT8186's compatible "mediatek,mt8186-vcodec-dec".
Adds MT8186's device private data mtk_vdec_single_core_pdata.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec.h | 1 +
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 4
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 19 +++
3 files changed, 24 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
index 66cd6d2242c3..4572f92826f2 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.h
@@ -69,6 +69,7 @@ extern const struct media_device_ops mtk_vcodec_media_ops;
extern const struct mtk_vcodec_dec_pdata mtk_vdec_8173_pdata;
extern const struct mtk_vcodec_dec_pdata mtk_vdec_8183_pdata;
extern const struct mtk_vcodec_dec_pdata mtk_lat_sig_core_pdata;
+extern const struct mtk_vcodec_dec_pdata mtk_vdec_single_core_pdata;
/*
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 6b52eaeedafa..2d21d0010c9c 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -464,6 +464,10 @@ static const struct of_device_id mtk_vcodec_match[] = {
.compatible = "mediatek,mt8192-vcodec-dec",
.data = _lat_sig_core_pdata,
},
+ {
+ .compatible = "mediatek,mt8186-vcodec-dec",
+ .data = _vdec_single_core_pdata,
+ },
{},
};
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
index 3770e8117488..4b83f00a8857 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
@@ -522,3 +522,22 @@ const struct mtk_vcodec_dec_pdata mtk_lat_sig_core_pdata =
{
.is_subdev_supported = true,
.hw_arch = MTK_VDEC_LAT_SINGLE_CORE,
};
+
+const struct mtk_vcodec_dec_pdata mtk_vdec_single_core_pdata = {
+ .init_vdec_params = mtk_init_vdec_params,
+ .ctrls_setup = mtk_vcodec_dec_ctrls_setup,
+ .vdec_vb2_ops = _vdec_request_vb2_ops,
+ .vdec_formats = mtk_video_formats,
+ .num_formats = _formats,
+ .default_out_fmt = _out_format,
+ .default_cap_fmt = _cap_format,
+ .vdec_framesizes = mtk_vdec_framesizes,
+ .num_framesizes = _framesizes,
+ .uses_stateless_api = true,
+ .worker = mtk_vdec_worker,
+ .flush_decoder = mtk_vdec_flush_decoder,
+ .cap_to_disp = mtk_vdec_stateless_cap_to_disp,
+ .get_cap_buffer = vdec_get_cap_buffer,
+ .is_subdev_supported = true,
+ .hw_arch = MTK_VDEC_PURE_SINGLE_CORE,
+};
--
2.25.1
[PATCH v6, 10/15] media: mtk-vcodec: Fix v4l2-compliance fail
Need to use default pic info when get pic info fail.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index ba188d16f0fb..5a429ed83ed4 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -478,11 +478,14 @@ static int vidioc_vdec_s_fmt(struct file *file, void
*priv,
ctx->picinfo.pic_w = pix_mp->width;
ctx->picinfo.pic_h = pix_mp->height;
+ /*
+* If get pic info fail, need to use the default pic info
params, or
+* v4l2-compliance will fail
+*/
ret = vdec_if_get_param(ctx, GET_PARAM_PIC_INFO, >picinfo);
if (ret) {
mtk_v4l2_err("[%d]Error!! Get GET_PARAM_PICTURE_INFO
Fail",
ctx->id);
- return -EINVAL;
}
ctx->last_decoded_picinfo = ctx->picinfo;
--
2.25.1
[PATCH v6, 13/15] media: mtk-vcodec: support stateless H.264 decoding for mt8192
Adds h264 lat and core architecture driver for mt8192,
and the decode mode is frame based for stateless decoder.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 614 ++
.../media/platform/mtk-vcodec/vdec_drv_if.c | 8 +-
.../media/platform/mtk-vcodec/vdec_drv_if.h | 1 +
include/linux/remoteproc/mtk_scp.h| 2 +
5 files changed, 625 insertions(+), 1 deletion(-)
create mode 100644
drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index 3f41d748eee5..22edb1c86598 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -10,6 +10,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec/vdec_vp9_if.o \
vdec/vdec_h264_req_if.o \
vdec/vdec_h264_req_common.o \
+ vdec/vdec_h264_req_multi_if.o \
mtk_vcodec_dec_drv.o \
vdec_drv_if.o \
vdec_vpu_if.o \
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
new file mode 100644
index ..1567dbc63e95
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c
@@ -0,0 +1,614 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: Yunfei Dong
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_dec.h"
+#include "../mtk_vcodec_intr.h"
+#include "../vdec_drv_base.h"
+#include "../vdec_drv_if.h"
+#include "../vdec_vpu_if.h"
+#include "vdec_h264_req_common.h"
+
+/**
+ * enum vdec_h264_core_dec_err_type - core decode error type
+ * @TRANS_BUFFER_FULL : trans buffer is full
+ * @SLICE_HEADER_FULL : slice header buffer is full
+ */
+enum vdec_h264_core_dec_err_type {
+ TRANS_BUFFER_FULL = 1,
+ SLICE_HEADER_FULL,
+};
+
+/**
+ * struct vdec_h264_slice_lat_dec_param - parameters for decode current frame
+ * @sps : h264 sps syntax parameters
+ * @pps : h264 pps syntax parameters
+ * @slice_header: h264 slice header syntax parameters
+ * @scaling_matrix : h264 scaling list parameters
+ * @decode_params : decoder parameters of each frame used for hardware decode
+ * @h264_dpb_info : dpb reference list
+ */
+struct vdec_h264_slice_lat_dec_param {
+ struct mtk_h264_sps_param sps;
+ struct mtk_h264_pps_param pps;
+ struct mtk_h264_slice_hd_param slice_header;
+ struct slice_api_h264_scaling_matrix scaling_matrix;
+ struct slice_api_h264_decode_param decode_params;
+ struct mtk_h264_dpb_info h264_dpb_info[V4L2_H264_NUM_DPB_ENTRIES];
+};
+
+/**
+ * struct vdec_h264_slice_info - decode information
+ * @nal_info: nal info of current picture
+ * @timeout : Decode timeout: 1 timeout, 0 no timeount
+ * @bs_buf_size : bitstream size
+ * @bs_buf_addr : bitstream buffer dma address
+ * @y_fb_dma: Y frame buffer dma address
+ * @c_fb_dma: C frame buffer dma address
+ * @vdec_fb_va : VDEC frame buffer struct virtual address
+ * @crc : Used to check whether hardware's status is right
+ */
+struct vdec_h264_slice_info {
+ u16 nal_info;
+ u16 timeout;
+ u32 bs_buf_size;
+ u64 bs_buf_addr;
+ u64 y_fb_dma;
+ u64 c_fb_dma;
+ u64 vdec_fb_va;
+ u32 crc[8];
+};
+
+/**
+ * struct vdec_h264_slice_vsi - shared memory for decode information exchange
+ *between VPU and Host. The memory is allocated by VPU then mapping to
+ *Host in vdec_h264_slice_init() and freed in vdec_h264_slice_deinit()
+ *by VPU. AP-W/R : AP is writer/reader on this item. VPU-W/R: VPU is
+ *write/reader on this item.
+ * @wdma_err_addr : wdma error dma address
+ * @wdma_start_addr : wdma start dma address
+ * @wdma_end_addr : wdma end dma address
+ * @slice_bc_start_addr : slice bc start dma address
+ * @slice_bc_end_addr : slice bc end dma address
+ * @row_info_start_addr : row info start dma address
+ * @row_info_end_addr : row info end dma address
+ * @trans_start : trans start dma address
+ * @trans_end : trans end dma address
+ * @wdma_end_addr_offset: wdma end address offset
+ *
+ * @mv_buf_dma : HW working motion vector buffer
+ *dma address (AP-W, VPU-R)
+ * @dec : decode information (AP-R, VPU-W)
+ * @h264_slice_params : decode parameters for hw used
+ */
+struct vdec_h264_slice_vsi {
+ /* LAT dec addr */
+ u64 wdma_err_addr;
+ u64 wdma_start_addr;
+ u64 wdma_end_addr;
+ u64 slice_bc_start_addr;
+ u64 slice_bc_end_addr;
+ u64 row_info_start_addr;
+ u64 row_info_end_addr;
+ u64 trans_start;
+ u64 trans_end;
+
[PATCH v6, 11/15] media: mtk-vcodec: record capture queue format type
Capture queue format type is difference for different platform,
need to calculate capture buffer size according to capture queue
format type in scp.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 2 ++
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 5a429ed83ed4..6ad17e69e32d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -468,6 +468,8 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
}
ctx->state = MTK_STATE_INIT;
}
+ } else {
+ ctx->capture_fourcc = fmt->fourcc;
}
/*
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index aa608ab0a247..fde79684106d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -277,6 +277,7 @@ struct vdec_pic_info {
* to be used with encoder and stateful decoder.
* @is_flushing: set to true if flushing is in progress.
* @current_codec: current set input codec, in V4L2 pixel format
+ * @capture_fourcc: capture queue type in V4L2 pixel format
*
* @colorspace: enum v4l2_colorspace; supplemental to pixelformat
* @ycbcr_enc: enum v4l2_ycbcr_encoding, Y'CbCr encoding
@@ -324,6 +325,7 @@ struct mtk_vcodec_ctx {
bool is_flushing;
u32 current_codec;
+ u32 capture_fourcc;
enum v4l2_colorspace colorspace;
enum v4l2_ycbcr_encoding ycbcr_enc;
--
2.25.1
[PATCH v6, 09/15] media: mtk-vcodec: disable vp8 4K capability
For vp8 not support 4K, need to disable it.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index bae43938ee37..ba188d16f0fb 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -532,7 +532,8 @@ static int vidioc_enum_framesizes(struct file *file, void
*priv,
fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
fsize->stepwise = dec_pdata->vdec_framesizes[i].stepwise;
if (!(ctx->dev->dec_capability &
- VCODEC_CAPABILITY_4K_DISABLED)) {
+ VCODEC_CAPABILITY_4K_DISABLED) &&
+ fsize->pixel_format != V4L2_PIX_FMT_VP8_FRAME) {
mtk_v4l2_debug(3, "4K is enabled");
fsize->stepwise.max_width =
VCODEC_DEC_4K_CODED_WIDTH;
--
2.25.1
[PATCH v6, 15/15] media: mtk-vcodec: support stateless VP9 decoding
Add support for VP9 decoding using the stateless API,
as supported by MT8192. And the drivers is lat and core architecture.
Signed-off-by: Yunfei Dong
Signed-off-by: George Sun
Reviewed-by: AngeloGioacchino Del Regno
---
drivers/media/platform/mtk-vcodec/Makefile|1 +
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 26 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h |1 +
.../mtk-vcodec/vdec/vdec_vp9_req_lat_if.c | 1971 +
.../media/platform/mtk-vcodec/vdec_drv_if.c |4 +
.../media/platform/mtk-vcodec/vdec_drv_if.h |1 +
6 files changed, 2001 insertions(+), 3 deletions(-)
create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_req_lat_if.c
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index b457daf2d196..93e7a343b5b0 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -9,6 +9,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec/vdec_vp8_if.o \
vdec/vdec_vp8_req_if.o \
vdec/vdec_vp9_if.o \
+ vdec/vdec_vp9_req_lat_if.o \
vdec/vdec_h264_req_if.o \
vdec/vdec_h264_req_common.o \
vdec/vdec_h264_req_multi_if.o \
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
index 2a0164ddc708..3770e8117488 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
@@ -91,13 +91,28 @@ static const struct mtk_stateless_control
mtk_stateless_controls[] = {
.max = V4L2_MPEG_VIDEO_VP8_PROFILE_3,
},
.codec_type = V4L2_PIX_FMT_VP8_FRAME,
- }
+ },
+ {
+ .cfg = {
+ .id = V4L2_CID_STATELESS_VP9_FRAME,
+ },
+ .codec_type = V4L2_PIX_FMT_VP9_FRAME,
+ },
+ {
+ .cfg = {
+ .id = V4L2_CID_MPEG_VIDEO_VP9_PROFILE,
+ .min = V4L2_MPEG_VIDEO_VP9_PROFILE_0,
+ .def = V4L2_MPEG_VIDEO_VP9_PROFILE_0,
+ .max = V4L2_MPEG_VIDEO_VP9_PROFILE_3,
+ },
+ .codec_type = V4L2_PIX_FMT_VP9_FRAME,
+ },
};
#define NUM_CTRLS ARRAY_SIZE(mtk_stateless_controls)
-static struct mtk_video_fmt mtk_video_formats[4];
-static struct mtk_codec_framesizes mtk_vdec_framesizes[2];
+static struct mtk_video_fmt mtk_video_formats[5];
+static struct mtk_codec_framesizes mtk_vdec_framesizes[3];
static struct mtk_video_fmt default_out_format;
static struct mtk_video_fmt default_cap_format;
@@ -366,6 +381,7 @@ static void mtk_vcodec_add_formats(unsigned int fourcc,
switch (fourcc) {
case V4L2_PIX_FMT_H264_SLICE:
case V4L2_PIX_FMT_VP8_FRAME:
+ case V4L2_PIX_FMT_VP9_FRAME:
mtk_video_formats[count_formats].fourcc = fourcc;
mtk_video_formats[count_formats].type = MTK_FMT_DEC;
mtk_video_formats[count_formats].num_planes = 1;
@@ -413,6 +429,10 @@ static void mtk_vcodec_get_supported_formats(struct
mtk_vcodec_ctx *ctx)
mtk_vcodec_add_formats(V4L2_PIX_FMT_VP8_FRAME, ctx);
out_format_count++;
}
+ if (ctx->dev->dec_capability & MTK_VDEC_FORMAT_VP9_FRAME) {
+ mtk_vcodec_add_formats(V4L2_PIX_FMT_VP9_FRAME, ctx);
+ out_format_count++;
+ }
if (cap_format_count)
default_cap_format = mtk_video_formats[cap_format_count - 1];
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index e16733fbf0c7..cd2939b47790 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -358,6 +358,7 @@ enum mtk_vdec_format_types {
MTK_VDEC_FORMAT_MT21C = 0x40,
MTK_VDEC_FORMAT_H264_SLICE = 0x100,
MTK_VDEC_FORMAT_VP8_FRAME = 0x200,
+ MTK_VDEC_FORMAT_VP9_FRAME = 0x400,
};
/**
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_req_lat_if.c
b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_req_lat_if.c
new file mode 100644
index ..d9a2a4b02b00
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_req_lat_if.c
@@ -0,0 +1,1971 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: George Sun
+ */
+
+#include
+#include
+#include
+
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_dec.h"
+#include "../mtk_vcodec_intr.h"
+#include "../vdec_drv_base.h"
+#include "../vdec_drv_if.h"
+#include "../vdec_vpu_if.h"
+
+/* reset_frame_context defined in VP9 spec */
+#define VP9_RESET_FRAME_CONTEXT_NONE0 0
+#define VP9_RESET_FRAME_CONTEXT_NONE1 1
+#define
[PATCH v6, 12/15] media: mtk-vcodec: Extract H264 common code
Mt8192 can use some of common code with mt8183. Moves them to
a new file in order to reuse.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../mtk-vcodec/vdec/vdec_h264_req_common.c| 310 +
.../mtk-vcodec/vdec/vdec_h264_req_common.h| 253 +++
.../mtk-vcodec/vdec/vdec_h264_req_if.c| 424 ++
4 files changed, 606 insertions(+), 382 deletions(-)
create mode 100644
drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.c
create mode 100644
drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.h
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index 359619653a0e..3f41d748eee5 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -9,6 +9,7 @@ mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec/vdec_vp8_if.o \
vdec/vdec_vp9_if.o \
vdec/vdec_h264_req_if.o \
+ vdec/vdec_h264_req_common.o \
mtk_vcodec_dec_drv.o \
vdec_drv_if.o \
vdec_vpu_if.o \
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.c
b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.c
new file mode 100644
index ..bf596755e91c
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.c
@@ -0,0 +1,310 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: Yunfei Dong
+ */
+
+#include "vdec_h264_req_common.h"
+
+/* get used parameters for sps/pps */
+#define GET_MTK_VDEC_FLAG(cond, flag) \
+ { dst_param->cond = ((src_param->flags & flag) ? (1) : (0)); }
+#define GET_MTK_VDEC_PARAM(param) \
+ { dst_param->param = src_param->param; }
+
+/*
+ * The firmware expects unused reflist entries to have the value 0x20.
+ */
+void mtk_vdec_h264_fixup_ref_list(u8 *ref_list, size_t num_valid)
+{
+ memset(_list[num_valid], 0x20, 32 - num_valid);
+}
+
+void *mtk_vdec_h264_get_ctrl_ptr(struct mtk_vcodec_ctx *ctx, int id)
+{
+ struct v4l2_ctrl *ctrl = v4l2_ctrl_find(>ctrl_hdl, id);
+
+ if (!ctrl)
+ return ERR_PTR(-EINVAL);
+
+ return ctrl->p_cur.p;
+}
+
+void mtk_vdec_h264_fill_dpb_info(struct mtk_vcodec_ctx *ctx,
+struct slice_api_h264_decode_param
*decode_params,
+struct mtk_h264_dpb_info *h264_dpb_info)
+{
+ const struct slice_h264_dpb_entry *dpb;
+ struct vb2_queue *vq;
+ struct vb2_buffer *vb;
+ struct vb2_v4l2_buffer *vb2_v4l2;
+ int index, vb2_index;
+
+ vq = v4l2_m2m_get_vq(ctx->m2m_ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE);
+
+ for (index = 0; index < V4L2_H264_NUM_DPB_ENTRIES; index++) {
+ dpb = _params->dpb[index];
+ if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_ACTIVE)) {
+ h264_dpb_info[index].reference_flag = 0;
+ continue;
+ }
+
+ vb2_index = vb2_find_timestamp(vq, dpb->reference_ts, 0);
+ if (vb2_index < 0) {
+ dev_err(>dev->plat_dev->dev,
+ "Reference invalid: dpb_index(%d)
reference_ts(%lld)",
+ index, dpb->reference_ts);
+ continue;
+ }
+
+ /* 1 for short term reference, 2 for long term reference */
+ if (!(dpb->flags & V4L2_H264_DPB_ENTRY_FLAG_LONG_TERM))
+ h264_dpb_info[index].reference_flag = 1;
+ else
+ h264_dpb_info[index].reference_flag = 2;
+
+ vb = vq->bufs[vb2_index];
+ vb2_v4l2 = container_of(vb, struct vb2_v4l2_buffer, vb2_buf);
+ h264_dpb_info[index].field = vb2_v4l2->field;
+
+ h264_dpb_info[index].y_dma_addr =
+ vb2_dma_contig_plane_dma_addr(vb, 0);
+ if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
+ h264_dpb_info[index].c_dma_addr =
+ vb2_dma_contig_plane_dma_addr(vb, 1);
+ else
+ h264_dpb_info[index].c_dma_addr =
+ h264_dpb_info[index].y_dma_addr +
+ ctx->picinfo.fb_sz[0];
+ }
+}
+
+void mtk_vdec_h264_copy_sps_params(struct mtk_h264_sps_param *dst_param,
+ const struct v4l2_ctrl_h264_sps *src_param)
+{
+ GET_MTK_VDEC_PARAM(chroma_format_idc);
+ GET_MTK_VDEC_PARAM(bit_depth_luma_minus8);
+ GET_MTK_VDEC_PARAM(bit_depth_chroma_minus8);
+ GET_MTK_VDEC_PARAM(log2_max_frame_num_minus4);
+ GET_MTK_VDEC_PARAM(pic_order_cnt_type);
+ GET_MTK_VDEC_PARAM(log2_max_pic_order_cnt_lsb_minus4);
+ GET_MTK_VDEC_PARAM(max_num_ref_frames);
+
[PATCH v6, 08/15] media: mtk-vcodec: Add format to support MT21C
Needs to use mediatek compressed mode for mt8192 decoder.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c | 7 ++-
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
index e51d935bd21d..9333e3418b98 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
@@ -81,7 +81,7 @@ static const struct mtk_stateless_control
mtk_stateless_controls[] = {
#define NUM_CTRLS ARRAY_SIZE(mtk_stateless_controls)
-static struct mtk_video_fmt mtk_video_formats[2];
+static struct mtk_video_fmt mtk_video_formats[3];
static struct mtk_codec_framesizes mtk_vdec_framesizes[1];
static struct mtk_video_fmt default_out_format;
@@ -359,6 +359,7 @@ static void mtk_vcodec_add_formats(unsigned int fourcc,
num_framesizes++;
break;
case V4L2_PIX_FMT_MM21:
+ case V4L2_PIX_FMT_MT21C:
mtk_video_formats[count_formats].fourcc = fourcc;
mtk_video_formats[count_formats].type = MTK_FMT_FRAME;
mtk_video_formats[count_formats].num_planes = 2;
@@ -384,6 +385,10 @@ static void mtk_vcodec_get_supported_formats(struct
mtk_vcodec_ctx *ctx)
mtk_vcodec_add_formats(V4L2_PIX_FMT_MM21, ctx);
cap_format_count++;
}
+ if (ctx->dev->dec_capability & MTK_VDEC_FORMAT_MT21C) {
+ mtk_vcodec_add_formats(V4L2_PIX_FMT_MT21C, ctx);
+ cap_format_count++;
+ }
if (ctx->dev->dec_capability & MTK_VDEC_FORMAT_H264_SLICE) {
mtk_vcodec_add_formats(V4L2_PIX_FMT_H264_SLICE, ctx);
out_format_count++;
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 13c12de85edf..aa608ab0a247 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -353,6 +353,7 @@ enum mtk_vdec_hw_arch {
*/
enum mtk_vdec_format_types {
MTK_VDEC_FORMAT_MM21 = 0x20,
+ MTK_VDEC_FORMAT_MT21C = 0x40,
MTK_VDEC_FORMAT_H264_SLICE = 0x100,
};
--
2.25.1
[PATCH v6, 14/15] media: mtk-vcodec: support stateless VP8 decoding
Add support for VP8 decoding using the stateless API,
as supported by MT8192.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/Makefile| 1 +
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 24 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 1 +
.../mtk-vcodec/vdec/vdec_vp8_req_if.c | 445 ++
.../media/platform/mtk-vcodec/vdec_drv_if.c | 4 +
.../media/platform/mtk-vcodec/vdec_drv_if.h | 1 +
6 files changed, 474 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_req_if.c
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index 22edb1c86598..b457daf2d196 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk-vcodec-dec.o \
mtk-vcodec-dec-y := vdec/vdec_h264_if.o \
vdec/vdec_vp8_if.o \
+ vdec/vdec_vp8_req_if.o \
vdec/vdec_vp9_if.o \
vdec/vdec_h264_req_if.o \
vdec/vdec_h264_req_common.o \
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
index 9333e3418b98..2a0164ddc708 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
@@ -76,13 +76,28 @@ static const struct mtk_stateless_control
mtk_stateless_controls[] = {
.max = V4L2_STATELESS_H264_START_CODE_ANNEX_B,
},
.codec_type = V4L2_PIX_FMT_H264_SLICE,
+ },
+ {
+ .cfg = {
+ .id = V4L2_CID_STATELESS_VP8_FRAME,
+ },
+ .codec_type = V4L2_PIX_FMT_VP8_FRAME,
+ },
+ {
+ .cfg = {
+ .id = V4L2_CID_MPEG_VIDEO_VP8_PROFILE,
+ .min = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
+ .def = V4L2_MPEG_VIDEO_VP8_PROFILE_0,
+ .max = V4L2_MPEG_VIDEO_VP8_PROFILE_3,
+ },
+ .codec_type = V4L2_PIX_FMT_VP8_FRAME,
}
};
#define NUM_CTRLS ARRAY_SIZE(mtk_stateless_controls)
-static struct mtk_video_fmt mtk_video_formats[3];
-static struct mtk_codec_framesizes mtk_vdec_framesizes[1];
+static struct mtk_video_fmt mtk_video_formats[4];
+static struct mtk_codec_framesizes mtk_vdec_framesizes[2];
static struct mtk_video_fmt default_out_format;
static struct mtk_video_fmt default_cap_format;
@@ -350,6 +365,7 @@ static void mtk_vcodec_add_formats(unsigned int fourcc,
switch (fourcc) {
case V4L2_PIX_FMT_H264_SLICE:
+ case V4L2_PIX_FMT_VP8_FRAME:
mtk_video_formats[count_formats].fourcc = fourcc;
mtk_video_formats[count_formats].type = MTK_FMT_DEC;
mtk_video_formats[count_formats].num_planes = 1;
@@ -393,6 +409,10 @@ static void mtk_vcodec_get_supported_formats(struct
mtk_vcodec_ctx *ctx)
mtk_vcodec_add_formats(V4L2_PIX_FMT_H264_SLICE, ctx);
out_format_count++;
}
+ if (ctx->dev->dec_capability & MTK_VDEC_FORMAT_VP8_FRAME) {
+ mtk_vcodec_add_formats(V4L2_PIX_FMT_VP8_FRAME, ctx);
+ out_format_count++;
+ }
if (cap_format_count)
default_cap_format = mtk_video_formats[cap_format_count - 1];
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index fde79684106d..e16733fbf0c7 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -357,6 +357,7 @@ enum mtk_vdec_format_types {
MTK_VDEC_FORMAT_MM21 = 0x20,
MTK_VDEC_FORMAT_MT21C = 0x40,
MTK_VDEC_FORMAT_H264_SLICE = 0x100,
+ MTK_VDEC_FORMAT_VP8_FRAME = 0x200,
};
/**
diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_req_if.c
b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_req_if.c
new file mode 100644
index ..6bd4f2365826
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_req_if.c
@@ -0,0 +1,445 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2021 MediaTek Inc.
+ * Author: Yunfei Dong
+ */
+
+#include
+#include
+#include
+#include
+
+#include "../mtk_vcodec_util.h"
+#include "../mtk_vcodec_dec.h"
+#include "../mtk_vcodec_intr.h"
+#include "../vdec_drv_base.h"
+#include "../vdec_drv_if.h"
+#include "../vdec_vpu_if.h"
+
+/* Decoding picture buffer size (3 reference frames plus current frame) */
+#define VP8_DPB_SIZE 4
+
+/* HW working buffer size (bytes) */
+#define VP8_SEG_ID_SZ SZ_256K
+#define VP8_PP_WRAPY_SZ SZ_64K
+#define VP8_PP_WRAPC_SZ SZ_64K
+#define VP8_VLD_PRED_SZ SZ_64K
+
+/**
+ * struct vdec_vp8_slice_info - decode misc information
+ * @vld_wrapper_dma
[PATCH v6, 04/15] media: mtk-vcodec: Read max resolution from dec_capability
Supported max resolution for different platforms are not the same: 2K
or 4K, getting it according to dec_capability.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
---
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 29 +++
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 4 +++
2 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 130ecef2e766..304f5afbd419 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -152,13 +152,15 @@ void mtk_vcodec_dec_set_default_params(struct
mtk_vcodec_ctx *ctx)
q_data->coded_height = DFT_CFG_HEIGHT;
q_data->fmt = ctx->dev->vdec_pdata->default_cap_fmt;
q_data->field = V4L2_FIELD_NONE;
+ ctx->max_width = MTK_VDEC_MAX_W;
+ ctx->max_height = MTK_VDEC_MAX_H;
v4l_bound_align_image(_data->coded_width,
MTK_VDEC_MIN_W,
- MTK_VDEC_MAX_W, 4,
+ ctx->max_width, 4,
_data->coded_height,
MTK_VDEC_MIN_H,
- MTK_VDEC_MAX_H, 5, 6);
+ ctx->max_height, 5, 6);
q_data->sizeimage[0] = q_data->coded_width * q_data->coded_height;
q_data->bytesperline[0] = q_data->coded_width;
@@ -217,7 +219,7 @@ static int vidioc_vdec_subscribe_evt(struct v4l2_fh *fh,
}
}
-static int vidioc_try_fmt(struct v4l2_format *f,
+static int vidioc_try_fmt(struct mtk_vcodec_ctx *ctx, struct v4l2_format *f,
const struct mtk_video_fmt *fmt)
{
struct v4l2_pix_format_mplane *pix_fmt_mp = >fmt.pix_mp;
@@ -225,9 +227,9 @@ static int vidioc_try_fmt(struct v4l2_format *f,
pix_fmt_mp->field = V4L2_FIELD_NONE;
pix_fmt_mp->width =
- clamp(pix_fmt_mp->width, MTK_VDEC_MIN_W, MTK_VDEC_MAX_W);
+ clamp(pix_fmt_mp->width, MTK_VDEC_MIN_W, ctx->max_width);
pix_fmt_mp->height =
- clamp(pix_fmt_mp->height, MTK_VDEC_MIN_H, MTK_VDEC_MAX_H);
+ clamp(pix_fmt_mp->height, MTK_VDEC_MIN_H, ctx->max_height);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
pix_fmt_mp->num_planes = 1;
@@ -245,16 +247,16 @@ static int vidioc_try_fmt(struct v4l2_format *f,
tmp_h = pix_fmt_mp->height;
v4l_bound_align_image(_fmt_mp->width,
MTK_VDEC_MIN_W,
- MTK_VDEC_MAX_W, 6,
+ ctx->max_width, 6,
_fmt_mp->height,
MTK_VDEC_MIN_H,
- MTK_VDEC_MAX_H, 6, 9);
+ ctx->max_height, 6, 9);
if (pix_fmt_mp->width < tmp_w &&
- (pix_fmt_mp->width + 64) <= MTK_VDEC_MAX_W)
+ (pix_fmt_mp->width + 64) <= ctx->max_width)
pix_fmt_mp->width += 64;
if (pix_fmt_mp->height < tmp_h &&
- (pix_fmt_mp->height + 64) <= MTK_VDEC_MAX_H)
+ (pix_fmt_mp->height + 64) <= ctx->max_height)
pix_fmt_mp->height += 64;
mtk_v4l2_debug(0,
@@ -294,7 +296,7 @@ static int vidioc_try_fmt_vid_cap_mplane(struct file *file,
void *priv,
fmt = mtk_vdec_find_format(f, dec_pdata);
}
- return vidioc_try_fmt(f, fmt);
+ return vidioc_try_fmt(ctx, f, fmt);
}
static int vidioc_try_fmt_vid_out_mplane(struct file *file, void *priv,
@@ -317,7 +319,7 @@ static int vidioc_try_fmt_vid_out_mplane(struct file *file,
void *priv,
return -EINVAL;
}
- return vidioc_try_fmt(f, fmt);
+ return vidioc_try_fmt(ctx, f, fmt);
}
static int vidioc_vdec_g_selection(struct file *file, void *priv,
@@ -445,7 +447,7 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv,
return -EINVAL;
q_data->fmt = fmt;
- vidioc_try_fmt(f, q_data->fmt);
+ vidioc_try_fmt(ctx, f, q_data->fmt);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
q_data->sizeimage[0] = pix_mp->plane_fmt[0].sizeimage;
q_data->coded_width = pix_mp->width;
@@ -545,6 +547,9 @@ static int vidioc_enum_framesizes(struct file *file, void
*priv,
fsize->stepwise.min_height,
fsize->stepwise.max_height,
fsize->stepwise.step_height);
+
+ ctx->max_width = fsize->stepwise.max_width;
+ ctx->max_height = fsize->stepwise.max_height;
return 0;
}
diff --git
[PATCH v6, 07/15] media: mtk-vcodec: Refactor supported vdec formats and framesizes
Supported output and capture format types for mt8192 are different
with mt8183. Needs to get format types according to decoder capability.
Signed-off-by: Yunfei Dong
---
.../platform/mtk-vcodec/mtk_vcodec_dec.c | 8 +-
.../mtk-vcodec/mtk_vcodec_dec_stateful.c | 13 +-
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 117 +-
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 13 +-
4 files changed, 107 insertions(+), 44 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
index 304f5afbd419..bae43938ee37 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c
@@ -26,7 +26,7 @@ mtk_vdec_find_format(struct v4l2_format *f,
const struct mtk_video_fmt *fmt;
unsigned int k;
- for (k = 0; k < dec_pdata->num_formats; k++) {
+ for (k = 0; k < *dec_pdata->num_formats; k++) {
fmt = _pdata->vdec_formats[k];
if (fmt->fourcc == f->fmt.pix_mp.pixelformat)
return fmt;
@@ -525,7 +525,7 @@ static int vidioc_enum_framesizes(struct file *file, void
*priv,
if (fsize->index != 0)
return -EINVAL;
- for (i = 0; i < dec_pdata->num_framesizes; ++i) {
+ for (i = 0; i < *dec_pdata->num_framesizes; ++i) {
if (fsize->pixel_format != dec_pdata->vdec_framesizes[i].fourcc)
continue;
@@ -564,7 +564,7 @@ static int vidioc_enum_fmt(struct v4l2_fmtdesc *f, void
*priv,
const struct mtk_video_fmt *fmt;
int i, j = 0;
- for (i = 0; i < dec_pdata->num_formats; i++) {
+ for (i = 0; i < *dec_pdata->num_formats; i++) {
if (output_queue &&
dec_pdata->vdec_formats[i].type != MTK_FMT_DEC)
continue;
@@ -577,7 +577,7 @@ static int vidioc_enum_fmt(struct v4l2_fmtdesc *f, void
*priv,
++j;
}
- if (i == dec_pdata->num_formats)
+ if (i == *dec_pdata->num_formats)
return -EINVAL;
fmt = _pdata->vdec_formats[i];
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
index 7966c132be8f..3f33beb9c551 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
@@ -37,7 +37,9 @@ static const struct mtk_video_fmt mtk_video_formats[] = {
},
};
-#define NUM_FORMATS ARRAY_SIZE(mtk_video_formats)
+static const unsigned int num_supported_formats =
+ ARRAY_SIZE(mtk_video_formats);
+
#define DEFAULT_OUT_FMT_IDX 0
#define DEFAULT_CAP_FMT_IDX 3
@@ -59,7 +61,8 @@ static const struct mtk_codec_framesizes
mtk_vdec_framesizes[] = {
},
};
-#define NUM_SUPPORTED_FRAMESIZE ARRAY_SIZE(mtk_vdec_framesizes)
+static const unsigned int num_supported_framesize =
+ ARRAY_SIZE(mtk_vdec_framesizes);
/*
* This function tries to clean all display buffers, the buffers will return
@@ -235,7 +238,7 @@ static void mtk_vdec_update_fmt(struct mtk_vcodec_ctx *ctx,
unsigned int k;
dst_q_data = >q_data[MTK_Q_DATA_DST];
- for (k = 0; k < NUM_FORMATS; k++) {
+ for (k = 0; k < num_supported_formats; k++) {
fmt = _video_formats[k];
if (fmt->fourcc == pixelformat) {
mtk_v4l2_debug(1, "Update cap fourcc(%d -> %d)",
@@ -617,11 +620,11 @@ const struct mtk_vcodec_dec_pdata mtk_vdec_8173_pdata = {
.ctrls_setup = mtk_vcodec_dec_ctrls_setup,
.vdec_vb2_ops = _vdec_frame_vb2_ops,
.vdec_formats = mtk_video_formats,
- .num_formats = NUM_FORMATS,
+ .num_formats = _supported_formats,
.default_out_fmt = _video_formats[DEFAULT_OUT_FMT_IDX],
.default_cap_fmt = _video_formats[DEFAULT_CAP_FMT_IDX],
.vdec_framesizes = mtk_vdec_framesizes,
- .num_framesizes = NUM_SUPPORTED_FRAMESIZE,
+ .num_framesizes = _supported_framesize,
.worker = mtk_vdec_worker,
.flush_decoder = mtk_vdec_flush_decoder,
.is_subdev_supported = false,
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
index 6d481410bf89..e51d935bd21d 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
@@ -81,33 +81,23 @@ static const struct mtk_stateless_control
mtk_stateless_controls[] = {
#define NUM_CTRLS ARRAY_SIZE(mtk_stateless_controls)
-static const struct mtk_video_fmt mtk_video_formats[] = {
- {
- .fourcc = V4L2_PIX_FMT_H264_SLICE,
- .type = MTK_FMT_DEC,
- .num_planes = 1,
- },
- {
- .fourcc = V4L2_PIX_FMT_MM21,
- .type = MTK_FMT_FRAME,
[PATCH v6, 06/15] media: mtk-vcodec: Refactor get and put capture buffer flow
For lat and core decode in parallel, need to get capture buffer
when core start to decode and put capture buffer to display
list when core decode done.
Signed-off-by: Yunfei Dong
---
.../mtk-vcodec/mtk_vcodec_dec_stateless.c | 121 --
.../platform/mtk-vcodec/mtk_vcodec_drv.h | 5 +-
.../mtk-vcodec/vdec/vdec_h264_req_if.c| 16 ++-
3 files changed, 102 insertions(+), 40 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
index 23a154c4e321..6d481410bf89 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
@@ -108,37 +108,87 @@ static const struct mtk_codec_framesizes
mtk_vdec_framesizes[] = {
#define NUM_SUPPORTED_FRAMESIZE ARRAY_SIZE(mtk_vdec_framesizes)
-static void mtk_vdec_stateless_set_dst_payload(struct mtk_vcodec_ctx *ctx,
- struct vdec_fb *fb)
+static void mtk_vdec_stateless_out_to_done(struct mtk_vcodec_ctx *ctx,
+ struct mtk_vcodec_mem *bs, int error)
{
- struct mtk_video_dec_buf *vdec_frame_buf =
- container_of(fb, struct mtk_video_dec_buf, frame_buffer);
- struct vb2_v4l2_buffer *vb = _frame_buf->m2m_buf.vb;
- unsigned int cap_y_size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
+ struct mtk_video_dec_buf *out_buf;
+ struct vb2_v4l2_buffer *vb;
- vb2_set_plane_payload(>vb2_buf, 0, cap_y_size);
- if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
- unsigned int cap_c_size =
- ctx->q_data[MTK_Q_DATA_DST].sizeimage[1];
+ if (!bs) {
+ mtk_v4l2_err("Free bitstream buffer fail.");
+ return;
+ }
+ out_buf = container_of(bs, struct mtk_video_dec_buf, bs_buffer);
+ vb = _buf->m2m_buf.vb;
- vb2_set_plane_payload(>vb2_buf, 1, cap_c_size);
+ mtk_v4l2_debug(2, "Free bitsteam buffer id = %d to done_list",
+ vb->vb2_buf.index);
+
+ v4l2_m2m_src_buf_remove(ctx->m2m_ctx);
+ if (error) {
+ v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
+ if (error == -EIO)
+ out_buf->error = true;
+ } else {
+ v4l2_m2m_buf_done(vb, VB2_BUF_STATE_DONE);
}
}
-static struct vdec_fb *vdec_get_cap_buffer(struct mtk_vcodec_ctx *ctx,
- struct vb2_v4l2_buffer *vb2_v4l2)
+static void mtk_vdec_stateless_cap_to_disp(struct mtk_vcodec_ctx *ctx,
+ struct vdec_fb *fb, int error)
{
- struct mtk_video_dec_buf *framebuf =
- container_of(vb2_v4l2, struct mtk_video_dec_buf, m2m_buf.vb);
- struct vdec_fb *pfb = >frame_buffer;
- struct vb2_buffer *dst_buf = _v4l2->vb2_buf;
+ struct mtk_video_dec_buf *vdec_frame_buf;
+ struct vb2_v4l2_buffer *vb;
+ unsigned int cap_y_size, cap_c_size;
+
+ if (!fb) {
+ mtk_v4l2_err("Free frame buffer fail.");
+ return;
+ }
+ vdec_frame_buf = container_of(fb, struct mtk_video_dec_buf,
+ frame_buffer);
+ vb = _frame_buf->m2m_buf.vb;
+
+ cap_y_size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
+ cap_c_size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[1];
+
+ v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
- pfb->base_y.va = NULL;
+ vb2_set_plane_payload(>vb2_buf, 0, cap_y_size);
+ if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2)
+ vb2_set_plane_payload(>vb2_buf, 1, cap_c_size);
+
+ mtk_v4l2_debug(2, "Free frame buffer id = %d to done_list",
+ vb->vb2_buf.index);
+ if (error)
+ v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
+ else
+ v4l2_m2m_buf_done(vb, VB2_BUF_STATE_DONE);
+}
+
+static struct vdec_fb *vdec_get_cap_buffer(struct mtk_vcodec_ctx *ctx)
+{
+ struct mtk_video_dec_buf *framebuf;
+ struct vb2_v4l2_buffer *vb2_v4l2;
+ struct vb2_buffer *dst_buf;
+ struct vdec_fb *pfb;
+
+ vb2_v4l2 = v4l2_m2m_next_dst_buf(ctx->m2m_ctx);
+ if (!vb2_v4l2) {
+ mtk_v4l2_debug(1, "[%d] dst_buf empty!!", ctx->id);
+ return NULL;
+ }
+
+ dst_buf = _v4l2->vb2_buf;
+ framebuf = container_of(vb2_v4l2, struct mtk_video_dec_buf, m2m_buf.vb);
+
+ pfb = >frame_buffer;
+ pfb->base_y.va = vb2_plane_vaddr(dst_buf, 0);
pfb->base_y.dma_addr = vb2_dma_contig_plane_dma_addr(dst_buf, 0);
pfb->base_y.size = ctx->q_data[MTK_Q_DATA_DST].sizeimage[0];
if (ctx->q_data[MTK_Q_DATA_DST].fmt->num_planes == 2) {
- pfb->base_c.va = NULL;
+ pfb->base_c.va = vb2_plane_vaddr(dst_buf, 1);
[PATCH v6, 05/15] media: mtk-vcodec: Call v4l2_m2m_set_dst_buffered() set capture buffer buffered
lat thread: output queue \ -> lat hardware -> lat trans buffer lat trans buffer / core thread: capture queue \ ->core hardware -> capture queue lat trans buffer / Lat and core work in different thread, setting capture buffer buffered. Signed-off-by: Yunfei Dong --- drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c index 5aebf88f997b..23a154c4e321 100644 --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c @@ -314,6 +314,9 @@ static void mtk_init_vdec_params(struct mtk_vcodec_ctx *ctx) src_vq = v4l2_m2m_get_vq(ctx->m2m_ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE); + if (ctx->dev->vdec_pdata->hw_arch != MTK_VDEC_PURE_SINGLE_CORE) + v4l2_m2m_set_dst_buffered(ctx->m2m_ctx, 1); + /* Support request api for output plane */ src_vq->supports_requests = true; src_vq->requires_requests = true; -- 2.25.1
[PATCH v6, 02/15] media: mtk-vcodec: Using firmware type to separate different firmware architecture
MT8173 platform use vpu firmware, mt8183/mt8192 will use scp
firmware instead, using chip name is not reasonable to separate
different firmware architecture. Using firmware type is much better.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
Reviewed-by: AngeloGioacchino Del Regno
---
.../platform/mtk-vcodec/mtk_vcodec_dec_stateful.c | 1 -
.../platform/mtk-vcodec/mtk_vcodec_dec_stateless.c | 2 --
drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 13 -
.../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 5 -
drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.c | 6 ++
drivers/media/platform/mtk-vcodec/mtk_vcodec_fw.h | 1 +
drivers/media/platform/mtk-vcodec/vdec_vpu_if.c | 4 ++--
drivers/media/platform/mtk-vcodec/venc_vpu_if.c | 2 +-
8 files changed, 10 insertions(+), 24 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
index 04ca43c77e5f..7966c132be8f 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateful.c
@@ -613,7 +613,6 @@ static struct vb2_ops mtk_vdec_frame_vb2_ops = {
};
const struct mtk_vcodec_dec_pdata mtk_vdec_8173_pdata = {
- .chip = MTK_MT8173,
.init_vdec_params = mtk_init_vdec_params,
.ctrls_setup = mtk_vcodec_dec_ctrls_setup,
.vdec_vb2_ops = _vdec_frame_vb2_ops,
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
index 23d997ac114d..5aebf88f997b 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_stateless.c
@@ -343,7 +343,6 @@ static struct vb2_ops mtk_vdec_request_vb2_ops = {
};
const struct mtk_vcodec_dec_pdata mtk_vdec_8183_pdata = {
- .chip = MTK_MT8183,
.init_vdec_params = mtk_init_vdec_params,
.ctrls_setup = mtk_vcodec_dec_ctrls_setup,
.vdec_vb2_ops = _vdec_request_vb2_ops,
@@ -362,7 +361,6 @@ const struct mtk_vcodec_dec_pdata mtk_vdec_8183_pdata = {
/* This platform data is used for one lat and one core architecture. */
const struct mtk_vcodec_dec_pdata mtk_lat_sig_core_pdata = {
- .chip = MTK_MT8192,
.init_vdec_params = mtk_init_vdec_params,
.ctrls_setup = mtk_vcodec_dec_ctrls_setup,
.vdec_vb2_ops = _vdec_request_vb2_ops,
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
index 94b47b7c912b..5056abe3d2be 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
@@ -335,13 +335,6 @@ struct mtk_vcodec_ctx {
struct vdec_msg_queue msg_queue;
};
-enum mtk_chip {
- MTK_MT8173,
- MTK_MT8183,
- MTK_MT8192,
- MTK_MT8195,
-};
-
/*
* enum mtk_vdec_hw_arch - Used to separate different hardware architecture
*/
@@ -367,7 +360,6 @@ enum mtk_vdec_hw_arch {
* @vdec_framesizes: supported video decoder frame sizes
* @num_framesizes: count of video decoder frame sizes
*
- * @chip: chip this decoder is compatible with
* @hw_arch: hardware arch is used to separate pure_sin_core and lat_sin_core
*
* @is_subdev_supported: whether support parent-node architecture(subdev)
@@ -390,7 +382,6 @@ struct mtk_vcodec_dec_pdata {
const struct mtk_codec_framesizes *vdec_framesizes;
const int num_framesizes;
- enum mtk_chip chip;
enum mtk_vdec_hw_arch hw_arch;
bool is_subdev_supported;
@@ -400,8 +391,6 @@ struct mtk_vcodec_dec_pdata {
/**
* struct mtk_vcodec_enc_pdata - compatible data for each IC
*
- * @chip: chip this encoder is compatible with
- *
* @uses_ext: whether the encoder uses the extended firmware messaging format
* @min_bitrate: minimum supported encoding bitrate
* @max_bitrate: maximum supported encoding bitrate
@@ -412,8 +401,6 @@ struct mtk_vcodec_dec_pdata {
* @core_id: stand for h264 or vp8 encode index
*/
struct mtk_vcodec_enc_pdata {
- enum mtk_chip chip;
-
bool uses_ext;
unsigned long min_bitrate;
unsigned long max_bitrate;
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
index 507ad1ea2104..3ac6969c54c0 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c
@@ -378,7 +378,6 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
}
static const struct mtk_vcodec_enc_pdata mt8173_avc_pdata = {
- .chip = MTK_MT8173,
.capture_formats = mtk_video_formats_capture_h264,
.num_capture_formats = ARRAY_SIZE(mtk_video_formats_capture_h264),
.output_formats = mtk_video_formats_output,
@@ -389,7 +388,6 @@ static const struct mtk_vcodec_enc_pdata mt8173_avc_pdata
[PATCH v6, 03/15] media: mtk-vcodec: get capture queue buffer size from scp
Different capture buffer format has different buffer size, need to get
real buffer size according to buffer type from scp.
Signed-off-by: Yunfei Dong
---
.../media/platform/mtk-vcodec/vdec_ipi_msg.h | 36 ++
.../media/platform/mtk-vcodec/vdec_vpu_if.c | 49 +++
.../media/platform/mtk-vcodec/vdec_vpu_if.h | 15 ++
3 files changed, 100 insertions(+)
diff --git a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
index bf54d6d9a857..47070be2a991 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
+++ b/drivers/media/platform/mtk-vcodec/vdec_ipi_msg.h
@@ -20,6 +20,7 @@ enum vdec_ipi_msgid {
AP_IPIMSG_DEC_RESET = 0xA004,
AP_IPIMSG_DEC_CORE = 0xA005,
AP_IPIMSG_DEC_CORE_END = 0xA006,
+ AP_IPIMSG_DEC_GET_PARAM = 0xA007,
VPU_IPIMSG_DEC_INIT_ACK = 0xB000,
VPU_IPIMSG_DEC_START_ACK = 0xB001,
@@ -28,6 +29,7 @@ enum vdec_ipi_msgid {
VPU_IPIMSG_DEC_RESET_ACK = 0xB004,
VPU_IPIMSG_DEC_CORE_ACK = 0xB005,
VPU_IPIMSG_DEC_CORE_END_ACK = 0xB006,
+ VPU_IPIMSG_DEC_GET_PARAM_ACK = 0xB007,
};
/**
@@ -114,4 +116,38 @@ struct vdec_vpu_ipi_init_ack {
uint32_t inst_id;
};
+/**
+ * struct vdec_ap_ipi_get_param - for AP_IPIMSG_DEC_GET_PARAM
+ * @msg_id : AP_IPIMSG_DEC_GET_PARAM
+ * @inst_id : instance ID. Used if the ABI version >= 2.
+ * @data : picture information
+ * @param_type : get param type
+ * @codec_type : Codec fourcc
+ */
+struct vdec_ap_ipi_get_param {
+ u32 msg_id;
+ u32 inst_id;
+ u32 data[4];
+ u32 param_type;
+ u32 codec_type;
+};
+
+/**
+ * struct vdec_vpu_ipi_get_param_ack - for VPU_IPIMSG_DEC_GET_PARAM_ACK
+ * @msg_id : VPU_IPIMSG_DEC_GET_PARAM_ACK
+ * @status : VPU execution result
+ * @ap_inst_addr : AP vcodec_vpu_inst instance address
+ * @data : picture information from SCP.
+ * @param_type : get param type
+ * @reserved : reserved param
+ */
+struct vdec_vpu_ipi_get_param_ack {
+ u32 msg_id;
+ s32 status;
+ u64 ap_inst_addr;
+ u32 data[4];
+ u32 param_type;
+ u32 reserved;
+};
+
#endif
diff --git a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
index 7210061c772f..35f4d5583084 100644
--- a/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec_vpu_if.c
@@ -6,6 +6,7 @@
#include "mtk_vcodec_drv.h"
#include "mtk_vcodec_util.h"
+#include "vdec_drv_if.h"
#include "vdec_ipi_msg.h"
#include "vdec_vpu_if.h"
#include "mtk_vcodec_fw.h"
@@ -54,6 +55,26 @@ static void handle_init_ack_msg(const struct
vdec_vpu_ipi_init_ack *msg)
}
}
+static void handle_get_param_msg_ack(const struct vdec_vpu_ipi_get_param_ack
*msg)
+{
+ struct vdec_vpu_inst *vpu = (struct vdec_vpu_inst *)
+ (unsigned long)msg->ap_inst_addr;
+
+ mtk_vcodec_debug(vpu, "+ ap_inst_addr = 0x%llx", msg->ap_inst_addr);
+
+ /* param_type is enum vdec_get_param_type */
+ switch (msg->param_type) {
+ case GET_PARAM_PIC_INFO:
+ vpu->fb_sz[0] = msg->data[0];
+ vpu->fb_sz[1] = msg->data[1];
+ break;
+ default:
+ mtk_vcodec_err(vpu, "invalid get param type=%d",
msg->param_type);
+ vpu->failure = 1;
+ break;
+ }
+}
+
/*
* vpu_dec_ipi_handler - Handler for VPU ipi message.
*
@@ -89,6 +110,9 @@ static void vpu_dec_ipi_handler(void *data, unsigned int
len, void *priv)
case VPU_IPIMSG_DEC_CORE_END_ACK:
break;
+ case VPU_IPIMSG_DEC_GET_PARAM_ACK:
+ handle_get_param_msg_ack(data);
+ break;
default:
mtk_vcodec_err(vpu, "invalid msg=%X", msg->msg_id);
break;
@@ -217,6 +241,31 @@ int vpu_dec_start(struct vdec_vpu_inst *vpu, uint32_t
*data, unsigned int len)
return err;
}
+int vpu_dec_get_param(struct vdec_vpu_inst *vpu, uint32_t *data,
+ unsigned int len, unsigned int param_type)
+{
+ struct vdec_ap_ipi_get_param msg;
+ int err;
+
+ mtk_vcodec_debug_enter(vpu);
+
+ if (len > ARRAY_SIZE(msg.data)) {
+ mtk_vcodec_err(vpu, "invalid len = %d\n", len);
+ return -EINVAL;
+ }
+
+ memset(, 0, sizeof(msg));
+ msg.msg_id = AP_IPIMSG_DEC_GET_PARAM;
+ msg.inst_id = vpu->inst_id;
+ memcpy(msg.data, data, sizeof(unsigned int) * len);
+ msg.param_type = param_type;
+ msg.codec_type = vpu->codec_type;
+
+ err = vcodec_vpu_send_msg(vpu, (void *), sizeof(msg));
+ mtk_vcodec_debug(vpu, "- ret=%d", err);
+ return err;
+}
+
int vpu_dec_core(struct vdec_vpu_inst *vpu)
{
return vcodec_send_ap_ipi(vpu, AP_IPIMSG_DEC_CORE);
diff
[PATCH v6, 01/15] media: mtk-vcodec: Add vdec enable/disable hardware helpers
Lock, power and clock are highly coupled operations. Adds vdec
enable/disable hardware helpers and uses them.
Signed-off-by: Yunfei Dong
Reviewed-by: Tzung-Bi Shih
---
.../platform/mtk-vcodec/mtk_vcodec_dec_drv.c | 5 -
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 168 +++---
.../platform/mtk-vcodec/mtk_vcodec_dec_pm.h | 6 +-
.../media/platform/mtk-vcodec/vdec_drv_if.c | 20 +--
.../platform/mtk-vcodec/vdec_msg_queue.c | 2 +
5 files changed, 117 insertions(+), 84 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
index 86b639d82be8..6b52eaeedafa 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_drv.c
@@ -195,9 +195,6 @@ static int fops_vcodec_open(struct file *file)
mtk_vcodec_dec_set_default_params(ctx);
if (v4l2_fh_is_singular(>fh)) {
- ret = mtk_vcodec_dec_pw_on(dev, MTK_VDEC_LAT0);
- if (ret < 0)
- goto err_load_fw;
/*
* Does nothing if firmware was already loaded.
*/
@@ -254,8 +251,6 @@ static int fops_vcodec_release(struct file *file)
v4l2_m2m_ctx_release(ctx->m2m_ctx);
mtk_vcodec_dec_release(ctx);
- if (v4l2_fh_is_singular(>fh))
- mtk_vcodec_dec_pw_off(dev, MTK_VDEC_LAT0);
v4l2_fh_del(>fh);
v4l2_fh_exit(>fh);
v4l2_ctrl_handler_free(>ctrl_hdl);
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
index 44035a50e335..1581a1277473 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec_pm.c
@@ -79,74 +79,31 @@ int mtk_vcodec_init_dec_clk(struct platform_device *pdev,
struct mtk_vcodec_pm *
}
EXPORT_SYMBOL_GPL(mtk_vcodec_init_dec_clk);
-int mtk_vcodec_dec_pw_on(struct mtk_vcodec_dev *vdec_dev, int hw_idx)
+static int mtk_vcodec_dec_pw_on(struct mtk_vcodec_pm *pm)
{
- struct mtk_vdec_hw_dev *subdev_dev;
- struct mtk_vcodec_pm *pm;
int ret;
- if (vdec_dev->vdec_pdata->is_subdev_supported) {
- subdev_dev = mtk_vcodec_get_hw_dev(vdec_dev, hw_idx);
- if (!subdev_dev) {
- mtk_v4l2_err("Failed to get hw dev\n");
- return -EINVAL;
- }
- pm = _dev->pm;
- } else {
- pm = _dev->pm;
- }
-
ret = pm_runtime_resume_and_get(pm->dev);
if (ret)
mtk_v4l2_err("pm_runtime_resume_and_get fail %d", ret);
return ret;
}
-EXPORT_SYMBOL_GPL(mtk_vcodec_dec_pw_on);
-void mtk_vcodec_dec_pw_off(struct mtk_vcodec_dev *vdec_dev, int hw_idx)
+static void mtk_vcodec_dec_pw_off(struct mtk_vcodec_pm *pm)
{
- struct mtk_vdec_hw_dev *subdev_dev;
- struct mtk_vcodec_pm *pm;
int ret;
- if (vdec_dev->vdec_pdata->is_subdev_supported) {
- subdev_dev = mtk_vcodec_get_hw_dev(vdec_dev, hw_idx);
- if (!subdev_dev) {
- mtk_v4l2_err("Failed to get hw dev\n");
- return;
- }
- pm = _dev->pm;
- } else {
- pm = _dev->pm;
- }
-
ret = pm_runtime_put_sync(pm->dev);
if (ret)
mtk_v4l2_err("pm_runtime_put_sync fail %d", ret);
}
-EXPORT_SYMBOL_GPL(mtk_vcodec_dec_pw_off);
-void mtk_vcodec_dec_clock_on(struct mtk_vcodec_dev *vdec_dev, int hw_idx)
+static void mtk_vcodec_dec_clock_on(struct mtk_vcodec_pm *pm)
{
- struct mtk_vdec_hw_dev *subdev_dev;
- struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *dec_clk;
int ret, i;
- if (vdec_dev->vdec_pdata->is_subdev_supported) {
- subdev_dev = mtk_vcodec_get_hw_dev(vdec_dev, hw_idx);
- if (!subdev_dev) {
- mtk_v4l2_err("Failed to get hw dev\n");
- return;
- }
- pm = _dev->pm;
- enable_irq(subdev_dev->dec_irq);
- } else {
- pm = _dev->pm;
- enable_irq(vdec_dev->dec_irq);
- }
-
dec_clk = >vdec_clk;
for (i = 0; i < dec_clk->clk_num; i++) {
ret = clk_prepare_enable(dec_clk->clk_info[i].vcodec_clk);
@@ -168,31 +125,120 @@ void mtk_vcodec_dec_clock_on(struct mtk_vcodec_dev
*vdec_dev, int hw_idx)
for (i -= 1; i >= 0; i--)
clk_disable_unprepare(dec_clk->clk_info[i].vcodec_clk);
}
-EXPORT_SYMBOL_GPL(mtk_vcodec_dec_clock_on);
-void mtk_vcodec_dec_clock_off(struct mtk_vcodec_dev *vdec_dev, int hw_idx)
+static void mtk_vcodec_dec_clock_off(struct mtk_vcodec_pm *pm)
{
- struct mtk_vdec_hw_dev *subdev_dev;
- struct mtk_vcodec_pm *pm;
struct mtk_vcodec_clk *dec_clk;
int
[PATCH v6, 00/15] media: mtk-vcodec: support for MT8192 decoder
This series adds support for mt8192 h264/vp8/vp9 decoder drivers. Firstly, refactor power/clock/interrupt interfaces for mt8192 is lat and core architecture. Secondly, add new functions to get frame buffer size and resolution according to decoder capability from scp side. Then add callback function to get/put capture buffer in order to enable lat and core decoder in parallel. Then add to support MT21C compressed mode and fix v4l2-compliance fail. Next, extract H264 request api driver to let mt8183 and mt8192 use the same code, and adds mt8192 frame based h264 driver for stateless decoder. Lastly, add vp8 and vp9 stateless decoder drivers. Patches 1 refactor power/clock/interrupt interface. Patches 2~4 get frame buffer size and resolution according to decoder capability. Patches 5~6 enable lat and core decode in parallel. Patch 7~10 add to support MT21C compressed mode and fix v4l2-compliance fail. patch 11 record capture queue format type. Patch 12~13 extract h264 driver and add mt8192 frame based driver for h264 decoder. Patch 14~15 add vp8 and vp9 stateless decoder drivers. --- changes compared with v5: - fix vp9 comments for patch 15 - fix vp8 comments for patch 14. - fix comments for patch 12. - fix build errors. changes compared with v4: - fix checkpatch.pl fail. - fix kernel-doc fail. - rebase to the latest media codec driver. changes compared with v3: - remove enum mtk_chip for patch 2. - add vp8 stateless decoder drivers for patch 14. - add vp9 stateless decoder drivers for patch 15. changes compared with v2: - add new patch 11 to record capture queue format type. - separate patch 4 according to tzung-bi's suggestion. - re-write commit message for patch 5 according to tzung-bi's suggestion. changes compared with v1: - rewrite commit message for patch 12. - rewrite cover-letter message. --- Yunfei Dong (15): media: mtk-vcodec: Add vdec enable/disable hardware helpers media: mtk-vcodec: Using firmware type to separate different firmware architecture media: mtk-vcodec: get capture queue buffer size from scp media: mtk-vcodec: Read max resolution from dec_capability media: mtk-vcodec: Call v4l2_m2m_set_dst_buffered() set capture buffer buffered media: mtk-vcodec: Refactor get and put capture buffer flow media: mtk-vcodec: Refactor supported vdec formats and framesizes media: mtk-vcodec: Add format to support MT21C media: mtk-vcodec: disable vp8 4K capability media: mtk-vcodec: Fix v4l2-compliance fail media: mtk-vcodec: record capture queue format type media: mtk-vcodec: Extract H264 common code media: mtk-vcodec: support stateless H.264 decoding for mt8192 media: mtk-vcodec: support stateless VP8 decoding media: mtk-vcodec: support stateless VP9 decoding drivers/media/platform/mtk-vcodec/Makefile|4 + .../platform/mtk-vcodec/mtk_vcodec_dec.c | 47 +- .../platform/mtk-vcodec/mtk_vcodec_dec_drv.c |5 - .../platform/mtk-vcodec/mtk_vcodec_dec_pm.c | 168 +- .../platform/mtk-vcodec/mtk_vcodec_dec_pm.h |6 +- .../mtk-vcodec/mtk_vcodec_dec_stateful.c | 14 +- .../mtk-vcodec/mtk_vcodec_dec_stateless.c | 282 ++- .../platform/mtk-vcodec/mtk_vcodec_drv.h | 40 +- .../platform/mtk-vcodec/mtk_vcodec_enc_drv.c |5 - .../media/platform/mtk-vcodec/mtk_vcodec_fw.c |6 + .../media/platform/mtk-vcodec/mtk_vcodec_fw.h |1 + .../mtk-vcodec/vdec/vdec_h264_req_common.c| 310 +++ .../mtk-vcodec/vdec/vdec_h264_req_common.h| 253 +++ .../mtk-vcodec/vdec/vdec_h264_req_if.c| 440 +--- .../mtk-vcodec/vdec/vdec_h264_req_multi_if.c | 614 + .../mtk-vcodec/vdec/vdec_vp8_req_if.c | 445 .../mtk-vcodec/vdec/vdec_vp9_req_lat_if.c | 1971 + .../media/platform/mtk-vcodec/vdec_drv_if.c | 36 +- .../media/platform/mtk-vcodec/vdec_drv_if.h |3 + .../media/platform/mtk-vcodec/vdec_ipi_msg.h | 36 + .../platform/mtk-vcodec/vdec_msg_queue.c |2 + .../media/platform/mtk-vcodec/vdec_vpu_if.c | 53 +- .../media/platform/mtk-vcodec/vdec_vpu_if.h | 15 + .../media/platform/mtk-vcodec/venc_vpu_if.c |2 +- include/linux/remoteproc/mtk_scp.h|2 + 25 files changed, 4174 insertions(+), 586 deletions(-) create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_common.h create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_multi_if.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_vp8_req_if.c create mode 100644 drivers/media/platform/mtk-vcodec/vdec/vdec_vp9_req_lat_if.c -- 2.25.1
Re: [PATCH v3 01/10] clk: Add Kunit tests for rate
Quoting Daniel Latypov (2022-01-20 21:25:03)
> On Thu, Jan 20, 2022 at 8:34 PM Stephen Boyd wrote:
> >
> > Quoting Daniel Latypov (2022-01-20 13:56:39)
> > > On Thu, Jan 20, 2022 at 1:31 PM Stephen Boyd wrote:
> > > KUnit doesn't have hard technical limitations in this regard.
> > >
> > > You could have something like this
> > >
> > > static void my_optional_kunit_test(struct kunit *test)
> > > {
> > > #ifdef CONFIG_OPTIONAL_FEATURE
> > >
> > > # else
> > > kunit_skip(test, "CONFIG_OPTIONAL_FEATURE is not enabled");
> > > #endif
> > > }
> > >
> > > I think it's just a matter of what's least confusing to users.
> >
> > Ok, I see. Is there some way to have multiple configs checked into the
> > tree so we can test different kernel configuration code paths? This
>
> Multiple kunitconfigs?
> There's no restrictions on those
>
> $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/clk
> $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/clk/kunitconfig.foo
> $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/clk/kunitconfig.bar
>
> The first one will assume drivers/clk/.kunitconfig.
> But there's no reason you need to have a file called that.
> One could just have multiple standalone kunitconfigs, named however they like.
>
> --kunitconfig is new enough (5.12+) that there's no real conventions yet.
>
> Another option is
> $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/clk \
>--kconfig_add=CONFIG_RARELY_USED=y
>
> This is another case where we can do whatever is least confusing.
Got it, thanks.
>
> > discussion isn't really relevant to this patch so we can take this up in
> > another thread if you like.
> >
> > >
> > > >
> > > > Maybe kunit should check that there was an EXPECT on return from the
> > > > test. Daniel?
> > >
> > > Sorry, I'm not sure I understand the question.
> > >
> > > Are you saying you want kunit to flag cases like
> > > static void empty_test(struct kunit *) {}
> > > ?
> >
> > Yes. I'd like kunit to enforce that all tests have at least one
> > EXPECT_*() in them.
>
> I totally understand the rationale.
> It's a bit misleading to say PASSED if no expectation/assertion passed.
> One might want a NO_STATUS (or maybe SKIPPED) result instead.
>
> But other unit test frameworks act the way KUnit does here, so there's
> an argument for consistency with others so users don't have to have a
> whole new mental model.
Ok if other test frameworks don't care then there's nothing to do.
[PATCH -next] drm/amd/display: don't use /** for non-kernel-doc comments
Change a static function's comment from "/**" (indicating kernel-doc
notation) to "/*" (indicating a regular C language comment).
This prevents multiple kernel-doc warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning:
Function parameter or member 'max_supported_frl_bw_in_kbps' not described in
'intersect_frl_link_bw_support'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning:
Function parameter or member 'hdmi_encoded_link_bw' not described in
'intersect_frl_link_bw_support'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:4343: warning:
expecting prototype for Return PCON's post FRL link training supported BW if
its non(). Prototype was for intersect_frl_link_bw_support() instead
Fixes: c022375ae095 ("drm/amd/display: Add DP-HDMI FRL PCON Support in DC")
Signed-off-by: Randy Dunlap
Reported-by: kernel test robot
Cc: Fangzhi Zuo
Cc: Alex Deucher
Cc: Nicholas Kazlauskas
Cc: Harry Wentland
Cc: Leo Li
Cc: Rodrigo Siqueira
Cc: amd-...@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
---
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20220121.orig/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ linux-next-20220121/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -4970,7 +4970,7 @@ uint32_t dc_link_bw_kbps_from_raw_frl_li
return 0;
}
-/**
+/*
* Return PCON's post FRL link training supported BW if its non-zero,
otherwise return max_supported_frl_bw.
*/
static uint32_t intersect_frl_link_bw_support(
Re: [RFC 21/28] dt-bindings: display: bridge: Document RZ/G2L MIPI DSI TX bindings
On Wed, Jan 12, 2022 at 05:46:05PM +, Biju Das wrote:
> The RZ/G2L MIPI DSI TX is embedded in the Renesas RZ/G2L family SoC's. It
> can operate in DSI mode, with up to four data lanes.
>
> Signed-off-by: Biju Das
> ---
> .../bindings/display/bridge/renesas,dsi.yaml | 143 ++
> 1 file changed, 143 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> new file mode 100644
> index ..8e56a9c53cc5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsi.yaml
> @@ -0,0 +1,143 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/display/bridge/renesas,dsi.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Renesas R-Car MIPI DSI Encoder
> +
> +maintainers:
> + - Biju Das
> +
> +description: |
> + This binding describes the MIPI DSI encoder embedded in the Renesas
> + RZ/G2L family of SoC's. The encoder can operate in DSI mode with up
> + to four data lanes.
Need a ref to dsi-controller.yaml.
> +
> +properties:
> + compatible:
> +enum:
> + - renesas,r9a07g044-mipi-dsi# for RZ/G2L
> +
> + reg:
> +items:
> + - description: Link register
> + - description: D-PHY register
D-PHY isn't a separate block?
> +
> + clocks:
> +items:
> + - description: DSI D-PHY PLL multiplied clock
> + - description: DSI D-PHY system clock
> + - description: DSI AXI bus clock
> + - description: DSI Register access clock
> + - description: DSI Video clock
> + - description: DSI D_PHY Escape mode Receive clock
> +
> + clock-names:
> +items:
> + - const: pllclk
> + - const: sysclk
> + - const: aclk
> + - const: pclk
> + - const: vclk
> + - const: lpclk
> +
> + power-domains:
> +maxItems: 1
> +
> + resets:
> +items:
> + - description: MIPI_DSI_CMN_RSTB
> + - description: MIPI_DSI_ARESET_N
> + - description: MIPI_DSI_PRESET_N
> +
> + reset-names:
> +items:
> + - const: rst
> + - const: arst
> + - const: prst
> +
> + ports:
> +$ref: /schemas/graph.yaml#/properties/ports
> +
> +properties:
> + port@0:
> +$ref: /schemas/graph.yaml#/properties/port
> +description: Parallel input port
> +
> + port@1:
> +$ref: /schemas/graph.yaml#/$defs/port-base
> +unevaluatedProperties: false
> +description: DSI output port
> +
> +properties:
> + endpoint:
> +$ref: /schemas/media/video-interfaces.yaml#
> +unevaluatedProperties: false
> +
> +properties:
> + data-lanes:
> +minItems: 1
> +maxItems: 4
> +
> +required:
> + - data-lanes
> +
> +required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - clock-names
> + - power-domains
> + - resets
> + - reset-names
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +
> +dsi0: dsi@1086 {
> +compatible = "renesas,r9a07g044-mipi-dsi";
> +reg = <0x1086 0x1>,
> + <0x1085 0x1>;
> +power-domains = <>;
> +clocks = < CPG_MOD R9A07G044_MIPI_DSI_PLLCLK>,
> + < CPG_MOD R9A07G044_MIPI_DSI_SYSCLK>,
> + < CPG_MOD R9A07G044_MIPI_DSI_ACLK>,
> + < CPG_MOD R9A07G044_MIPI_DSI_PCLK>,
> + < CPG_MOD R9A07G044_MIPI_DSI_VCLK>,
> + < CPG_MOD R9A07G044_MIPI_DSI_LPCLK>;
> +clock-names = "pllclk", "sysclk", "aclk", "pclk", "vclk", "lpclk";
> +resets = < R9A07G044_MIPI_DSI_CMN_RSTB>,
> + < R9A07G044_MIPI_DSI_ARESET_N>,
> + < R9A07G044_MIPI_DSI_PRESET_N>;
> +reset-names = "rst", "arst", "prst";
> +
> +ports {
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +port@0 {
> +reg = <0>;
> +dsi0_in: endpoint {
> +remote-endpoint = <_out_dsi0>;
> +};
> +};
> +
> +port@1 {
> +reg = <1>;
> +dsi0_out: endpoint {
> +data-lanes = <1 2 3 4>;
> +remote-endpoint = <_in>;
> +};
> +};
> +};
> +};
> +...
> --
> 2.17.1
>
>
Re: [RFC 17/28] dt-bindings: display: renesas,du: Document r9a07g044l bindings
On Wed, Jan 12, 2022 at 05:46:01PM +, Biju Das wrote: > Extend the Renesas DU display bindings to support the r9a07g044l RZ/G2L. > > Signed-off-by: Biju Das > --- > .../bindings/display/renesas,du.yaml | 54 +++ > 1 file changed, 54 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml > b/Documentation/devicetree/bindings/display/renesas,du.yaml > index 13efea574584..fc050b1088f3 100644 > --- a/Documentation/devicetree/bindings/display/renesas,du.yaml > +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml > @@ -40,6 +40,7 @@ properties: >- renesas,du-r8a77990 # for R-Car E3 compatible DU >- renesas,du-r8a77995 # for R-Car D3 compatible DU >- renesas,du-r8a779a0 # for R-Car V3U compatible DU > + - renesas,du-r9a07g044l # for RZ/G2L compatible DU > >reg: > maxItems: 1 > @@ -824,6 +825,59 @@ allOf: > - reset-names > - renesas,vsps > > + - if: > + properties: > +compatible: > + contains: > +enum: > + - renesas,du-r9a07g044l > +then: > + properties: > +clocks: > + items: > +- description: LCDC Main clock > +- description: LCDC Register Access Clock > +- description: LCDC Video Clock > + > +clock-names: > + items: > +- const: du.0 > +- const: pclk > +- const: vclk > + > +interrupts: > + maxItems: 1 > + > +resets: > + maxItems: 1 > + > +reset-names: > + items: > +- const: du.0 > + > +ports: > + properties: > +port@0: > + description: DPAD 0 > +port@1: > + description: DSI 0 > +port@2: false > +port@3: false > + > + required: > +- port@0 > +- port@1 > + > +renesas,vsps: > + minItems: 1 The minimum number of items is 1 by default if not otherwise specified. maxItems: 1 ??? > + > + required: > +- clock-names > +- interrupts > +- resets > +- reset-names > +- renesas,vsps > + > additionalProperties: false > > examples: > -- > 2.17.1 > >
[PATCH] drm/i915/selftests: Use less in contexts steal guc id test
Using more guc_ids in the stealing guc id test has no real benefit. Tearing down lots of contexts all at the same time takes a bit of time due to the H2G / G2H ping-pong with the GuC. On some slower platforms this can cause timeous when flushing the test as the GT isn't idle when this ping-pong is happening. Reduce the number of guc ids to speed up the flushing of the test. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/4821 Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c index d3327b802b761..a115894d5896e 100644 --- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c +++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c @@ -157,7 +157,7 @@ static int intel_guc_steal_guc_ids(void *arg) wakeref = intel_runtime_pm_get(gt->uncore->rpm); engine = intel_selftest_find_any_engine(gt); sv = guc->submission_state.num_guc_ids; - guc->submission_state.num_guc_ids = 4096; + guc->submission_state.num_guc_ids = 512; /* Create spinner to block requests in below loop */ ce[context_index] = intel_context_create(engine); -- 2.34.1
Re: [PATCH] dt-bindings: msm/mdp4: convert to yaml format
On Sun, 09 Jan 2022 18:18:13 +0100, David Heidelberg wrote: > Convert mdp4 binding into yaml format. > > Signed-off-by: David Heidelberg > --- > .../devicetree/bindings/display/msm/mdp4.txt | 114 > .../devicetree/bindings/display/msm/mdp4.yaml | 124 ++ > 2 files changed, 124 insertions(+), 114 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/display/msm/mdp4.txt > create mode 100644 Documentation/devicetree/bindings/display/msm/mdp4.yaml > Applied, thanks!
Re: [PATCH v3] dt-bindings: display/msm: hdmi: split and convert to yaml
On Sun, Jan 09, 2022 at 01:03:47AM +0100, David Heidelberg wrote:
> Convert Qualcomm HDMI binding into HDMI TX and PHY yaml bindings.
>
> Other changes:
> - fixed reg-names numbering to match 0..3 instead 0,1,3,4
> - phy part moved into phy/ directory
>
> Signed-off-by: David Heidelberg
> ---
> v2:
> - move phy into phy/
> - added maxItems for gpios
> - simplified pinctrl-names
> - dropped some inconsistent quotes
>
> v3:
> - adjusted $id of phy file to the new path from v2
> Signed-off-by: David Heidelberg
> ---
> .../devicetree/bindings/display/msm/hdmi.txt | 99 -
> .../bindings/display/msm/qcom,hdmi.yaml | 206 ++
> .../bindings/phy/qcom,hdmi-phy.yaml | 119 ++
> 3 files changed, 325 insertions(+), 99 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/display/msm/hdmi.txt
> create mode 100644
> Documentation/devicetree/bindings/display/msm/qcom,hdmi.yaml
> create mode 100644 Documentation/devicetree/bindings/phy/qcom,hdmi-phy.yaml
>
> diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt
> b/Documentation/devicetree/bindings/display/msm/hdmi.txt
> deleted file mode 100644
> index 5f90a40da51b..
> --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt
> +++ /dev/null
> @@ -1,99 +0,0 @@
> -Qualcomm adreno/snapdragon hdmi output
> -
> -Required properties:
> -- compatible: one of the following
> - * "qcom,hdmi-tx-8996"
> - * "qcom,hdmi-tx-8994"
> - * "qcom,hdmi-tx-8084"
> - * "qcom,hdmi-tx-8974"
> - * "qcom,hdmi-tx-8660"
> - * "qcom,hdmi-tx-8960"
> -- reg: Physical base address and length of the controller's registers
> -- reg-names: "core_physical"
> -- interrupts: The interrupt signal from the hdmi block.
> -- power-domains: Should be < MDSS_GDSC>.
> -- clocks: device clocks
> - See ../clocks/clock-bindings.txt for details.
> -- core-vdda-supply: phandle to supply regulator
> -- hdmi-mux-supply: phandle to mux regulator
> -- phys: the phandle for the HDMI PHY device
> -- phy-names: the name of the corresponding PHY device
> -
> -Optional properties:
> -- hpd-gpios: hpd pin
> -- qcom,hdmi-tx-mux-en-gpios: hdmi mux enable pin
> -- qcom,hdmi-tx-mux-sel-gpios: hdmi mux select pin
> -- qcom,hdmi-tx-mux-lpm-gpios: hdmi mux lpm pin
> -- power-domains: reference to the power domain(s), if available.
> -- pinctrl-names: the pin control state names; should contain "default"
> -- pinctrl-0: the default pinctrl state (active)
> -- pinctrl-1: the "sleep" pinctrl state
> -
> -HDMI PHY:
> -Required properties:
> -- compatible: Could be the following
> - * "qcom,hdmi-phy-8660"
> - * "qcom,hdmi-phy-8960"
> - * "qcom,hdmi-phy-8974"
> - * "qcom,hdmi-phy-8084"
> - * "qcom,hdmi-phy-8996"
> -- #phy-cells: Number of cells in a PHY specifier; Should be 0.
> -- reg: Physical base address and length of the registers of the PHY sub
> blocks.
> -- reg-names: The names of register regions. The following regions are
> required:
> - * "hdmi_phy"
> - * "hdmi_pll"
> - For HDMI PHY on msm8996, these additional register regions are required:
> -* "hdmi_tx_l0"
> -* "hdmi_tx_l1"
> -* "hdmi_tx_l3"
> -* "hdmi_tx_l4"
> -- power-domains: Should be < MDSS_GDSC>.
> -- clocks: device clocks
> - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> -- core-vdda-supply: phandle to vdda regulator device node
> -
> -Example:
> -
> -/ {
> - ...
> -
> - hdmi: hdmi@4a0 {
> - compatible = "qcom,hdmi-tx-8960";
> - reg-names = "core_physical";
> - reg = <0x04a0 0x2f0>;
> - interrupts = ;
> - power-domains = < MDSS_GDSC>;
> - clock-names =
> - "core",
> - "master_iface",
> - "slave_iface";
> - clocks =
> - < HDMI_APP_CLK>,
> - < HDMI_M_AHB_CLK>,
> - < HDMI_S_AHB_CLK>;
> - qcom,hdmi-tx-ddc-clk = < 70 GPIO_ACTIVE_HIGH>;
> - qcom,hdmi-tx-ddc-data = < 71 GPIO_ACTIVE_HIGH>;
> - qcom,hdmi-tx-hpd = < 72 GPIO_ACTIVE_HIGH>;
> - core-vdda-supply = <_hdmi_mvs>;
> - hdmi-mux-supply = <_3p3v>;
> - pinctrl-names = "default", "sleep";
> - pinctrl-0 = <_active _active _active>;
> - pinctrl-1 = <_suspend _suspend _suspend>;
> -
> - phys = <_phy>;
> - phy-names = "hdmi_phy";
> - };
> -
> - hdmi_phy: phy@4a00400 {
> - compatible = "qcom,hdmi-phy-8960";
> - reg-names = "hdmi_phy",
> - "hdmi_pll";
> - reg = <0x4a00400 0x60>,
> - <0x4a00500 0x100>;
> - #phy-cells = <0>;
> - power-domains = < MDSS_GDSC>;
> - clock-names = "slave_iface";
> - clocks = < HDMI_S_AHB_CLK>;
> - core-vdda-supply = <_hdmi_mvs>;
> - };
> -};
> diff --git
Re: [WIP PATCH] dt-bindings: display: msm: dsi-controller-main: distinguish DSI versions
On Sat, Jan 08, 2022 at 08:00:58PM +0100, David Heidelberg wrote: > Update documentation compatible and checking to comprehend > both V2 and 6G version bindings. > > Following this commit, there will be update for > compatible string in chipsets dtsi. > > Additional changes: > - switch to unevaluatedProperties > > Signed-off-by: David Heidelberg > --- > Rob, I know you mentioned using rather chipset names, but since > meanwhile I coded this, I'll let you decide if should make sense to > change it or keep it this way. It all depends on how many chips per version. I'm guessing only 1 or 2 given how many QCom SoCs I'm aware of. I think this should probably be split to 2 docs for the v2 and 6g versions. Rob
[PATCH v4 8/9] drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats
This will be useful to write tests that depends on these formats.
ARGB and XRGB follows the a similar implementation of the former formats.
Just adjusting for 16 bits per channel.
Signed-off-by: Igor Torrente
---
V3: Adapt the handlers to the new format introduced in patch 7 V3.
---
drivers/gpu/drm/vkms/vkms_formats.c | 67 +++
drivers/gpu/drm/vkms/vkms_formats.h | 12 +
drivers/gpu/drm/vkms/vkms_plane.c | 5 +-
drivers/gpu/drm/vkms/vkms_writeback.c | 2 +
4 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index 0d1838d1b835..661da39d1276 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -7,6 +7,10 @@ format_transform_func get_fmt_transform_function(u32 format)
{
if (format == DRM_FORMAT_ARGB)
return _to_ARGB16161616;
+ else if (format == DRM_FORMAT_ARGB16161616)
+ return _ARGB16161616;
+ else if (format == DRM_FORMAT_XRGB16161616)
+ return _to_ARGB16161616;
else
return _to_ARGB16161616;
}
@@ -15,6 +19,10 @@ format_transform_func get_wb_fmt_transform_function(u32
format)
{
if (format == DRM_FORMAT_ARGB)
return _to_ARGB;
+ else if (format == DRM_FORMAT_ARGB16161616)
+ return _to_ARGB16161616;
+ else if (format == DRM_FORMAT_XRGB16161616)
+ return _to_XRGB16161616;
else
return _to_XRGB;
}
@@ -89,6 +97,35 @@ void XRGB_to_ARGB16161616(struct vkms_frame_info
*frame_info, int y,
}
}
+void get_ARGB16161616(struct vkms_frame_info *frame_info, int y,
+ struct line_buffer *stage_buffer)
+{
+ u16 *src_pixels = get_packed_src_addr(frame_info, y);
+ int x, x_limit = drm_rect_width(_info->dst);
+
+ for (x = 0; x < x_limit; x++, src_pixels += 4) {
+ stage_buffer[x].a = src_pixels[3];
+ stage_buffer[x].r = src_pixels[2];
+ stage_buffer[x].g = src_pixels[1];
+ stage_buffer[x].b = src_pixels[0];
+ }
+}
+
+void XRGB16161616_to_ARGB16161616(struct vkms_frame_info *frame_info, int y,
+ struct line_buffer *stage_buffer)
+{
+ u16 *src_pixels = get_packed_src_addr(frame_info, y);
+ int x, x_limit = drm_rect_width(_info->dst);
+
+ for (x = 0; x < x_limit; x++, src_pixels += 4) {
+ stage_buffer[x].a = (u16)0x;
+ stage_buffer[x].r = src_pixels[2];
+ stage_buffer[x].g = src_pixels[1];
+ stage_buffer[x].b = src_pixels[0];
+ }
+}
+
+
/*
* The following functions take an line of ARGB16161616 pixels from the
* src_buffer, convert them to a specific format, and store them in the
@@ -136,3 +173,33 @@ void convert_to_XRGB(struct vkms_frame_info
*frame_info,
dst_pixels[0] = DIV_ROUND_UP(src_buffer[x].b, 257);
}
}
+
+void convert_to_ARGB16161616(struct vkms_frame_info *frame_info, int y,
+struct line_buffer *src_buffer)
+{
+ int x, x_dst = frame_info->dst.x1;
+ u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
+ int x_limit = drm_rect_width(_info->dst);
+
+ for (x = 0; x < x_limit; x++, dst_pixels += 4) {
+ dst_pixels[3] = src_buffer[x].a;
+ dst_pixels[2] = src_buffer[x].r;
+ dst_pixels[1] = src_buffer[x].g;
+ dst_pixels[0] = src_buffer[x].b;
+ }
+}
+
+void convert_to_XRGB16161616(struct vkms_frame_info *frame_info, int y,
+struct line_buffer *src_buffer)
+{
+ int x, x_dst = frame_info->dst.x1;
+ u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
+ int x_limit = drm_rect_width(_info->dst);
+
+ for (x = 0; x < x_limit; x++, dst_pixels += 4) {
+ dst_pixels[3] = src_buffer[x].a;
+ dst_pixels[2] = src_buffer[x].r;
+ dst_pixels[1] = src_buffer[x].g;
+ dst_pixels[0] = src_buffer[x].b;
+ }
+}
diff --git a/drivers/gpu/drm/vkms/vkms_formats.h
b/drivers/gpu/drm/vkms/vkms_formats.h
index 817e8b2124ae..22358f3a33ab 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.h
+++ b/drivers/gpu/drm/vkms/vkms_formats.h
@@ -15,12 +15,24 @@ void ARGB_to_ARGB16161616(struct vkms_frame_info
*frame_info, int y,
void XRGB_to_ARGB16161616(struct vkms_frame_info *frame_info, int y,
struct line_buffer *stage_buffer);
+void get_ARGB16161616(struct vkms_frame_info *frame_info, int y,
+ struct line_buffer *stage_buffer);
+
+void XRGB16161616_to_ARGB16161616(struct vkms_frame_info *frame_info, int y,
+ struct line_buffer *stage_buffer);
+
void convert_to_ARGB(struct vkms_frame_info *frame_info, int y,
[PATCH v4 9/9] drm: vkms: Add support to the RGB565 format
Adds this common format to vkms.
This commit also adds new helper macros to deal with fixed-point
arithmetic.
It was done to improve the precision of the conversion to ARGB16161616
since the "conversion ratio" is not an integer.
Signed-off-by: Igor Torrente
---
V3: Adapt the handlers to the new format introduced in patch 7 V3.
---
drivers/gpu/drm/vkms/vkms_formats.c | 74 +++
drivers/gpu/drm/vkms/vkms_formats.h | 6 +++
drivers/gpu/drm/vkms/vkms_plane.c | 6 ++-
drivers/gpu/drm/vkms/vkms_writeback.c | 3 +-
4 files changed, 86 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_formats.c
b/drivers/gpu/drm/vkms/vkms_formats.c
index 661da39d1276..dc612882dd8c 100644
--- a/drivers/gpu/drm/vkms/vkms_formats.c
+++ b/drivers/gpu/drm/vkms/vkms_formats.c
@@ -11,6 +11,8 @@ format_transform_func get_fmt_transform_function(u32 format)
return _ARGB16161616;
else if (format == DRM_FORMAT_XRGB16161616)
return _to_ARGB16161616;
+ else if (format == DRM_FORMAT_RGB565)
+ return _to_ARGB16161616;
else
return _to_ARGB16161616;
}
@@ -23,6 +25,8 @@ format_transform_func get_wb_fmt_transform_function(u32
format)
return _to_ARGB16161616;
else if (format == DRM_FORMAT_XRGB16161616)
return _to_XRGB16161616;
+ else if (format == DRM_FORMAT_RGB565)
+ return _to_RGB565;
else
return _to_XRGB;
}
@@ -33,6 +37,26 @@ static int pixel_offset(struct vkms_frame_info *frame_info,
int x, int y)
+ (x * frame_info->cpp);
}
+/*
+ * FP stands for _Fixed Point_ and **not** _Float Point_
+ * LF stands for Long Float (i.e. double)
+ * The following macros help doing fixed point arithmetic.
+ */
+/*
+ * With FP scale 15 we have 17 and 15 bits of integer and fractional parts
+ * respectively.
+ * | 0.000 |
+ * 31 0
+ */
+#define FP_SCALE 15
+
+#define LF_TO_FP(a) ((a) * (u64)(1 << FP_SCALE))
+#define INT_TO_FP(a) ((a) << FP_SCALE)
+#define FP_MUL(a, b) ((s32)(((s64)(a) * (b)) >> FP_SCALE))
+#define FP_DIV(a, b) ((s32)(((s64)(a) << FP_SCALE) / (b)))
+/* This macro converts a fixed point number to int, and round half up it */
+#define FP_TO_INT_ROUND_UP(a) (((a) + (1 << (FP_SCALE - 1))) >> FP_SCALE)
+
/*
* packed_pixels_addr - Get the pointer to pixel of a given pair of coordinates
*
@@ -125,6 +149,33 @@ void XRGB16161616_to_ARGB16161616(struct vkms_frame_info
*frame_info, int y,
}
}
+void RGB565_to_ARGB16161616(struct vkms_frame_info *frame_info, int y,
+ struct line_buffer *stage_buffer)
+{
+ u16 *src_pixels = get_packed_src_addr(frame_info, y);
+ int x, x_limit = drm_rect_width(_info->dst);
+
+ for (x = 0; x < x_limit; x++, src_pixels++) {
+ u16 rgb_565 = le16_to_cpu(*src_pixels);
+ int fp_r = INT_TO_FP((rgb_565 >> 11) & 0x1f);
+ int fp_g = INT_TO_FP((rgb_565 >> 5) & 0x3f);
+ int fp_b = INT_TO_FP(rgb_565 & 0x1f);
+
+ /*
+* The magic constants is the "conversion ratio" and is
calculated
+* dividing 65535(2^16 - 1) by 31(2^5 -1) and 63(2^6 - 1)
+* respectively.
+*/
+ int fp_rb_ratio = LF_TO_FP(2114.032258065);
+ int fp_g_ratio = LF_TO_FP(1040.238095238);
+
+ stage_buffer[x].a = (u16)0x;
+ stage_buffer[x].r = FP_TO_INT_ROUND_UP(FP_MUL(fp_r,
fp_rb_ratio));
+ stage_buffer[x].g = FP_TO_INT_ROUND_UP(FP_MUL(fp_g,
fp_g_ratio));
+ stage_buffer[x].b = FP_TO_INT_ROUND_UP(FP_MUL(fp_b,
fp_rb_ratio));
+ }
+}
+
/*
* The following functions take an line of ARGB16161616 pixels from the
@@ -203,3 +254,26 @@ void convert_to_XRGB16161616(struct vkms_frame_info
*frame_info, int y,
dst_pixels[0] = src_buffer[x].b;
}
}
+
+void convert_to_RGB565(struct vkms_frame_info *frame_info, int y,
+ struct line_buffer *src_buffer)
+{
+ int x, x_dst = frame_info->dst.x1;
+ u16 *dst_pixels = packed_pixels_addr(frame_info, x_dst, y);
+ int x_limit = drm_rect_width(_info->dst);
+
+ for (x = 0; x < x_limit; x++, dst_pixels++) {
+ int fp_r = INT_TO_FP(src_buffer[x].r);
+ int fp_g = INT_TO_FP(src_buffer[x].g);
+ int fp_b = INT_TO_FP(src_buffer[x].b);
+
+ int fp_rb_ratio = LF_TO_FP(2114.032258065);
+ int fp_g_ratio = LF_TO_FP(1040.238095238);
+
+ u16 r = FP_TO_INT_ROUND_UP(FP_DIV(fp_r, fp_rb_ratio));
+ u16 g = FP_TO_INT_ROUND_UP(FP_DIV(fp_g, fp_g_ratio));
+ u16 b = FP_TO_INT_ROUND_UP(FP_DIV(fp_b, fp_rb_ratio));
+
+ *dst_pixels = cpu_to_le16(r << 11 | g << 5 | b);
[PATCH v4 6/9] drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation
Add a helper function to validate the connector configuration receive in
the encoder atomic_check by the drivers.
So the drivers don't need do these common validations themselves.
Signed-off-by: Igor Torrente
---
V2: Move the format verification to a new helper at the drm_atomic_helper.c
(Thomas Zimmermann).
V3: Format check improvements (Leandro Ribeiro).
Minor improvements(Thomas Zimmermann).
---
drivers/gpu/drm/drm_atomic_helper.c | 39 +++
drivers/gpu/drm/vkms/vkms_writeback.c | 9 +++
include/drm/drm_atomic_helper.h | 3 +++
3 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index a7a05e1e26bb..ccb6e62bf80a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -776,6 +776,45 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
}
EXPORT_SYMBOL(drm_atomic_helper_check_modeset);
+/**
+ * drm_atomic_helper_check_wb_connector_state() - Check writeback encoder state
+ * @encoder: encoder state to check
+ * @conn_state: connector state to check
+ *
+ * Checks if the writeback connector state is valid, and returns an error if it
+ * isn't.
+ *
+ * RETURNS:
+ * Zero for success or -errno
+ */
+int
+drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
+struct drm_connector_state *conn_state)
+{
+ struct drm_writeback_job *wb_job = conn_state->writeback_job;
+ struct drm_property_blob *pixel_format_blob;
+ struct drm_framebuffer *fb;
+ size_t i, nformats;
+ u32 *formats;
+
+ if (!wb_job || !wb_job->fb)
+ return 0;
+
+ pixel_format_blob = wb_job->connector->pixel_formats_blob_ptr;
+ nformats = pixel_format_blob->length / sizeof(u32);
+ formats = pixel_format_blob->data;
+ fb = wb_job->fb;
+
+ for (i = 0; i < nformats; i++)
+ if (fb->format->format == formats[i])
+ return 0;
+
+ drm_dbg_kms(encoder->dev, "Invalid pixel format %p4cc\n",
>format->format);
+
+ return -EINVAL;
+}
+EXPORT_SYMBOL(drm_atomic_helper_check_wb_encoder_state);
+
/**
* drm_atomic_helper_check_plane_state() - Check plane state for validity
* @plane_state: plane state to check
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
b/drivers/gpu/drm/vkms/vkms_writeback.c
index de379331b236..ad4bb1fb37ca 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -30,6 +30,7 @@ static int vkms_wb_encoder_atomic_check(struct drm_encoder
*encoder,
{
struct drm_framebuffer *fb;
const struct drm_display_mode *mode = _state->mode;
+ int ret;
if (!conn_state->writeback_job || !conn_state->writeback_job->fb)
return 0;
@@ -41,11 +42,9 @@ static int vkms_wb_encoder_atomic_check(struct drm_encoder
*encoder,
return -EINVAL;
}
- if (fb->format->format != vkms_wb_formats[0]) {
- DRM_DEBUG_KMS("Invalid pixel format %p4cc\n",
- >format->format);
- return -EINVAL;
- }
+ ret = drm_atomic_helper_check_wb_encoder_state(encoder, conn_state);
+ if (ret < 0)
+ return ret;
return 0;
}
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 4045e2507e11..3fbf695da60f 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -40,6 +40,9 @@ struct drm_private_state;
int drm_atomic_helper_check_modeset(struct drm_device *dev,
struct drm_atomic_state *state);
+int
+drm_atomic_helper_check_wb_encoder_state(struct drm_encoder *encoder,
+struct drm_connector_state
*conn_state);
int drm_atomic_helper_check_plane_state(struct drm_plane_state *plane_state,
const struct drm_crtc_state *crtc_state,
int min_scale,
--
2.30.2
[PATCH v4 7/9] drm: vkms: Refactor the plane composer to accept new formats
Currently the blend function only accepts XRGB_ and ARGB_
as a color input.
This patch refactors all the functions related to the plane composition
to overcome this limitation.
A new internal format(`struct pixel`) is introduced to deal with all
possible inputs. It consists of 16 bits fields that represent each of
the channels.
The pixels blend is done using this internal format. And new handlers
are being added to convert a specific format to/from this internal format.
So the blend operation depends on these handlers to convert to this common
format. The blended result, if necessary, is converted to the writeback
buffer format.
This patch introduces three major differences to the blend function.
1 - All the planes are blended at once.
2 - The blend calculus is done as per line instead of per pixel.
3 - It is responsible to calculates the CRC and writing the writeback
buffer(if necessary).
These changes allow us to allocate way less memory in the intermediate
buffer to compute these operations. Because now we don't need to
have the entire intermediate image lines at once, just one line is
enough.
| Memory consumption (output dimensions) |
|:--:|
| Current | This patch|
|:--:|:-:|
| Width * Heigth | 2 * Width |
Beyond memory, we also have a minor performance benefit from all
these changes. Results running the IGT tests `*kms_cursor_crc*`:
| Frametime |
|:--:|
| Implementation | Current | This commit |
|:---:|:-:|::|
| frametime range | 8~22 ms |5~18 ms |
| Average | 10.0 ms |7.3 ms|
Reported-by: kernel test robot
Signed-off-by: Igor Torrente
---
V2: Improves the performance drastically, by perfoming the operations
per-line and not per-pixel(Pekka Paalanen).
Minor improvements(Pekka Paalanen).
V3: Changes the code to blend the planes all at once. This improves
performance, memory consumption, and removes much of the weirdness
of the V2(Pekka Paalanen and me).
Minor improvements(Pekka Paalanen and me).
V4: Rebase the code and adapt it to the new NUM_OVERLAY_PLANES constant.
---
drivers/gpu/drm/vkms/Makefile| 1 +
drivers/gpu/drm/vkms/vkms_composer.c | 335 +--
drivers/gpu/drm/vkms/vkms_formats.c | 138 +++
drivers/gpu/drm/vkms/vkms_formats.h | 31 +++
4 files changed, 333 insertions(+), 172 deletions(-)
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c
create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h
diff --git a/drivers/gpu/drm/vkms/Makefile b/drivers/gpu/drm/vkms/Makefile
index 72f779cbfedd..1b28a6a32948 100644
--- a/drivers/gpu/drm/vkms/Makefile
+++ b/drivers/gpu/drm/vkms/Makefile
@@ -3,6 +3,7 @@ vkms-y := \
vkms_drv.o \
vkms_plane.o \
vkms_output.o \
+ vkms_formats.o \
vkms_crtc.o \
vkms_composer.o \
vkms_writeback.o
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 95029d2ebcac..9f70fcf84fb9 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -9,202 +9,210 @@
#include
#include "vkms_drv.h"
+#include "vkms_formats.h"
-static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
-const struct vkms_frame_info *frame_info)
+static u16 pre_mul_blend_channel(u16 src, u16 dst, u16 alpha)
{
- u32 pixel;
- int src_offset = frame_info->offset + (y * frame_info->pitch)
- + (x * frame_info->cpp);
+ u32 new_color;
- pixel = *(u32 *)[src_offset];
+ new_color = (src * 0x + dst * (0x - alpha));
- return pixel;
+ return DIV_ROUND_UP(new_color, 0x);
}
/**
- * compute_crc - Compute CRC value on output frame
+ * pre_mul_alpha_blend - alpha blending equation
+ * @src_frame_info: source framebuffer's metadata
+ * @stage_buffer: The line with the pixels from src_plane
+ * @output_buffer: A line buffer that receives all the blends output
*
- * @vaddr: address to final framebuffer
- * @frame_info: framebuffer's metadata
+ * Using the information from the `frame_info`, this blends only the
+ * necessary pixels from the `stage_buffer` to the `output_buffer`
+ * using premultiplied blend formula.
*
- * returns CRC value computed using crc32 on the visible portion of
- * the final framebuffer at vaddr_out
+ * The current DRM assumption is that pixel color values have been already
+ * pre-multiplied with the alpha channel values. See more
+ * drm_plane_create_blend_mode_property(). Also, this formula assumes a
+ * completely opaque background.
*/
-static uint32_t compute_crc(const u8 *vaddr,
- const struct vkms_frame_info *frame_info)
+static void pre_mul_alpha_blend(struct
[PATCH v4 5/9] drm: vkms: Add fb information to `vkms_writeback_job`
This commit is the groundwork to introduce new formats to the planes and
writeback buffer. As part of it, a new buffer metadata field is added to
`vkms_writeback_job`, this metadata is represented by the `vkms_composer`
struct.
This will allow us, in the future, to have different compositing and wb
format types.
Signed-off-by: Igor Torrente
---
V2: Change the code to get the drm_framebuffer reference and not copy its
contents(Thomas Zimmermann).
V3: Drop the refcount in the wb code(Thomas Zimmermann).
---
drivers/gpu/drm/vkms/vkms_composer.c | 4 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 12 ++--
drivers/gpu/drm/vkms/vkms_plane.c | 10 +-
drivers/gpu/drm/vkms/vkms_writeback.c | 20 +---
4 files changed, 30 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 2d946368a561..95029d2ebcac 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -153,7 +153,7 @@ static void compose_plane(struct vkms_frame_info
*primary_plane_info,
struct vkms_frame_info *plane_frame_info,
void *vaddr_out)
{
- struct drm_framebuffer *fb = _frame_info->fb;
+ struct drm_framebuffer *fb = plane_frame_info->fb;
void *vaddr;
void (*pixel_blend)(const u8 *p_src, u8 *p_dst);
@@ -175,7 +175,7 @@ static int compose_active_planes(void **vaddr_out,
struct vkms_frame_info *primary_plane_info,
struct vkms_crtc_state *crtc_state)
{
- struct drm_framebuffer *fb = _plane_info->fb;
+ struct drm_framebuffer *fb = primary_plane_info->fb;
struct drm_gem_object *gem_obj = drm_gem_fb_get_obj(fb, 0);
const void *vaddr;
int i;
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 2e6342164bef..c850d755247c 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -22,13 +22,8 @@
#define NUM_OVERLAY_PLANES 8
-struct vkms_writeback_job {
- struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
- struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
-};
-
struct vkms_frame_info {
- struct drm_framebuffer fb;
+ struct drm_framebuffer *fb;
struct drm_rect src, dst;
struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
unsigned int offset;
@@ -36,6 +31,11 @@ struct vkms_frame_info {
unsigned int cpp;
};
+struct vkms_writeback_job {
+ struct dma_buf_map data[DRM_FORMAT_MAX_PLANES];
+ struct vkms_frame_info frame_info;
+};
+
/**
* vkms_plane_state - Driver specific plane state
* @base: base plane state
diff --git a/drivers/gpu/drm/vkms/vkms_plane.c
b/drivers/gpu/drm/vkms/vkms_plane.c
index a56b0f76eddd..28752af0118c 100644
--- a/drivers/gpu/drm/vkms/vkms_plane.c
+++ b/drivers/gpu/drm/vkms/vkms_plane.c
@@ -50,12 +50,12 @@ static void vkms_plane_destroy_state(struct drm_plane
*plane,
struct vkms_plane_state *vkms_state = to_vkms_plane_state(old_state);
struct drm_crtc *crtc = vkms_state->base.base.crtc;
- if (crtc) {
+ if (crtc && vkms_state->frame_info->fb) {
/* dropping the reference we acquired in
* vkms_primary_plane_update()
*/
- if (drm_framebuffer_read_refcount(_state->frame_info->fb))
- drm_framebuffer_put(_state->frame_info->fb);
+ if (drm_framebuffer_read_refcount(vkms_state->frame_info->fb))
+ drm_framebuffer_put(vkms_state->frame_info->fb);
}
kfree(vkms_state->frame_info);
@@ -110,9 +110,9 @@ static void vkms_plane_atomic_update(struct drm_plane
*plane,
frame_info = vkms_plane_state->frame_info;
memcpy(_info->src, _state->src, sizeof(struct drm_rect));
memcpy(_info->dst, _state->dst, sizeof(struct drm_rect));
- memcpy(_info->fb, fb, sizeof(struct drm_framebuffer));
+ frame_info->fb = fb;
memcpy(_info->map, _plane_state->data,
sizeof(frame_info->map));
- drm_framebuffer_get(_info->fb);
+ drm_framebuffer_get(frame_info->fb);
frame_info->offset = fb->offsets[0];
frame_info->pitch = fb->pitches[0];
frame_info->cpp = fb->format->cpp[0];
diff --git a/drivers/gpu/drm/vkms/vkms_writeback.c
b/drivers/gpu/drm/vkms/vkms_writeback.c
index 8694227f555f..de379331b236 100644
--- a/drivers/gpu/drm/vkms/vkms_writeback.c
+++ b/drivers/gpu/drm/vkms/vkms_writeback.c
@@ -75,12 +75,15 @@ static int vkms_wb_prepare_job(struct
drm_writeback_connector *wb_connector,
if (!vkmsjob)
return -ENOMEM;
- ret = drm_gem_fb_vmap(job->fb, vkmsjob->map, vkmsjob->data);
+ ret = drm_gem_fb_vmap(job->fb, vkmsjob->frame_info.map, vkmsjob->data);
if (ret) {
DRM_ERROR("vmap failed: %d\n", ret);
goto
[PATCH v4 4/9] drm: vkms: Rename `vkms_composer` to `vkms_frame_info`
Changes the name of this struct to a more meaningful name.
A name that represents better what this struct is about.
Composer is the code that do the compositing of the planes.
This struct is contains information of the frame that is
being used in the output composition. Thus, vkms_frame_info
is a better name to represent this.
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_composer.c | 87 ++--
drivers/gpu/drm/vkms/vkms_drv.h | 6 +-
drivers/gpu/drm/vkms/vkms_plane.c| 38 ++--
3 files changed, 66 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 82f79e508f81..2d946368a561 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -11,11 +11,11 @@
#include "vkms_drv.h"
static u32 get_pixel_from_buffer(int x, int y, const u8 *buffer,
-const struct vkms_composer *composer)
+const struct vkms_frame_info *frame_info)
{
u32 pixel;
- int src_offset = composer->offset + (y * composer->pitch)
- + (x * composer->cpp);
+ int src_offset = frame_info->offset + (y * frame_info->pitch)
+ + (x * frame_info->cpp);
pixel = *(u32 *)[src_offset];
@@ -26,24 +26,24 @@ static u32 get_pixel_from_buffer(int x, int y, const u8
*buffer,
* compute_crc - Compute CRC value on output frame
*
* @vaddr: address to final framebuffer
- * @composer: framebuffer's metadata
+ * @frame_info: framebuffer's metadata
*
* returns CRC value computed using crc32 on the visible portion of
* the final framebuffer at vaddr_out
*/
static uint32_t compute_crc(const u8 *vaddr,
- const struct vkms_composer *composer)
+ const struct vkms_frame_info *frame_info)
{
int x, y;
u32 crc = 0, pixel = 0;
- int x_src = composer->src.x1 >> 16;
- int y_src = composer->src.y1 >> 16;
- int h_src = drm_rect_height(>src) >> 16;
- int w_src = drm_rect_width(>src) >> 16;
+ int x_src = frame_info->src.x1 >> 16;
+ int y_src = frame_info->src.y1 >> 16;
+ int h_src = drm_rect_height(_info->src) >> 16;
+ int w_src = drm_rect_width(_info->src) >> 16;
for (y = y_src; y < y_src + h_src; ++y) {
for (x = x_src; x < x_src + w_src; ++x) {
- pixel = get_pixel_from_buffer(x, y, vaddr, composer);
+ pixel = get_pixel_from_buffer(x, y, vaddr, frame_info);
crc = crc32_le(crc, (void *), sizeof(u32));
}
}
@@ -98,8 +98,8 @@ static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst)
* blend - blend value at vaddr_src with value at vaddr_dst
* @vaddr_dst: destination address
* @vaddr_src: source address
- * @dst_composer: destination framebuffer's metadata
- * @src_composer: source framebuffer's metadata
+ * @dst_frame_info: destination framebuffer's metadata
+ * @src_frame_info: source framebuffer's metadata
* @pixel_blend: blending equation based on plane format
*
* Blend the vaddr_src value with the vaddr_dst value using a pixel blend
@@ -111,33 +111,33 @@ static void x_blend(const u8 *xrgb_src, u8 *xrgb_dst)
* pixel color values
*/
static void blend(void *vaddr_dst, void *vaddr_src,
- struct vkms_composer *dst_composer,
- struct vkms_composer *src_composer,
+ struct vkms_frame_info *dst_frame_info,
+ struct vkms_frame_info *src_frame_info,
void (*pixel_blend)(const u8 *, u8 *))
{
int i, j, j_dst, i_dst;
int offset_src, offset_dst;
u8 *pixel_dst, *pixel_src;
- int x_src = src_composer->src.x1 >> 16;
- int y_src = src_composer->src.y1 >> 16;
+ int x_src = src_frame_info->src.x1 >> 16;
+ int y_src = src_frame_info->src.y1 >> 16;
- int x_dst = src_composer->dst.x1;
- int y_dst = src_composer->dst.y1;
- int h_dst = drm_rect_height(_composer->dst);
- int w_dst = drm_rect_width(_composer->dst);
+ int x_dst = src_frame_info->dst.x1;
+ int y_dst = src_frame_info->dst.y1;
+ int h_dst = drm_rect_height(_frame_info->dst);
+ int w_dst = drm_rect_width(_frame_info->dst);
int y_limit = y_src + h_dst;
int x_limit = x_src + w_dst;
for (i = y_src, i_dst = y_dst; i < y_limit; ++i) {
for (j = x_src, j_dst = x_dst; j < x_limit; ++j) {
- offset_dst = dst_composer->offset
-+ (i_dst * dst_composer->pitch)
-+ (j_dst++ * dst_composer->cpp);
- offset_src = src_composer->offset
-+ (i * src_composer->pitch)
-+
[PATCH v4 3/9] drm: vkms: Replace hardcoded value of `vkms_composer.map` to DRM_FORMAT_MAX_PLANES
The `map` vector at `vkms_composer` uses a hardcoded value to define its
size.
If someday the maximum number of planes increases, this hardcoded value
can be a problem.
This value is being replaced with the DRM_FORMAT_MAX_PLANES macro.
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h
index 9496fdc900b8..0eeea6f93733 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.h
+++ b/drivers/gpu/drm/vkms/vkms_drv.h
@@ -30,7 +30,7 @@ struct vkms_writeback_job {
struct vkms_composer {
struct drm_framebuffer fb;
struct drm_rect src, dst;
- struct dma_buf_map map[4];
+ struct dma_buf_map map[DRM_FORMAT_MAX_PLANES];
unsigned int offset;
unsigned int pitch;
unsigned int cpp;
--
2.30.2
[PATCH v4 2/9] drm: vkms: Alloc the compose frame using vzalloc
Currently, the memory to the composition frame is being allocated using
the kzmalloc. This comes with the limitation of maximum size of one
page size(which in the x86_64 is 4Kb and 4MB for default and hugepage
respectively).
Somes test of igt (e.g. kms_plane@pixel-format) uses more than 4MB when
testing some pixel formats like ARGB16161616.
This problem is addessed by allocating the memory using kvzalloc that
circunvents this limitation.
Signed-off-by: Igor Torrente
---
drivers/gpu/drm/vkms/vkms_composer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vkms/vkms_composer.c
b/drivers/gpu/drm/vkms/vkms_composer.c
index 9e8204be9a14..82f79e508f81 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -180,7 +180,7 @@ static int compose_active_planes(void **vaddr_out,
int i;
if (!*vaddr_out) {
- *vaddr_out = kzalloc(gem_obj->size, GFP_KERNEL);
+ *vaddr_out = kvzalloc(gem_obj->size, GFP_KERNEL);
if (!*vaddr_out) {
DRM_ERROR("Cannot allocate memory for output frame.");
return -ENOMEM;
@@ -263,7 +263,7 @@ void vkms_composer_worker(struct work_struct *work)
crtc_state);
if (ret) {
if (ret == -EINVAL && !wb_pending)
- kfree(vaddr_out);
+ kvfree(vaddr_out);
return;
}
@@ -275,7 +275,7 @@ void vkms_composer_worker(struct work_struct *work)
crtc_state->wb_pending = false;
spin_unlock_irq(>composer_lock);
} else {
- kfree(vaddr_out);
+ kvfree(vaddr_out);
}
/*
--
2.30.2
[PATCH v4 1/9] drm: vkms: Replace the deprecated drm_mode_config_init
`drm_mode_config_init` is deprecated since commit c3b790ea07a1 ("drm: Manage
drm_mode_config_init with drmm_") in favor of `drmm_mode_config_init`. Update
the former to the latter.
Signed-off-by: Igor Torrente
---
V2: Change the code style(Thomas Zimmermann).
V4: Update the commit message(Nícolas F. R. A. Prado)
---
drivers/gpu/drm/vkms/vkms_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vkms/vkms_drv.c b/drivers/gpu/drm/vkms/vkms_drv.c
index 0ffe5f0e33f7..ee4d96dabe19 100644
--- a/drivers/gpu/drm/vkms/vkms_drv.c
+++ b/drivers/gpu/drm/vkms/vkms_drv.c
@@ -140,8 +140,12 @@ static const struct drm_mode_config_helper_funcs
vkms_mode_config_helpers = {
static int vkms_modeset_init(struct vkms_device *vkmsdev)
{
struct drm_device *dev = >drm;
+ int ret;
+
+ ret = drmm_mode_config_init(dev);
+ if (ret < 0)
+ return ret;
- drm_mode_config_init(dev);
dev->mode_config.funcs = _mode_funcs;
dev->mode_config.min_width = XRES_MIN;
dev->mode_config.min_height = YRES_MIN;
--
2.30.2
[PATCH v4 0/9] Add new formats support to vkms
Summary === This series of patches refactor some vkms components in order to introduce new formats to the planes and writeback connector. Now in the blend function, the plane's pixels are converted to ARGB16161616 and then blended together. The CRC is calculated based on the ARGB1616161616 buffer. And if required, this buffer is copied/converted to the writeback buffer format. And to handle the pixel conversion, new functions were added to convert from a specific format to ARGB16161616 (the reciprocal is also true). Tests = This patch series was tested using the following igt tests: -t ".*kms_plane.*" -t ".*kms_writeback.*" -t ".*kms_cursor_crc*" -t ".*kms_flip.*" New tests passing --- - pipe-A-cursor-size-change - pipe-A-cursor-alpha-transparent Performance --- Further optimizing the code, now it's running slightly faster than the V2. And it consumes less memory than the current implementation in the common case (more detail in the commit message). Results running the IGT tests `kms_cursor_crc`: | Frametime | |:---:|:-:|:--:|::|:---:| | implmentation | Current | Per-pixel(V1) | Per-line(V2) | V3| | frametime range | 8~22 ms |32~56 ms|6~19 ms | 5~18 ms | | Average | 10.0 ms | 35.8 ms|8.6 ms| 7.3 ms | | Memory consumption (output dimensions) | |:--:| | Current | This patch| |:--:|:-:| | Width * Heigth | 2 * Width | XRGB to ARGB behavior = During the development, I decided to always fill the alpha channel of the output pixel whenever the conversion from a format without an alpha channel to ARGB16161616 is necessary. Therefore, I ignore the value received from the XRGB and overwrite the value with 0x. --- Igor Torrente (9): drm: vkms: Replace the deprecated drm_mode_config_init drm: vkms: Alloc the compose frame using vzalloc drm: vkms: Replace hardcoded value of `vkms_composer.map` to DRM_FORMAT_MAX_PLANES drm: vkms: Rename `vkms_composer` to `vkms_frame_info` drm: vkms: Add fb information to `vkms_writeback_job` drm: drm_atomic_helper: Add a new helper to deal with the writeback connector validation drm: vkms: Refactor the plane composer to accept new formats drm: vkms: Adds XRGB_16161616 and ARGB_1616161616 formats drm: vkms: Add support to the RGB565 format drivers/gpu/drm/drm_atomic_helper.c | 39 +++ drivers/gpu/drm/vkms/Makefile | 1 + drivers/gpu/drm/vkms/vkms_composer.c | 336 +- drivers/gpu/drm/vkms/vkms_drv.c | 6 +- drivers/gpu/drm/vkms/vkms_drv.h | 20 +- drivers/gpu/drm/vkms/vkms_formats.c | 279 + drivers/gpu/drm/vkms/vkms_formats.h | 49 drivers/gpu/drm/vkms/vkms_plane.c | 47 ++-- drivers/gpu/drm/vkms/vkms_writeback.c | 32 ++- include/drm/drm_atomic_helper.h | 3 + 10 files changed, 600 insertions(+), 212 deletions(-) create mode 100644 drivers/gpu/drm/vkms/vkms_formats.c create mode 100644 drivers/gpu/drm/vkms/vkms_formats.h -- 2.30.2
[Bug 215511] Dual monitor with amd 5700 causes system to hang at startup.
https://bugzilla.kernel.org/show_bug.cgi?id=215511 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Can you bisect to see what broke it and/or what fixed it originally? -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH 1/2] drm/i915/guc: Don't check CT descriptor status before CT write / read
On Fri, Jan 21, 2022 at 09:28:46AM +0200, Jani Nikula wrote: > On Thu, 20 Jan 2022, Matthew Brost wrote: > > Don't check CT descriptor status, unless CONFIG_DRM_I915_DEBUG_GUC is > > set, before CT write / read as this could result in a read across the > > PCIe bus thus adding latency to every CT write / read. On well behavied > > systems this vaue should always read as zero. For some reason it doesn't > > the CT channel is broken and will eventually recover from a GT reset, > > albeit the GT reset will not be triggered immediately by seeing that > > descriptor status is non-zero. > > > > v2: > > (CI) > > - Fix build error (hide corrupted label in write function behind > > CONFIG_DRM_I915_DEBUG_GUC) > > > > Signed-off-by: Matthew Brost > > --- > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 ++ > > 1 file changed, 6 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > index de89d40abd38d..948cf31429412 100644 > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c > > @@ -379,8 +379,10 @@ static int ct_write(struct intel_guc_ct *ct, > > u32 *cmds = ctb->cmds; > > unsigned int i; > > > > +#ifdef CONFIG_DRM_I915_DEBUG_GUC > > if (unlikely(desc->status)) > > goto corrupted; > > +#endif > > Please don't add #ifdefs inline. You can use > IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC) in if statements, but otherwise > the code needs to be split out to a separate function. > Sure, but I feel like I've actually been by someone else to not use the IS_ENABLED macro and use ifdefs inlines... Matt > BR, > Jani. > > > > > GEM_BUG_ON(tail > size); > > > > @@ -445,11 +447,13 @@ static int ct_write(struct intel_guc_ct *ct, > > > > return 0; > > > > +#ifdef CONFIG_DRM_I915_DEBUG_GUC > > corrupted: > > CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n", > > desc->head, desc->tail, desc->status); > > ctb->broken = true; > > return -EPIPE; > > +#endif > > } > > > > /** > > @@ -815,8 +819,10 @@ static int ct_read(struct intel_guc_ct *ct, struct > > ct_incoming_msg **msg) > > if (unlikely(ctb->broken)) > > return -EPIPE; > > > > +#ifdef CONFIG_DRM_I915_DEBUG_GUC > > if (unlikely(desc->status)) > > goto corrupted; > > +#endif > > > > GEM_BUG_ON(head > size); > > -- > Jani Nikula, Intel Open Source Graphics Center
[PATCH v5 4/6] drm/msm/dpu: stop embedding dpu_hw_blk into dpu_hw_intf
Now as dpu_hw_intf is not hanled by dpu_rm_get_assigned_resources, there
is no point in embedding the (empty) struct dpu_hw_blk into dpu_hw_intf
(and using typecasts between dpu_hw_blk and dpu_hw_intf). Drop it and
use dpu_hw_intf directly.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 11 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 17 +++--
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 9 ++---
3 files changed, 9 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 3568be80dab5..230d122fa43b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -78,7 +78,6 @@ struct dpu_hw_intf_ops {
};
struct dpu_hw_intf {
- struct dpu_hw_blk base;
struct dpu_hw_blk_reg_map hw;
/* intf */
@@ -90,16 +89,6 @@ struct dpu_hw_intf {
struct dpu_hw_intf_ops ops;
};
-/**
- * to_dpu_hw_intf - convert base object dpu_hw_base to container
- * @hw: Pointer to base hardware block
- * return: Pointer to hardware block container
- */
-static inline struct dpu_hw_intf *to_dpu_hw_intf(struct dpu_hw_blk *hw)
-{
- return container_of(hw, struct dpu_hw_intf, base);
-}
-
/**
* dpu_hw_intf_init(): Initializes the intf driver for the passed
* interface idx.
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 8df21a46308e..96554e962e38 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -74,14 +74,8 @@ int dpu_rm_destroy(struct dpu_rm *rm)
dpu_hw_ctl_destroy(hw);
}
}
- for (i = 0; i < ARRAY_SIZE(rm->intf_blks); i++) {
- struct dpu_hw_intf *hw;
-
- if (rm->intf_blks[i]) {
- hw = to_dpu_hw_intf(rm->intf_blks[i]);
- dpu_hw_intf_destroy(hw);
- }
- }
+ for (i = 0; i < ARRAY_SIZE(rm->hw_intf); i++)
+ dpu_hw_intf_destroy(rm->hw_intf[i]);
return 0;
}
@@ -179,7 +173,7 @@ int dpu_rm_init(struct dpu_rm *rm,
DPU_ERROR("failed intf object creation: err %d\n", rc);
goto fail;
}
- rm->intf_blks[intf->id - INTF_0] = >base;
+ rm->hw_intf[intf->id - INTF_0] = hw;
}
for (i = 0; i < cat->ctl_count; i++) {
@@ -593,8 +587,3 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
return num_blks;
}
-
-struct dpu_hw_intf *dpu_rm_get_intf(struct dpu_rm *rm, enum dpu_intf intf_idx)
-{
- return to_dpu_hw_intf(rm->intf_blks[intf_idx - INTF_0]);
-}
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index ee50f6651b6e..9b13200a050a 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -18,14 +18,14 @@ struct dpu_global_state;
* @pingpong_blks: array of pingpong hardware resources
* @mixer_blks: array of layer mixer hardware resources
* @ctl_blks: array of ctl hardware resources
- * @intf_blks: array of intf hardware resources
+ * @hw_intf: array of intf hardware resources
* @dspp_blks: array of dspp hardware resources
*/
struct dpu_rm {
struct dpu_hw_blk *pingpong_blks[PINGPONG_MAX - PINGPONG_0];
struct dpu_hw_blk *mixer_blks[LM_MAX - LM_0];
struct dpu_hw_blk *ctl_blks[CTL_MAX - CTL_0];
- struct dpu_hw_blk *intf_blks[INTF_MAX - INTF_0];
+ struct dpu_hw_intf *hw_intf[INTF_MAX - INTF_0];
struct dpu_hw_blk *dspp_blks[DSPP_MAX - DSPP_0];
struct dpu_hw_blk *merge_3d_blks[MERGE_3D_MAX - MERGE_3D_0];
};
@@ -90,7 +90,10 @@ int dpu_rm_get_assigned_resources(struct dpu_rm *rm,
* @rm: DPU Resource Manager handle
* @intf_idx: INTF's index
*/
-struct dpu_hw_intf *dpu_rm_get_intf(struct dpu_rm *rm, enum dpu_intf intf_idx);
+static inline struct dpu_hw_intf *dpu_rm_get_intf(struct dpu_rm *rm, enum
dpu_intf intf_idx)
+{
+ return rm->hw_intf[intf_idx - INTF_0];
+}
#endif /* __DPU_RM_H__ */
--
2.34.1
[PATCH v5 5/6] drm/msm/dpu: fix error handling in dpu_rm_init
Using IS_ERR_OR_NULL() together with PTR_ERR() is a typical mistake. If
the value is NULL, then the function will return 0 instead of a proper
return code. Moreover none of dpu_hw_*_init() functions can return NULL.
So, replace all dpu_rm_init()'s IS_ERR_OR_NULL() calls with IS_ERR().
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 96554e962e38..7497538adae1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -109,7 +109,7 @@ int dpu_rm_init(struct dpu_rm *rm,
continue;
}
hw = dpu_hw_lm_init(lm->id, mmio, cat);
- if (IS_ERR_OR_NULL(hw)) {
+ if (IS_ERR(hw)) {
rc = PTR_ERR(hw);
DPU_ERROR("failed lm object creation: err %d\n", rc);
goto fail;
@@ -126,7 +126,7 @@ int dpu_rm_init(struct dpu_rm *rm,
continue;
}
hw = dpu_hw_merge_3d_init(merge_3d->id, mmio, cat);
- if (IS_ERR_OR_NULL(hw)) {
+ if (IS_ERR(hw)) {
rc = PTR_ERR(hw);
DPU_ERROR("failed merge_3d object creation: err %d\n",
rc);
@@ -144,7 +144,7 @@ int dpu_rm_init(struct dpu_rm *rm,
continue;
}
hw = dpu_hw_pingpong_init(pp->id, mmio, cat);
- if (IS_ERR_OR_NULL(hw)) {
+ if (IS_ERR(hw)) {
rc = PTR_ERR(hw);
DPU_ERROR("failed pingpong object creation: err %d\n",
rc);
@@ -168,7 +168,7 @@ int dpu_rm_init(struct dpu_rm *rm,
continue;
}
hw = dpu_hw_intf_init(intf->id, mmio, cat);
- if (IS_ERR_OR_NULL(hw)) {
+ if (IS_ERR(hw)) {
rc = PTR_ERR(hw);
DPU_ERROR("failed intf object creation: err %d\n", rc);
goto fail;
@@ -185,7 +185,7 @@ int dpu_rm_init(struct dpu_rm *rm,
continue;
}
hw = dpu_hw_ctl_init(ctl->id, mmio, cat);
- if (IS_ERR_OR_NULL(hw)) {
+ if (IS_ERR(hw)) {
rc = PTR_ERR(hw);
DPU_ERROR("failed ctl object creation: err %d\n", rc);
goto fail;
@@ -202,7 +202,7 @@ int dpu_rm_init(struct dpu_rm *rm,
continue;
}
hw = dpu_hw_dspp_init(dspp->id, mmio, cat);
- if (IS_ERR_OR_NULL(hw)) {
+ if (IS_ERR(hw)) {
rc = PTR_ERR(hw);
DPU_ERROR("failed dspp object creation: err %d\n", rc);
goto fail;
--
2.34.1
[PATCH v5 6/6] drm/msm/dpu: move VBIF blocks handling to dpu_rm
Move handling of VBIF blocks into dpu_rm. This serves the purpose of
unification of handling of all hardware blocks inside the DPU driver.
This removes hand-coded loops in dpu_vbif (which look for necessary VBIF
instance by looping through the dpu_kms->hw_vbif and comparing
vbif_idx).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 28 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 19 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 12 +
drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c| 26 ++-
6 files changed, 40 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h
index 6417aa28d32c..895e86dabcb6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h
@@ -8,6 +8,7 @@
#include "dpu_hw_catalog.h"
#include "dpu_hw_mdss.h"
#include "dpu_hw_util.h"
+#include "dpu_hw_blk.h"
struct dpu_hw_vbif;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 47fe11a84a77..4a1983d8561b 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -782,8 +782,6 @@ static long dpu_kms_round_pixclk(struct msm_kms *kms,
unsigned long rate,
static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
{
- int i;
-
if (dpu_kms->hw_intr)
dpu_hw_intr_destroy(dpu_kms->hw_intr);
dpu_kms->hw_intr = NULL;
@@ -791,15 +789,6 @@ static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms)
/* safe to call these more than once during shutdown */
_dpu_kms_mmu_destroy(dpu_kms);
- if (dpu_kms->catalog) {
- for (i = 0; i < dpu_kms->catalog->vbif_count; i++) {
- u32 vbif_idx = dpu_kms->catalog->vbif[i].id;
-
- if ((vbif_idx < VBIF_MAX) && dpu_kms->hw_vbif[vbif_idx])
- dpu_hw_vbif_destroy(dpu_kms->hw_vbif[vbif_idx]);
- }
- }
-
if (dpu_kms->rm_init)
dpu_rm_destroy(_kms->rm);
dpu_kms->rm_init = false;
@@ -1027,7 +1016,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
{
struct dpu_kms *dpu_kms;
struct drm_device *dev;
- int i, rc = -EINVAL;
+ int rc = -EINVAL;
if (!kms) {
DPU_ERROR("invalid kms\n");
@@ -1116,21 +1105,6 @@ static int dpu_kms_hw_init(struct msm_kms *kms)
goto power_error;
}
- for (i = 0; i < dpu_kms->catalog->vbif_count; i++) {
- u32 vbif_idx = dpu_kms->catalog->vbif[i].id;
-
- dpu_kms->hw_vbif[i] = dpu_hw_vbif_init(vbif_idx,
- dpu_kms->vbif[vbif_idx], dpu_kms->catalog);
- if (IS_ERR_OR_NULL(dpu_kms->hw_vbif[vbif_idx])) {
- rc = PTR_ERR(dpu_kms->hw_vbif[vbif_idx]);
- if (!dpu_kms->hw_vbif[vbif_idx])
- rc = -EINVAL;
- DPU_ERROR("failed to init vbif %d: %d\n", vbif_idx, rc);
- dpu_kms->hw_vbif[vbif_idx] = NULL;
- goto power_error;
- }
- }
-
rc = dpu_core_perf_init(_kms->perf, dev, dpu_kms->catalog,
_dpu_kms_get_clk(dpu_kms, "core"));
if (rc) {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 3f518c809e33..b96c901483ae 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
@@ -105,7 +105,6 @@ struct dpu_kms {
struct dpu_rm rm;
bool rm_init;
- struct dpu_hw_vbif *hw_vbif[VBIF_MAX];
struct dpu_hw_mdp *hw_mdp;
bool has_danger_ctrl;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index 7497538adae1..6d49666c4e77 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -76,6 +76,8 @@ int dpu_rm_destroy(struct dpu_rm *rm)
}
for (i = 0; i < ARRAY_SIZE(rm->hw_intf); i++)
dpu_hw_intf_destroy(rm->hw_intf[i]);
+ for (i = 0; i < ARRAY_SIZE(rm->hw_vbif); i++)
+ dpu_hw_vbif_destroy(rm->hw_vbif[i]);
return 0;
}
@@ -210,6 +212,23 @@ int dpu_rm_init(struct dpu_rm *rm,
rm->dspp_blks[dspp->id - DSPP_0] = >base;
}
+ for (i = 0; i < cat->vbif_count; i++) {
+ struct dpu_hw_vbif *hw;
+ const struct dpu_vbif_cfg *vbif = >vbif[i];
+
+ if (vbif->id < VBIF_0 || vbif->id >= VBIF_MAX) {
+ DPU_ERROR("skip vbif %d with invalid id\n", vbif->id);
+ continue;
+ }
+ hw =
[PATCH v5 3/6] drm/msm/dpu: get INTF blocks directly rather than through RM
INTF blocks are not really handled by resource manager, they are
assigned at dpu_encoder_setup_display using dpu_encoder_get_intf().
Then this allocation is passed to RM and then returned to then
dpu_encoder.
So allocate them outside of RM and use them directly.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 36 +-
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 16 -
.../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 5 --
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 8 ---
.../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 8 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 68 ++-
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 8 +++
8 files changed, 16 insertions(+), 134 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 1e648db439f9..11f7126728db 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -420,26 +420,6 @@ int dpu_encoder_get_linecount(struct drm_encoder *drm_enc)
return linecount;
}
-void dpu_encoder_get_hw_resources(struct drm_encoder *drm_enc,
- struct dpu_encoder_hw_resources *hw_res)
-{
- struct dpu_encoder_virt *dpu_enc = NULL;
- int i = 0;
-
- dpu_enc = to_dpu_encoder_virt(drm_enc);
- DPU_DEBUG_ENC(dpu_enc, "\n");
-
- /* Query resources used by phys encs, expected to be without overlap */
- memset(hw_res, 0, sizeof(*hw_res));
-
- for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
-
- if (phys->ops.get_hw_resources)
- phys->ops.get_hw_resources(phys, hw_res);
- }
-}
-
static void dpu_encoder_destroy(struct drm_encoder *drm_enc)
{
struct dpu_encoder_virt *dpu_enc = NULL;
@@ -973,7 +953,7 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
struct dpu_hw_blk *hw_lm[MAX_CHANNELS_PER_ENC];
struct dpu_hw_blk *hw_dspp[MAX_CHANNELS_PER_ENC] = { NULL };
int num_lm, num_ctl, num_pp;
- int i, j;
+ int i;
if (!drm_enc) {
DPU_ERROR("invalid encoder\n");
@@ -1040,8 +1020,6 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
cstate->num_mixers = num_lm;
for (i = 0; i < dpu_enc->num_phys_encs; i++) {
- int num_blk;
- struct dpu_hw_blk *hw_blk[MAX_CHANNELS_PER_ENC];
struct dpu_encoder_phys *phys = dpu_enc->phys_encs[i];
if (!dpu_enc->hw_pp[i]) {
@@ -1059,16 +1037,8 @@ static void dpu_encoder_virt_mode_set(struct drm_encoder
*drm_enc,
phys->hw_pp = dpu_enc->hw_pp[i];
phys->hw_ctl = to_dpu_hw_ctl(hw_ctl[i]);
- num_blk = dpu_rm_get_assigned_resources(_kms->rm,
- global_state, drm_enc->base.id, DPU_HW_BLK_INTF,
- hw_blk, ARRAY_SIZE(hw_blk));
- for (j = 0; j < num_blk; j++) {
- struct dpu_hw_intf *hw_intf;
-
- hw_intf = to_dpu_hw_intf(hw_blk[i]);
- if (hw_intf->idx == phys->intf_idx)
- phys->hw_intf = hw_intf;
- }
+ if (phys->intf_idx >= INTF_0 && phys->intf_idx < INTF_MAX)
+ phys->hw_intf = dpu_rm_get_intf(_kms->rm,
phys->intf_idx);
if (!phys->hw_intf) {
DPU_ERROR_ENC(dpu_enc,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
index e241914a9677..722dd7db6bdf 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h
@@ -18,22 +18,6 @@
#define IDLE_TIMEOUT (66 - 16/2)
-/**
- * Encoder functions and data types
- * @intfs: Interfaces this encoder is using, INTF_MODE_NONE if unused
- */
-struct dpu_encoder_hw_resources {
- enum dpu_intf_mode intfs[INTF_MAX];
-};
-
-/**
- * dpu_encoder_get_hw_resources - Populate table of required hardware resources
- * @encoder: encoder pointer
- * @hw_res:resource table to populate with encoder required resources
- */
-void dpu_encoder_get_hw_resources(struct drm_encoder *encoder,
- struct dpu_encoder_hw_resources *hw_res);
-
/**
* dpu_encoder_assign_crtc - Link the encoder to the crtc it's assigned to
* @encoder: encoder pointer
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
index e7270eb6b84b..42febfce79c7 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h
@@ -91,9 +91,6 @@ struct dpu_encoder_virt_ops {
* @disable:
[PATCH v5 2/6] drm/msm/dpu: add DSPP blocks teardown
Add missing calls to dpu_hw_dspp_destroy() to free resources allocated
for DSPP hardware blocks.
Fixes: e47616df008b ("drm/msm/dpu: add support for color processing blocks in
dpu driver")
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index b5b1ea1e4de6..63ed0d7df848 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -35,6 +35,14 @@ int dpu_rm_destroy(struct dpu_rm *rm)
{
int i;
+ for (i = 0; i < ARRAY_SIZE(rm->dspp_blks); i++) {
+ struct dpu_hw_dspp *hw;
+
+ if (rm->dspp_blks[i]) {
+ hw = to_dpu_hw_dspp(rm->dspp_blks[i]);
+ dpu_hw_dspp_destroy(hw);
+ }
+ }
for (i = 0; i < ARRAY_SIZE(rm->pingpong_blks); i++) {
struct dpu_hw_pingpong *hw;
--
2.34.1
[PATCH v5 1/6] drm/msm/dpu: drop unused lm_max_width from RM
No code uses lm_max_width from resource manager, so drop it. Instead of
calculating the lm_max_width, code can use max_mixer_width field from
the hw catalog.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Stephen Boyd
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 12
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 4
2 files changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index f9c83d6e427a..b5b1ea1e4de6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -114,18 +114,6 @@ int dpu_rm_init(struct dpu_rm *rm,
goto fail;
}
rm->mixer_blks[lm->id - LM_0] = >base;
-
- if (!rm->lm_max_width) {
- rm->lm_max_width = lm->sblk->maxwidth;
- } else if (rm->lm_max_width != lm->sblk->maxwidth) {
- /*
-* Don't expect to have hw where lm max widths differ.
-* If found, take the min.
-*/
- DPU_ERROR("unsupported: lm maxwidth differs\n");
- if (rm->lm_max_width > lm->sblk->maxwidth)
- rm->lm_max_width = lm->sblk->maxwidth;
- }
}
for (i = 0; i < cat->merge_3d_count; i++) {
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
index 1f12c8d5b8aa..0f27759211b5 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h
@@ -20,8 +20,6 @@ struct dpu_global_state;
* @ctl_blks: array of ctl hardware resources
* @intf_blks: array of intf hardware resources
* @dspp_blks: array of dspp hardware resources
- * @lm_max_width: cached layer mixer maximum width
- * @rm_lock: resource manager mutex
*/
struct dpu_rm {
struct dpu_hw_blk *pingpong_blks[PINGPONG_MAX - PINGPONG_0];
@@ -30,8 +28,6 @@ struct dpu_rm {
struct dpu_hw_blk *intf_blks[INTF_MAX - INTF_0];
struct dpu_hw_blk *dspp_blks[DSPP_MAX - DSPP_0];
struct dpu_hw_blk *merge_3d_blks[MERGE_3D_MAX - MERGE_3D_0];
-
- uint32_t lm_max_width;
};
/**
--
2.34.1
[PATCH v5 0/6] drm/msm/dpu: simplify RM code
INTF blocks are not really handled by resource manager, they are assigned at dpu_encoder_setup_display using dpu_encoder_get_intf(). Then this allocation is passed to RM and then returned to then dpu_encoder. So allocate them outside of RM and use them directly. While we are at it, drop the lm_max_width from the RM and simplify VBIF handling (move creation/destruction to the RM too). Once this and SSPP handling patches are merged, the RM would handle lifetime of all dpu_hw_* objects. Changes since v4: - Changes IS_ERR_OR_NULL() to IS_ERR() in dpu_rm_init() - Removed if(!null) conditions when calling dpu_hw_intf_destroy() and dpu_hw_vbif_destroy() Changes since v3: - Add missing DSPP blocks teardown - Remove dpu_hw_blk from dpu_hw_intf - move dpu_hw_vbif creation/destruction to the RM Changes since v2: - Dropped DSPP, PP and MERGE_3D patches for now. Changes since v1: - Split into separate patch series to ease review. Dmitry Baryshkov (6): drm/msm/dpu: drop unused lm_max_width from RM drm/msm/dpu: add DSPP blocks teardown drm/msm/dpu: get INTF blocks directly rather than through RM drm/msm/dpu: stop embedding dpu_hw_blk into dpu_hw_intf drm/msm/dpu: fix error handling in dpu_rm_init drm/msm/dpu: move VBIF blocks handling to dpu_rm drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 36 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 16 --- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 5 - .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 8 -- .../drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 8 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 11 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.h | 1 + drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 28 +--- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 - drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c| 126 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h| 31 - drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 26 +--- 12 files changed, 73 insertions(+), 225 deletions(-) -- 2.34.1
Re: [PATCH v4 5/5] drm/msm/dpu: move VBIF blocks handling to dpu_rm
On 07/01/2022 04:27, Stephen Boyd wrote:
Quoting Dmitry Baryshkov (2022-01-05 15:10:31)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
index bf4d72356a12..2301ac114920 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
@@ -78,6 +78,10 @@ int dpu_rm_destroy(struct dpu_rm *rm)
if (rm->hw_intf[i])
dpu_hw_intf_destroy(rm->hw_intf[i]);
}
+ for (i = 0; i < ARRAY_SIZE(rm->hw_vbif); i++) {
+ if (rm->hw_vbif[i])
+ dpu_hw_vbif_destroy(rm->hw_vbif[i]);
Maybe drop this check and pass NULL to dpu_hw_vbif_destroy() sometimes?
Then the check can be omitted and the braces dropped
Nice idea. This also applies to dpu_hw_intf_destroy, so I'm going to
apply it to the previous patch.
+ }
return 0;
}
@@ -212,6 +216,23 @@ int dpu_rm_init(struct dpu_rm *rm,
rm->dspp_blks[dspp->id - DSPP_0] = >base;
}
+ for (i = 0; i < cat->vbif_count; i++) {
+ struct dpu_hw_vbif *hw;
+ const struct dpu_vbif_cfg *vbif = >vbif[i];
+
+ if (vbif->id < VBIF_0 || vbif->id >= VBIF_MAX) {
+ DPU_ERROR("skip vbif %d with invalid id\n", vbif->id);
+ continue;
+ }
+ hw = dpu_hw_vbif_init(vbif->id, mmio, cat);
+ if (IS_ERR_OR_NULL(hw)) {
+ rc = PTR_ERR(hw);
+ DPU_ERROR("failed vbif object creation: err %d\n", rc);
+ goto fail;
If it's NULL then rc will be 0 and fail will return 0. Is that
intentional?
Actually no. And init functions can not return NULL. So let's fix it too.
+ }
+ rm->hw_vbif[vbif->id - VBIF_0] = hw;
+ }
+
return 0;
fail:
--
With best wishes
Dmitry
Re: [PATCH] drm/amd/display: Fix memory leak
[Public]
Applied. Thanks!
From: Wentland, Harry
Sent: Friday, January 21, 2022 2:03 PM
To: Yongzhi Liu ; Li, Sun peng (Leo) ;
Siqueira, Rodrigo ; Deucher, Alexander
; Koenig, Christian ; Pan,
Xinhui ; airl...@linux.ie ;
dan...@ffwll.ch ; Lipski, Mikita ; Lin,
Wayne ; Kazlauskas, Nicholas ;
Zuo, Jerry ; anson.ja...@amd.com ;
eryk.b...@amd.com ; Pillai, Aurabindo
; Das, Nirmoy
Cc: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ;
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] drm/amd/display: Fix memory leak
On 2022-01-21 06:26, Yongzhi Liu wrote:
> [why]
> Resource release is needed on the error handling path
> to prevent memory leak.
>
> [how]
> Fix this by adding kfree on the error handling path.
>
> Signed-off-by: Yongzhi Liu
Reviewed-by: Harry Wentland
Harry
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 80
> --
> 1 file changed, 60 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index ded64d0..e463d46 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -227,8 +227,10 @@ static ssize_t dp_link_settings_read(struct file *f,
> char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -389,8 +391,10 @@ static ssize_t dp_phy_settings_read(struct file *f, char
> __user *buf,
>break;
>
>r = put_user((*(rd_buf + result)), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1359,8 +1363,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f,
> char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1376,8 +1382,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f,
> char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1546,8 +1554,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
> char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1563,8 +1573,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
> char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1731,8 +1743,10 @@ static ssize_t dp_dsc_slice_height_read(struct file
> *f, char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1748,8 +1762,10 @@ static ssize_t dp_dsc_slice_height_read(struct file
> *f, char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> + }
>
>buf += 1;
>size -= 1;
> @@ -1912,8 +1928,10 @@ static ssize_t dp_dsc_bits_per_pixel_read(struct file
> *f, char __user *buf,
>break;
>}
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
>return -ENXIO;
> + }
>
>dsc = pipe_ctx->stream_res.dsc;
>if (dsc)
> @@ -1929,8 +1947,10 @@ static ssize_t dp_dsc_bits_per_pixel_read(struct file
> *f, char __user *buf,
>break;
>
>r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
>return r; /* r = -EFAULT */
> +
Re: [PATCH] drm/amd/pm: remove useless if
Applied. Thanks! Alex On Fri, Jan 21, 2022 at 6:48 AM Jiapeng Chong wrote: > > Clean the following coccicheck warning: > > ./drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c:7035:2-4: WARNING: possible > condition with no effect (if == else). > > Reported-by: Abaci Robot > Signed-off-by: Jiapeng Chong > --- > drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c > b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c > index 23ff0d812e4b..7427c50409d4 100644 > --- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c > +++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c > @@ -7032,10 +7032,7 @@ static int si_power_control_set_level(struct > amdgpu_device *adev) > ret = si_resume_smc(adev); > if (ret) > return ret; > - ret = si_set_sw_state(adev); > - if (ret) > - return ret; > - return 0; > + return si_set_sw_state(adev); > } > > static void si_set_vce_clock(struct amdgpu_device *adev, > -- > 2.20.1.7.g153144c >
Re: [PATCH] drm/amd/amdgpu/amdgpu_cs: fix refcount leak of a dma_fence obj
On Fri, Jan 21, 2022 at 2:45 AM Christian König wrote: > > Am 21.01.22 um 06:28 schrieb Xin Xiong: > > This issue takes place in an error path in > > amdgpu_cs_fence_to_handle_ioctl(). When `info->in.what` falls into > > default case, the function simply returns -EINVAL, forgetting to > > decrement the reference count of a dma_fence obj, which is bumped > > earlier by amdgpu_cs_get_fence(). This may result in reference count > > leaks. > > > > Fix it by decreasing the refcount of specific object before returning > > the error code. > > > > Signed-off-by: Xin Xiong > > Signed-off-by: Xin Tan > > Good catch. Reviewed-by: Christian König Applied manually. Strangely I never got this on any of my emails, and I don't see it in the archives. Alex > > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > index 0311d799a..894869789 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c > > @@ -1510,6 +1510,7 @@ int amdgpu_cs_fence_to_handle_ioctl(struct drm_device > > *dev, void *data, > > return 0; > > > > default: > > + dma_fence_put(fence); > > return -EINVAL; > > } > > } >
Re: [PATCH v3 2/3] drm/msm/dpu: simplify clocks handling
Quoting Dmitry Baryshkov (2022-01-20 23:37:45)
> On Fri, 21 Jan 2022 at 07:30, Stephen Boyd wrote:
> >
> > Quoting Dmitry Baryshkov (2022-01-19 14:16:15)
> > > diff --git a/drivers/gpu/drm/msm/msm_io_utils.c
> > > b/drivers/gpu/drm/msm/msm_io_utils.c
> > > index 7b504617833a..5533c87c7158 100644
> > > --- a/drivers/gpu/drm/msm/msm_io_utils.c
> > > +++ b/drivers/gpu/drm/msm/msm_io_utils.c
>
> >
> > > + if (rc) {
> > > + DRM_DEV_ERROR(>dev, "Failed to get clock refs
> > > %d\n", rc);
> > > + return rc;
> > > + }
> > > +
> > > + rc = of_clk_set_defaults(pdev->dev.of_node, false);
> >
> > Why is this needed?
>
> Both mdss and mdp devices use assigned-clocks properties, while not
> being a clock provider (or a child of it).
> So I assumed it should call the of_clk_set_defaults(node, false)
A device node doesn't need to be a clk provider to call
of_clk_set_defaults(). Does the call to of_clk_set_defaults() in
drivers/base/platform.c cover this?
> Not to mention that this call exists in the msm_dss_parse_clock(),
> which is being refactored/replaced.
>
Indeed it's already in the code.
> >
> > > + if (rc) {
> > > + DRM_DEV_ERROR(>dev, "Failed to set clock defaults
> > > %d\n", rc);
> > > + return rc;
> > > + }
> > > +
> > > + *clocks = bulk;
> > > +
[PATCH 0/2] Fix up request cancel
Fix request cancellation + add request cancel low level trace point. Signed-off-by: Matthew Brost Matthew Brost (2): drm/i915: Add request cancel low level trace point drm/i915/guc: Cancel requests immediately drivers/gpu/drm/i915/gt/intel_context.h | 1 + drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++ .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 46 +++ drivers/gpu/drm/i915/i915_trace.h | 10 4 files changed, 42 insertions(+), 20 deletions(-) -- 2.34.1
[PATCH 2/2] drm/i915/guc: Cancel requests immediately
Change the preemption timeout to the smallest possible value (1 us) when
disabling scheduling to cancel a request and restore it after
cancelation. This not only cancels the request as fast as possible, it
fixes a bug where the preemption timeout is 0 which results in the
schedule disable hanging forever.
Reported-by: Jani Saarinen
Fixes: 62eaf0ae217d4 ("drm/i915/guc: Support request cancellation")
Link: https://gitlab.freedesktop.org/drm/intel/-/issues/4960
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 5 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 46 +++
2 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 30cd81ad8911a..730998823dbea 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -198,6 +198,11 @@ struct intel_context {
* each priority bucket
*/
u32 prio_count[GUC_CLIENT_PRIORITY_NUM];
+ /**
+* @preemption_timeout: preemption timeout of the context, used
+* to restore this value after request cancellation
+*/
+ u32 preemption_timeout;
} guc_state;
struct {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 3918f1be114fa..966947c450253 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -2147,7 +2147,8 @@ static inline u32 get_children_join_value(struct
intel_context *ce,
return __get_parent_scratch(ce)->join[child_index].semaphore;
}
-static void guc_context_policy_init(struct intel_engine_cs *engine,
+static void guc_context_policy_init(struct intel_context *ce,
+ struct intel_engine_cs *engine,
struct guc_lrc_desc *desc)
{
desc->policy_flags = 0;
@@ -2157,7 +2158,8 @@ static void guc_context_policy_init(struct
intel_engine_cs *engine,
/* NB: For both of these, zero means disabled. */
desc->execution_quantum = engine->props.timeslice_duration_ms * 1000;
- desc->preemption_timeout = engine->props.preempt_timeout_ms * 1000;
+ ce->guc_state.preemption_timeout = engine->props.preempt_timeout_ms *
1000;
+ desc->preemption_timeout = ce->guc_state.preemption_timeout;
}
static int guc_lrc_desc_pin(struct intel_context *ce, bool loop)
@@ -2193,7 +2195,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->hw_context_desc = ce->lrc.lrca;
desc->priority = ce->guc_state.prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
- guc_context_policy_init(engine, desc);
+ guc_context_policy_init(ce, engine, desc);
/*
* If context is a parent, we need to register a process descriptor
@@ -2226,7 +2228,7 @@ static int guc_lrc_desc_pin(struct intel_context *ce,
bool loop)
desc->hw_context_desc = child->lrc.lrca;
desc->priority = ce->guc_state.prio;
desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD;
- guc_context_policy_init(engine, desc);
+ guc_context_policy_init(child, engine, desc);
}
clear_children_join_go_memory(ce);
@@ -2409,6 +2411,19 @@ static u16 prep_context_pending_disable(struct
intel_context *ce)
return ce->guc_id.id;
}
+static void __guc_context_set_preemption_timeout(struct intel_guc *guc,
+u16 guc_id,
+u32 preemption_timeout)
+{
+ u32 action[] = {
+ INTEL_GUC_ACTION_SET_CONTEXT_PREEMPTION_TIMEOUT,
+ guc_id,
+ preemption_timeout
+ };
+
+ intel_guc_send_busy_loop(guc, action, ARRAY_SIZE(action), 0, true);
+}
+
static struct i915_sw_fence *guc_context_block(struct intel_context *ce)
{
struct intel_guc *guc = ce_to_guc(ce);
@@ -2442,8 +2457,10 @@ static struct i915_sw_fence *guc_context_block(struct
intel_context *ce)
spin_unlock_irqrestore(>guc_state.lock, flags);
- with_intel_runtime_pm(runtime_pm, wakeref)
+ with_intel_runtime_pm(runtime_pm, wakeref) {
+ __guc_context_set_preemption_timeout(guc, guc_id, 1);
__guc_context_sched_disable(guc, ce, guc_id);
+ }
return >guc_state.blocked;
}
@@ -2492,8 +2509,10 @@ static void guc_context_unblock(struct intel_context *ce)
spin_unlock_irqrestore(>guc_state.lock, flags);
- if (enable) {
- with_intel_runtime_pm(runtime_pm, wakeref)
+ with_intel_runtime_pm(runtime_pm, wakeref) {
+
[PATCH 1/2] drm/i915: Add request cancel low level trace point
Add request cancel trace point guarded by
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINT.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.h | 1 +
drivers/gpu/drm/i915/i915_trace.h | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index d8c74bbf9aae2..3aed4d77f116c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -124,6 +124,7 @@ intel_context_is_pinned(struct intel_context *ce)
static inline void intel_context_cancel_request(struct intel_context *ce,
struct i915_request *rq)
{
+ trace_i915_request_cancel(rq);
GEM_BUG_ON(!ce->ops->cancel_request);
return ce->ops->cancel_request(ce, rq);
}
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 37b5c9e9d260e..d0a11a8bb0ca3 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -324,6 +324,11 @@ DEFINE_EVENT(i915_request, i915_request_add,
);
#if defined(CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS)
+DEFINE_EVENT(i915_request, i915_request_cancel,
+TP_PROTO(struct i915_request *rq),
+TP_ARGS(rq)
+);
+
DEFINE_EVENT(i915_request, i915_request_guc_submit,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq)
@@ -497,6 +502,11 @@ DEFINE_EVENT(intel_context, intel_context_do_unpin,
#else
#if !defined(TRACE_HEADER_MULTI_READ)
+static inline void
+trace_i915_request_cancel(struct i915_request *rq)
+{
+}
+
static inline void
trace_i915_request_guc_submit(struct i915_request *rq)
{
--
2.34.1
[PATCH v4 5/5] drm/i915/uapi: document behaviour for DG2 64K support
From: Matthew Auld
On discrete platforms like DG2, we need to support a minimum page size
of 64K when dealing with device local-memory. This is quite tricky for
various reasons, so try to document the new implicit uapi for this.
v3: fix typos and less emphasis
v2: Fixed suggestions on formatting [Daniel]
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Acked-by: Jordan Justen
Reviewed-by: Ramalingam C
cc: Simon Ser
cc: Pekka Paalanen
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: mesa-...@lists.freedesktop.org
Cc: Tony Ye
Cc: Slawomir Milczarek
---
include/uapi/drm/i915_drm.h | 44 -
1 file changed, 39 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5e678917da70..77e5e74c32c1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1118,10 +1118,16 @@ struct drm_i915_gem_exec_object2 {
/**
* When the EXEC_OBJECT_PINNED flag is specified this is populated by
* the user with the GTT offset at which this object will be pinned.
+*
* When the I915_EXEC_NO_RELOC flag is specified this must contain the
* presumed_offset of the object.
+*
* During execbuffer2 the kernel populates it with the value of the
* current GTT offset of the object, for future presumed_offset writes.
+*
+* See struct drm_i915_gem_create_ext for the rules when dealing with
+* alignment restrictions with I915_MEMORY_CLASS_DEVICE, on devices with
+* minimum page sizes, like DG2.
*/
__u64 offset;
@@ -3145,11 +3151,39 @@ struct drm_i915_gem_create_ext {
*
* The (page-aligned) allocated size for the object will be returned.
*
-* Note that for some devices we have might have further minimum
-* page-size restrictions(larger than 4K), like for device local-memory.
-* However in general the final size here should always reflect any
-* rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
-* extension to place the object in device local-memory.
+*
+* DG2 64K min page size implications:
+*
+* On discrete platforms, starting from DG2, we have to contend with GTT
+* page size restrictions when dealing with I915_MEMORY_CLASS_DEVICE
+* objects. Specifically the hardware only supports 64K or larger GTT
+* page sizes for such memory. The kernel will already ensure that all
+* I915_MEMORY_CLASS_DEVICE memory is allocated using 64K or larger page
+* sizes underneath.
+*
+* Note that the returned size here will always reflect any required
+* rounding up done by the kernel, i.e 4K will now become 64K on devices
+* such as DG2.
+*
+* Special DG2 GTT address alignment requirement:
+*
+* The GTT alignment will also need to be at least 2M for such objects.
+*
+* Note that due to how the hardware implements 64K GTT page support, we
+* have some further complications:
+*
+* 1) The entire PDE (which covers a 2MB virtual address range), must
+* contain only 64K PTEs, i.e mixing 4K and 64K PTEs in the same
+* PDE is forbidden by the hardware.
+*
+* 2) We still need to support 4K PTEs for I915_MEMORY_CLASS_SYSTEM
+* objects.
+*
+* To keep things simple for userland, we mandate that any GTT mappings
+* must be aligned to and rounded up to 2MB. As this only wastes virtual
+* address space and avoids userland having to copy any needlessly
+* complicated PDE sharing scheme (coloring) and only affects DG2, this
+* is deemed to be a good compromise.
*/
__u64 size;
/**
--
2.25.1
[PATCH v4 3/5] drm/i915: support 64K GTT pages for discrete cards
From: Matthew Auld
discrete cards optimise 64K GTT pages for local-memory, since everything
should be allocated at 64K granularity. We say goodbye to sparse
entries, and instead get a compact 256B page-table for 64K pages,
which should be more cache friendly. 4K pages for local-memory
are no longer supported by the HW.
v4: don't return uninitialized err in igt_ppgtt_compact
Reported-by: kernel test robot
Signed-off-by: Matthew Auld
Signed-off-by: Stuart Summers
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 60 ++
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 +-
drivers/gpu/drm/i915/gt/intel_gtt.h | 3 +
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 +
4 files changed, 169 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index f36191ebf964..a7d9bdb85d70 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -1478,6 +1478,65 @@ static int igt_ppgtt_sanity_check(void *arg)
return err;
}
+static int igt_ppgtt_compact(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *obj;
+ int err;
+
+ /*
+* Simple test to catch issues with compact 64K pages -- since the pt is
+* compacted to 256B that gives us 32 entries per pt, however since the
+* backing page for the pt is 4K, any extra entries we might incorrectly
+* write out should be ignored by the HW. If ever hit such a case this
+* test should catch it since some of our writes would land in scratch.
+*/
+
+ if (!HAS_64K_PAGES(i915)) {
+ pr_info("device lacks compact 64K page support, skipping\n");
+ return 0;
+ }
+
+ if (!HAS_LMEM(i915)) {
+ pr_info("device lacks LMEM support, skipping\n");
+ return 0;
+ }
+
+ /* We want the range to cover multiple page-table boundaries. */
+ obj = i915_gem_object_create_lmem(i915, SZ_4M, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ err = i915_gem_object_pin_pages_unlocked(obj);
+ if (err)
+ goto out_put;
+
+ if (obj->mm.page_sizes.phys < I915_GTT_PAGE_SIZE_64K) {
+ pr_info("LMEM compact unable to allocate huge-page(s)\n");
+ goto out_unpin;
+ }
+
+ /*
+* Disable 2M GTT pages by forcing the page-size to 64K for the GTT
+* insertion.
+*/
+ obj->mm.page_sizes.sg = I915_GTT_PAGE_SIZE_64K;
+
+ err = igt_write_huge(i915, obj);
+ if (err)
+ pr_err("LMEM compact write-huge failed\n");
+
+out_unpin:
+ i915_gem_object_unpin_pages(obj);
+out_put:
+ i915_gem_object_put(obj);
+
+ if (err == -ENOMEM)
+ err = 0;
+
+ return err;
+}
+
static int igt_tmpfs_fallback(void *arg)
{
struct drm_i915_private *i915 = arg;
@@ -1735,6 +1794,7 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_tmpfs_fallback),
SUBTEST(igt_ppgtt_smoke_huge),
SUBTEST(igt_ppgtt_sanity_check),
+ SUBTEST(igt_ppgtt_compact),
};
if (!HAS_PPGTT(i915)) {
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index c43e724afa9f..62471730266c 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -233,6 +233,8 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
start, end, lvl);
} else {
unsigned int count;
+ unsigned int pte = gen8_pd_index(start, 0);
+ unsigned int num_ptes;
u64 *vaddr;
count = gen8_pt_count(start, end);
@@ -242,10 +244,18 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
atomic_read(>used));
GEM_BUG_ON(!count || count >= atomic_read(>used));
+ num_ptes = count;
+ if (pt->is_compact) {
+ GEM_BUG_ON(num_ptes % 16);
+ GEM_BUG_ON(pte % 16);
+ num_ptes /= 16;
+ pte /= 16;
+ }
+
vaddr = px_vaddr(pt);
- memset64(vaddr + gen8_pd_index(start, 0),
+ memset64(vaddr + pte,
vm->scratch[0]->encode,
-count);
+num_ptes);
[PATCH v4 2/5] drm/i915: enforce min GTT alignment for discrete cards
From: Matthew Auld
For local-memory objects we need to align the GTT addresses
to 64K, both for the ppgtt and ggtt.
We need to support vm->min_alignment > 4K, depending
on the vm itself and the type of object we are inserting.
With this in mind update the GTT selftests to take this
into account.
For compact-pt we further align and pad lmem object GTT addresses
to 2MB to ensure PDEs contain consistent page sizes as
required by the HW.
v3:
* use needs_compact_pt flag to discriminate between
64K and 64K with compact-pt
* add i915_vm_obj_min_alignment
* use i915_vm_obj_min_alignment to round up vma reservation
if compact-pt instead of hard coding
Signed-off-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
---
.../i915/gem/selftests/i915_gem_client_blt.c | 23 +++--
drivers/gpu/drm/i915/gt/intel_gtt.c | 12 +++
drivers/gpu/drm/i915/gt/intel_gtt.h | 15 +++
drivers/gpu/drm/i915/i915_vma.c | 9 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 96 ---
5 files changed, 114 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
index c8ff8bf0986d..f0bfce53258f 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
@@ -39,6 +39,7 @@ struct tiled_blits {
struct blit_buffer scratch;
struct i915_vma *batch;
u64 hole;
+ u64 align;
u32 width;
u32 height;
};
@@ -410,14 +411,21 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_free;
}
- hole_size = 2 * PAGE_ALIGN(WIDTH * HEIGHT * 4);
+ t->align = I915_GTT_PAGE_SIZE_2M; /* XXX worst case, derive from vm! */
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_LOCAL));
+ t->align = max(t->align,
+ i915_vm_min_alignment(t->ce->vm, INTEL_MEMORY_SYSTEM));
+
+ hole_size = 2 * round_up(WIDTH * HEIGHT * 4, t->align);
hole_size *= 2; /* room to maneuver */
- hole_size += 2 * I915_GTT_MIN_ALIGNMENT;
+ hole_size += 2 * t->align; /* padding on either side */
mutex_lock(>ce->vm->mutex);
memset(, 0, sizeof(hole));
err = drm_mm_insert_node_in_range(>ce->vm->mm, ,
- hole_size, 0, I915_COLOR_UNEVICTABLE,
+ hole_size, t->align,
+ I915_COLOR_UNEVICTABLE,
0, U64_MAX,
DRM_MM_INSERT_BEST);
if (!err)
@@ -428,7 +436,7 @@ tiled_blits_create(struct intel_engine_cs *engine, struct
rnd_state *prng)
goto err_put;
}
- t->hole = hole.start + I915_GTT_MIN_ALIGNMENT;
+ t->hole = hole.start + t->align;
pr_info("Using hole at %llx\n", t->hole);
err = tiled_blits_create_buffers(t, WIDTH, HEIGHT, prng);
@@ -455,7 +463,7 @@ static void tiled_blits_destroy(struct tiled_blits *t)
static int tiled_blits_prepare(struct tiled_blits *t,
struct rnd_state *prng)
{
- u64 offset = PAGE_ALIGN(t->width * t->height * 4);
+ u64 offset = round_up(t->width * t->height * 4, t->align);
u32 *map;
int err;
int i;
@@ -486,8 +494,7 @@ static int tiled_blits_prepare(struct tiled_blits *t,
static int tiled_blits_bounce(struct tiled_blits *t, struct rnd_state *prng)
{
- u64 offset =
- round_up(t->width * t->height * 4, 2 * I915_GTT_MIN_ALIGNMENT);
+ u64 offset = round_up(t->width * t->height * 4, 2 * t->align);
int err;
/* We want to check position invariant tiling across GTT eviction */
@@ -500,7 +507,7 @@ static int tiled_blits_bounce(struct tiled_blits *t, struct
rnd_state *prng)
/* Reposition so that we overlap the old addresses, and slightly off */
err = tiled_blit(t,
->buffers[2], t->hole + I915_GTT_MIN_ALIGNMENT,
+>buffers[2], t->hole + t->align,
>buffers[1], t->hole + 3 * offset / 2);
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c
b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 46be4197b93f..df23ebdfc994 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -223,6 +223,18 @@ void i915_address_space_init(struct i915_address_space
*vm, int subclass)
GEM_BUG_ON(!vm->total);
drm_mm_init(>mm, 0, vm->total);
+
+ memset64(vm->min_alignment, I915_GTT_MIN_ALIGNMENT,
+ARRAY_SIZE(vm->min_alignment));
+
+ if (HAS_64K_PAGES(vm->i915) &&
[PATCH v4 4/5] drm/i915: add gtt misalignment test
add test to check handling of misaligned offsets and sizes
v4:
* remove spurious blank lines
* explicitly cast intel_region_id to intel_memory_type in misaligned_pin
Reported-by: kernel test robot
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 128 ++
1 file changed, 128 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index b80788a2b7f9..f082b5ff3b5e 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -22,10 +22,12 @@
*
*/
+#include "gt/intel_gtt.h"
#include
#include
#include "gem/i915_gem_context.h"
+#include "gem/i915_gem_region.h"
#include "gem/selftests/mock_context.h"
#include "gt/intel_context.h"
#include "gt/intel_gpu_commands.h"
@@ -1067,6 +1069,120 @@ static int shrink_boom(struct i915_address_space *vm,
return err;
}
+static int misaligned_case(struct i915_address_space *vm, struct
intel_memory_region *mr,
+ u64 addr, u64 size, unsigned long flags)
+{
+ struct drm_i915_gem_object *obj;
+ struct i915_vma *vma;
+ int err = 0;
+ u64 expected_vma_size, expected_node_size;
+
+ obj = i915_gem_object_create_region(mr, size, 0, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ vma = i915_vma_instance(obj, vm, NULL);
+ if (IS_ERR(vma)) {
+ err = PTR_ERR(vma);
+ goto err_put;
+ }
+
+ err = i915_vma_pin(vma, 0, 0, addr | flags);
+ if (err)
+ goto err_put;
+ i915_vma_unpin(vma);
+
+ if (!drm_mm_node_allocated(>node)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ if (i915_vma_misplaced(vma, 0, 0, addr | flags)) {
+ err = -EINVAL;
+ goto err_put;
+ }
+
+ expected_vma_size = round_up(size, 1 <<
(ffs(vma->resource->page_sizes_gtt) - 1));
+ expected_node_size = expected_vma_size;
+
+ if (IS_DG2(vm->i915) && i915_gem_object_is_lmem(obj)) {
+ /* dg2 should expand lmem node to 2MB */
+ expected_vma_size = round_up(size, I915_GTT_PAGE_SIZE_64K);
+ expected_node_size = round_up(size, I915_GTT_PAGE_SIZE_2M);
+ }
+
+ if (vma->size != expected_vma_size || vma->node.size !=
expected_node_size) {
+ err = i915_vma_unbind(vma);
+ err = -EBADSLT;
+ goto err_put;
+ }
+
+ err = i915_vma_unbind(vma);
+ if (err)
+ goto err_put;
+
+ GEM_BUG_ON(drm_mm_node_allocated(>node));
+
+err_put:
+ i915_gem_object_put(obj);
+ cleanup_freed_objects(vm->i915);
+ return err;
+}
+
+static int misaligned_pin(struct i915_address_space *vm,
+ u64 hole_start, u64 hole_end,
+ unsigned long end_time)
+{
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+ unsigned long flags = PIN_OFFSET_FIXED | PIN_USER;
+ int err = 0;
+ u64 hole_size = hole_end - hole_start;
+
+ if (i915_is_ggtt(vm))
+ flags |= PIN_GLOBAL;
+
+ for_each_memory_region(mr, vm->i915, id) {
+ u64 min_alignment = i915_vm_min_alignment(vm, (enum
intel_memory_type)id);
+ u64 size = min_alignment;
+ u64 addr = round_up(hole_start + (hole_size / 2),
min_alignment);
+
+ /* we can't test < 4k alignment due to flags being encoded in
lower bits */
+ if (min_alignment != I915_GTT_PAGE_SIZE_4K) {
+ err = misaligned_case(vm, mr, addr + (min_alignment /
2), size, flags);
+ /* misaligned should error with -EINVAL*/
+ if (!err)
+ err = -EBADSLT;
+ if (err != -EINVAL)
+ return err;
+ }
+
+ /* test for vma->size expansion to min page size */
+ err = misaligned_case(vm, mr, addr, PAGE_SIZE, flags);
+ if (min_alignment > hole_size) {
+ if (!err)
+ err = -EBADSLT;
+ else if (err == -ENOSPC)
+ err = 0;
+ }
+ if (err)
+ return err;
+
+ /* test for intermediate size not expanding vma->size for large
alignments */
+ err = misaligned_case(vm, mr, addr, size / 2, flags);
+ if (min_alignment > hole_size) {
+ if (!err)
+ err = -EBADSLT;
+ else if (err == -ENOSPC)
+ err = 0;
+ }
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
static int
[PATCH v4 0/5] discrete card 64K page support
This series continues support for 64K pages for discrete cards. It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4 Changes since that series: - set min alignment for DG2 to 2MB in i915_address_space_init - replace coloring with simpler 2MB VA alignment for lmem buffers - enforce alignment to 2MB for lmem objects on DG2 in i915_vma_insert - expand vma reservation to round up to 2MB on DG2 in i915_vma_insert - add alignment test v2: rebase and fix for async vma that landed v3: * fix uapi doc typos * add needs_compact_pt flag patch * cleanup vma expansion to use vm->min_alignment instead of hard coding v4: * fix err return in igt_ppgtt_compact test * placate ci robot with explicit enum conversion in misaligned_pin * remove some blank lines Matthew Auld (3): drm/i915: enforce min GTT alignment for discrete cards drm/i915: support 64K GTT pages for discrete cards drm/i915/uapi: document behaviour for DG2 64K support Ramalingam C (1): drm/i915: add needs_compact_pt flag Robert Beckett (1): drm/i915: add gtt misalignment test .../gpu/drm/i915/gem/selftests/huge_pages.c | 60 + .../i915/gem/selftests/i915_gem_client_blt.c | 23 +- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 108 - drivers/gpu/drm/i915/gt/intel_gtt.c | 12 + drivers/gpu/drm/i915/gt/intel_gtt.h | 18 ++ drivers/gpu/drm/i915/gt/intel_ppgtt.c | 1 + drivers/gpu/drm/i915/i915_drv.h | 10 +- drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_vma.c | 9 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 224 +++--- include/uapi/drm/i915_drm.h | 44 +++- 12 files changed, 460 insertions(+), 52 deletions(-) -- 2.25.1
[PATCH v4 1/5] drm/i915: add needs_compact_pt flag
From: Ramalingam C
Add a new platform flag, needs_compact_pt, to mark the requirement of
compact pt layout support for the ppGTT when using 64K GTT pages.
With this flag has_64k_pages will only indicate requirement of 64K
GTT page sizes or larger for device local memory access.
Suggested-by: Matthew Auld
Signed-off-by: Ramalingam C
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/i915_drv.h | 10 +++---
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 44c1f98144b4..1258b7779705 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1512,12 +1512,16 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
- * device local memory access. Also this flag implies that we require or
- * at least support the compact PT layout for the ppGTT when using the 64K
- * GTT pages.
+ * device local memory access.
*/
#define HAS_64K_PAGES(dev_priv) (INTEL_INFO(dev_priv)->has_64k_pages)
+/* Set this flag when platform doesn't allow both 64k pages and 4k pages in
+ * the same PT. this flag means we need to support compact PT layout for the
+ * ppGTT when using the 64K GTT pages.
+ */
+#define NEEDS_COMPACT_PT(dev_priv) (INTEL_INFO(dev_priv)->needs_compact_pt)
+
#define HAS_IPC(dev_priv) (INTEL_INFO(dev_priv)->display.has_ipc)
#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 4081fd50ba9d..799b56569ef5 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info xehpsdv_info = {
PLATFORM(INTEL_XEHPSDV),
.display = { },
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1045,6 +1046,7 @@ static const struct intel_device_info dg2_info = {
.media.rel = 55,
PLATFORM(INTEL_DG2),
.has_64k_pages = 1,
+ .needs_compact_pt = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 3699b1c539ea..c8aaf646430c 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -130,6 +130,7 @@ enum intel_ppgtt_type {
/* Keep has_* in alphabetical order */ \
func(has_64bit_reloc); \
func(has_64k_pages); \
+ func(needs_compact_pt); \
func(gpu_reset_clobbers_display); \
func(has_reset_engine); \
func(has_global_mocs); \
--
2.25.1
Re: [PATCH] drm/amd/display: Fix memory leak
On 2022-01-21 06:26, Yongzhi Liu wrote:
> [why]
> Resource release is needed on the error handling path
> to prevent memory leak.
>
> [how]
> Fix this by adding kfree on the error handling path.
>
> Signed-off-by: Yongzhi Liu
Reviewed-by: Harry Wentland
Harry
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 80
> --
> 1 file changed, 60 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> index ded64d0..e463d46 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
> @@ -227,8 +227,10 @@ static ssize_t dp_link_settings_read(struct file *f,
> char __user *buf,
> break;
>
> r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
> return r; /* r = -EFAULT */
> + }
>
> buf += 1;
> size -= 1;
> @@ -389,8 +391,10 @@ static ssize_t dp_phy_settings_read(struct file *f, char
> __user *buf,
> break;
>
> r = put_user((*(rd_buf + result)), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
> return r; /* r = -EFAULT */
> + }
>
> buf += 1;
> size -= 1;
> @@ -1359,8 +1363,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f,
> char __user *buf,
> break;
> }
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
> return -ENXIO;
> + }
>
> dsc = pipe_ctx->stream_res.dsc;
> if (dsc)
> @@ -1376,8 +1382,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f,
> char __user *buf,
> break;
>
> r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
> return r; /* r = -EFAULT */
> + }
>
> buf += 1;
> size -= 1;
> @@ -1546,8 +1554,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
> char __user *buf,
> break;
> }
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
> return -ENXIO;
> + }
>
> dsc = pipe_ctx->stream_res.dsc;
> if (dsc)
> @@ -1563,8 +1573,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
> char __user *buf,
> break;
>
> r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
> return r; /* r = -EFAULT */
> + }
>
> buf += 1;
> size -= 1;
> @@ -1731,8 +1743,10 @@ static ssize_t dp_dsc_slice_height_read(struct file
> *f, char __user *buf,
> break;
> }
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
> return -ENXIO;
> + }
>
> dsc = pipe_ctx->stream_res.dsc;
> if (dsc)
> @@ -1748,8 +1762,10 @@ static ssize_t dp_dsc_slice_height_read(struct file
> *f, char __user *buf,
> break;
>
> r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
> return r; /* r = -EFAULT */
> + }
>
> buf += 1;
> size -= 1;
> @@ -1912,8 +1928,10 @@ static ssize_t dp_dsc_bits_per_pixel_read(struct file
> *f, char __user *buf,
> break;
> }
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
> return -ENXIO;
> + }
>
> dsc = pipe_ctx->stream_res.dsc;
> if (dsc)
> @@ -1929,8 +1947,10 @@ static ssize_t dp_dsc_bits_per_pixel_read(struct file
> *f, char __user *buf,
> break;
>
> r = put_user(*(rd_buf + result), buf);
> - if (r)
> + if (r) {
> + kfree(rd_buf);
> return r; /* r = -EFAULT */
> + }
>
> buf += 1;
> size -= 1;
> @@ -2088,8 +2108,10 @@ static ssize_t dp_dsc_pic_width_read(struct file *f,
> char __user *buf,
> break;
> }
>
> - if (!pipe_ctx)
> + if (!pipe_ctx) {
> + kfree(rd_buf);
> return -ENXIO;
> + }
>
> dsc = pipe_ctx->stream_res.dsc;
> if (dsc)
> @@ -2105,8 +2127,10 @@ static ssize_t dp_dsc_pic_width_read(struct file *f,
> char __user *buf,
> break;
>
> r = put_user(*(rd_buf + result),
Re: [PATCH 2/3] drm/i915/guc: Add work queue to trigger a GT reset
On 1/20/2022 20:31, Matthew Brost wrote:
The G2H handler needs to be flushed during a GT reset but a G2H
indicating engine reset failure can trigger a GT reset. Add a worker to
trigger the GT rest when an engine reset failure is received to break
this circular dependency.
v2:
(John Harrison)
- Store engine reset mask
- Fix typo in commit message
v3:
(John Harrison)
- Fix another typo in commit message
- s/reset_*/reset_fail_*/
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 9 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +--
2 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 9d26a86fe557a..d59bbf49d1c2b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -119,6 +119,15 @@ struct intel_guc {
* function as it might be in an atomic context (no sleeping)
*/
struct work_struct destroyed_worker;
+ /**
+* @reset_fail_worker: worker to trigger a GT reset after an
+* engine reset fails
+*/
+ struct work_struct reset_fail_worker;
+ /**
+* @reset_fail_mask: mask of engines that failed to reset
+*/
+ intel_engine_mask_t reset_fail_mask;
} submission_state;
/**
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 3918f1be114fa..9a3f503d201aa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1731,6 +1731,7 @@ void intel_guc_submission_reset_finish(struct intel_guc
*guc)
}
static void destroyed_worker_func(struct work_struct *w);
+static void reset_fail_worker_func(struct work_struct *w);
/*
* Set up the memory resources to be shared with the GuC (via the GGTT)
@@ -1761,6 +1762,8 @@ int intel_guc_submission_init(struct intel_guc *guc)
INIT_LIST_HEAD(>submission_state.destroyed_contexts);
INIT_WORK(>submission_state.destroyed_worker,
destroyed_worker_func);
+ INIT_WORK(>submission_state.reset_fail_worker,
+ reset_fail_worker_func);
guc->submission_state.guc_ids_bitmap =
bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID(guc), GFP_KERNEL);
@@ -4026,6 +4029,26 @@ guc_lookup_engine(struct intel_guc *guc, u8 guc_class,
u8 instance)
return gt->engine_class[engine_class][instance];
}
+static void reset_fail_worker_func(struct work_struct *w)
+{
+ struct intel_guc *guc = container_of(w, struct intel_guc,
+
submission_state.reset_fail_worker);
+ struct intel_gt *gt = guc_to_gt(guc);
+ intel_engine_mask_t reset_fail_mask;
+ unsigned long flags;
+
+ spin_lock_irqsave(>submission_state.lock, flags);
+ reset_fail_mask = guc->submission_state.reset_fail_mask;
+ guc->submission_state.reset_fail_mask = 0;
+ spin_unlock_irqrestore(>submission_state.lock, flags);
+
+ if (likely(reset_fail_mask))
+ intel_gt_handle_error(gt, reset_fail_mask,
+ I915_ERROR_CAPTURE,
+ "GuC failed to reset engine mask=0x%x\n",
+ reset_fail_mask);
+}
+
int intel_guc_engine_failure_process_msg(struct intel_guc *guc,
const u32 *msg, u32 len)
{
@@ -4033,6 +4056,7 @@ int intel_guc_engine_failure_process_msg(struct intel_guc
*guc,
struct intel_gt *gt = guc_to_gt(guc);
u8 guc_class, instance;
u32 reason;
+ unsigned long flags;
if (unlikely(len != 3)) {
drm_err(>i915->drm, "Invalid length %u", len);
@@ -4057,10 +4081,15 @@ int intel_guc_engine_failure_process_msg(struct
intel_guc *guc,
drm_err(>i915->drm, "GuC engine reset request failed on %d:%d (%s)
because 0x%08X",
guc_class, instance, engine->name, reason);
- intel_gt_handle_error(gt, engine->mask,
- I915_ERROR_CAPTURE,
- "GuC failed to reset %s (reason=0x%08x)\n",
- engine->name, reason);
+ spin_lock_irqsave(>submission_state.lock, flags);
+ guc->submission_state.reset_fail_mask |= engine->mask;
+ spin_unlock_irqrestore(>submission_state.lock, flags);
+
+ /*
+* A GT reset flushes this worker queue (G2H handler) so we must use
+* another worker to trigger a GT reset.
+*/
+ queue_work(system_unbound_wq, >submission_state.reset_fail_worker);
return 0;
}
Re: [PATCH 1/3] drm: add writeback pointers to drm_connector
+ laurent on this
Hi Suraj
On 1/11/2022 2:17 AM, Kandpal, Suraj wrote:
Changing drm_connector and drm_encoder feilds to pointers in
drm_writeback_connector as the elements of struct
drm_writeback_connector are:
struct drm_writeback_connector {
struct drm_connector base;
struct drm_encoder encoder;
Similarly the elements of intel_encoder and intel_connector
are:
struct intel_encoder {
struct drm_encoder base;
struct intel_connector {
struct drm_connector base;
The function drm_writeback_connector_init() will initialize the
drm_connector and drm_encoder and attach them as well.
Since the drm_connector/encoder are both struct in
drm_writeback_connector and intel_connector/encoder, we need
one of them to be a pointer so we can reference them or else we
will be pointing to 2 seprate instances.
Usually the struct defined in drm framework pointing to any
struct will be pointer and allocating them and initialization
will be done with the users.
Like struct drm_connector and drm_encoder are part of drm
framework and the users of these such as i915 have included them
in their struct intel_connector and intel_encoder. Likewise
struct drm_writeback_connector is a special connector and hence
is not a user of drm_connector and hence this should be pointers.
Adding drm_writeback_connector to drm_connector so that
writeback_connector can be fetched from drm_connector as the previous
container_of method won't work due to change in the feilds of
drm_connector and drm_encoder in drm_writeback_connector.
Note:The corresponding ripple effect due to the above changes namely in
two drivers as I can see it komeda and vkms have been dealt with in the
upcoming patches of this series.
Signed-off-by: Kandpal, Suraj
Jani pointed me to this thread as i had posted something similar here :
https://patchwork.freedesktop.org/patch/470296/ but since this thread
was posted earlier, we can discuss further here.
Overall, its similar to what I had posted in the RFC and your commit
text also covers my concerns too.
One question I have about your change is since you have changed
wb_connector::encoder to be a pointer, i saw the other changes in the
series but they do not allocate an encoder. Would this not affect the
other drivers which are assuming that the encoder in wb_connector is
struct drm_encoder encoder and not struct drm_encoder* encoder.
Your changes fix the compilation issue but wouldnt this crash as encoder
wasnt allocated for other drivers.
---
drivers/gpu/drm/drm_writeback.c | 19 ++-
include/drm/drm_connector.h | 3 +++
include/drm/drm_writeback.h | 6 +++---
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504f1bb..47238db42363 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -87,7 +87,7 @@ static const char *drm_writeback_fence_get_driver_name(struct
dma_fence *fence)
struct drm_writeback_connector *wb_connector =
fence_to_wb_connector(fence);
- return wb_connector->base.dev->driver->name;
+ return wb_connector->base->dev->driver->name;
}
static const char *
@@ -177,7 +177,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
const u32 *formats, int n_formats)
{
struct drm_property_blob *blob;
- struct drm_connector *connector = _connector->base;
+ struct drm_connector *connector = wb_connector->base;
struct drm_mode_config *config = >mode_config;
int ret = create_writeback_properties(dev);
@@ -189,14 +189,15 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
- drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
- ret = drm_encoder_init(dev, _connector->encoder,
+ drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+ ret = drm_encoder_init(dev, wb_connector->encoder,
_writeback_encoder_funcs,
DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
goto fail;
connector->interlace_allowed = 0;
+ connector->wb_connector = wb_connector;
ret = drm_connector_init(dev, connector, con_funcs,
DRM_MODE_CONNECTOR_WRITEBACK);
@@ -204,7 +205,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
ret = drm_connector_attach_encoder(connector,
- _connector->encoder);
+ wb_connector->encoder);
if (ret)
goto attach_fail;
@@ -233,7 +234,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
attach_fail:
drm_connector_cleanup(connector);
connector_fail:
-
Re: Renesas rcar-du and DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE
On Wed, Dec 29, 2021 at 10:19 PM Charles Stevens wrote: > > > Hi All, > I am working on a platform based on the Renesas RZ/G2 SoC family. This > chip uses the rcar-du driver for the display. I would like to submit a patch > to address the fact that the driver does not check/honor the flag > DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE. My issue is that I would like to make as > small a change to the driver as possible, but the panel bus_flags don't seem > to even make it to the crtc driver. The crtc driver seems to use > adjusted_mode to set the HSYNC and VSYNC polarity and as I said ignores the > pixel clock polarity leaving it at the default of driving on the falling > edge. In my investigations so far I have not figured out how to chase the > pointers from the CRTC to the bridge to the panel in order to be able to look > at bus_flags. My current approach also modifies the encoder initialization to > cache the needed panel and then find the attached encoder during CRTC > initialization to find the bus flags. This seems like a lot of work and not > something that would be accepted as a patch. The OMAP DSS seems to have > problems accessing this flag as well. The TI driver goes so far as to > document the current approach as a HACK and suggest a fairly large change to > the driver to address the problem. Am I missing something? Is there an easy > way to get from a drm_crtc to a drm_panel that is in the same pipeline? > > Any pointers would be greatly appreciated! + Laurent, Kieran Charles, I added Laurent and Kieran because they appear as the maintainers for the rcar-du driver. adam > > Thanks! > > -charles
Re: [PATCH 24/31] video: backlight: changing LED_* from enum led_brightness to actual value
On Fri, Jan 21, 2022 at 01:54:29PM -0300, Luiz Sampaio wrote: > The enum led_brightness, which contains the declaration of LED_OFF, > LED_ON, LED_HALF and LED_FULL is obsolete, as the led class now supports > max_brightness. Reviewed-by: Daniel Thompson BTW it looks like this patch might wants to land in one tree (I can't see since I'm only on copy of this one). If so please discuss with Lee how you want to land it. Put more directly, please don't treat my Reviewed-by: as an Acked-by: ;-) ! Daniel. > --- > drivers/video/backlight/adp8860_bl.c | 4 ++-- > drivers/video/backlight/adp8870_bl.c | 4 ++-- > drivers/video/backlight/led_bl.c | 2 +- > 3 files changed, 5 insertions(+), 5 deletions(-) > > diff --git a/drivers/video/backlight/adp8860_bl.c > b/drivers/video/backlight/adp8860_bl.c > index 8ec19425671f..063be4189e7e 100644 > --- a/drivers/video/backlight/adp8860_bl.c > +++ b/drivers/video/backlight/adp8860_bl.c > @@ -261,10 +261,10 @@ static int adp8860_led_probe(struct i2c_client *client) > led_dat->cdev.name = cur_led->name; > led_dat->cdev.default_trigger = cur_led->default_trigger; > led_dat->cdev.brightness_set = adp8860_led_set; > - led_dat->cdev.brightness = LED_OFF; > + led_dat->cdev.brightness = 0; > led_dat->flags = cur_led->flags >> FLAG_OFFT_SHIFT; > led_dat->client = client; > - led_dat->new_brightness = LED_OFF; > + led_dat->new_brightness = 0; > INIT_WORK(_dat->work, adp8860_led_work); > > ret = led_classdev_register(>dev, _dat->cdev); > diff --git a/drivers/video/backlight/adp8870_bl.c > b/drivers/video/backlight/adp8870_bl.c > index 8b5213a39527..b04faf8d631d 100644 > --- a/drivers/video/backlight/adp8870_bl.c > +++ b/drivers/video/backlight/adp8870_bl.c > @@ -287,10 +287,10 @@ static int adp8870_led_probe(struct i2c_client *client) > led_dat->cdev.name = cur_led->name; > led_dat->cdev.default_trigger = cur_led->default_trigger; > led_dat->cdev.brightness_set = adp8870_led_set; > - led_dat->cdev.brightness = LED_OFF; > + led_dat->cdev.brightness = 0; > led_dat->flags = cur_led->flags >> FLAG_OFFT_SHIFT; > led_dat->client = client; > - led_dat->new_brightness = LED_OFF; > + led_dat->new_brightness = 0; > INIT_WORK(_dat->work, adp8870_led_work); > > ret = led_classdev_register(>dev, _dat->cdev); > diff --git a/drivers/video/backlight/led_bl.c > b/drivers/video/backlight/led_bl.c > index f54d256e2d54..1b869624b4f8 100644 > --- a/drivers/video/backlight/led_bl.c > +++ b/drivers/video/backlight/led_bl.c > @@ -46,7 +46,7 @@ static void led_bl_power_off(struct led_bl_data *priv) > return; > > for (i = 0; i < priv->nb_leds; i++) > - led_set_brightness(priv->leds[i], LED_OFF); > + led_set_brightness(priv->leds[i], 0); > > priv->enabled = false; > } > -- > 2.34.1 >
Re: [RFC PATCH] drm: allow passing a real encoder object for wb connector
Hi Jani
On 1/21/2022 1:17 AM, Jani Nikula wrote:
On Thu, 20 Jan 2022, Abhinav Kumar wrote:
Instead of creating an internal encoder for the writeback
connector to satisfy DRM requirements, allow the clients
to pass a real encoder to it by changing the drm_writeback's
encoder to a pointer.
If a real encoder is not passed, drm_writeback_connector_init
will internally allocate one.
This will help the clients to manage the real encoder states
better as they will allocate and maintain the encoder.
See also the thread starting at [1], and please try to coordinate.
I don't know what the end result should be like, I'm just saying please
collaborate instead of racing to get one set of changes in.
BR,
Jani.
[1]
https://patchwork.freedesktop.org/patch/msgid/2022001801.28310-1-suraj.kand...@intel.com
Thanks for pointing to this thread. Since
https://patchwork.freedesktop.org/patch/469090/ has been posted earlier
and is more complete in terms of handling other vendor changes, we can
continue on that one.
But I dont see any comments on that one yet.
Hi Laurent
In that case can you please check the
https://patchwork.freedesktop.org/patch/469090/ thread , we can continue
our discussion there.
We also have the same issue too. Our encoder also maintains its own
struct drm_encoder.
Thanks
Abhinav
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/drm_writeback.c | 11 +++
include/drm/drm_writeback.h | 2 +-
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index dccf4504..fdb7381 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -189,8 +189,11 @@ int drm_writeback_connector_init(struct drm_device *dev,
if (IS_ERR(blob))
return PTR_ERR(blob);
- drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
- ret = drm_encoder_init(dev, _connector->encoder,
+ /* allocate the internal drm encoder if a real one wasnt passed */
+ if (!wb_connector->encoder)
+ wb_connector->encoder = devm_kzalloc(dev->dev, sizeof(struct
drm_encoder), GFP_KERNEL);
+ drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
+ ret = drm_encoder_init(dev, wb_connector->encoder,
_writeback_encoder_funcs,
DRM_MODE_ENCODER_VIRTUAL, NULL);
if (ret)
@@ -204,7 +207,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
goto connector_fail;
ret = drm_connector_attach_encoder(connector,
- _connector->encoder);
+ wb_connector->encoder);
if (ret)
goto attach_fail;
@@ -233,7 +236,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
attach_fail:
drm_connector_cleanup(connector);
connector_fail:
- drm_encoder_cleanup(_connector->encoder);
+ drm_encoder_cleanup(wb_connector->encoder);
fail:
drm_property_blob_put(blob);
return ret;
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index 9697d27..f0d8147 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -31,7 +31,7 @@ struct drm_writeback_connector {
* by passing the @enc_funcs parameter to drm_writeback_connector_init()
* function.
*/
- struct drm_encoder encoder;
+ struct drm_encoder *encoder;
/**
* @pixel_formats_blob_ptr:
Re: [PATCH v3] drm/ast: Don't check new mode if CRTC is being disabled
On Thu, May 07, 2020 at 11:06:40AM +0200, Thomas Zimmermann wrote:
> Suspending failed because there's no mode if the CRTC is being
> disabled. Early-out in this case. This fixes runtime PM for ast.
>
> v3:
> * fixed commit message
> v2:
> * added Tested-by/Reported-by tags
> * added Fixes tags and CC (Sam)
> * improved comment
>
> Signed-off-by: Thomas Zimmermann
> Reported-by: Cary Garrett
> Tested-by: Cary Garrett
> Fixes: b48e1b6ffd28 ("drm/ast: Add CRTC helpers for atomic modesetting")
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: # v5.6+
> ---
> drivers/gpu/drm/ast/ast_mode.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 7a9f20a2fd303..0cbbb21edb4e1 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc
> *crtc,
> return -EINVAL;
> }
>
> + if (!state->enable)
> + return 0; /* no mode checks if CRTC is being disabled */
> +
> ast_state = to_ast_crtc_state(state);
>
> format = ast_state->format;
hey,
I'm seeing a regression that I bisected down to this change. I
installed GNOME on a couple of different server models that have
AMI-based BMCs, which provide a web-based graphics display (virtual
KVM). When I enter the lock screen on current upstream kernels, the
display freezes, and I see the following messages appear in syslog
whenever I generate keyboard/mouse events on that display:
Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update:
drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Page flip discarded:
drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update:
drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Page flip discarded:
drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update:
drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Page flip discarded:
drmModeAtomicCommit: Invalid argument
Jan 19 20:34:53 starbuck gnome-shell[5002]: Failed to post KMS update:
drmModeAtomicCommit: Invalid argument
If I back out this change w/ the following patch (code has evolved
slightly preventing a clean revert), then the lock screen once again
behaves normally:
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 956c8982192b..336c545c46f5 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -1012,9 +1012,6 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc
*crtc,
const struct drm_format_info *format;
bool succ;
- if (!crtc_state->enable)
- return 0; /* no mode checks if CRTC is being disabled */
-
ast_state = to_ast_crtc_state(crtc_state);
format = ast_state->format;
Apologies for noticing so long after the fact. I don't normally run a
desktop environment on these servers, I just happened to be debugging
something recently that required it.
-dann
Re: (EXT) Re: [PATCH 1/1] drm: mxsfb: Fix NULL pointer dereference
On 1/21/22 14:24, Alexander Stein wrote:
Am Freitag, 21. Januar 2022, 14:14:01 CET schrieb Marek Vasut:
On 1/21/22 14:12, Alexander Stein wrote:
Do not deference the NULL pointer if the bridge does not return a
bridge state. Assume a fixed format instead.
Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest
bridge if present") Signed-off-by: Alexander Stein
---
This can happen if a "ti,sn75lvds83", "lvds-encoder" bridge is attached
to it. atomic_get_input_bus_fmts is only implemented for the
lvds-decoder case.
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index 0655582ae8ed..4cfb6c001679
100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -361,7 +361,11 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc
*crtc,>
bridge_state =
drm_atomic_get_new_bridge_state(state,
mxsfb->bridge);
- bus_format = bridge_state->input_bus_cfg.format;
+ if (!bridge_state)
+ bus_format = MEDIA_BUS_FMT_FIXED;
+ else
+ bus_format = bridge_state-
input_bus_cfg.format;
+
if (bus_format == MEDIA_BUS_FMT_FIXED) {
dev_warn_once(drm->dev,
"Bridge does not provide bus
format, assuming
MEDIA_BUS_FMT_RGB888_1X24.
\n"
Shouldn't this be fixed on the bridge driver side instead ?
Which bridge driver do you use ?
It's drivers/gpu/drm/bridge/lvds-codec.c. I thought naming the compatibles
would suffice. I consider a patch for the bridge driver as a separate issue,
hence the warning from mxsfb. Although I'm unsure how/what to implement.
Similar to the encode case where the bus format is specified in DT?
I'm sorry, I missed the lvds-codec part. Laurent is already on CC.
Anyway, mxsfb should not never dereference the NULL pointer which
drm_atomic_get_new_bridge_state is allowed to return.
That line ^ should be in the commit message.
Re: (EXT) Re: [PATCH 1/1] drm: mxsfb: Fix NULL pointer dereference
Am Freitag, 21. Januar 2022, 14:14:01 CET schrieb Marek Vasut:
> On 1/21/22 14:12, Alexander Stein wrote:
> > Do not deference the NULL pointer if the bridge does not return a
> > bridge state. Assume a fixed format instead.
> >
> > Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest
> > bridge if present") Signed-off-by: Alexander Stein
> >
> > ---
> > This can happen if a "ti,sn75lvds83", "lvds-encoder" bridge is attached
> > to it. atomic_get_input_bus_fmts is only implemented for the
> > lvds-decoder case.
> >
> > drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > b/drivers/gpu/drm/mxsfb/mxsfb_kms.c index 0655582ae8ed..4cfb6c001679
> > 100644
> > --- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > +++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
> > @@ -361,7 +361,11 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc
> > *crtc,>
> > bridge_state =
> >
> > drm_atomic_get_new_bridge_state(state,
> >
> >
mxsfb->bridge);
> >
> > - bus_format = bridge_state->input_bus_cfg.format;
> > + if (!bridge_state)
> > + bus_format = MEDIA_BUS_FMT_FIXED;
> > + else
> > + bus_format = bridge_state-
>input_bus_cfg.format;
> > +
> >
> > if (bus_format == MEDIA_BUS_FMT_FIXED) {
> >
> > dev_warn_once(drm->dev,
> >
> > "Bridge does not provide bus
format, assuming
> > MEDIA_BUS_FMT_RGB888_1X24.
\n"
>
> Shouldn't this be fixed on the bridge driver side instead ?
>
> Which bridge driver do you use ?
It's drivers/gpu/drm/bridge/lvds-codec.c. I thought naming the compatibles
would suffice. I consider a patch for the bridge driver as a separate issue,
hence the warning from mxsfb. Although I'm unsure how/what to implement.
Similar to the encode case where the bus format is specified in DT?
Anyway, mxsfb should not never dereference the NULL pointer which
drm_atomic_get_new_bridge_state is allowed to return.
Best regards,
Alexander
Re: [PATCH 1/1] drm: mxsfb: Fix NULL pointer dereference
On 1/21/22 14:12, Alexander Stein wrote:
Do not deference the NULL pointer if the bridge does not return a
bridge state. Assume a fixed format instead.
Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge if
present")
Signed-off-by: Alexander Stein
---
This can happen if a "ti,sn75lvds83", "lvds-encoder" bridge is attached
to it. atomic_get_input_bus_fmts is only implemented for the
lvds-decoder case.
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 0655582ae8ed..4cfb6c001679 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -361,7 +361,11 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
bridge_state =
drm_atomic_get_new_bridge_state(state,
mxsfb->bridge);
- bus_format = bridge_state->input_bus_cfg.format;
+ if (!bridge_state)
+ bus_format = MEDIA_BUS_FMT_FIXED;
+ else
+ bus_format = bridge_state->input_bus_cfg.format;
+
if (bus_format == MEDIA_BUS_FMT_FIXED) {
dev_warn_once(drm->dev,
"Bridge does not provide bus format, assuming
MEDIA_BUS_FMT_RGB888_1X24.\n"
Shouldn't this be fixed on the bridge driver side instead ?
Which bridge driver do you use ?
[PATCH 1/1] drm: mxsfb: Fix NULL pointer dereference
Do not deference the NULL pointer if the bridge does not return a
bridge state. Assume a fixed format instead.
Fixes: commit b776b0f00f24 ("drm: mxsfb: Use bus_format from the nearest bridge
if present")
Signed-off-by: Alexander Stein
---
This can happen if a "ti,sn75lvds83", "lvds-encoder" bridge is attached
to it. atomic_get_input_bus_fmts is only implemented for the
lvds-decoder case.
drivers/gpu/drm/mxsfb/mxsfb_kms.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
index 0655582ae8ed..4cfb6c001679 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_kms.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_kms.c
@@ -361,7 +361,11 @@ static void mxsfb_crtc_atomic_enable(struct drm_crtc *crtc,
bridge_state =
drm_atomic_get_new_bridge_state(state,
mxsfb->bridge);
- bus_format = bridge_state->input_bus_cfg.format;
+ if (!bridge_state)
+ bus_format = MEDIA_BUS_FMT_FIXED;
+ else
+ bus_format = bridge_state->input_bus_cfg.format;
+
if (bus_format == MEDIA_BUS_FMT_FIXED) {
dev_warn_once(drm->dev,
"Bridge does not provide bus format,
assuming MEDIA_BUS_FMT_RGB888_1X24.\n"
--
2.25.1
Re: [PATCH 1/1] drm: mxsfb: Use dev_err_probe() helper
On 1/21/22 10:56, Alexander Stein wrote: Use the dev_err_probe() helper, instead of open-coding the same operation. This also adds a nice hint in /sys/kernel/debug/devices_deferred. Signed-off-by: Alexander Stein Reviewed-by: Marek Vasut Thanks
Re: [PATCH v5 0/5] drm: exynos: dsi: Convert drm bridge
Hi Jagan, On 21.01.2022 12:40, Jagan Teki wrote: > On Fri, Jan 21, 2022 at 5:06 PM Marek Szyprowski > wrote: >> On 17.01.2022 09:42, Jagan Teki wrote: >>> Updated series about drm bridge conversion of exynos dsi. >>> >>> Previous version can be accessible, here [1]. >>> >>> Patch 1: connector reset >>> >>> Patch 2: panel_bridge API >>> >>> Patch 3: bridge conversion >>> >>> Patch 4: atomic functions >>> >>> Patch 5: DSI init in pre_enable >>> >>> Apply below patches to test on Exynos DSI: >>> - >>> https://protect2.fireeye.com/v1/url?k=53bdf119-0c26c815-53bc7a56-000babff3563-792dc1a6b54db43e=1=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1825%2F >>> - >>> https://protect2.fireeye.com/v1/url?k=cb269ea3-94bda7af-cb2715ec-000babff3563-e6f545b4a32558ba=1=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1838%2F >>> >>> [1] >>> https://protect2.fireeye.com/v1/url?k=ee1dae12-b186971e-ee1c255d-000babff3563-83eaf8e86e67e0d9=1=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fcover%2F1826%2F >>> >>> Any inputs? >> I've tried a few times, but I am unable to find what is the base for >> this patchset. I always get a conflict around exynos_dsi_mode_set() >> function. I've tried current linux-next, drm-next, v5.16-rc1 and v5.16. >> It looks that I must have missed applying some patch before playing with >> this. >> >> I've also tried to apply only the last patch, as if I got it right, it >> is the only difference between v4 and v5 and updated 'drm: of: Lookup if >> child node has panel or bridge'. In such case the board freezes during >> the drm initialization. > Please use drm-misc/drm-misc-next with below patches and then apply this > series. I don't have a good news. It doesn't work. The last patch even breaks DSI operation: [ 4.520276] [drm] Exynos DRM: using 1380.decon device for DMA mapping operations [ 4.520578] exynos-drm exynos-drm: bound 1380.decon (ops decon_component_ops) [ 4.580473] exynos-drm exynos-drm: bound 1388.decon (ops decon_component_ops) [ 4.580726] exynos-drm exynos-drm: bound 1393.mic (ops exynos_mic_component_ops) [ 4.584304] exynos-dsi 1390.dsi: [drm:exynos_dsi_host_attach] Attached s6e3hf2 device [ 4.585141] exynos-drm exynos-drm: bound 1390.dsi (ops exynos_dsi_component_ops) [ 4.593189] rc_core: Couldn't load IR keymap rc-cec [ 4.594133] Registered IR keymap rc-empty [ 4.598760] rc rc0: sii8620 as /devices/virtual/rc/rc0 [ 4.605219] input: sii8620 as /devices/virtual/rc/rc0/input1 [ 4.610238] exynos-drm exynos-drm: bound 1397.hdmi (ops hdmi_component_ops) [ 4.920038] exynos-dsi 1390.dsi: xfer timed out: 39 03 00 00 f0 5a 5a [ 5.024033] [ cut here ] [ 5.024055] [CRTC:49:crtc-0] vblank wait timed out [ 5.024129] WARNING: CPU: 4 PID: 151 at drivers/gpu/drm/drm_atomic_helper.c:1530 drm_atomic_helper_wait_for_vblanks.part.24+0x298/0x2a8 [ 5.024171] Modules linked in: [ 5.024195] CPU: 4 PID: 151 Comm: kworker/4:7 Not tainted 5.16.0-rc5+ #11232 [ 5.024219] Hardware name: Samsung TM2E board (DT) [ 5.024232] Workqueue: events output_poll_execute [ 5.024262] pstate: 6005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 5.024285] pc : drm_atomic_helper_wait_for_vblanks.part.24+0x298/0x2a8 [ 5.024308] lr : drm_atomic_helper_wait_for_vblanks.part.24+0x298/0x2a8 [ 5.024327] sp : 800013b5b970 [ 5.024340] x29: 800013b5b970 x28: x27: 2437e400 [ 5.024391] x26: x25: x24: 800011aa0c60 [ 5.024437] x23: 0001 x22: 25113000 x21: 0001 [ 5.024482] x20: 316fc800 x19: x18: [ 5.024526] x17: 00480a11 x16: 0028 x15: 800011b66df8 [ 5.024571] x14: x13: 0a74756f2064656d x12: 6974207469617720 [ 5.024615] x11: 656820747563205b x10: 003a x9 : 7e82f035 [ 5.024661] x8 : 800011b66df8 x7 : 800013b5b740 x6 : 0001 [ 5.024704] x5 : 0001 x4 : x3 : 0007 [ 5.024747] x2 : 800012524ea0 x1 : 68a66f6a76622200 x0 : [ 5.024791] Call trace: [ 5.024802] drm_atomic_helper_wait_for_vblanks.part.24+0x298/0x2a8 [ 5.024825] drm_atomic_helper_commit_tail_rpm+0x60/0x78 [ 5.024845] commit_tail+0x9c/0x170 [ 5.024864] drm_atomic_helper_commit+0x188/0x3a0 [ 5.024884] drm_atomic_commit+0x54/0x68 [ 5.024906] drm_client_modeset_commit_atomic+0x260/0x288 [ 5.024927] drm_client_modeset_commit_locked+0x54/0x1c0 [ 5.024945] drm_client_modeset_commit+0x2c/0x50 [ 5.024962] __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xf8 [ 5.024983] drm_fb_helper_set_par+0x38/0x70 [ 5.025000] drm_fb_helper_hotplug_event.part.29+0xb0/0xe0 [
Re: [PATCH v9 3/6] drm: implement top-down allocation method
On 19/01/2022 11:37, Arunpravin wrote:
Implemented a function which walk through the order list,
compares the offset and returns the maximum offset block,
this method is unpredictable in obtaining the high range
address blocks which depends on allocation and deallocation.
for instance, if driver requests address at a low specific
range, allocator traverses from the root block and splits
the larger blocks until it reaches the specific block and
in the process of splitting, lower orders in the freelist
are occupied with low range address blocks and for the
subsequent TOPDOWN memory request we may return the low
range blocks.To overcome this issue, we may go with the
below approach.
The other approach, sorting each order list entries in
ascending order and compares the last entry of each
order list in the freelist and return the max block.
This creates sorting overhead on every drm_buddy_free()
request and split up of larger blocks for a single page
request.
v2:
- Fix alignment issues(Matthew Auld)
- Remove unnecessary list_empty check(Matthew Auld)
- merged the below patch to see the feature in action
- add top-down alloc support to i915 driver
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 36 ---
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 3 ++
include/drm/drm_buddy.h | 1 +
3 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index 954e31962c74..6aa5c1ce25bf 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -371,6 +371,26 @@ alloc_range_bias(struct drm_buddy *mm,
return ERR_PTR(err);
}
+static struct drm_buddy_block *
+get_maxblock(struct list_head *head)
+{
+ struct drm_buddy_block *max_block = NULL, *node;
+
+ max_block = list_first_entry_or_null(head,
+struct drm_buddy_block,
+link);
+ if (!max_block)
+ return NULL;
+
+ list_for_each_entry(node, head, link) {
+ if (drm_buddy_block_offset(node) >
+ drm_buddy_block_offset(max_block))
+ max_block = node;
+ }
If we feed in the knowledge of the visible_size(or perhaps implement
that generically as "zones"), I think this can be done more efficiently.
It could also be useful to track directly in the allocator how much of
the visible_size is still available, rather than having to do that in
the upper levels by scanning the entire list. But hopefully in practice
this should be good enough for our needs,
Reviewed-by: Matthew Auld
+
+ return max_block;
+}
+
static struct drm_buddy_block *
alloc_from_freelist(struct drm_buddy *mm,
unsigned int order,
@@ -381,11 +401,17 @@ alloc_from_freelist(struct drm_buddy *mm,
int err;
for (i = order; i <= mm->max_order; ++i) {
- block = list_first_entry_or_null(>free_list[i],
-struct drm_buddy_block,
-link);
- if (block)
- break;
+ if (flags & DRM_BUDDY_TOPDOWN_ALLOCATION) {
+ block = get_maxblock(>free_list[i]);
+ if (block)
+ break;
+ } else {
+ block = list_first_entry_or_null(>free_list[i],
+struct drm_buddy_block,
+link);
+ if (block)
+ break;
+ }
}
if (!block)
diff --git a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
index 1411f4cf1f21..3662434b64bb 100644
--- a/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
+++ b/drivers/gpu/drm/i915/i915_ttm_buddy_manager.c
@@ -53,6 +53,9 @@ static int i915_ttm_buddy_man_alloc(struct
ttm_resource_manager *man,
INIT_LIST_HEAD(_res->blocks);
bman_res->mm = mm;
+ if (place->flags & TTM_PL_FLAG_TOPDOWN)
+ bman_res->flags |= DRM_BUDDY_TOPDOWN_ALLOCATION;
+
if (place->fpfn || lpfn != man->size)
bman_res->flags |= DRM_BUDDY_RANGE_ALLOCATION;
diff --git a/include/drm/drm_buddy.h b/include/drm/drm_buddy.h
index 865664b90a8a..424fc443115e 100644
--- a/include/drm/drm_buddy.h
+++ b/include/drm/drm_buddy.h
@@ -28,6 +28,7 @@
})
#define DRM_BUDDY_RANGE_ALLOCATION (1 << 0)
+#define DRM_BUDDY_TOPDOWN_ALLOCATION (1 << 1)
struct drm_buddy_block {
#define DRM_BUDDY_HEADER_OFFSET GENMASK_ULL(63, 12)
Re: [PATCH v9 2/6] drm: improve drm_buddy_alloc function
On 19/01/2022 11:37, Arunpravin wrote:
- Make drm_buddy_alloc a single function to handle
range allocation and non-range allocation demands
- Implemented a new function alloc_range() which allocates
the requested power-of-two block comply with range limitations
- Moved order computation and memory alignment logic from
i915 driver to drm buddy
v2:
merged below changes to keep the build unbroken
- drm_buddy_alloc_range() becomes obsolete and may be removed
- enable ttm range allocation (fpfn / lpfn) support in i915 driver
- apply enhanced drm_buddy_alloc() function to i915 driver
v3(Matthew Auld):
- Fix alignment issues and remove unnecessary list_empty check
- add more validation checks for input arguments
- make alloc_range() block allocations as bottom-up
- optimize order computation logic
- replace uint64_t with u64, which is preferred in the kernel
v4(Matthew Auld):
- keep drm_buddy_alloc_range() function implementation for generic
actual range allocations
- keep alloc_range() implementation for end bias allocations
v5(Matthew Auld):
- modify drm_buddy_alloc() passing argument place->lpfn to lpfn
as place->lpfn will currently always be zero for i915
v6(Matthew Auld):
- fixup potential uaf - If we are unlucky and can't allocate
enough memory when splitting blocks, where we temporarily
end up with the given block and its buddy on the respective
free list, then we need to ensure we delete both blocks,
and no just the buddy, before potentially freeing them
Hmm, not sure we really want to squash existing bug fixes into this
patch. Perhaps bring in [1] to the start of your series? i915_buddy is
gone now. Alternatively I can resend such that it applies on top
drm_buddy. Your choice.
[1] https://patchwork.freedesktop.org/patch/469806/?series=98953=1
- fix warnings reported by kernel test robot
Signed-off-by: Arunpravin
---
drivers/gpu/drm/drm_buddy.c | 326 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 67 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 2 +
include/drm/drm_buddy.h | 22 +-
4 files changed, 293 insertions(+), 124 deletions(-)
diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c
index d60878bc9c20..954e31962c74 100644
--- a/drivers/gpu/drm/drm_buddy.c
+++ b/drivers/gpu/drm/drm_buddy.c
@@ -282,23 +282,99 @@ void drm_buddy_free_list(struct drm_buddy *mm, struct
list_head *objects)
}
EXPORT_SYMBOL(drm_buddy_free_list);
-/**
- * drm_buddy_alloc_blocks - allocate power-of-two blocks
- *
- * @mm: DRM buddy manager to allocate from
- * @order: size of the allocation
- *
- * The order value here translates to:
- *
- * 0 = 2^0 * mm->chunk_size
- * 1 = 2^1 * mm->chunk_size
- * 2 = 2^2 * mm->chunk_size
- *
- * Returns:
- * allocated ptr to the _buddy_block on success
- */
-struct drm_buddy_block *
-drm_buddy_alloc_blocks(struct drm_buddy *mm, unsigned int order)
+static inline bool overlaps(u64 s1, u64 e1, u64 s2, u64 e2)
+{
+ return s1 <= e2 && e1 >= s2;
+}
+
+static inline bool contains(u64 s1, u64 e1, u64 s2, u64 e2)
+{
+ return s1 <= s2 && e1 >= e2;
+}
+
+static struct drm_buddy_block *
+alloc_range_bias(struct drm_buddy *mm,
+u64 start, u64 end,
+unsigned int order)
+{
+ struct drm_buddy_block *block;
+ struct drm_buddy_block *buddy;
+ LIST_HEAD(dfs);
+ int err;
+ int i;
+
+ end = end - 1;
+
+ for (i = 0; i < mm->n_roots; ++i)
+ list_add_tail(>roots[i]->tmp_link, );
+
+ do {
+ u64 block_start;
+ u64 block_end;
+
+ block = list_first_entry_or_null(,
+struct drm_buddy_block,
+tmp_link);
+ if (!block)
+ break;
+
+ list_del(>tmp_link);
+
+ if (drm_buddy_block_order(block) < order)
+ continue;
+
+ block_start = drm_buddy_block_offset(block);
+ block_end = block_start + drm_buddy_block_size(mm, block) - 1;
+
+ if (!overlaps(start, end, block_start, block_end))
+ continue;
+
+ if (drm_buddy_block_is_allocated(block))
+ continue;
+
+ if (contains(start, end, block_start, block_end) &&
+ order == drm_buddy_block_order(block)) {
+ /*
+* Find the free block within the range.
+*/
+ if (drm_buddy_block_is_free(block))
+ return block;
+
+ continue;
+ }
+
+ if (!drm_buddy_block_is_split(block)) {
+ err = split_block(mm, block);
+ if
Re: [PATCH v9 12/15] media: mtk-vcodec: enc: Remove mtk_vcodec_release_enc_pm
Hi Matthias, On 1/13/22 17:10, Matthias Brugger wrote: > Hi Hans, > > On 13/01/2022 11:15, Hans Verkuil wrote: >> On 13/01/2022 11:11, AngeloGioacchino Del Regno wrote: >>> Il 11/01/22 11:57, AngeloGioacchino Del Regno ha scritto: Il 12/11/21 11:55, Yong Wu ha scritto: > After this patchset, mtk_vcodec_release_enc_pm has only one line. > then remove that function, use pm_runtime_disable instead. > > meanwhile, mtk_vcodec_init_enc_pm only operate for the clocks, > rename it from the _pm to _clk. > > No functional change. > > CC: Tiffany Lin > CC: Irui Wang > Signed-off-by: Yong Wu Reviewed-by: AngeloGioacchino Del Regno >>> >>> Hello Yong, >>> the mtk-vcodec patches were merged in Yunfei's vcodec patch series and Hans >>> has >>> scheduled that for v5.18. >>> >>> Can you please send a v10 and drop patches 10/15, 11/15, 12/15 (all of the >>> media: mtk-vcodec: *) from this series? >>> >>> For the records, I think that after sending v10 this series is ready to be >>> merged, >>> as it was well reviewed and also tested on many MTK platforms. >> >> Good to know. When I have the v10 I'll try to prioritize reviewing it and >> running >> my usual tests. >> >> Yong, please make sure you run 'checkpatch.pl --strict' over the v10 patches >> and fix >> any issues (using common sense). >> > > Can you please take me in the look when you take the patches. I'll take the > DTS related as soon as you queue up the others. This just got merged into our tree. Regards, Hans
Re: [Intel-gfx] [PATCH 6/7] drm: Document fdinfo format specification
On 20/01/2022 16:44, Rob Clark wrote: On Wed, Jan 19, 2022 at 7:09 AM Daniel Vetter wrote: On Thu, Jan 06, 2022 at 04:55:35PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Proposal to standardise the fdinfo text format as optionally output by DRM drivers. Idea is that a simple but, well defined, spec will enable generic userspace tools to be written while at the same time avoiding a more heavy handed approach of adding a mid-layer to DRM. i915 implements a subset of the spec, everything apart from the memory stats currently, and a matching intel_gpu_top tool exists. Open is to see if AMD can migrate to using the proposed GPU utilisation key-value pairs, or if they are not workable to see whether to go vendor specific, or if a standardised alternative can be found which is workable for both drivers. Same for the memory utilisation key-value pairs proposal. v2: * Update for removal of name and pid. v3: * 'Drm-driver' tag will be obtained from struct drm_driver.name. (Daniel) Signed-off-by: Tvrtko Ursulin Cc: David M Nieto Cc: Christian König Cc: Daniel Vetter Cc: Daniel Stone Cc: Chris Healy Acked-by: Christian König I'm assuming this ack here and later on is a "amdgpu plans to use this too" kind of affair. Especially also in the lights of eventually using matching semantics for cgroups and everything else tied to gpu execution resource management. If not I'm mildly worried that we're creating fake-standard stuff here which cannot actually be used by anything resembling driver-agnostic userspace. I think I could implement something like this for drm/msm. I am a bit uncertain about the memory stats (ie. how are we intended to account for imported/exported/shared bo's)? But we already track cycles+time per submit for devfreq, it would be pretty easy to add per drm_file counters to accumulate the per-submit results. We could even track per-context (submitqueue) for processes that have more than a single context, although not sure if that is useful. Interesting tidbit is that the whole i915 work started from a customer request to expose just that (per context) in a form akin to getrusage(2). I think this kind of introspection capability is interesting but as it is driver specific territory it's only anecdotal for what this thread is concerned. And I think there is probably some room for shared helper to print parts other than the per-engine stats (and maybe memory stats, although even that could be a shared implementation for some drivers).. with a driver callback for the non-generic parts, ie. something like: drm_driver::show_client_stats(struct drm_file *, struct drm_printer *) but that can come later. If there is a tool somewhere that displays this info, that would be useful for testing my implementation. I have a patch to Intel specific intel_gpu_top (see https://patchwork.freedesktop.org/patch/468491/?series=98555=1). I'll have a look to see how much work would it be to extract common bits into a library and write a quick agnostic tool using it. Regards, Tvrtko
[PATCH] drm/amd/pm: remove useless if
Clean the following coccicheck warning: ./drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c:7035:2-4: WARNING: possible condition with no effect (if == else). Reported-by: Abaci Robot Signed-off-by: Jiapeng Chong --- drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c index 23ff0d812e4b..7427c50409d4 100644 --- a/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c +++ b/drivers/gpu/drm/amd/pm/legacy-dpm/si_dpm.c @@ -7032,10 +7032,7 @@ static int si_power_control_set_level(struct amdgpu_device *adev) ret = si_resume_smc(adev); if (ret) return ret; - ret = si_set_sw_state(adev); - if (ret) - return ret; - return 0; + return si_set_sw_state(adev); } static void si_set_vce_clock(struct amdgpu_device *adev, -- 2.20.1.7.g153144c
Re: [PATCH v5 0/5] drm: exynos: dsi: Convert drm bridge
Hi Marek, On Fri, Jan 21, 2022 at 5:06 PM Marek Szyprowski wrote: > > Hi, > > On 17.01.2022 09:42, Jagan Teki wrote: > > Updated series about drm bridge conversion of exynos dsi. > > > > Previous version can be accessible, here [1]. > > > > Patch 1: connector reset > > > > Patch 2: panel_bridge API > > > > Patch 3: bridge conversion > > > > Patch 4: atomic functions > > > > Patch 5: DSI init in pre_enable > > > > Apply below patches to test on Exynos DSI: > > - > > https://protect2.fireeye.com/v1/url?k=53bdf119-0c26c815-53bc7a56-000babff3563-792dc1a6b54db43e=1=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1825%2F > > - > > https://protect2.fireeye.com/v1/url?k=cb269ea3-94bda7af-cb2715ec-000babff3563-e6f545b4a32558ba=1=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1838%2F > > > > [1] > > https://protect2.fireeye.com/v1/url?k=ee1dae12-b186971e-ee1c255d-000babff3563-83eaf8e86e67e0d9=1=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fcover%2F1826%2F > > > > Any inputs? > > I've tried a few times, but I am unable to find what is the base for > this patchset. I always get a conflict around exynos_dsi_mode_set() > function. I've tried current linux-next, drm-next, v5.16-rc1 and v5.16. > It looks that I must have missed applying some patch before playing with > this. > > I've also tried to apply only the last patch, as if I got it right, it > is the only difference between v4 and v5 and updated 'drm: of: Lookup if > child node has panel or bridge'. In such case the board freezes during > the drm initialization. Please use drm-misc/drm-misc-next with below patches and then apply this series. - https://patchwork.amarulasolutions.com/patch/1825/ - https://patchwork.amarulasolutions.com/patch/1838/ Jagan.
Re: [PATCH v5 0/5] drm: exynos: dsi: Convert drm bridge
Hi, On 17.01.2022 09:42, Jagan Teki wrote: > Updated series about drm bridge conversion of exynos dsi. > > Previous version can be accessible, here [1]. > > Patch 1: connector reset > > Patch 2: panel_bridge API > > Patch 3: bridge conversion > > Patch 4: atomic functions > > Patch 5: DSI init in pre_enable > > Apply below patches to test on Exynos DSI: > - > https://protect2.fireeye.com/v1/url?k=53bdf119-0c26c815-53bc7a56-000babff3563-792dc1a6b54db43e=1=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1825%2F > - > https://protect2.fireeye.com/v1/url?k=cb269ea3-94bda7af-cb2715ec-000babff3563-e6f545b4a32558ba=1=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fpatch%2F1838%2F > > [1] > https://protect2.fireeye.com/v1/url?k=ee1dae12-b186971e-ee1c255d-000babff3563-83eaf8e86e67e0d9=1=9a4ea3ad-9e7d-443d-ad21-ce694a7cd352=https%3A%2F%2Fpatchwork.amarulasolutions.com%2Fcover%2F1826%2F > > Any inputs? I've tried a few times, but I am unable to find what is the base for this patchset. I always get a conflict around exynos_dsi_mode_set() function. I've tried current linux-next, drm-next, v5.16-rc1 and v5.16. It looks that I must have missed applying some patch before playing with this. I've also tried to apply only the last patch, as if I got it right, it is the only difference between v4 and v5 and updated 'drm: of: Lookup if child node has panel or bridge'. In such case the board freezes during the drm initialization. Best regards -- Marek Szyprowski, PhD Samsung R Institute Poland
Re: [Linaro-mm-sig] [PATCH 1/9] dma-buf: consolidate dma_fence subclass checking
Am 21.01.22 um 08:41 schrieb Thomas Hellström (Intel):
On 1/20/22 14:27, Christian König wrote:
Consolidate the wrapper functions to check for dma_fence
subclasses in the dma_fence header.
This makes it easier to document and also check the different
requirements for fence containers in the subclasses.
Signed-off-by: Christian König
---
include/linux/dma-fence-array.h | 15 +
include/linux/dma-fence-chain.h | 3 +--
include/linux/dma-fence.h | 38 +
3 files changed, 40 insertions(+), 16 deletions(-)
diff --git a/include/linux/dma-fence-array.h
b/include/linux/dma-fence-array.h
index 303dd712220f..fec374f69e12 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -45,19 +45,6 @@ struct dma_fence_array {
struct irq_work work;
};
-extern const struct dma_fence_ops dma_fence_array_ops;
-
-/**
- * dma_fence_is_array - check if a fence is from the array subsclass
- * @fence: fence to test
- *
- * Return true if it is a dma_fence_array and false otherwise.
- */
-static inline bool dma_fence_is_array(struct dma_fence *fence)
-{
- return fence->ops == _fence_array_ops;
-}
-
/**
* to_dma_fence_array - cast a fence to a dma_fence_array
* @fence: fence to cast to a dma_fence_array
@@ -68,7 +55,7 @@ static inline bool dma_fence_is_array(struct
dma_fence *fence)
static inline struct dma_fence_array *
to_dma_fence_array(struct dma_fence *fence)
{
- if (fence->ops != _fence_array_ops)
+ if (!fence || !dma_fence_is_array(fence))
return NULL;
return container_of(fence, struct dma_fence_array, base);
diff --git a/include/linux/dma-fence-chain.h
b/include/linux/dma-fence-chain.h
index 54fe3443fd2c..ee906b659694 100644
--- a/include/linux/dma-fence-chain.h
+++ b/include/linux/dma-fence-chain.h
@@ -49,7 +49,6 @@ struct dma_fence_chain {
spinlock_t lock;
};
-extern const struct dma_fence_ops dma_fence_chain_ops;
/**
* to_dma_fence_chain - cast a fence to a dma_fence_chain
@@ -61,7 +60,7 @@ extern const struct dma_fence_ops dma_fence_chain_ops;
static inline struct dma_fence_chain *
to_dma_fence_chain(struct dma_fence *fence)
{
- if (!fence || fence->ops != _fence_chain_ops)
+ if (!fence || !dma_fence_is_chain(fence))
return NULL;
return container_of(fence, struct dma_fence_chain, base);
diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
index 1ea691753bd3..775cdc0b4f24 100644
--- a/include/linux/dma-fence.h
+++ b/include/linux/dma-fence.h
@@ -587,4 +587,42 @@ struct dma_fence *dma_fence_get_stub(void);
struct dma_fence *dma_fence_allocate_private_stub(void);
u64 dma_fence_context_alloc(unsigned num);
+extern const struct dma_fence_ops dma_fence_array_ops;
+extern const struct dma_fence_ops dma_fence_chain_ops;
+
+/**
+ * dma_fence_is_array - check if a fence is from the array subclass
+ * @fence: the fence to test
+ *
+ * Return true if it is a dma_fence_array and false otherwise.
+ */
+static inline bool dma_fence_is_array(struct dma_fence *fence)
+{
+ return fence->ops == _fence_array_ops;
+}
+
+/**
+ * dma_fence_is_chain - check if a fence is from the chain subclass
+ * @fence: the fence to test
+ *
+ * Return true if it is a dma_fence_chain and false otherwise.
+ */
+static inline bool dma_fence_is_chain(struct dma_fence *fence)
+{
+ return fence->ops == _fence_chain_ops;
+}
+
+/**
+ * dma_fence_is_container - check if a fence is a container for
other fences
+ * @fence: the fence to test
+ *
+ * Return true if this fence is a container for other fences, false
otherwise.
+ * This is important since we can't build up large fence structure
or otherwise
+ * we run into recursion during operation on those fences.
+ */
+static inline bool dma_fence_is_container(struct dma_fence *fence)
+{
+ return dma_fence_is_array(fence) || dma_fence_is_chain(fence);
+}
What's the strategy here moving forward if we add more dma_resv
containers, or if a driver adds a container that similarly has risc of
recursion? Should we perhaps add an ops bool for this, or require that
all dma_resv containers that has this limitation be part of the
dma-buf subsystem rather than driver-specific?
Good question.
I think that all containers which also implement the dma_fence interface
should be part of the DMA-buf subsystem and not driver specific. Drivers
just tend to reinvent something incorrectly.
Where/How should we document that?
Regards,
Christian.
Thanks,
/Thomas
+
#endif /* __LINUX_DMA_FENCE_H */
[PATCH] drm/amd/display: Fix memory leak
[why]
Resource release is needed on the error handling path
to prevent memory leak.
[how]
Fix this by adding kfree on the error handling path.
Signed-off-by: Yongzhi Liu
---
.../drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 80 --
1 file changed, 60 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
index ded64d0..e463d46 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c
@@ -227,8 +227,10 @@ static ssize_t dp_link_settings_read(struct file *f, char
__user *buf,
break;
r = put_user(*(rd_buf + result), buf);
- if (r)
+ if (r) {
+ kfree(rd_buf);
return r; /* r = -EFAULT */
+ }
buf += 1;
size -= 1;
@@ -389,8 +391,10 @@ static ssize_t dp_phy_settings_read(struct file *f, char
__user *buf,
break;
r = put_user((*(rd_buf + result)), buf);
- if (r)
+ if (r) {
+ kfree(rd_buf);
return r; /* r = -EFAULT */
+ }
buf += 1;
size -= 1;
@@ -1359,8 +1363,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f, char
__user *buf,
break;
}
- if (!pipe_ctx)
+ if (!pipe_ctx) {
+ kfree(rd_buf);
return -ENXIO;
+ }
dsc = pipe_ctx->stream_res.dsc;
if (dsc)
@@ -1376,8 +1382,10 @@ static ssize_t dp_dsc_clock_en_read(struct file *f, char
__user *buf,
break;
r = put_user(*(rd_buf + result), buf);
- if (r)
+ if (r) {
+ kfree(rd_buf);
return r; /* r = -EFAULT */
+ }
buf += 1;
size -= 1;
@@ -1546,8 +1554,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
char __user *buf,
break;
}
- if (!pipe_ctx)
+ if (!pipe_ctx) {
+ kfree(rd_buf);
return -ENXIO;
+ }
dsc = pipe_ctx->stream_res.dsc;
if (dsc)
@@ -1563,8 +1573,10 @@ static ssize_t dp_dsc_slice_width_read(struct file *f,
char __user *buf,
break;
r = put_user(*(rd_buf + result), buf);
- if (r)
+ if (r) {
+ kfree(rd_buf);
return r; /* r = -EFAULT */
+ }
buf += 1;
size -= 1;
@@ -1731,8 +1743,10 @@ static ssize_t dp_dsc_slice_height_read(struct file *f,
char __user *buf,
break;
}
- if (!pipe_ctx)
+ if (!pipe_ctx) {
+ kfree(rd_buf);
return -ENXIO;
+ }
dsc = pipe_ctx->stream_res.dsc;
if (dsc)
@@ -1748,8 +1762,10 @@ static ssize_t dp_dsc_slice_height_read(struct file *f,
char __user *buf,
break;
r = put_user(*(rd_buf + result), buf);
- if (r)
+ if (r) {
+ kfree(rd_buf);
return r; /* r = -EFAULT */
+ }
buf += 1;
size -= 1;
@@ -1912,8 +1928,10 @@ static ssize_t dp_dsc_bits_per_pixel_read(struct file
*f, char __user *buf,
break;
}
- if (!pipe_ctx)
+ if (!pipe_ctx) {
+ kfree(rd_buf);
return -ENXIO;
+ }
dsc = pipe_ctx->stream_res.dsc;
if (dsc)
@@ -1929,8 +1947,10 @@ static ssize_t dp_dsc_bits_per_pixel_read(struct file
*f, char __user *buf,
break;
r = put_user(*(rd_buf + result), buf);
- if (r)
+ if (r) {
+ kfree(rd_buf);
return r; /* r = -EFAULT */
+ }
buf += 1;
size -= 1;
@@ -2088,8 +2108,10 @@ static ssize_t dp_dsc_pic_width_read(struct file *f,
char __user *buf,
break;
}
- if (!pipe_ctx)
+ if (!pipe_ctx) {
+ kfree(rd_buf);
return -ENXIO;
+ }
dsc = pipe_ctx->stream_res.dsc;
if (dsc)
@@ -2105,8 +2127,10 @@ static ssize_t dp_dsc_pic_width_read(struct file *f,
char __user *buf,
break;
r = put_user(*(rd_buf + result), buf);
- if (r)
+ if (r) {
+ kfree(rd_buf);
return r; /* r = -EFAULT */
+ }
buf += 1;
size
Re: [Linaro-mm-sig] [PATCH 2/9] dma-buf: warn about dma_fence_array container rules
Am 21.01.22 um 08:31 schrieb Thomas Hellström: On 1/20/22 14:27, Christian König wrote: It's not allowed to nest another dma_fence container into a dma_fence_array or otherwise we can run into recursion. Warn about that when we create a dma_fence_array. Signed-off-by: Christian König Reviewed-by: Daniel Vetter --- drivers/dma-buf/dma-fence-array.c | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index 3e07f961e2f3..4bfbcb885bbc 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -176,6 +176,19 @@ struct dma_fence_array *dma_fence_array_create(int num_fences, array->base.error = PENDING_ERROR; + /* dma_fence_array objects should never contain any other fence Nit: First comment line of multi-line comments shouldn't contain text. + * containers or otherwise we run into recursion and potential kernel + * stack overflow on operations on the dma_fence_array. + * + * The correct way of handling this is to flatten out the array by the + * caller instead. + * + * Enforce this here by checking that we don't create a dma_fence_array + * with any container inside. + */ + while (seqno--) + WARN_ON(dma_fence_is_container(fences[seqno])); + s/seqno/num_fences/g ? Ah, of course! Typing to fast. Thanks, Christian. Thanks, Thomas return array; } EXPORT_SYMBOL(dma_fence_array_create);
Re: linux-next: build warning after merge of the drm-misc tree
Hi Stepen,
On 1/20/22 04:18, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 15 Oct 2021 20:54:22 +1100 Stephen Rothwell
> wrote:
>>
>> After merging the drm-misc tree, today's linux-next build (htmldocs)
>> produced this warning:
>>
>> Documentation/gpu/drm-kms-helpers:451:
>> /home/sfr/next/next/drivers/gpu/drm/drm_privacy_screen.c:270: WARNING:
>> Inline emphasis start-string without end-string.
>>
>> Introduced by commit
>>
>> 8a12b170558a ("drm/privacy-screen: Add notifier support (v2)")
>
> I am still getting this warning.
Sorry I completely missed your original report on this between
all the other kernel related emails.
I'll prepare a fix for this coming Monday.
Regards,
Hans
Re: [PATCH v3 00/22] drm/rockchip: RK356x VOP2 support
Hi Piotr,
On Wed, Jan 19, 2022 at 12:29:49PM +0100, Piotr Oniszczuk wrote:
>
>
> > Wiadomość napisana przez Sascha Hauer w dniu
> > 20.12.2021, o godz. 12:06:
> >
> >
> > Third round of patches and last one for this year. I hopefully integrated
> > all review feedback. Additionally the driver is now fully converted to
> > regmap, so no struct vop_reg necessary anymore.
> >
> > Sascha
> >
> > Changes since v2:
> > - Add pin names to HDMI supply pin description
> > - Add hclk support to HDMI driver
> > - Dual license rockchip-vop2 binding, update binding
> > - Add HDMI connector to board dts files
> > - drop unnecessary gamma_lut registers from vop2
> > - Update dclk_vop[012] clock handling, no longer hacks needed
> > - Complete regmap conversion
> >
>
> Sascha
>
> I'm using you VOP2 code on rk3566 tvbox (x96-x6) with very good results.
>
> I have just few questions:
>
> 1. how support for CEC looks/prospects (plans for future, not in this code,
> expecting others should implement, etc)?
I had to google what CEC actually is. We don't have plans supporting it.
It looks like this is a matter of the HDMI driver supporting this and
not bound to the rockchip driver.
>
> 2. VOP2 code works nice for me for x11/glamour and for EGLFS with EGL DMAbuf
> rendering by Mesa EGL_LINUX_DMA_BUF_EXT.
> I have issue however with app. rendering to DRM planes (GUI is DRM plane1,
> video is DRM pane2).
> My ppp starts/works without any errors in log - but screen stays with kernel
> messages content.
> (it looks to me like i.e. app renders to DRM plane but DRM display driver not
> pass it to CRTC. just wild guess here...).
You enabled the panfrost driver with other patches, right?
>
> 3. in kernel dmesg I have many:
>
> "rockchip-drm display-subsystem: [drm] *ERROR* Unsupported format modifier
> 0x811".
This message is correct. This corresponds to
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED and the VOP2 driver doesn't
support this. I have a similar problem here with
weston-simple-dmabuf-egl. By default this uses DRM_FORMAT_XRGB
which ends up being PIPE_FORMAT_B8G8R8_UNORM in MESA. In
panfrost_afbc_format() we have:
/* Don't allow swizzled formats on v7 */
switch (format) {
case PIPE_FORMAT_B8G8R8A8_UNORM:
case PIPE_FORMAT_B8G8R8X8_UNORM:
case PIPE_FORMAT_A8R8G8B8_UNORM:
case PIPE_FORMAT_X8R8G8B8_UNORM:
case PIPE_FORMAT_X8B8G8R8_UNORM:
case PIPE_FORMAT_A8B8G8R8_UNORM:
case PIPE_FORMAT_B8G8R8_UNORM:
case PIPE_FORMAT_B5G6R5_UNORM:
if (dev->arch >= 7)
return PIPE_FORMAT_NONE;
break;
default:
break;
}
This means the driver won't do AFBC with that format and picks
DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED instead. Now weston is
clever enough to not pass that into the VOP2 driver, apparently your
application is not and as a result you see that message.
In weston-simple-dmabuf-egl I can pass a suitable format on the command
line, in my case I use DRM_FORMAT_ABGR (which becomes
PIPE_FORMAT_R8G8B8A8_UNORM). With this the panfrost driver does AFBC
which then can be rendered in the VOP2 cluster window overlay.
>
> It comes from MESA i think - but i suspect because VOP2 provides
> unknown/wrong DRM modifier to mesa?
Nope, the modifiers the VOP2 driver propagates are correct. It doesn't
claim to support DRM_FORMAT_MOD_ARM_16X16_BLOCK_U_INTERLEAVED.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [GIT PULL] fbdev updates & fixes for v5.17-rc1
On Fri, 21 Jan 2022, Helge Deller wrote: > On 1/21/22 10:19, Lee Jones wrote: > > On Fri, 21 Jan 2022, Jani Nikula wrote: > > > >> On Fri, 21 Jan 2022, Daniel Vetter wrote: > >>> On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote: > A first bunch of updates and fixes for the following fbdev & backlight > drivers: > ocfb, aty128fb, mb862xx, omapfb, qcom-wled, dt-bindings, hyperv_fb, > lm3630a_bl, omap2, controlfb, matroxfb > > Nothing really important, mostly cleanups, const conversions, added null > pointer/boundary checks and build fixes. > > Signed-off-by: Helge Deller > >>> > >>> Not sure whether Linus missed this or just wanted to let the > >>> discussion settle first. But since this is all random patches for > >>> drivers that many distros don't even enable anymore there's no issues > >>> here, and I very much welcome someone volunteering to pick these up. > >>> I'd expect there's a pile more since it's been 1-2 years since Bart > >>> took care of these and merged them consistently. > >>> > >>> Acked-by: Daniel Vetter > >> > >> ... > >> > drivers/video/backlight/lm3630a_bl.c | 1 - > drivers/video/backlight/qcom-wled.c | 1 + > >> > >> Backlight changes usually go through the backlight tree. > > Sorry, I didn't know yet. > > > Yes, they do. How were these applied to the DRM tree? > > I did applied them. When you apply patches, you should reply to let the contributor know. > Shall I drop them and you decide about them? No, there's no need for that. > Next I round I'll take care not to pick backlight patches. Thank you. -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [GIT PULL] fbdev updates & fixes for v5.17-rc1
On Fri, 21 Jan 2022, Daniel Vetter wrote: > On Fri, Jan 21, 2022 at 10:19 AM Lee Jones wrote: > > > > On Fri, 21 Jan 2022, Jani Nikula wrote: > > > > > On Fri, 21 Jan 2022, Daniel Vetter wrote: > > > > On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote: > > > >> A first bunch of updates and fixes for the following fbdev & backlight > > > >> drivers: > > > >> ocfb, aty128fb, mb862xx, omapfb, qcom-wled, dt-bindings, hyperv_fb, > > > >> lm3630a_bl, omap2, controlfb, matroxfb > > > >> > > > >> Nothing really important, mostly cleanups, const conversions, added > > > >> null > > > >> pointer/boundary checks and build fixes. > > > >> > > > >> Signed-off-by: Helge Deller > > > > > > > > Not sure whether Linus missed this or just wanted to let the > > > > discussion settle first. But since this is all random patches for > > > > drivers that many distros don't even enable anymore there's no issues > > > > here, and I very much welcome someone volunteering to pick these up. > > > > I'd expect there's a pile more since it's been 1-2 years since Bart > > > > took care of these and merged them consistently. > > > > > > > > Acked-by: Daniel Vetter > > > > > > ... > > > > > > >> drivers/video/backlight/lm3630a_bl.c | 1 - > > > >> drivers/video/backlight/qcom-wled.c | 1 + > > > > > > Backlight changes usually go through the backlight tree. > > > > Yes, they do. How were these applied to the DRM tree? > > They are not applied to any drm trees, Helge jumped in last week to > take over drivers/video maintainership. > -Daniel Sorry s/DRM/fbdev/ > > I don't see any mails about them being applied: > > > > Luca Weiss (2): > > backlight: qcom-wled: Add PM6150L compatible > > > > > > https://lore.kernel.org/all/20211229170358.2457006-2-luca.we...@fairphone.com/ > > > > Xu Wang (2): > > backlight: lm3630a_bl: Remove redundant 'flush_workqueue()' calls > > > > https://lore.kernel.org/all/20220113084806.13822-1-vu...@iscas.ac.cn/ > > > > > -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 1/1] drm: mxsfb: Use dev_err_probe() helper
Use the dev_err_probe() helper, instead of open-coding the same
operation. This also adds a nice hint in
/sys/kernel/debug/devices_deferred.
Signed-off-by: Alexander Stein
---
Based on next-20220120
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 86d78634a979..bc0d766d217b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -258,8 +258,7 @@ static int mxsfb_load(struct drm_device *drm,
ret = mxsfb_attach_bridge(mxsfb);
if (ret) {
- if (ret != -EPROBE_DEFER)
- dev_err(drm->dev, "Cannot connect bridge: %d\n", ret);
+ dev_err_probe(drm->dev, ret, "Cannot connect bridge\n");
goto err_vblank;
}
--
2.25.1
[PATCH] drm/exynos: Don't fail if no TE-gpio is defined for DSI driver
TE-gpio is optional and if it is not found then gpiod_get_optional()
returns NULL. In such case the code will continue and try to convert NULL
gpiod to irq what in turn fails. The failure is then propagated and driver
is not registered.
Fix this by returning early from exynos_dsi_register_te_irq() if no
TE-gpio is found.
Fixes: ee6c8b5afa62 ("drm/exynos: Replace legacy gpio interface for gpiod
interface")
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 32a36572b894..14ebbb124852 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1335,7 +1335,9 @@ static int exynos_dsi_register_te_irq(struct exynos_dsi
*dsi,
int te_gpio_irq;
dsi->te_gpio = devm_gpiod_get_optional(dsi->dev, "te", GPIOD_IN);
- if (IS_ERR(dsi->te_gpio)) {
+ if (!dsi->te_gpio) {
+ return 0;
+ } else if (IS_ERR(dsi->te_gpio)) {
dev_err(dsi->dev, "gpio request failed with %ld\n",
PTR_ERR(dsi->te_gpio));
return PTR_ERR(dsi->te_gpio);
--
2.17.1
Re: [GIT PULL] fbdev updates & fixes for v5.17-rc1
On 1/21/22 10:19, Lee Jones wrote: > On Fri, 21 Jan 2022, Jani Nikula wrote: > >> On Fri, 21 Jan 2022, Daniel Vetter wrote: >>> On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote: A first bunch of updates and fixes for the following fbdev & backlight drivers: ocfb, aty128fb, mb862xx, omapfb, qcom-wled, dt-bindings, hyperv_fb, lm3630a_bl, omap2, controlfb, matroxfb Nothing really important, mostly cleanups, const conversions, added null pointer/boundary checks and build fixes. Signed-off-by: Helge Deller >>> >>> Not sure whether Linus missed this or just wanted to let the >>> discussion settle first. But since this is all random patches for >>> drivers that many distros don't even enable anymore there's no issues >>> here, and I very much welcome someone volunteering to pick these up. >>> I'd expect there's a pile more since it's been 1-2 years since Bart >>> took care of these and merged them consistently. >>> >>> Acked-by: Daniel Vetter >> >> ... >> drivers/video/backlight/lm3630a_bl.c | 1 - drivers/video/backlight/qcom-wled.c | 1 + >> >> Backlight changes usually go through the backlight tree. Sorry, I didn't know yet. > Yes, they do. How were these applied to the DRM tree? I did applied them. Shall I drop them and you decide about them? Next I round I'll take care not to pick backlight patches. Helge > I don't see any mails about them being applied: > > Luca Weiss (2): > backlight: qcom-wled: Add PM6150L compatible > > > https://lore.kernel.org/all/20211229170358.2457006-2-luca.we...@fairphone.com/ > > Xu Wang (2): > backlight: lm3630a_bl: Remove redundant 'flush_workqueue()' calls > > https://lore.kernel.org/all/20220113084806.13822-1-vu...@iscas.ac.cn/ >
Re: [GIT PULL] fbdev updates & fixes for v5.17-rc1
On Fri, Jan 21, 2022 at 10:19 AM Lee Jones wrote: > > On Fri, 21 Jan 2022, Jani Nikula wrote: > > > On Fri, 21 Jan 2022, Daniel Vetter wrote: > > > On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote: > > >> A first bunch of updates and fixes for the following fbdev & backlight > > >> drivers: > > >> ocfb, aty128fb, mb862xx, omapfb, qcom-wled, dt-bindings, hyperv_fb, > > >> lm3630a_bl, omap2, controlfb, matroxfb > > >> > > >> Nothing really important, mostly cleanups, const conversions, added null > > >> pointer/boundary checks and build fixes. > > >> > > >> Signed-off-by: Helge Deller > > > > > > Not sure whether Linus missed this or just wanted to let the > > > discussion settle first. But since this is all random patches for > > > drivers that many distros don't even enable anymore there's no issues > > > here, and I very much welcome someone volunteering to pick these up. > > > I'd expect there's a pile more since it's been 1-2 years since Bart > > > took care of these and merged them consistently. > > > > > > Acked-by: Daniel Vetter > > > > ... > > > > >> drivers/video/backlight/lm3630a_bl.c | 1 - > > >> drivers/video/backlight/qcom-wled.c | 1 + > > > > Backlight changes usually go through the backlight tree. > > Yes, they do. How were these applied to the DRM tree? They are not applied to any drm trees, Helge jumped in last week to take over drivers/video maintainership. -Daniel > > I don't see any mails about them being applied: > > Luca Weiss (2): > backlight: qcom-wled: Add PM6150L compatible > > > https://lore.kernel.org/all/20211229170358.2457006-2-luca.we...@fairphone.com/ > > Xu Wang (2): > backlight: lm3630a_bl: Remove redundant 'flush_workqueue()' calls > > https://lore.kernel.org/all/20220113084806.13822-1-vu...@iscas.ac.cn/ > > -- > Lee Jones [李琼斯] > Principal Technical Lead - Developer Services > Linaro.org │ Open source software for Arm SoCs > Follow Linaro: Facebook | Twitter | Blog -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[Bug 215511] New: Dual monitor with amd 5700 causes system to hang at startup.
https://bugzilla.kernel.org/show_bug.cgi?id=215511 Bug ID: 215511 Summary: Dual monitor with amd 5700 causes system to hang at startup. Product: Drivers Version: 2.5 Kernel Version: 5.16.1 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: pmes...@gmail.com Regression: No Created attachment 300294 --> https://bugzilla.kernel.org/attachment.cgi?id=300294=edit dual monitor boot crash with amdgpu card. Hello, system mostly crashes (sometimes in different ways) when i start with more than one monitor attached. If i switch off one monitor then system boots correctly (i don't need to detach the displayport cable, just to switch off the monitor). When both monitors are connected, most of the times it just crashes as the attached log, sometimes it boots but screen is flickering and with artifacts. This happened with kernel 5.10 and 5.11, it was fixed i don't remember exactly when, and is happening again. For me it worked with kernel 5.15.8 and failed with 5.15.13. It is still failing with 5.16.1. Kind regards and many thanks for your work in the most crucial open-source project. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
Re: [PATCH] drm: Update docs after moving DisplayPort helpers around
On Thu, 20 Jan 2022, Thomas Zimmermann wrote:
> DRM's DisplayPort helpers moved into the subdirectory dp/. Change
> the documentation accordingly.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: adb9d5a2cc77 ("drm/dp: Move DisplayPort helpers into separate helper
> module")
> Reported-by: Jani Nikula
> Cc: Thomas Zimmermann
> Cc: Lyude Paul
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: dri-devel@lists.freedesktop.org
Thanks.
Tested-by: Jani Nikula
I didn't actually check the generated html, but the errors are gone. ;)
> ---
> Documentation/gpu/drm-kms-helpers.rst | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst
> b/Documentation/gpu/drm-kms-helpers.rst
> index 5bb55ec1b9b5..c3ce91eecbc1 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -232,34 +232,34 @@ HDCP Helper Functions Reference
> Display Port Helper Functions Reference
> ===
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c
> :doc: dp helpers
>
> -.. kernel-doc:: include/drm/drm_dp_helper.h
> +.. kernel-doc:: include/drm/dp/drm_dp_helper.h
> :internal:
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c
> :export:
>
> Display Port CEC Helper Functions Reference
> ===
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c
> :doc: dp cec helpers
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c
> :export:
>
> Display Port Dual Mode Adaptor Helper Functions Reference
> =
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c
> :doc: dp dual mode helpers
>
> -.. kernel-doc:: include/drm/drm_dp_dual_mode_helper.h
> +.. kernel-doc:: include/drm/dp/drm_dp_dual_mode_helper.h
> :internal:
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_dual_mode_helper.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c
> :export:
>
> Display Port MST Helpers
> @@ -268,19 +268,19 @@ Display Port MST Helpers
> Overview
>
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c
> :doc: dp mst helper
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c
> :doc: Branch device and port refcounting
>
> Functions Reference
> ---
>
> -.. kernel-doc:: include/drm/drm_dp_mst_helper.h
> +.. kernel-doc:: include/drm/dp/drm_dp_mst_helper.h
> :internal:
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c
> :export:
>
> Topology Lifetime Internals
> @@ -289,7 +289,7 @@ Topology Lifetime Internals
> These functions aren't exported to drivers, but are documented here to help
> make
> the MST topology helpers easier to understand
>
> -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c
> +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c
> :functions: drm_dp_mst_topology_try_get_mstb drm_dp_mst_topology_get_mstb
> drm_dp_mst_topology_put_mstb
> drm_dp_mst_topology_try_get_port drm_dp_mst_topology_get_port
--
Jani Nikula, Intel Open Source Graphics Center
Re: [GIT PULL] fbdev updates & fixes for v5.17-rc1
On Fri, 21 Jan 2022, Jani Nikula wrote: > On Fri, 21 Jan 2022, Daniel Vetter wrote: > > On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote: > >> A first bunch of updates and fixes for the following fbdev & backlight > >> drivers: > >> ocfb, aty128fb, mb862xx, omapfb, qcom-wled, dt-bindings, hyperv_fb, > >> lm3630a_bl, omap2, controlfb, matroxfb > >> > >> Nothing really important, mostly cleanups, const conversions, added null > >> pointer/boundary checks and build fixes. > >> > >> Signed-off-by: Helge Deller > > > > Not sure whether Linus missed this or just wanted to let the > > discussion settle first. But since this is all random patches for > > drivers that many distros don't even enable anymore there's no issues > > here, and I very much welcome someone volunteering to pick these up. > > I'd expect there's a pile more since it's been 1-2 years since Bart > > took care of these and merged them consistently. > > > > Acked-by: Daniel Vetter > > ... > > >> drivers/video/backlight/lm3630a_bl.c | 1 - > >> drivers/video/backlight/qcom-wled.c | 1 + > > Backlight changes usually go through the backlight tree. Yes, they do. How were these applied to the DRM tree? I don't see any mails about them being applied: Luca Weiss (2): backlight: qcom-wled: Add PM6150L compatible https://lore.kernel.org/all/20211229170358.2457006-2-luca.we...@fairphone.com/ Xu Wang (2): backlight: lm3630a_bl: Remove redundant 'flush_workqueue()' calls https://lore.kernel.org/all/20220113084806.13822-1-vu...@iscas.ac.cn/ -- Lee Jones [李琼斯] Principal Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [RFC PATCH] drm: allow passing a real encoder object for wb connector
On Thu, 20 Jan 2022, Abhinav Kumar wrote:
> Instead of creating an internal encoder for the writeback
> connector to satisfy DRM requirements, allow the clients
> to pass a real encoder to it by changing the drm_writeback's
> encoder to a pointer.
>
> If a real encoder is not passed, drm_writeback_connector_init
> will internally allocate one.
>
> This will help the clients to manage the real encoder states
> better as they will allocate and maintain the encoder.
See also the thread starting at [1], and please try to coordinate.
I don't know what the end result should be like, I'm just saying please
collaborate instead of racing to get one set of changes in.
BR,
Jani.
[1]
https://patchwork.freedesktop.org/patch/msgid/2022001801.28310-1-suraj.kand...@intel.com
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/drm_writeback.c | 11 +++
> include/drm/drm_writeback.h | 2 +-
> 2 files changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
> index dccf4504..fdb7381 100644
> --- a/drivers/gpu/drm/drm_writeback.c
> +++ b/drivers/gpu/drm/drm_writeback.c
> @@ -189,8 +189,11 @@ int drm_writeback_connector_init(struct drm_device *dev,
> if (IS_ERR(blob))
> return PTR_ERR(blob);
>
> - drm_encoder_helper_add(_connector->encoder, enc_helper_funcs);
> - ret = drm_encoder_init(dev, _connector->encoder,
> + /* allocate the internal drm encoder if a real one wasnt passed */
> + if (!wb_connector->encoder)
> + wb_connector->encoder = devm_kzalloc(dev->dev, sizeof(struct
> drm_encoder), GFP_KERNEL);
> + drm_encoder_helper_add(wb_connector->encoder, enc_helper_funcs);
> + ret = drm_encoder_init(dev, wb_connector->encoder,
> _writeback_encoder_funcs,
> DRM_MODE_ENCODER_VIRTUAL, NULL);
> if (ret)
> @@ -204,7 +207,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> goto connector_fail;
>
> ret = drm_connector_attach_encoder(connector,
> - _connector->encoder);
> + wb_connector->encoder);
> if (ret)
> goto attach_fail;
>
> @@ -233,7 +236,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
> attach_fail:
> drm_connector_cleanup(connector);
> connector_fail:
> - drm_encoder_cleanup(_connector->encoder);
> + drm_encoder_cleanup(wb_connector->encoder);
> fail:
> drm_property_blob_put(blob);
> return ret;
> diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
> index 9697d27..f0d8147 100644
> --- a/include/drm/drm_writeback.h
> +++ b/include/drm/drm_writeback.h
> @@ -31,7 +31,7 @@ struct drm_writeback_connector {
>* by passing the @enc_funcs parameter to drm_writeback_connector_init()
>* function.
>*/
> - struct drm_encoder encoder;
> + struct drm_encoder *encoder;
>
> /**
>* @pixel_formats_blob_ptr:
--
Jani Nikula, Intel Open Source Graphics Center
Re: [GIT PULL] fbdev updates & fixes for v5.17-rc1
On Fri, 21 Jan 2022, Daniel Vetter wrote: > On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote: >> A first bunch of updates and fixes for the following fbdev & backlight >> drivers: >> ocfb, aty128fb, mb862xx, omapfb, qcom-wled, dt-bindings, hyperv_fb, >> lm3630a_bl, omap2, controlfb, matroxfb >> >> Nothing really important, mostly cleanups, const conversions, added null >> pointer/boundary checks and build fixes. >> >> Signed-off-by: Helge Deller > > Not sure whether Linus missed this or just wanted to let the > discussion settle first. But since this is all random patches for > drivers that many distros don't even enable anymore there's no issues > here, and I very much welcome someone volunteering to pick these up. > I'd expect there's a pile more since it's been 1-2 years since Bart > took care of these and merged them consistently. > > Acked-by: Daniel Vetter ... >> drivers/video/backlight/lm3630a_bl.c | 1 - >> drivers/video/backlight/qcom-wled.c | 1 + Backlight changes usually go through the backlight tree. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
On Fri, Jan 21, 2022 at 9:46 AM Gerd Hoffmann wrote: > > Hi, > > > What I still don't understand: why are you so keen on maintaining an > > interface that only serves the console? Nothing else uses fbdev these days. > > Why not improve DRM/userspace to the point where it fits your requirements? > > Long-term, the latter would make a lot more sense. > > And note that it is *much* easier to write drm drivers these days. > We got alot of helpers, we got generic fbdev emulation and more. > > If you are curious just compare the initial commit of the bochs drm > driver with the current code. Initially the driver had to manage ttm > and fbdev and whatnot else. These days writing a (non-accelerated) drm > driver is basically some boilerplate picking the helpers which work best > for your hardware, the code to actually program the hardware and that's > it. > > The "new drivers should be drm" policy exists for years already btw, > exactly because of the unfixable fbdev API limitations. The bochs drm > was a fbdev driver initially. Never merged. Got rewritten as drm > driver and that was merged instead. In 2013, almost a decade ago. > > And, yes, it very well might be that drm misses some piece here and > there for specific hardware, such as fbdev emulation not supporting > rgb332. But I fully agree with Thomas here: Improving drm is probably > a much better way to spend your time. drm is where the development > happens. fbdev is only kept alive. Just to clarify, since we had lots of smaller and bigger misunderstandings in the thread thus far: DRM_FORMAT_RGB332 exists, so drm support that already. The fbdev emulation doesn't yet, but all that's needed for that is filling out the code to remap the drm description to the fbdev format description for this case. Plus testing it all works ofc with fbcon and whatelse. Note that RGB332 is a bit more work than e.g. C4, since atm fbdev still uses only bpp to identify formats, so would need to be switch over to drm_fourcc first before adding anything which aliases with something existing (we have C8 already wired up). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [GIT PULL] fbdev updates & fixes for v5.17-rc1
On Wed, Jan 19, 2022 at 5:02 PM Helge Deller wrote: > > The following changes since commit 0c947b893d69231a9add855939da7c66237ab44f: > > Merge tag '5.17-rc-part1-smb3-fixes' of > git://git.samba.org/sfrench/cifs-2.6 (2022-01-17 09:53:21 +0200) > > are available in the Git repository at: > > http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git > tags/fbdev-5.17-2 > > for you to fetch changes up to 842086bc7262a36f002e0361f9dc351556cae3f3: > > video: fbdev: controlfb: Fix COMPILE_TEST build (2022-01-17 22:39:37 +0100) > > > fbdev updates for v5.17-rc1 > > A first bunch of updates and fixes for the following fbdev & backlight > drivers: > ocfb, aty128fb, mb862xx, omapfb, qcom-wled, dt-bindings, hyperv_fb, > lm3630a_bl, omap2, controlfb, matroxfb > > Nothing really important, mostly cleanups, const conversions, added null > pointer/boundary checks and build fixes. > > Signed-off-by: Helge Deller Not sure whether Linus missed this or just wanted to let the discussion settle first. But since this is all random patches for drivers that many distros don't even enable anymore there's no issues here, and I very much welcome someone volunteering to pick these up. I'd expect there's a pile more since it's been 1-2 years since Bart took care of these and merged them consistently. Acked-by: Daniel Vetter Cheers, Daniel > > > Chunyang Zhong (1): > video: ocfb: add const to of_device_id > > Colin Ian King (2): > fbdev: aty128fb: make some arrays static const > video: fbdev: mb862xx: remove redundant assignment to pointer ptr > > Greg Kroah-Hartman (1): > omapfb: use default_groups in kobj_type > > Jiasheng Jiang (1): > video: fbdev: Check for null res pointer > > Luca Weiss (2): > backlight: qcom-wled: Add PM6150L compatible > dt-bindings: simple-framebuffer: allow standalone compatible > > Michael Kelley (1): > video: hyperv_fb: Fix validation of screen resolution > > Minghao Chi (1): > drivers/video: remove redundant res variable > > Xu Wang (2): > backlight: lm3630a_bl: Remove redundant 'flush_workqueue()' calls > fbdev: omap2: omapfb: Remove redundant 'flush_workqueue()' calls > > Yang Guang (1): > video: fbdev: use swap() to make code cleaner > > YueHaibing (1): > video: fbdev: controlfb: Fix COMPILE_TEST build > > Z. Liu (1): > matroxfb: set maxvram of vbG200eW to the same as vbG200 to avoid black > screen > > .../devicetree/bindings/display/simple-framebuffer.yaml | 12 +++- > drivers/video/backlight/lm3630a_bl.c | 1 - > drivers/video/backlight/qcom-wled.c | 1 + > drivers/video/fbdev/aty/aty128fb.c | 10 ++ > drivers/video/fbdev/aty/mach64_ct.c | 4 +--- > drivers/video/fbdev/controlfb.c | 2 ++ > drivers/video/fbdev/hyperv_fb.c | 16 > +++- > drivers/video/fbdev/imxfb.c | 2 ++ > drivers/video/fbdev/matrox/matroxfb_base.c | 2 +- > drivers/video/fbdev/mb862xx/mb862xxfb_accel.c| 2 +- > drivers/video/fbdev/ocfb.c | 2 +- > drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c | 3 ++- > drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c | 3 ++- > drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c | 3 ++- > drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 1 - > drivers/video/fbdev/sis/sis_main.c | 2 +- > 16 files changed, 32 insertions(+), 34 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer
Hi, > What I still don't understand: why are you so keen on maintaining an > interface that only serves the console? Nothing else uses fbdev these days. > Why not improve DRM/userspace to the point where it fits your requirements? > Long-term, the latter would make a lot more sense. And note that it is *much* easier to write drm drivers these days. We got alot of helpers, we got generic fbdev emulation and more. If you are curious just compare the initial commit of the bochs drm driver with the current code. Initially the driver had to manage ttm and fbdev and whatnot else. These days writing a (non-accelerated) drm driver is basically some boilerplate picking the helpers which work best for your hardware, the code to actually program the hardware and that's it. The "new drivers should be drm" policy exists for years already btw, exactly because of the unfixable fbdev API limitations. The bochs drm was a fbdev driver initially. Never merged. Got rewritten as drm driver and that was merged instead. In 2013, almost a decade ago. And, yes, it very well might be that drm misses some piece here and there for specific hardware, such as fbdev emulation not supporting rgb332. But I fully agree with Thomas here: Improving drm is probably a much better way to spend your time. drm is where the development happens. fbdev is only kept alive. take care, Gerd
