dri-devel June 2022

dri-devel@lists.freedesktop.org

332 participants
697 discussions

Re: [PATCH v3 00/14] Driver of Intel(R) Gaussian & Neural Accelerator
by maciej.kwapulinski＠linux.intel.com 20 Jun '22

20 Jun '22

On Wed, 16 Jun 2021 09:38:14 +0200, Maciej Kwapulinski wrote: > after consulting, we will try to share api and some kernel code > between the two drivers. We prepared a prototype work based on Daniel Vetter’s invitation to evaluate DRM framework as prospective fit. Early results look quite promising. Effective leverage of DRM framework for non GPU driver has been achieved. GNA driver source code turned out to have been simplified by offloading some areas (device management + memory regions management). As a result, GNA driver source code size has been reduced by 15% (420 lines). DRM Framework complexity has not been an issue so far. Plan for next step is to publish code to dri-devel ML. Please share your thoughts. Regards, Maciej

3 3

DRM FB interface does not sanitize len when mmap'ed
by Nuno Gonçalves 20 Jun '22

20 Jun '22

I am crashing the kernel by doing something I believe I am allowed to do. Using mmap to write to /dev/fb0 as the compatibility layer for Tiny DRM vot,v220hf01a-t (ili9225). First it happens that because of the display resolution of 220*176 the buffer is (16 bit) 77440 bytes, which is not a multiple of the page size (4096), unlike most regular resolution displays. When I touch the mmap'ed virtual address above base+73728 (4096*18) up to 77439: auto file = open("/dev/fb0", O_RDWR); if (!file) throw; auto fbp = (char *)mmap(0, 220 * 176 * 2, PROT_READ | PROT_WRITE, MAP_SHARED, file, 0); if ((size_t)fbp <= 0) throw; fbp[220 * 176 * 2 - 2] = 0; I get a crash: [ 14.150463] Unable to handle kernel paging request at virtual address ffffffc00827c000 [ 14.158640] Mem abort info: [ 14.161626] ESR = 0x96000007 [ 14.164969] EC = 0x25: DABT (current EL), IL = 32 bits [ 14.170470] SET = 0, FnV = 0 [ 14.173735] EA = 0, S1PTW = 0 [ 14.177047] FSC = 0x07: level 3 translation fault [ 14.182095] Data abort info: [ 14.185083] ISV = 0, ISS = 0x00000007 [ 14.189035] CM = 0, WnR = 0 [ 14.192107] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000000d54000 [ 14.198997] [ffffffc00827c000] pgd=1000000001501003, p4d=1000000001501003, pud=1000000001501003, pmd=1000000001d5c003, pte=0000000000000000 [ 14.211992] Internal error: Oops: 96000007 [#1] PREEMPT SMP [ 14.217659] CPU: 0 PID: 50 Comm: kworker/0:2 Not tainted 5.18.3 #18 [ 14.224027] Hardware name: Raspberry Pi Compute Module 3 Plus Rev 1.0 (DT) [ 14.231005] Workqueue: events drm_fb_helper_damage_work [ 14.236333] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 14.243405] pc : __memcpy+0x15c/0x230 [ 14.247131] lr : drm_fb_helper_damage_work+0x25c/0x310 [ 14.252352] sp : ffffffc00822bd30 [ 14.255712] x29: ffffffc00822bd30 x28: 00000000000001b8 x27: ffffff80017e1d10 [ 14.262970] x26: ffffffc008267e80 x25: 00000000000000b0 x24: ffffff8002416800 [ 14.270228] x23: ffffff8001fd8080 x22: ffffff80017e1c00 x21: ffffff80017e1ccc [ 14.277487] x20: ffffffc00827be80 x19: ffffff80017e1cd0 x18: ffffffe5d80bac08 [ 14.284745] x17: 0000000000000013 x16: 000000fe72080e00 x15: 0000000000000000 [ 14.292003] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 [ 14.299259] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 14.306517] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 14.313772] x5 : ffffffc008268038 x4 : ffffffc00827c038 x3 : ffffffc008267fc0 [ 14.321029] x2 : 0000000000000028 x1 : ffffffc00827bfc0 x0 : ffffffc008267e80 [ 14.328288] Call trace: [ 14.330766] __memcpy+0x15c/0x230 [ 14.334135] process_one_work+0x1dc/0x450 [ 14.338214] worker_thread+0x300/0x450 [ 14.342025] kthread+0x100/0x110 [ 14.345305] ret_from_fork+0x10/0x20 [ 14.348947] Code: a9422428 a9032c6a a9432c2a a984346c (a9c4342c) [ 14.355132] ---[ end trace 0000000000000000 ]--- By constraining the input with this small patch it works fine: --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -684,11 +684,13 @@ static void drm_fb_helper_damage(struct fb_info *info, u32 x, u32 y, static void drm_fb_helper_memory_range_to_clip(struct fb_info *info, off_t off, size_t len, struct drm_rect *clip) { + struct drm_fb_helper *fb_helper = info->par; + off_t end = off + len; u32 x1 = 0; u32 y1 = off / info->fix.line_length; u32 x2 = info->var.xres; - u32 y2 = DIV_ROUND_UP(end, info->fix.line_length); + u32 y2 = min_t(u32, DIV_ROUND_UP(end, info->fix.line_length), fb_helper->fb->height); if ((y2 - y1) == 1) { /* I am sure this patch is not how it should be fixed, but I have no knowledge of the subsystem to fix it "at the right place". Thanks, Nuno

