dri-devel March 2022

dri-devel@lists.freedesktop.org

370 participants
780 discussions

DMA-buf and uncached system memory
by Christian König 24 Jun '22

24 Jun '22

Hi guys, we are currently working an Freesync and direct scan out from system memory on AMD APUs in A+A laptops. On problem we stumbled over is that our display hardware needs to scan out from uncached system memory and we currently don't have a way to communicate that through DMA-buf. For our specific use case at hand we are going to implement something driver specific, but the question is should we have something more generic for this? After all the system memory access pattern is a PCIe extension and as such something generic. Regards, Christian.

11 43

[Bug 201957] New: amdgpu: ring gfx timeout
by bugzilla-daemon＠bugzilla.kernel.org 23 Jun '22

23 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=201957 Bug ID: 201957 Summary: amdgpu: ring gfx timeout Product: Drivers Version: 2.5 Kernel Version: 4.19.8, 4.20-rc5 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: felix.adrianto(a)gmail.com Regression: No Error message: [Dec 5 22:08] amdgpu 0000:23:00.0: GPU fault detected: 146 0x0000480c for process yuzu pid 2920 thread yuzu:cs0 pid 2935 [ +0.000005] amdgpu 0000:23:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 [ +0.000002] amdgpu 0000:23:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0604800C [ +0.000003] amdgpu 0000:23:00.0: VM fault (0x0c, vmid 3, pasid 32770) at page 0, read from 'TC4' (0x54433400) (72) [ +10.053011] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=37241, emitted seq=37244 [ +0.000007] [drm] GPU recovery disabled. How to reproduce the issue: 1. Playing with yuzu-emulator 2. Load Super Mario Odyssey 3. Start new game 4. When Mario is about to jump for the first time after being woken up by Cappy, this bug must occur. During the issue, the following occured: 1. Graphic locked up. 2. System can be access through SSH. System specification: Debian Sid Radeon RX 580 I have tried the following combination: 1. Kernel 4.17, 4.18, 4.19, 4.20, drm-next-4.21.wip 2. Mesa 18.2, 18.3, 19.0-development branch But none of the above combination fixes the issue. Let me know if you need more information and more testing from me. -- You are receiving this mail because: You are watching the assignee of the bug.

2 79

[PATCH v1 0/9] drm/bridge: ps8640 and ti-sn65dsi86 updates
by Sam Ravnborg 22 Jun '22

22 Jun '22

Add a new macro DRM_BRIDGE_STATE_OPS that can be used to assign atomic_reset and atomic_{duplicate,destroy}_state to the default implementations. They will be valid in most cases. Add a drm variant of media-bus-format.h to hold a single function to get the bpc from the bus format. Also add a small drm_atomic_helper_bridge_dsi_input_bus_fmt helper. Update ti-sn65dsi86 to support atomic and NO_CONNECTOR. The NO_CONNECTOR support was from Rob Clark - I just rebased it. To support NO_CONNECTOR use the newly introduced function to lokk up bpc from the bus format. Update parade-ps8640 to support atomic. To do this just migrate to the atomic variants of the operations and add the few mandatry missing callbacks. A few of the patches are migrated from a patchset I posted several months ago and I decided to add them here for now, which explains why there is a v4 of a patch in a v1 submission. For the output bus fmt stuff I did what I think is correct - but as I have paged out all my memory of this it may be all wrong. The code builds - but needs testing. I was temped to move bridge helpers to a new drm_bridge_helper.c but that will wait until next time. Sam Rob Clark (1): drm/bridge: ti-sn65dsi86: Add NO_CONNECTOR support Sam Ravnborg (8): drm/bridge: add DRM_BRIDGE_STATE_OPS macro drm: add drm specific media-bus-format header file drm: add drm_atomic_helper_bridge_dsi_input_bus_fmt drm/bridge: ti-sn65dsi86: Use atomic variants of drm_bridge_funcs drm/bridge: ti-sn65dsi86: Fetch bpc via drm_bridge_state drm/bridge: ps8640: Use atomic variants of drm_bridge_funcs drm/bridge: ps8640: plug atomic_get_input_bus_fmts drm/bridge: Drop unused drm_bridge_chain functions drivers/gpu/drm/bridge/parade-ps8640.c | 18 ++++-- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 57 +++++++++-------- drivers/gpu/drm/drm_atomic_helper.c | 41 ++++++++++++ drivers/gpu/drm/drm_bridge.c | 110 --------------------------------- include/drm/drm_atomic_helper.h | 7 +++ include/drm/drm_bridge.h | 40 ++++-------- include/drm/media-bus-format.h | 53 ++++++++++++++++ 7 files changed, 157 insertions(+), 169 deletions(-)

