dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

[PATCH 1/3] mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe()
by Yang Yingliang 27 Apr '22

27 Apr '22

It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code. Fixes: ec4ba01e894d ("mtd: rawnand: Add new Cadence NAND driver to MTD subsystem") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- drivers/mtd/nand/raw/cadence-nand-controller.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/raw/cadence-nand-controller.c b/drivers/mtd/nand/raw/cadence-nand-controller.c index 7eec60ea9056..0d72672f8b64 100644 --- a/drivers/mtd/nand/raw/cadence-nand-controller.c +++ b/drivers/mtd/nand/raw/cadence-nand-controller.c @@ -2983,11 +2983,10 @@ static int cadence_nand_dt_probe(struct platform_device *ofdev) if (IS_ERR(cdns_ctrl->reg)) return PTR_ERR(cdns_ctrl->reg); - res = platform_get_resource(ofdev, IORESOURCE_MEM, 1); - cdns_ctrl->io.dma = res->start; - cdns_ctrl->io.virt = devm_ioremap_resource(&ofdev->dev, res); + cdns_ctrl->io.virt = devm_platform_get_and_ioremap_resource(ofdev, 1, &res); if (IS_ERR(cdns_ctrl->io.virt)) return PTR_ERR(cdns_ctrl->io.virt); + cdns_ctrl->io.dma = res->start; dt->clk = devm_clk_get(cdns_ctrl->dev, "nf_clk"); if (IS_ERR(dt->clk)) -- 2.25.1

2 5

[PATCH 0/2] drm/nvdla: Add driver support for NVDLA
by Cai Huoqing 27 Apr '22

27 Apr '22

The NVIDIA Deep Learning Accelerator (NVDLA) is an open source IP which is integrated into NVIDIA Jetson AGX Xavier, so add driver support for this accelerator. NVDLA introduce: http://nvdla.org/primer.html User mode driver: https://github.com/caihuoq/nvdla/tree/main/sw/umd Cai Huoqing (2): MAINTAINERS: Add the driver info of the NVDLA drm/nvdla: Add driver support for NVDLA MAINTAINERS | 7 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/nvdla/Kconfig | 8 + drivers/gpu/drm/nvdla/Makefile | 19 + drivers/gpu/drm/nvdla/nvdla_bdma.c | 200 + drivers/gpu/drm/nvdla/nvdla_cache.c | 215 + drivers/gpu/drm/nvdla/nvdla_cdp.c | 300 ++ drivers/gpu/drm/nvdla/nvdla_common.c | 295 ++ drivers/gpu/drm/nvdla/nvdla_common.h | 835 +++ drivers/gpu/drm/nvdla/nvdla_conv.c | 683 +++ drivers/gpu/drm/nvdla/nvdla_drm.c | 695 +++ drivers/gpu/drm/nvdla/nvdla_drm.h | 127 + drivers/gpu/drm/nvdla/nvdla_engine.c | 233 + drivers/gpu/drm/nvdla/nvdla_engine.h | 272 + drivers/gpu/drm/nvdla/nvdla_gem.c | 393 ++ drivers/gpu/drm/nvdla/nvdla_ioctl.h | 99 + drivers/gpu/drm/nvdla/nvdla_pdp.c | 446 ++ drivers/gpu/drm/nvdla/nvdla_reg.h | 6411 +++++++++++++++++++++++ drivers/gpu/drm/nvdla/nvdla_rubik.c | 217 + drivers/gpu/drm/nvdla/nvdla_sched.h | 52 + drivers/gpu/drm/nvdla/nvdla_scheduler.c | 1005 ++++ drivers/gpu/drm/nvdla/nvdla_sdp.c | 728 +++ 23 files changed, 13243 insertions(+) create mode 100644 drivers/gpu/drm/nvdla/Kconfig create mode 100644 drivers/gpu/drm/nvdla/Makefile create mode 100644 drivers/gpu/drm/nvdla/nvdla_bdma.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_cache.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_cdp.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_common.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_common.h create mode 100644 drivers/gpu/drm/nvdla/nvdla_conv.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_drm.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_drm.h create mode 100644 drivers/gpu/drm/nvdla/nvdla_engine.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_engine.h create mode 100644 drivers/gpu/drm/nvdla/nvdla_gem.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_ioctl.h create mode 100644 drivers/gpu/drm/nvdla/nvdla_pdp.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_reg.h create mode 100644 drivers/gpu/drm/nvdla/nvdla_rubik.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_sched.h create mode 100644 drivers/gpu/drm/nvdla/nvdla_scheduler.c create mode 100644 drivers/gpu/drm/nvdla/nvdla_sdp.c -- 2.25.1