2 3

radeon driver warning
by John Garry 20 Jun '22

20 Jun '22

Hi guys, This warning in the radeon driver breaks my randconfig build on v5.19-rc2: drivers/gpu/drm/radeon/radeon_object.c:186:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [;;https://gcc.gnu.org/onl inedocs/gcc/Warning-Options.html#index-Wcpp-Werror=cpp;;] Is anything being done to fix it? I don't see anything in -next or on dridevel list recently which it could be. thanks, John

3 8

[PATCH v2 0/3] drm/msm/hdmi: turn MSM8996 HDMI PHY into OF clock provider
by Dmitry Baryshkov 20 Jun '22

20 Jun '22

On MSM8996 the HDMI PHY is the QMP PHY, it provides an HDMI PLL clock used by the MMCC. Add support for providing this clock to the OF framework by registerding the clock provider and adding #clock-cells property to the DT node. Changes since v1: - Also handle the xo clock (include it into the dtsi, use parent_data instead of parent_names). The patches were changed, so I didn't pick up the R-b tags. Dmitry Baryshkov (3): dt-bindings: phy: qcom,hdmi-phy-qmp: add clock-cells and XO clock drm/msm/hdmi: make hdmi_phy_8996 OF clk provider arm64: dts: qcom: msm8996: add #clock-cells and XO clock to the HDMI PHY node .../bindings/phy/qcom,hdmi-phy-qmp.yaml | 14 ++++++++--- arch/arm64/boot/dts/qcom/msm8996.dtsi | 8 ++++-- drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 25 +++++++++++-------- 3 files changed, 31 insertions(+), 16 deletions(-) -- 2.35.1

2 5

[PATCH, v2] media: mediatek: vcodec: Initialize decoder parameters after getting dec_capability
by Yunfei Dong 20 Jun '22

20 Jun '22

Need to get dec_capability from scp first, then initialize decoder supported format and other parameters according to dec_capability value. Fixes: fd00d90330d1 ("media: mtk-vcodec: vdec: move stateful ops into their own file") Signed-off-by: Yunfei Dong <yunfei.dong(a)mediatek.com> Tested-by: Chen-Yu Tsai <wenst(a)chromium.org> --- compared witch v1: - add Fixes lables --- drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c | 2 -- drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c index 1465ddff1c6b..41589470da32 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c @@ -112,8 +112,6 @@ void mtk_vcodec_dec_set_default_params(struct mtk_vcodec_ctx *ctx) { struct mtk_q_data *q_data; - ctx->dev->vdec_pdata->init_vdec_params(ctx); - ctx->m2m_ctx->q_lock = &ctx->dev->dev_mutex; ctx->fh.m2m_ctx = ctx->m2m_ctx; ctx->fh.ctrl_handler = &ctx->ctrl_hdl; diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c index 4103d7c1b638..99d7b15f2b9d 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c @@ -208,6 +208,8 @@ static int fops_vcodec_open(struct file *file) dev->dec_capability = mtk_vcodec_fw_get_vdec_capa(dev->fw_handler); + ctx->dev->vdec_pdata->init_vdec_params(ctx); + mtk_v4l2_debug(0, "decoder capability %x", dev->dec_capability); } -- 2.25.1

3 2

[PATCH] drm/radeon: Add build directory to include path
by Michel Dänzer 20 Jun '22

20 Jun '22

From: Michel Dänzer <mdaenzer(a)redhat.com> Fixes compile errors with out-of-tree builds, e.g. ../drivers/gpu/drm/radeon/r420.c:38:10: fatal error: r420_reg_safe.h: No such file or directory 38 | #include "r420_reg_safe.h" | ^~~~~~~~~~~~~~~~~ Signed-off-by: Michel Dänzer <mdaenzer(a)redhat.com> --- drivers/gpu/drm/radeon/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile index 11c97edde54d..37caf5236048 100644 --- a/drivers/gpu/drm/radeon/Makefile +++ b/drivers/gpu/drm/radeon/Makefile @@ -3,6 +3,8 @@ # Makefile for the drm device driver. This driver provides support for the # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. +ccflags-y += -I$(src) + hostprogs := mkregtable targets := rn50_reg_safe.h r100_reg_safe.h r200_reg_safe.h rv515_reg_safe.h r300_reg_safe.h r420_reg_safe.h rs600_reg_safe.h r600_reg_safe.h evergreen_reg_safe.h cayman_reg_safe.h -- 2.35.1

6 12

[PATCH v2 0/1] Drop wbinvd_on_all_cpus usage
by Michael Cheng 20 Jun '22

20 Jun '22

To align with the discussion in [1][2], this patch series drops all usage of wbvind_on_all_cpus within i915 by either replacing the call with certain drm clflush helpers, or reverting to a previous logic. [1]. https://lists.freedesktop.org/archives/dri-devel/2021-November/330928.html [2]. https://patchwork.freedesktop.org/patch/475752/?series=99991&rev=5 v2 (Michael Cheng) : Per feedback from Thomas and Tvrtko, this series should be split into two parts; First part is to unblock i915 from build errors and second part will focus on implementing range flushes on the propose reverts. Michael Cheng (1): i915/gem: drop wbinvd_on_all_cpus usage drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) -- 2.25.1

3 3

[PATCH, v2] media: mediatek: vcodec: Fix non subdev architecture open power fail
by Yunfei Dong 20 Jun '22

20 Jun '22

According to subdev_bitmap bit value to open hardware power, need to set subdev_bitmap value for non subdev architecture. Fixes: c05bada35f01 ("media: mtk-vcodec: Add to support multi hardware decode") Signed-off-by: Yunfei Dong <yunfei.dong(a)mediatek.com> --- compare with v1: - add "Fixes" label --- drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c index 995e6e2fb1ab..4103d7c1b638 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec_drv.c @@ -386,6 +386,8 @@ static int mtk_vcodec_probe(struct platform_device *pdev) mtk_v4l2_err("Main device of_platform_populate failed."); goto err_reg_cont; } + } else { + set_bit(MTK_VDEC_CORE, dev->subdev_bitmap); } ret = video_register_device(vfd_dec, VFL_TYPE_VIDEO, -1); -- 2.18.0