4 29

[PATCH v8 00/16] clk: provide new devm helpers for prepared and enabled clocks
by Uwe Kleine-König 22 Jun '22

22 Jun '22

Hello, this is another try to convince the relevant people that devm_clk_get_enabled() is a nice idea. Compared to v7 (back in May 2021) this series is rebased to v5.17-rc8 and converts quite some drivers that open code devm_clk_get_enabled() up to now (patches #3 - #11). A concern about devm_clk_get_enabled() in v7 was that it helps people to be lazy and I agree that in some situations when devm_clk_get_enabled() is used it would be more efficient and sensible to care to only enable the clk when really needed. On the other hand, the function is right for some users, e.g. the watchdog drivers. For the others it's not so simple to judge. Given that there are a lot of drivers that are lazy even if doing so is some effort (i.e. calling clk_prepare_enable() and devm_add_action()) convinces me, that introducing the function family is sensible. (And if you want to work on these drivers, grepping for devm_clk_get_enabled gives you a few candidates once the series is in :-) Otherwise looking at the diffstat of this series: 48 files changed, 257 insertions(+), 851 deletions(-) is quite convincing. Just the first two patches (which introduce the new functions) account for 2 files changed, 169 insertions(+), 17 deletions(-) . A rough third of the added lines is documentation. The rest is driver updates which then has: 46 files changed, 88 insertions(+), 834 deletions(-) which makes a really nice cleanup. The series is build-tested on arm64, m68k, powerpc, riscv, s390, sparc64 and x86_64 using an allmodconfig. Best regards Uwe Uwe Kleine-König (16): clk: generalize devm_clk_get() a bit clk: Provide new devm_clk helpers for prepared and enabled clocks hwmon: Make use of devm_clk_get_enabled() iio: Make use of devm_clk_get_enabled() hwrng: meson - Don't open-code devm_clk_get_optional_enabled() bus: bt1: Don't open code devm_clk_get_enabled() gpio: vf610: Simplify error handling in probe drm/meson: dw-hdmi: Don't open code devm_clk_get_enabled() rtc: ingenic: Simplify using devm_clk_get_enabled() clk: meson: axg-audio: Don't duplicate devm_clk_get_enabled() watchdog: Make use of devm_clk_get_enabled() pwm: atmel: Simplify using devm_clk_get_prepared() rtc: at91sam9: Simplify using devm_clk_get_enabled() i2c: imx: Simplify using devm_clk_get_enabled() spi: davinci: Simplify using devm_clk_get_enabled() dmaengine: lgm: Fix error handling drivers/bus/bt1-apb.c | 23 +------ drivers/bus/bt1-axi.c | 23 +------ drivers/char/hw_random/meson-rng.c | 20 +----- drivers/clk/clk-devres.c | 96 ++++++++++++++++++++++----- drivers/clk/meson/axg-audio.c | 36 ++-------- drivers/dma/lgm/lgm-dma.c | 8 +-- drivers/gpio/gpio-vf610.c | 45 +++---------- drivers/gpu/drm/meson/meson_dw_hdmi.c | 48 +++++--------- drivers/hwmon/axi-fan-control.c | 15 +---- drivers/hwmon/ltc2947-core.c | 17 +---- drivers/hwmon/mr75203.c | 26 +------- drivers/hwmon/sparx5-temp.c | 19 +----- drivers/i2c/busses/i2c-imx.c | 12 +--- drivers/iio/adc/ad7124.c | 15 +---- drivers/iio/adc/ad7768-1.c | 17 +---- drivers/iio/adc/ad9467.c | 17 +---- drivers/iio/adc/ingenic-adc.c | 15 +---- drivers/iio/adc/lpc18xx_adc.c | 18 +---- drivers/iio/adc/rockchip_saradc.c | 44 +----------- drivers/iio/adc/ti-ads131e08.c | 19 +----- drivers/iio/adc/xilinx-ams.c | 15 +---- drivers/iio/adc/xilinx-xadc-core.c | 18 +---- drivers/iio/frequency/adf4371.c | 17 +---- drivers/iio/frequency/admv1013.c | 15 +---- drivers/iio/frequency/adrf6780.c | 16 +---- drivers/iio/imu/adis16475.c | 15 +---- drivers/pwm/pwm-atmel.c | 16 +---- drivers/rtc/rtc-at91sam9.c | 22 ++---- drivers/rtc/rtc-jz4740.c | 21 +----- drivers/spi/spi-davinci.c | 11 +-- drivers/watchdog/cadence_wdt.c | 17 +---- drivers/watchdog/davinci_wdt.c | 18 +---- drivers/watchdog/imgpdc_wdt.c | 31 +-------- drivers/watchdog/imx2_wdt.c | 15 +---- drivers/watchdog/imx7ulp_wdt.c | 15 +---- drivers/watchdog/loongson1_wdt.c | 17 +---- drivers/watchdog/lpc18xx_wdt.c | 30 +-------- drivers/watchdog/meson_gxbb_wdt.c | 16 +---- drivers/watchdog/of_xilinx_wdt.c | 16 +---- drivers/watchdog/pic32-dmt.c | 15 +---- drivers/watchdog/pic32-wdt.c | 17 +---- drivers/watchdog/pnx4008_wdt.c | 15 +---- drivers/watchdog/qcom-wdt.c | 16 +---- drivers/watchdog/rtd119x_wdt.c | 16 +---- drivers/watchdog/st_lpc_wdt.c | 16 +---- drivers/watchdog/stm32_iwdg.c | 31 +-------- drivers/watchdog/visconti_wdt.c | 18 +---- include/linux/clk.h | 90 ++++++++++++++++++++++++- 48 files changed, 257 insertions(+), 851 deletions(-) base-commit: 09688c0166e76ce2fb85e86b9d99be8b0084cdf9 -- 2.35.1

6 13

[PATCH v7, 00/15] media: mtk-vcodec: support for M8192 decoder
by Yunfei Dong 21 Jun '22

21 Jun '22

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 v6: - rebase to the latest media stage and fix conficts - fix memcpy to memcpy_fromio or memcpy_toio - fix h264 crash when test field bitstream 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 | 166 +- .../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 | 621 ++++++ .../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, 4180 insertions(+), 585 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

5 35

[PATCH v2 0/4] Add PSR support for eDP
by Vinod Polimera 21 Jun '22

21 Jun '22

*** BLURB HERE *** Vinod Polimera (4): drm/msm/dp: Add basic PSR support for eDP drm/bridge: use atomic enable/disable for bridge callbacks drm/msm/disp/dpu1: use atomic enable/disable callbacks for encoder functions drm/msm/disp/dpu1: add PSR support for eDP interface in dpu driver drivers/gpu/drm/bridge/panel.c | 102 ++++++++++++++-- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 31 ++++- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 40 ++++++- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +- drivers/gpu/drm/msm/dp/dp_catalog.c | 81 +++++++++++++ drivers/gpu/drm/msm/dp/dp_catalog.h | 4 + drivers/gpu/drm/msm/dp/dp_ctrl.c | 63 ++++++++++ drivers/gpu/drm/msm/dp/dp_ctrl.h | 3 + drivers/gpu/drm/msm/dp/dp_display.c | 14 +++ drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dp/dp_drm.c | 177 +++++++++++++++++++++++++++- drivers/gpu/drm/msm/dp/dp_link.c | 22 ++++ drivers/gpu/drm/msm/dp/dp_panel.c | 21 ++++ drivers/gpu/drm/msm/dp/dp_panel.h | 6 + drivers/gpu/drm/msm/dp/dp_reg.h | 19 +++ drivers/gpu/drm/msm/msm_drv.h | 6 + 16 files changed, 568 insertions(+), 24 deletions(-) -- 2.7.4

7 18

[Bug 172421] New: radeon: allow to set the TMDS frequency by a special kernel parameter
by bugzilla-daemon＠bugzilla.kernel.org 19 Jun '22

19 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=172421 Bug ID: 172421 Summary: radeon: allow to set the TMDS frequency by a special kernel parameter Product: Drivers Version: 2.5 Kernel Version: 4.8.0-rc7+ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: enhancement Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: estellnb(a)elstel.org Regression: No Despite different claims by ATI in 2016 Radeon R5 230 graphics cards featuring HDMI, DVI and VGA had originally been sold as 4K-ready up to the year 2015. The only prove I have for this is a comercial invoice from Nexus Mobile and a packaging card. As far as I know Radeon R5 230 cards currently sold can still be run stable and reliable under UltraHD provided that you apply the right kernel patch (see for the attachement). Unfortunately neither my former merchant nor ATI have responded about my questions concerning this change in trade and marketing policy. My request would now be to integrate the provided patch into the mainline kernel. It does not change the behaviour of the radeon driver unless you specify a nonzero value for the radeon.hdmimhz parameter. If you do I have tested the R5 230 cards I have to run stable and reliably for days. At least the 2GB variant of this card has largely sufficient resources for proficient desktop computing under UltraHD including image manipulation in 3840x2160. While never officially discussed for the radeon driver nouveau is already implementing a similar parameter called nouveau.hdmimhz since kernel 4.5.x. Though it thereby becomes possible to specify a hdmimhz that is far above the cards technical possibilties the nouveau developers I have talked with say that it would rarely be possible to damage any card by overcloking the TMDS. In deed I have successfully been overclocking my GeForce 9600M GT to feature 4K/2160p. Even specifying values considerable higher than 225MHz did not damage my GeForce 9600M GT though the screen stayed black upon the nouveau driver initialization. While the Radeon R5 230 works well at 297MHz (as long as you specify that via radeon.hdmimhz) I have similarly to the GeForce 9600M GT tried to overclock a Radeon R7 240. It did produce stable images at a higher hdmimhz like 330 though the HDMI input of my monitor features no more than 30Hz at 3840x2160 (tested with or without a DP-adapter). While it remains questionable if the provided patch can improve things for newer Radeon cards I would believe it to be beneficial for some elder cards. At least it is known to be beneficial for the R5 230 initially marketed as 4K-ready. The according radeon patch provided with this report has so far already been accepted by the Mageia 6 distribution. Though the attached patch is for application at the current 4.8.0-rcX+ kernels most of my machines that rely on it still run with 4.6.0. -- You are receiving this mail because: You are watching the assignee of the bug.

2 23

[PATCH v2] drm/nouveau/bios: Rename prom_init() and friends functions
by Christophe Leroy 17 Jun '22

17 Jun '22

While working at fixing powerpc headers, I ended up with the following error. drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c:48:1: error: conflicting types for 'prom_init'; have 'void *(struct nvkm_bios *, const char *)' make[5]: *** [scripts/Makefile.build:288: drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.o] Error 1 powerpc and a few other architectures have a prom_init() global function. One day or another it will conflict with the one in shadowrom.c Those being static, they can easily be renamed. Do it. While at it, also rename the ops structure as 'nvbios_prom' instead of 'nvbios_rom' in order to make it clear that it refers to the NV_PROM device. Signed-off-by: Christophe Leroy <christophe.leroy(a)csgroup.eu> --- v2: using nvbios_prom prefix instead of nvbios_rom. Changed structure name to keep things consistant. drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c | 2 +- .../gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c | 14 +++++++------- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h index fac1bff1311b..cfa8a0c356dd 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/priv.h @@ -19,7 +19,7 @@ struct nvbios_source { int nvbios_extend(struct nvkm_bios *, u32 length); int nvbios_shadow(struct nvkm_bios *); -extern const struct nvbios_source nvbios_rom; +extern const struct nvbios_source nvbios_prom; extern const struct nvbios_source nvbios_ramin; extern const struct nvbios_source nvbios_acpi_fast; extern const struct nvbios_source nvbios_acpi_slow; diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c index 4b571cc6bc70..19188683c8fc 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c @@ -171,7 +171,7 @@ nvbios_shadow(struct nvkm_bios *bios) struct shadow mthds[] = { { 0, &nvbios_of }, { 0, &nvbios_ramin }, - { 0, &nvbios_rom }, + { 0, &nvbios_prom }, { 0, &nvbios_acpi_fast }, { 4, &nvbios_acpi_slow }, { 1, &nvbios_pcirom }, diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c index ffa4b395220a..39144ceb117b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadowrom.c @@ -25,7 +25,7 @@ #include <subdev/pci.h> static u32 -prom_read(void *data, u32 offset, u32 length, struct nvkm_bios *bios) +nvbios_prom_read(void *data, u32 offset, u32 length, struct nvkm_bios *bios) { struct nvkm_device *device = data; u32 i; @@ -38,14 +38,14 @@ prom_read(void *data, u32 offset, u32 length, struct nvkm_bios *bios) } static void -prom_fini(void *data) +nvbios_prom_fini(void *data) { struct nvkm_device *device = data; nvkm_pci_rom_shadow(device->pci, true); } static void * -prom_init(struct nvkm_bios *bios, const char *name) +nvbios_prom_init(struct nvkm_bios *bios, const char *name) { struct nvkm_device *device = bios->subdev.device; if (device->card_type == NV_40 && device->chipset >= 0x4c) @@ -55,10 +55,10 @@ prom_init(struct nvkm_bios *bios, const char *name) } const struct nvbios_source -nvbios_rom = { +nvbios_prom = { .name = "PROM", - .init = prom_init, - .fini = prom_fini, - .read = prom_read, + .init = nvbios_prom_init, + .fini = nvbios_prom_fini, + .read = nvbios_prom_read, .rw = false, }; -- 2.35.1

4 6

[Bug 213145] New: AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!"
by bugzilla-daemon＠bugzilla.kernel.org 13 Jun '22

13 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=213145 Bug ID: 213145 Summary: AMDGPU resets, timesout and crashes after "*ERROR* Waiting for fences timed out!" Product: Drivers Version: 2.5 Kernel Version: 5.10.37 and 5.10.38 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: tgayoso(a)gmail.com Regression: No Created attachment 296867 --> https://bugzilla.kernel.org/attachment.cgi?id=296867&action=edit lspci output AMDGPU driver crashes randomly corrupting screen and freezing X with: [ 60.449781] [drm:0xffffffffc25a7a57] *ERROR* Waiting for fences timed out! [ 60.971941] [drm:0xffffffffc25281ae] *ERROR* ring gfx timeout, signaled seq=3658, emitted seq=3660 [ 60.971946] [drm:0xffffffffc25281cb] *ERROR* Process information: process Xorg pid 1192 thread Xorg:cs0 pid 1193 [ 60.971952] amdgpu 0000:05:00.0: amdgpu: GPU reset begin! ... (some output suppressed for clarity, look at attached dmesg, please). [ 61.800343] amdgpu 0000:05:00.0: amdgpu: recover vram bo from shadow start [ 61.800346] amdgpu 0000:05:00.0: amdgpu: recover vram bo from shadow done [ 61.800348] [drm] Skip scheduling IBs! [ 61.800350] [drm] Skip scheduling IBs! [ 61.800382] [drm] Skip scheduling IBs! [ 61.800398] amdgpu 0000:05:00.0: amdgpu: GPU reset(2) succeeded! [ 61.800566] [drm] Skip scheduling IBs! [ 61.800580] [drm] Skip scheduling IBs! [ 61.800627] [drm] Skip scheduling IBs! [ 61.801012] [drm] Skip scheduling IBs! [ 61.801024] [drm] Skip scheduling IBs! [ 61.801052] [drm] Skip scheduling IBs! [ 61.801062] [drm] Skip scheduling IBs! [ 61.801096] [drm] Skip scheduling IBs! [ 61.801105] [drm] Skip scheduling IBs! [ 61.801137] [drm] Skip scheduling IBs! [ 61.801806] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.808746] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.809392] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.809764] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.810389] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.810866] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.812529] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.813359] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.814770] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 61.816488] [drm:0xffffffffc24219b8] *ERROR* Failed to initialize parser -125! [ 62.541982] ucsi_acpi USBC000:00: PPM init failed (-110) [ 67.004898] amdgpu_cs_ioctl: 1467 callbacks suppressed Hardware: ASUS TUF506IU laptop (dual GPU Renoir and Nvidia GeForce GTX 1660 Ti Mobile) Detailed hardware in lspci.txt. Detailed modules in lsmod.txt. Kernle config attached in Kernel_config. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 20

[Bug 210301] New: *ERROR* IB test failed on gfx (-110) on Ryzen 4750u
by bugzilla-daemon＠bugzilla.kernel.org 11 Jun '22

11 Jun '22

https://bugzilla.kernel.org/show_bug.cgi?id=210301 Bug ID: 210301 Summary: *ERROR* IB test failed on gfx (-110) on Ryzen 4750u Product: Drivers Version: 2.5 Kernel Version: 5.9.8 Hardware: Intel 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: ar_registration(a)mailbox.org Regression: No Boting in a new Thinkpad T14 AMD (4750u), I get *sometimes* the following errors: 2020-11-21T16:45:15.53245 kern.err: [ 5.934142] amdgpu 0000:07:00.0: [drm:amdgpu_ib_ring_tests [amdgpu]] *ERROR* IB test failed on gfx (-110). 2020-11-21T16:45:15.53247 kern.err: [ 5.935598] [drm:process_one_work] *ERROR* ib ring test failed (-110). When this happens (typically 9/10 times) the machine eventually hangs. Sometimes with a page fault, sometimes with a general protection fault, but *always* in what appears to be the zfs calls. When the machine boots without the "*ERROR* IB test failed on gfx ", the machines *never* produces segmentation faults/general protection faults, even under very heavy i/o load. I have reproduced this problem: - In kernels 5.8.18, 5.9.6, 5.9.7, 5.9.8 - With two different SSD - With the firmware versions 20201118, 20201022, 20200918 - I have updated te BIOS two times (versions 1.09, 1.25, 1.27) I boot with the kernel command line options amd_iommu=on iommu=soft in order to avoid *another* error (AMD-Vi: Unable to read/write to IOMMU perf counter.) For example: 2020-10-24T22:00:29.88940 kern.warn: [ 1021.160344] general protection fault, probably for non-canonical address 0x3ff800040000000: 0000 [#1] SMP NOPTI 2020-10-24T22:00:29.89005 kern.warn: [ 1021.160348] CPU: 10 PID: 12746 Comm: bonnie++ Tainted: P O 5.8.16_1 #1 2020-10-24T22:00:29.89014 kern.warn: [ 1021.160349] Hardware name: LENOVO 20UDCTO1WW/20UDCTO1WW, BIOS R1BET40W(1.09 ) 08/07/2020 2020-10-24T22:00:29.89005 kern.warn: [ 1021.160348] CPU: 10 PID: 12746 Comm: bonnie++ Tainted: P O 5.8.16_1 #1 2020-10-24T22:00:29.89014 kern.warn: [ 1021.160349] Hardware name: LENOVO 20UDCTO1WW/20UDCTO1WW, BIOS R1BET40W(1.09 ) 08/07/2020 2020-10-24T22:00:29.89021 kern.warn: [ 1021.160385] RIP: 0010:dbuf_find+0x86/0x190 [zfs] 2020-10-24T22:00:29.89030 kern.warn: [ 1021.160387] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89033 kern.warn: [ 1021.160387] RSP: 0018:ffffb3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89030 kern.warn: [ 1021.160387] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89033 kern.warn: [ 1021.160387] RSP: 0018:ffffb3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89041 kern.warn: [ 1021.160389] RAX: 03ff800040000000 RBX: 00000000000587ce RCX: 0000000000001fd4 2020-10-24T22:00:29.89044 kern.warn: [ 1021.160389] RDX: ffff98bc4b6dbe00 RSI: 00000000000587ce RDI: ffffffffc11be4d0 2020-10-24T22:00:29.89046 kern.warn: [ 1021.160390] RBP: ffff98bc9cfa3000 R08: 99de27c9bb992351 R09: 9ae16a3b2f90404f 2020-10-24T22:00:29.89049 kern.warn: [ 1021.160391] R10: 0000000000000000 R11: ffff98bcca928000 R12: 0000000000030fc0 2020-10-24T22:00:29.89061 kern.warn: [ 1021.160391] R13: 0000000000000000 R14: ffff98bc4b6dbe00 R15: ffffffffc11be4d0 2020-10-24T22:00:29.89065 kern.warn: [ 1021.160392] FS: 00007f739cf48740(0000) GS:ffff98bccf080000(0000) knlGS:0000000000000000 2020-10-24T22:00:29.89070 kern.warn: [ 1021.160393] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2020-10-24T22:00:29.89077 kern.warn: [ 1021.160393] CR2: 00007f790e77d280 CR3: 0000000757346000 CR4: 0000000000340ee0 2020-10-24T22:00:29.89081 kern.warn: [ 1021.160394] Call Trace: 2020-10-24T22:00:29.89084 kern.warn: [ 1021.160400] ? _cond_resched+0x15/0x30 2020-10-24T22:00:29.89088 kern.warn: [ 1021.160410] dbuf_hold_impl_arg+0x41/0x610 [zfs] 2020-10-24T22:00:29.89091 kern.warn: [ 1021.160413] ? spl_kmem_alloc+0xbf/0x100 [spl] 2020-10-24T22:00:29.89095 kern.warn: [ 1021.160424] dbuf_hold_impl+0x94/0xc0 [zfs] 2020-10-24T22:00:29.89098 kern.warn: [ 1021.160434] dbuf_hold_level+0x2b/0x60 [zfs] 2020-10-24T22:00:29.89102 kern.warn: [ 1021.160446] dmu_tx_check_ioerr+0x35/0xd0 [zfs] 2020-10-24T22:00:29.89105 kern.warn: [ 1021.160457] dmu_tx_count_write+0xe5/0x1a0 [zfs] 2020-10-24T22:00:29.89109 kern.warn: [ 1021.160468] dmu_tx_hold_write_by_dnode+0x35/0x50 [zfs] 2020-10-24T22:00:29.89112 kern.warn: [ 1021.160481] zfs_write+0x410/0xe00 [zfs] 2020-10-24T22:00:29.89116 kern.warn: [ 1021.160485] ? enqueue_entity+0xf1/0x580 2020-10-24T22:00:29.89121 kern.warn: [ 1021.160497] zpl_write_common_iovec+0xaf/0x100 [zfs] 2020-10-24T22:00:29.89126 kern.warn: [ 1021.160509] zpl_iter_write+0xed/0x120 [zfs] 2020-10-24T22:00:29.89129 kern.warn: [ 1021.160511] new_sync_write+0x11b/0x1b0 2020-10-24T22:00:29.89133 kern.warn: [ 1021.160513] vfs_write+0x1c3/0x1f0 2020-10-24T22:00:29.89136 kern.warn: [ 1021.160515] ksys_write+0x5f/0xe0 2020-10-24T22:00:29.89140 kern.warn: [ 1021.160516] do_syscall_64+0x44/0x70 2020-10-24T22:00:29.89145 kern.warn: [ 1021.160518] entry_SYSCALL_64_after_hwframe+0x44/0xa9 2020-10-24T22:00:29.89150 kern.warn: [ 1021.160519] RIP: 0033:0x7f739d4f7de3 2020-10-24T22:00:29.89155 kern.warn: [ 1021.160521] Code: 75 05 48 83 c4 58 c3 e8 9b 43 ff ff 66 2e 0f 1f 84 00 00 00 00 00 90 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18 2020-10-24T22:00:29.89160 kern.warn: [ 1021.160521] RSP: 002b:00007ffee6a2caa8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 2020-10-24T22:00:29.89165 kern.warn: [ 1021.160522] RAX: ffffffffffffffda RBX: 00007ffee6a2caf0 RCX: 00007f739d4f7de3 2020-10-24T22:00:29.89177 kern.warn: [ 1021.160523] RDX: 0000000000002000 RSI: 00005623e29fd000 RDI: 0000000000000003 2020-10-24T22:00:29.89188 kern.warn: [ 1021.160523] RBP: 0000000000001d41 R08: 0000000000000000 R09: 0036343732312e00 2020-10-24T22:00:29.89202 kern.warn: [ 1021.160524] R10: 0000000000000180 R11: 0000000000000246 R12: 000000000001fd40 2020-10-24T22:00:29.89207 kern.warn: [ 1021.160524] R13: 00007ffee6a2caf0 R14: 00007ffee6a2cad0 R15: 00005623e29fd000 2020-10-24T22:00:29.89212 2020-10-24T22:00:29.89212 2020-10-24T22:00:29.89212 kern.warn: [ 1021.160525] Modules linked in: ctr ccm acpi_call(O) 8021q garp mrp stp llc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev btusb mc btrtl btbcm btintel joydev snd_soc_dmic snd_acp3x_pdm_dma snd_acp3x_rn snd_soc_core snd_compress snd_pcm_dmaengine ac97_bus tps6598x typec roles edac_mce_amd kvm_amd iwlmvm kvm mac80211 irqbypass crct10dif_pclmul ghash_clmulni_intel snd_hda_codec_realtek aesni_intel libarc4 snd_hda_codec_generic snd_hda_codec_hdmi crypto_simd cryptd snd_hda_intel glue_helper snd_intel_dspcfg rapl iwlwifi snd_hda_codec psmouse input_leds pcspkr wmi_bmof snd_hda_core snd_hwdep ipmi_devintf cfg80211 r8169 snd_rn_pci_acp3x sp5100_tco tpm_crb snd_pcm snd_pci_acp3x ccp ipmi_msghandler realtek k10temp i2c_piix4 thinkpad_acpi i2c_multi_instantiate ledtrig_audio ac tpm_tis tpm_tis_core evdev mac_hid tpm i2c_scmi rng_core acpi_cpufreq i2c_designware_platform tiny_power_button i2c_designware_core snd_seq snd_seq_device snd_timer snd soundcore kern.warn: [ 1021.160525] Modules linked in: ctr ccm acpi_call(O) 8021q garp mrp stp llc uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev btusb mc btrtl btbcm btintel joydev snd_soc_dmic snd_acp3x_pdm_dma snd_acp3x_rn snd_soc_core snd_compress snd_pcm_dmaengine ac97_bus tps6598x typec roles edac_mce_amd kvm_amd iwlmvm kvm mac80211 irqbypass crct10dif_pclmul ghash_clmulni_intel snd_hda_codec_realtek aesni_intel libarc4 snd_hda_codec_generic snd_hda_codec_hdmi crypto_simd cryptd snd_hda_intel glue_helper snd_intel_dspcfg rapl iwlwifi snd_hda_codec psmouse input_leds pcspkr wmi_bmof snd_hda_core snd_hwdep ipmi_devintf cfg80211 r8169 snd_rn_pci_acp3x sp5100_tco tpm_crb snd_pcm snd_pci_acp3x ccp ipmi_msghandler realtek k10temp i2c_piix4 thinkpad_acpi i2c_multi_instantiate ledtrig_audio ac tpm_tis tpm_tis_core evdev mac_hid tpm i2c_scmi rng_core acpi_cpufreq i2c_designware_platform tiny_power_button i2c_designware_core snd_seq snd_seq_device snd_timer snd soundcore 2020-10-24T22:00:29.89238 kern.warn: [ 1021.160552] vhost_vsock vmw_vsock_virtio_transport_common vsock vhost_net vhost tap vhost_iotlb uhid hid hci_vhci bluetooth ecdh_generic rfkill ecc crc16 vfio_iommu_type1 vfio dm_mod uinput userio ppp_generic slhc tun loop nvram btrfs blake2b_generic xor raid6_pq libcrc32c crc32c_generic cuse fuse zfs(PO) zunicode(PO) zlua(PO) zavl(PO) icp(PO) amdgpu iommu_v2 gpu_sched i2c_algo_bit ttm rtsx_pci_sdmmc mmc_core drm_kms_helper syscopyarea sysfillrect zcommon(PO) sysimgblt fb_sys_fops cec znvpair(PO) rc_core xhci_pci xhci_pci_renesas spl(O) xhci_hcd ehci_pci crc32_pclmul drm crc32c_intel ehci_hcd serio_raw usbcore agpgart rtsx_pci wmi button battery video 2020-10-24T22:00:29.89243 kern.warn: [ 1021.160577] ---[ end trace 17b0063aeadb5c32 ]--- 2020-10-24T22:00:29.89248 kern.warn: [ 1021.160589] RIP: 0010:dbuf_find+0x86/0x190 [zfs] 2020-10-24T22:00:29.89253 kern.warn: [ 1021.160589] Code: 7b 01 00 49 89 57 28 4a 8b 04 f0 48 85 c0 0f 84 b2 00 00 00 48 8b 0c 24 49 89 d6 eb 0d 48 8b 40 38 48 85 c0 0f 84 9c 00 00 00 <48> 39 18 75 ee 48 39 68 20 75 e8 44 38 68 50 75 e2 48 39 48 40 75 2020-10-24T22:00:29.89267 kern.warn: [ 1021.160590] RSP: 0018:ffffb3ff15a4ba28 EFLAGS: 00010206 2020-10-24T22:00:29.89271 kern.warn: [ 1021.160591] RAX: 03ff800040000000 RBX: 00000000000587ce RCX: 0000000000001fd4 2020-10-24T22:00:29.89276 kern.warn: [ 1021.160591] RDX: ffff98bc4b6dbe00 RSI: 00000000000587ce RDI: ffffffffc11be4d0 2020-10-24T22:00:29.89281 kern.warn: [ 1021.160592] RBP: ffff98bc9cfa3000 R08: 99de27c9bb992351 R09: 9ae16a3b2f90404f 2020-10-24T22:00:29.89287 kern.warn: [ 1021.160592] R10: 0000000000000000 R11: ffff98bcca928000 R12: 0000000000030fc0 2020-10-24T22:00:29.89292 kern.warn: [ 1021.160593] R13: 0000000000000000 R14: ffff98bc4b6dbe00 R15: ffffffffc11be4d0 2020-10-24T22:00:29.89297 kern.warn: [ 1021.160593] FS: 00007f739cf48740(0000) GS:ffff98bccf080000(0000) knlGS:0000000000000000 2020-10-24T22:00:29.89302 kern.warn: [ 1021.160594] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2020-10-24T22:00:29.89307 kern.warn: [ 1021.160594] CR2: 00007f790e77d280 CR3: 0000000757346000 CR4: 0000000000340ee0 -- You are receiving this mail because: You are watching the assignee of the bug.

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2022