7 18

[PATCH] drm/amdgpu: do not use passthrough mode in Xen dom0
by Marek Marczykowski-Górecki 27 Apr '22

27 Apr '22

While technically Xen dom0 is a virtual machine too, it does have access to most of the hardware so it doesn't need to be considered a "passthrough". Commit b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for APUs in passthrough") changed how FB is accessed based on passthrough mode. This breaks amdgpu in Xen dom0 with message like this: [drm:dc_dmub_srv_wait_idle [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3 While the reason for this failure is unclear, the passthrough mode is not really necessary in Xen dom0 anyway. So, to unbreak booting affected kernels, disable passthrough mode in this case. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1985 Fixes: b818a5d37454 ("drm/amdgpu/gmc: use PCI BARs for APUs in passthrough") Signed-off-by: Marek Marczykowski-Górecki <marmarek(a)invisiblethingslab.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c index a025f080aa6a..5e3756643da3 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c @@ -24,6 +24,7 @@ #include <linux/module.h> #include <drm/drm_drv.h> +#include <xen/xen.h> #include "amdgpu.h" #include "amdgpu_ras.h" @@ -710,7 +711,8 @@ void amdgpu_detect_virtualization(struct amdgpu_device *adev) adev->virt.caps |= AMDGPU_SRIOV_CAPS_ENABLE_IOV; if (!reg) { - if (is_virtual_machine()) /* passthrough mode exclus sriov mod */ + /* passthrough mode exclus sriov mod */ + if (is_virtual_machine() && !xen_initial_domain()) adev->virt.caps |= AMDGPU_PASSTHROUGH_MODE; } -- 2.35.1

2 1

[PATCH v6 00/19] Add writeback block support for DPU
by Abhinav Kumar 27 Apr '22

27 Apr '22

This series adds support for writeback block on DPU. Writeback block is extremely useful to validate boards having no physical displays in addition to many other use-cases where we want to get the output of the display pipeline to examine whether issue is with the display pipeline or with the panel. These changes have been validated on SM8250 RB5 boards with IGT KMS writeback test-suite thereby further increasing the IGT test coverage for DPU. I am sharing the test results below. root@linaro-developer:~/igt_repo/igt-gpu-tools/build/tests# ./kms_writeback [ 35.066157] Console: switching to colour dummy device 80x25 [ 35.071964] [IGT] kms_writeback: executing IGT-Version: 1.26-gae2eb9e1 (aarch64) (Linux: 5.16.0-rc2-62171-g132577e2697b aarch64) [ 35.611418] [IGT] kms_writeback: starting subtest writeback-pixel-formats Starting subtest: writeback-pixel-formats [ 35.618528] [IGT] kms_writeback: starting subtest writeback-invalid-parameters Subtest writeback-pixel-formats: SUCCESS (0.000s) Starting subtest: writeback-invalid-parameters Subtest writeback-invalid-parameters: SUCCESS (0.028s) 35.657437] [IGT] kms_writeback: starting subtest writeback-fb-id Starting subtest: writeback-fb-id Subtest writeback-fb-id: SUCCESS (0.030s) [ 35.698957] [IGT] kms_writeback: starting subtest writeback-check-output Starting subtest: writeback-check-output [ 35.852834] [IGT] kms_writeback: exiting, ret=0 Subtest writeback-check-output: SUCCESS (0.142s) [ 35.861291] Console: switching to colour frame buffer device 240x67 root@linaro-developer:~/igt_repo/igt-gpu-tools/build/tests# The changes can easily be extended to support any other chipset using the DPU driver by adding the support in the catalog. Writeback block supports various formats and features. The support for all of them can be incrementally added on top of this framework when validation is improved and the test frameworks are extended to validate them. changes in v6: - fix the comment about intf_idx and wb_idx - add the condition for valid phys_enc with intf_idx and wb_idx Abhinav Kumar (19): drm: allow passing possible_crtcs to drm_writeback_connector_init() drm: introduce drm_writeback_connector_init_with_encoder() API drm/msm/dpu: add writeback blocks to the sm8250 DPU catalog drm/msm/dpu: add reset_intf_cfg operation for dpu_hw_ctl drm/msm/dpu: rename dpu_hw_pipe_cdp_cfg to dpu_hw_cdp_cfg drm/msm/dpu: add dpu_hw_wb abstraction for writeback blocks drm/msm/dpu: add writeback blocks to DPU RM drm/msm/dpu: add changes to support writeback in hw_ctl drm/msm/dpu: add an API to reset the encoder related hw blocks drm/msm/dpu: make changes to dpu_encoder to support virtual encoder drm/msm/dpu: add encoder operations to prepare/cleanup wb job drm/msm/dpu: move _dpu_plane_get_qos_lut to dpu_hw_util file drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback drm/msm/dpu: add the writeback connector layer drm/msm/dpu: initialize dpu encoder and connector for writeback drm/msm/dpu: gracefully handle null fb commits for writeback drm/msm/dpu: add writeback blocks to the display snapshot drm/msm/dpu: add wb_idx to existing DRM prints in dpu_encoder drm/msm/dpu: add wb_idx to DRM traces in dpu_encoder .../drm/arm/display/komeda/komeda_wb_connector.c | 4 +- drivers/gpu/drm/arm/malidp_mw.c | 4 +- drivers/gpu/drm/drm_writeback.c | 73 +- drivers/gpu/drm/msm/Makefile | 3 + drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 9 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 310 +++++++-- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h | 22 + drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 50 ++ .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 763 +++++++++++++++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 72 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 66 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 82 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 21 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.h | 18 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.c | 25 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_util.h | 19 + drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c | 279 ++++++++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h | 115 ++++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 66 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 31 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 22 + drivers/gpu/drm/msm/disp/dpu1/dpu_rm.h | 12 + drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 26 +- drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 76 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.h | 31 + drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 4 +- drivers/gpu/drm/vc4/vc4_txp.c | 3 +- drivers/gpu/drm/vkms/vkms_writeback.c | 4 +- include/drm/drm_writeback.h | 11 +- 30 files changed, 2095 insertions(+), 128 deletions(-) create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_wb.h create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c create mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.h -- 2.7.4