2 1

Re: [RFT][PATCH v1 6/6] vfio: Replace phys_pfn with phys_page for vfio_pin_pages()
by Jason Gunthorpe 20 Jun '22

20 Jun '22

On Fri, Jun 17, 2022 at 01:54:05AM -0700, Christoph Hellwig wrote: > There is a bunch of code an comments in the iommu type1 code that > suggest we can pin memory that is not page backed. AFAIK you can.. The whole follow_pte() mechanism allows raw PFNs to be loaded into the type1 maps and the pin API will happily return them. This happens in almost every qemu scenario because PCI MMIO BAR memory ends up routed down this path. Thanks, Jason

1 0

Re: [RFT][PATCH v1 5/6] vfio/ccw: Add kmap_local_page() for memcpy
by Jason Gunthorpe 20 Jun '22

20 Jun '22

On Fri, Jun 17, 2022 at 01:44:30AM -0700, Christoph Hellwig wrote: > On Thu, Jun 16, 2022 at 04:52:11PM -0700, Nicolin Chen wrote: > > The pinned PFN list returned from vfio_pin_pages() is simply converted > > using page_to_pfn() without protection, so direct access via memcpy() > > will crash on S390 if the PFN is an IO PFN. Instead, the pages should > > be touched using kmap_local_page(). > > I don't see how this helps. kmap_local_page only works for either > pages in the kernel direct map or highmem, but not for memory that needs > to be ioremapped. And there is no highmem on s390. The remark about io memory is because on s390 memcpy() will crash even on ioremapped memory, you have to use the memcpy_to/fromio() which uses the special s390 io access instructions. This helps because we now block io memory from ever getting into these call paths. I'm pretty sure this is a serious security bug, but would let the IBM folks remark as I don't know it all that well.. As for the kmap, I thought it was standard practice even if it is a non-highmem? Aren't people trying to use this for other security stuff these days? Jason

1 0

← Newer
1
...
18
19
20
21
22
23
24
...
70
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2022