2 22

[PATCH] drm/i915/uc: use io memcpy functions for device memory copy
by Balasubramani Vivekanandan 27 Apr '22

27 Apr '22

When copying RSA use io memcpy functions if the destination address contains a GPU local memory address. Considering even the source address can be on local memory, a bounce buffer is used to copy from io to io. The intention of this patch is to make i915 portable outside x86 mainly on ARM64. Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan(a)intel.com> --- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c index bb864655c495..06d30670e15c 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c @@ -589,7 +589,7 @@ static int uc_fw_rsa_data_create(struct intel_uc_fw *uc_fw) struct intel_gt *gt = __uc_fw_to_gt(uc_fw); struct i915_vma *vma; size_t copied; - void *vaddr; + void *vaddr, *bounce; int err; err = i915_inject_probe_error(gt->i915, -ENXIO); @@ -621,7 +621,26 @@ static int uc_fw_rsa_data_create(struct intel_uc_fw *uc_fw) goto unpin_out; } - copied = intel_uc_fw_copy_rsa(uc_fw, vaddr, vma->size); + if (i915_gem_object_is_lmem(vma->obj)) { + /* When vma is allocated from the GPU local memmory, it means + * the destination address contains an io memory and we need to + * use memcpy function for io memory for copying, to ensure + * i915 portability outside x86. It is most likely the RSA will + * also be on local memory and so the source of copy will also + * be an io address. Since we cannot directly copy from io to + * io, we use a bounce buffer to copy. + */ + copied = 0; + bounce = kmalloc(vma->size, GFP_KERNEL); + if (likely(bounce)) { + copied = intel_uc_fw_copy_rsa(uc_fw, bounce, vma->size); + memcpy_toio((void __iomem *)vaddr, bounce, copied); + kfree(bounce); + } + } else { + copied = intel_uc_fw_copy_rsa(uc_fw, vaddr, vma->size); + } + i915_gem_object_unpin_map(vma->obj); if (copied < uc_fw->rsa_size) { -- 2.25.1

2 1

[PATCH] drm/bochs: Explicitly include linux/module.h
by Michel Dänzer 27 Apr '22

27 Apr '22

From: Michel Dänzer <mdaenzer(a)redhat.com> Instead of relying on it getting pulled in indirectly. Signed-off-by: Michel Dänzer <mdaenzer(a)redhat.com> --- drivers/gpu/drm/tiny/bochs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tiny/bochs.c b/drivers/gpu/drm/tiny/bochs.c index ed971c8bb446..4f8bf86633df 100644 --- a/drivers/gpu/drm/tiny/bochs.c +++ b/drivers/gpu/drm/tiny/bochs.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0-or-later +#include <linux/module.h> #include <linux/pci.h> #include <drm/drm_aperture.h> -- 2.35.1

2 1

[PATCH 0/4] Add Toshiba Visconti AFFINE image processing accelerator driver
by Yuji Ishikawa 27 Apr '22

27 Apr '22

This series is the AFFINE image processing accelerator driver for Toshiba's ARM SoC, Visconti[0]. This provides DT binding documentation, device driver, MAINTAINER files. Best regards, Yuji [0]: https://toshiba.semicon-storage.com/ap-en/semiconductor/product/image-recog… Yuji Ishikawa (4): dt-bindings: soc: visconti: Add Toshiba Visconti AFFINE image processing accelerator bindings soc: visconti: Add Toshiba Visconti image processing accelerator common source soc: visconti: Add Toshiba Visconti AFFINE image processing accelerator MAINTAINERS: Add entries for Toshiba Visconti AFFINE image processing accelerator .../soc/visconti/toshiba,visconti-affine.yaml | 53 ++ MAINTAINERS | 2 + drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/visconti/Kconfig | 7 + drivers/soc/visconti/Makefile | 8 + drivers/soc/visconti/affine/Makefile | 6 + drivers/soc/visconti/affine/affine.c | 451 ++++++++++++++++++ drivers/soc/visconti/affine/hwd_affine.c | 207 ++++++++ drivers/soc/visconti/affine/hwd_affine.h | 83 ++++ drivers/soc/visconti/affine/hwd_affine_reg.h | 45 ++ drivers/soc/visconti/ipa_common.c | 55 +++ drivers/soc/visconti/ipa_common.h | 19 + drivers/soc/visconti/uapi/affine.h | 87 ++++ drivers/soc/visconti/uapi/ipa.h | 87 ++++ 15 files changed, 1112 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/visconti/toshiba,visconti-affine.yaml create mode 100644 drivers/soc/visconti/Kconfig create mode 100644 drivers/soc/visconti/Makefile create mode 100644 drivers/soc/visconti/affine/Makefile create mode 100644 drivers/soc/visconti/affine/affine.c create mode 100644 drivers/soc/visconti/affine/hwd_affine.c create mode 100644 drivers/soc/visconti/affine/hwd_affine.h create mode 100644 drivers/soc/visconti/affine/hwd_affine_reg.h create mode 100644 drivers/soc/visconti/ipa_common.c create mode 100644 drivers/soc/visconti/ipa_common.h create mode 100644 drivers/soc/visconti/uapi/affine.h create mode 100644 drivers/soc/visconti/uapi/ipa.h -- 2.17.1

2 5

[Bug 215892] New: 6500XT [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30!
by bugzilla-daemon＠kernel.org 27 Apr '22

27 Apr '22

https://bugzilla.kernel.org/show_bug.cgi?id=215892 Bug ID: 215892 Summary: 6500XT [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30! Product: Drivers Version: 2.5 Kernel Version: 5.18-rc4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: ulatec(a)gmail.com Regression: No Created attachment 300811 --> https://bugzilla.kernel.org/attachment.cgi?id=300811&action=edit New PowerColor board with chip that produces kernel errors Hello! This is my first time submitted a bug here. I apologize if I make any mistakes here, but I am going to do my best to describe the efforts that I have gone through to attempt to resolve this issue on my own. As well, I hope not to overload with information, but just wish to help with skipping over the basic questions. I have numerous PowerColor RX 6500XT graphics cards, and all of them with a specific chip package (picture attached) have the same issue. Any PowerColor RX 6500XT with 2152 printed at the top of the package, and "TFTB43.00" at the bottom of the package suffers the same kernel errors. Previously (up until a few weeks ago) PowerColor was shipping 6500XT boards with chips that were stamped with 2146 and "TFAW62.T5" at the top and bottom of the package respectively. Boards with those chips have zero kernel errors and work flawlessly. As well, I have tested various 6500XT and 6400 boards from different AIB partners of AMD and have not had any issues other than this specific variant from PowerColor. To be honest, I am not sure if the root of the problem is in pcieport or in amdgpu, but the amdgpu error throws first. I have attached the full dmesg output but to save some time here are some highlighted lines of issue: [ 5.506718] [drm:amdgpu_dm_init.isra.0.cold [amdgpu]] *ERROR* Failed to register vline0 irq 30! [ 14.368915] pcieport 0000:01:00.0: can't change power state from D0 to D3hot (config space inaccessible) [ 15.270778] pcieport 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 15.270799] pcieport 0000:02:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 25.478689] pcieport 0000:01:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 25.478696] pcieport 0000:02:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 25.722619] amdgpu 0000:03:00.0: can't change power state from D3cold to D0 (config space inaccessible) [ 35.833714] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for VM flush hub: 0! [ 35.941450] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for sem acquire in VM flush! [ 36.048999] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for VM flush hub: 1! [ 36.156835] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for sem acquire in VM flush! [ 36.264770] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for VM flush hub: 1! [ 36.372616] [drm:gmc_v10_0_flush_vm_hub.constprop.0 [amdgpu]] *ERROR* Timeout waiting for VM flush hub: 0! What I have attempted so far: Results were the same for the following kernels: 5.4.190, 5.10.111, 5.15.34, 5.17.4 and now 5.18-rc4. Many different motherboards with varying chipsets (B250, H510, X370, B550). Same result. Enabling/Disabling clock gating, ASPM, extended synch control for PCIE. Same result. The problematic cards from PowerColor indeed do work in Windows without issue. This leads me to believe that something may have changed with TUL's implementation of the 6500XT from one production run to another. Hopefully someone from the amdgpu team can help here. To summarize, PowerColor's prior 6500XT production worked flawlessly with the drivers in the mainline kernel. New production for some reason is no longer usable. New cards work in Windows, but now throw the errors above. Not an isolated issue of one card, as I have tested 12 identical ones with the same chip and all have the same result regardless of motherboard, cpu, power, kernel, OS, etc. Cards (6500XT and 6400s) from other partners have not had any issues. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 6

[PATCH] drm/arm/mali-dp: Fix spelling typo in comment
by pengfuyuan 27 Apr '22

27 Apr '22

Fix spelling typo in comment. Signed-off-by: pengfuyuan <pengfuyuan(a)kylinos.cn> --- drivers/gpu/drm/arm/malidp_regs.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/arm/malidp_regs.h b/drivers/gpu/drm/arm/malidp_regs.h index 514c50dcb74d..3bc16db70ddb 100644 --- a/drivers/gpu/drm/arm/malidp_regs.h +++ b/drivers/gpu/drm/arm/malidp_regs.h @@ -145,7 +145,7 @@ #define MALIDP_SE_COEFFTAB_DATA_MASK 0x3fff #define MALIDP_SE_SET_COEFFTAB_DATA(x) \ ((x) & MALIDP_SE_COEFFTAB_DATA_MASK) -/* Enhance coeffents reigster offset */ +/* Enhance coefficients register offset */ #define MALIDP_SE_IMAGE_ENH 0x3C /* ENH_LIMITS offset 0x0 */ #define MALIDP_SE_ENH_LOW_LEVEL 24 -- 2.25.1

2 1

[PATCH] i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers
by Wan Jiabing 27 Apr '22

27 Apr '22

Fix following coccicheck error: ./drivers/gpu/drm/i915/gvt/handlers.c:2925:35-41: ERROR: block is NULL but dereferenced. Use gvt->mmio.mmio_block instead of block to avoid NULL pointer dereference when find_mmio_block returns NULL. Fixes: e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from GVT-g") Signed-off-by: Wan Jiabing <wanjiabing(a)vivo.com> --- drivers/gpu/drm/i915/gvt/handlers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/handlers.c b/drivers/gpu/drm/i915/gvt/handlers.c index cf00398c2870..7ffe0fb512a9 100644 --- a/drivers/gpu/drm/i915/gvt/handlers.c +++ b/drivers/gpu/drm/i915/gvt/handlers.c @@ -2922,7 +2922,7 @@ static int init_mmio_block_handlers(struct intel_gvt *gvt) block = find_mmio_block(gvt, VGT_PVINFO_PAGE); if (!block) { WARN(1, "fail to assign handlers to mmio block %x\n", - i915_mmio_reg_offset(block->offset)); + i915_mmio_reg_offset(gvt->mmio.mmio_block->offset)); return -ENODEV; } -- 2.35.3

1 0

← Newer
1
...
22
23
24
25
26
27
28
...
96
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022