dri-devel January 2022

dri-devel@lists.freedesktop.org

373 participants
842 discussions

[PATCH] drm/udl: Return correct error code on kmalloc failure
by Harshit Mogalapalli 15 Jan '22

15 Jan '22

-ENOMEM is correct error code to return on a memory allocation failure instead of -1. Smatch Warning: drivers/gpu/drm/udl/udl_connector.c:27 udl_get_edid_block() warn: returning -1 instead of -ENOMEM is sloppy Fixes: a51143001d9e ("drm/udl: Refactor edid retrieving in UDL driver (v2)") Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli(a)oracle.com> --- drivers/gpu/drm/udl/udl_connector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/udl/udl_connector.c b/drivers/gpu/drm/udl/udl_connector.c index 930574ad2bca..b7a9c6d103ba 100644 --- a/drivers/gpu/drm/udl/udl_connector.c +++ b/drivers/gpu/drm/udl/udl_connector.c @@ -24,7 +24,7 @@ static int udl_get_edid_block(void *data, u8 *buf, unsigned int block, read_buff = kmalloc(2, GFP_KERNEL); if (!read_buff) - return -1; + return -ENOMEM; for (i = 0; i < len; i++) { int bval = (i + block * EDID_LENGTH) << 8; -- 2.27.0

1 0

[PATCH v5 00/32] component: Make into an aggregate bus
by Stephen Boyd 15 Jan '22

15 Jan '22

This series is from discussion we had on reordering the device lists for drm shutdown paths[1]. I've introduced an 'aggregate' bus that we put the aggregate device onto and then we probe the aggregate device once all the components are probed and call component_add(). The probe/remove hooks are where the bind/unbind calls go, and then a shutdown hook is added that can be used to shutdown the drm display pipeline at the right time. This works for me on my sc7180 board. I no longer get a warning from i2c at shutdown that we're trying to make an i2c transaction after the i2c bus has been shutdown. There's more work to do on the msm drm driver to extract component device resources like clks, regulators, etc. out of the component bind function into the driver probe but I wanted to move everything over now in other component drivers before tackling that problem. Tested-by tags would be appreciated, and Acked-by/Reviewed-by tags too. Per Daniel, I've resent this to collect Acks or Review tags from gregkh and once Greg is happy with the driver core bits it can be merged through drm-misc tree via dianders (both are on the To line). One last thing, I suspect I'll have to send this once again after the merge window because something is probably in linux-next that conflicts with some driver patch. I'll do that in about two weeks. Changes since v4 (https://lore.kernel.org/r/20211202222732.2453851-1-swboyd@chromium.org): - Picked up tags - Moved rename patch to first in the series - Squashed device and bus type patch together Changes since v3 (https://lore.kernel.org/r/20211026000044.885195-1-swboyd@chromium.org): - Picked up tags - Rebased to v5.16-rc2 - Updated component.c for a few new patches there - Dropped a conversion patch - Added a conversion patch Changes since v2 (https://lore.kernel.org/r/20211006193819.2654854-1-swboyd@chromium.org): - Picked up acks - Fixed build warnings/errors - Reworked patch series to rename 'master' in a different patch Changes since v1 (https://lore.kernel.org/r/20210520002519.3538432-1-swboyd@chromium.org): - Use devlink to connect components to the aggregate device - Don't set the registering device as a parent of the aggregate device - New patch for bind_component/unbind_component ops that takes the aggregate device - Convert all drivers in the tree to use the aggregate driver approach - Allow one aggregate driver to be used for multiple aggregate devices [1] https://lore.kernel.org/r/20210508074118.1621729-1-swboyd@chromium.org Stephen Boyd (32): component: Replace most references to 'master' with 'aggregate device' component: Introduce the aggregate bus_type component: Move struct aggregate_device out to header file component: Add {bind,unbind}_component() ops that take aggregate device drm/of: Add a drm_of_aggregate_probe() API drm/msm: Migrate to aggregate driver drm/komeda: Migrate to aggregate driver drm/arm/hdlcd: Migrate to aggregate driver drm/malidp: Migrate to aggregate driver drm/armada: Migrate to aggregate driver drm/etnaviv: Migrate to aggregate driver drm/kirin: Migrate to aggregate driver drm/exynos: Migrate to aggregate driver drm/imx: Migrate to aggregate driver drm/ingenic: Migrate to aggregate driver drm/mcde: Migrate to aggregate driver drm/mediatek: Migrate to aggregate driver drm/meson: Migrate to aggregate driver drm/omap: Migrate to aggregate driver drm/rockchip: Migrate to aggregate driver drm/sti: Migrate to aggregate driver drm/sun4i: Migrate to aggregate driver drm/tilcdc: Migrate to aggregate driver drm/vc4: Migrate to aggregate driver iommu/mtk: Migrate to aggregate driver mei: Migrate to aggregate driver power: supply: ab8500: Migrate to aggregate driver fbdev: omap2: Migrate to aggregate driver sound: hdac: Migrate to aggregate driver ASoC: codecs: wcd938x: Migrate to aggregate driver component: Get rid of drm_of_component_probe() component: Remove component_master_ops and friends drivers/base/component.c | 544 ++++++++++-------- .../gpu/drm/arm/display/komeda/komeda_drv.c | 20 +- drivers/gpu/drm/arm/hdlcd_drv.c | 21 +- drivers/gpu/drm/arm/malidp_drv.c | 21 +- drivers/gpu/drm/armada/armada_drv.c | 23 +- drivers/gpu/drm/drm_drv.c | 2 +- drivers/gpu/drm/drm_of.c | 18 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 20 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 21 +- .../gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 20 +- drivers/gpu/drm/imx/imx-drm-core.c | 20 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 25 +- drivers/gpu/drm/mcde/mcde_drv.c | 23 +- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 20 +- drivers/gpu/drm/meson/meson_drv.c | 21 +- drivers/gpu/drm/msm/msm_drv.c | 46 +- drivers/gpu/drm/omapdrm/dss/dss.c | 20 +- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 20 +- drivers/gpu/drm/sti/sti_drv.c | 20 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 26 +- drivers/gpu/drm/tilcdc/tilcdc_drv.c | 28 +- drivers/gpu/drm/vc4/vc4_drv.c | 20 +- drivers/iommu/mtk_iommu.c | 14 +- drivers/iommu/mtk_iommu.h | 6 +- drivers/iommu/mtk_iommu_v1.c | 14 +- drivers/misc/mei/hdcp/mei_hdcp.c | 22 +- drivers/misc/mei/pxp/mei_pxp.c | 22 +- drivers/power/supply/ab8500_charger.c | 22 +- drivers/video/fbdev/omap2/omapfb/dss/dss.c | 20 +- include/drm/drm_of.h | 10 +- include/linux/component.h | 92 ++- sound/hda/hdac_component.c | 21 +- sound/soc/codecs/wcd938x.c | 20 +- 33 files changed, 772 insertions(+), 490 deletions(-) Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Chen Feng <puck.chen(a)hisilicon.com> Cc: Chen-Yu Tsai <wens(a)csie.org> Cc: Christian Gmeiner <christian.gmeiner(a)gmail.com> Cc: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Emma Anholt <emma(a)anholt.net> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: "Heiko Stübner" <heiko(a)sntech.de> Cc: Inki Dae <inki.dae(a)samsung.com> Cc: James Qian Wang (Arm Technology China) <james.qian.wang(a)arm.com> Cc: Jaroslav Kysela <perex(a)perex.cz> Cc: Joerg Roedel <joro(a)8bytes.org> Cc: John Stultz <john.stultz(a)linaro.org> Cc: Joonyoung Shim <jy0922.shim(a)samsung.com> Cc: Jyri Sarha <jyri.sarha(a)iki.fi> Cc: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> Cc: Kyungmin Park <kyungmin.park(a)samsung.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: <linux-fbdev(a)vger.kernel.org> Cc: <linux-omap(a)vger.kernel.org> Cc: <linux-pm(a)vger.kernel.org> Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: Liviu Dudau <liviu.dudau(a)arm.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Mark Brown <broonie(a)kernel.org> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Paul Cercueil <paul(a)crapouillou.net> Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: "Rafael J. Wysocki" <rafael(a)kernel.org> Cc: Rob Clark <robdclark(a)gmail.com> Cc: Russell King <linux(a)armlinux.org.uk> Cc: Russell King <linux+etnaviv(a)armlinux.org.uk> Cc: Russell King <rmk+kernel(a)arm.linux.org.uk> Cc: Sandy Huang <hjc(a)rock-chips.com> Cc: Saravana Kannan <saravanak(a)google.com> Cc: Sebastian Reichel <sre(a)kernel.org> Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com> Cc: Takashi Iwai <tiwai(a)suse.com> Cc: Tian Tao <tiantao6(a)hisilicon.com> Cc: Tomas Winkler <tomas.winkler(a)intel.com> Cc: Tomi Valkeinen <tomba(a)kernel.org> Cc: Will Deacon <will(a)kernel.org> Cc: Xinliang Liu <xinliang.liu(a)linaro.org> Cc: Xinwei Kong <kong.kongxinwei(a)hisilicon.com> Cc: Yong Wu <yong.wu(a)mediatek.com> Cc: Vitaly Lubart <vitaly.lubart(a)intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Kai Vehmanen <kai.vehmanen(a)linux.intel.com> base-commit: 136057256686de39cc3a07c2e39ef6bc43003ff6 -- https://chromeos.dev

3 43

[PATCH 0/5] drm/exynos: Use platform_get_irq*() variants to fetch IRQ's
by Lad Prabhakar 15 Jan '22

15 Jan '22

Hi All, This patch series aims to drop using platform_get_resource() for IRQ types in preparation for removal of static setup of IRQ resource from DT core code. Dropping usage of platform_get_resource() was agreed based on the discussion [0]. [0] https://patchwork.kernel.org/project/linux-renesas-soc/ patch/20211209001056.29774-1-prabhakar.mahadev-lad.rj(a)bp.renesas.com/ Cheers, Prabhakar Lad Prabhakar (5): drm/exynos/exynos7_drm_decon: Use platform_get_irq_byname() to get the interrupt drm/exynos: mixer: Use platform_get_irq() to get the interrupt drm/exynos/exynos_drm_fimd: Use platform_get_irq_byname() to get the interrupt drm/exynos/fimc: Use platform_get_irq() to get the interrupt drm/exynos: gsc: Use platform_get_irq() to get the interrupt drivers/gpu/drm/exynos/exynos7_drm_decon.c | 12 +++--------- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 13 +++++-------- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 ++++--------- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 10 +++------- drivers/gpu/drm/exynos/exynos_mixer.c | 14 ++++++-------- 5 files changed, 21 insertions(+), 41 deletions(-) -- 2.17.1

3 8

[PATCH v15 0/4] group dp driver related patches into one series
by Kuogee Hsieh 14 Jan '22

14 Jan '22

Group below 4 dp driver related patches into one series. Kuogee Hsieh (4): drm/msm/dp: do not initialize phy until plugin interrupt received drm/msm/dp: populate connector of struct dp_panel drm/msm/dp: add support of tps4 (training pattern 4) for HBR3 drm/msm/dp: stop link training after link training 2 failed drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++--- drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +- drivers/gpu/drm/msm/dp/dp_ctrl.c | 100 ++++++++++++++++------------------ drivers/gpu/drm/msm/dp/dp_ctrl.h | 8 +-- drivers/gpu/drm/msm/dp/dp_display.c | 105 +++++++++++++++++++++--------------- 5 files changed, 118 insertions(+), 109 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 7

[PATCH v16 0/4] group dp driver related patches into one series
by Kuogee Hsieh 14 Jan '22

14 Jan '22

Group below 4 dp driver related patches into one series. Kuogee Hsieh (4): drm/msm/dp: do not initialize phy until plugin interrupt received drm/msm/dp: populate connector of struct dp_panel drm/msm/dp: add support of tps4 (training pattern 4) for HBR3 drm/msm/dp: stop link training after link training 2 failed drivers/gpu/drm/msm/dp/dp_catalog.c | 12 ++--- drivers/gpu/drm/msm/dp/dp_catalog.h | 2 +- drivers/gpu/drm/msm/dp/dp_ctrl.c | 100 ++++++++++++++++------------------ drivers/gpu/drm/msm/dp/dp_ctrl.h | 8 +-- drivers/gpu/drm/msm/dp/dp_display.c | 103 +++++++++++++++++++++--------------- 5 files changed, 116 insertions(+), 109 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

1 4

[PATCH v2 0/3] clk: Implement a clock request API
by Maxime Ripard 14 Jan '22

14 Jan '22

Hi, This is a follow-up of the discussion here: https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/ This implements a mechanism to raise and lower clock rates based on consumer workloads, with an example of such an implementation for the RaspberryPi4 HDMI controller. There's a couple of things worth discussing: - The name is in conflict with clk_request_rate, and even though it feels like the right name to me, we should probably avoid any confusion - The code so far implements a policy of always going for the lowest rate possible. While we don't have an use-case for something else, this should maybe be made more flexible? Let me know what you think Maxime Changes from v1: - Return NULL in clk_request_start if clk pointer is NULL - Test for clk_req pointer in clk_request_done - Add another user in vc4 - Rebased on top of v5.15-rc1 Dom Cobley (1): drm/vc4: hvs: Convert to the new clock request API Maxime Ripard (2): clk: Introduce a clock request API drm/vc4: hdmi: Convert to the new clock request API drivers/clk/clk.c | 126 +++++++++++++++++++++++++++++++++ drivers/gpu/drm/vc4/vc4_hdmi.c | 15 ++-- drivers/gpu/drm/vc4/vc4_hdmi.h | 3 + drivers/gpu/drm/vc4/vc4_kms.c | 5 +- include/linux/clk.h | 4 ++ 5 files changed, 146 insertions(+), 7 deletions(-) -- 2.31.1

3 13

[PATCH] drm/amd/display: Remove redundant initialization of dpg_width
by Jiapeng Chong 14 Jan '22

14 Jan '22

dpg_width is being initialized to width but this is never read as dpg_width is overwritten later on. Remove the redundant initialization. Cleans up the following clang-analyzer warning: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:6020:8: warning: Value stored to 'dpg_width' during its initialization is never read [clang-analyzer-deadcode.DeadStores]. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c index 497470513e76..1f8831156bc4 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c @@ -6017,7 +6017,7 @@ static void set_crtc_test_pattern(struct dc_link *link, else if (link->dc->hwss.set_disp_pattern_generator) { struct pipe_ctx *odm_pipe; int opp_cnt = 1; - int dpg_width = width; + int dpg_width; for (odm_pipe = pipe_ctx->next_odm_pipe; odm_pipe; odm_pipe = odm_pipe->next_odm_pipe) opp_cnt++; -- 2.20.1.7.g153144c

2 1

[PATCH] drm/amd/pm: Replace one-element array with flexible-array member
by cgel.zte＠gmail.com 14 Jan '22

14 Jan '22

From: Changcheng Deng <deng.changcheng(a)zte.com.cn> There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use "flexible array members" for these cases. The older style of one-element or zero-length arrays should no longer be used. Reference: https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-… Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Changcheng Deng <deng.changcheng(a)zte.com.cn> --- drivers/gpu/drm/amd/pm/powerplay/inc/smu_ucode_xfer_cz.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/pm/powerplay/inc/smu_ucode_xfer_cz.h b/drivers/gpu/drm/amd/pm/powerplay/inc/smu_ucode_xfer_cz.h index eb0f79f9c876..701aae598b58 100644 --- a/drivers/gpu/drm/amd/pm/powerplay/inc/smu_ucode_xfer_cz.h +++ b/drivers/gpu/drm/amd/pm/powerplay/inc/smu_ucode_xfer_cz.h @@ -121,7 +121,7 @@ typedef struct SMU_Task SMU_Task; struct TOC { uint8_t JobList[NUM_JOBLIST_ENTRIES]; - SMU_Task tasks[1]; + SMU_Task tasks[]; }; // META DATA COMMAND Definitions -- 2.25.1

2 1

[PATCH 0/3] (Re)enable DP/HDMI audio for RK3399 Gru
by Brian Norris 14 Jan '22

14 Jan '22

This series fixes DP/HDMI audio for RK3399 Gru systems. First, there was a regression with the switch to SPDIF. Patch 1 can be taken separately as a regression fix if desired. But it's not quite so useful (at least on Chrome OS systems) without the second part. Second, jack detection was never upstreamed, because the hdmi-codec dependencies were still being worked out when this platform was first supported. Patches cover a few subsystems. Perhaps this is something for arm-soc? Brian Norris (3): arm64: dts: rockchip: Switch RK3399-Gru DP to SPDIF output drm/rockchip: cdn-dp: Support HDMI codec plug-change callback ASoC: rk3399_gru_sound: Wire up DP jack detection arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 10 +++---- drivers/gpu/drm/rockchip/cdn-dp-core.c | 28 ++++++++++++++++++++ drivers/gpu/drm/rockchip/cdn-dp-core.h | 4 +++ sound/soc/rockchip/rk3399_gru_sound.c | 20 ++++++++++++++ 4 files changed, 57 insertions(+), 5 deletions(-) -- 2.34.1.703.g22d0c6ccf7-goog

1 4

[Bug 215494] New: [radeon, rv370] Running piglit shaders@glsl-vs-raytrace-bug26691 test causes hard lockup & reboot
by bugzilla-daemon＠bugzilla.kernel.org 14 Jan '22

14 Jan '22

https://bugzilla.kernel.org/show_bug.cgi?id=215494 Bug ID: 215494 Summary: [radeon, rv370] Running piglit shaders@glsl-vs-raytrace-bug26691 test causes hard lockup & reboot Product: Drivers Version: 2.5 Kernel Version: 5.16.0 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: erhard_f(a)mailbox.org CC: alexdeucher(a)gmail.com Regression: No Created attachment 300268 --> https://bugzilla.kernel.org/attachment.cgi?id=300268&action=edit kernel dmesg (kernel 5.16.0, Ryzen 9 5950X) Running the piglit festsuite (git-11ee10ba04) for https://gitlab.freedesktop.org/mesa/mesa/-/issues/3152 via './piglit run -1 quick -l verbose -s --dmesg' on a Radeon X600 causes the X600 to hard lockup & reboot. On my system this happens with kernel 5.15.11, 5.16.0, mesa 21.3.4 and mesa 22 (git-8b3d947267). I had a closer look and found out that shaders@glsl-vs-raytrace-bug26691 causes the lockup. Running "./piglit/bin/glsl-vs-raytrace-bug26691 -auto -fbo" as a single test works sometimes the 1st time, but re-running it a 2nd or a 3rd time always causes the lockup: [...] [ 518.794824] radeon: wait for empty RBBM fifo failed! Bad things might happen. [ 519.110152] Failed to wait GUI idle while programming pipes. Bad things might happen. [ 519.111220] radeon 0000:07:00.0: Saved 59 dwords of commands on ring 0. [ 519.111247] radeon 0000:07:00.0: (r300_asic_reset:426) RBBM_STATUS=0x8411C100 [ 519.616733] radeon 0000:07:00.0: (r300_asic_reset:445) RBBM_STATUS=0x8401C100 [ 520.118160] radeon 0000:07:00.0: (r300_asic_reset:457) RBBM_STATUS=0x8400C100 [ 520.118231] radeon 0000:07:00.0: failed to reset GPU [ 520.319694] pcieport 0000:00:03.1: AER: Corrected error received: 0000:00:03.1 [ 520.319723] pcieport 0000:00:03.1: PCIe Bus Error: severity=Corrected, type=Transaction Layer, (Receiver ID) [ 520.319729] pcieport 0000:00:03.1: device [1022:1483] error status/mask=00002000/00004000 [ 520.319735] pcieport 0000:00:03.1: [13] NonFatalErr [ 520.722345] pcieport 0000:00:03.1: AER: Corrected error received: 0000:00:03.1 For regular desktop usage the X600 seems ok so far. Some data about the system: $ inxi -b System: Host: prototype Kernel: 5.16.0-Zen3 x86_64 bits: 64 Desktop: Openbox 3.6.1 Distro: Gentoo Base System release 2.7 Machine: Type: Desktop Mobo: ASRock model: B450M Steel Legend serial: <superuser/root required> UEFI: American Megatrends v: P4.20 date: 08/03/2021 CPU: Info: 16-Core AMD Ryzen 9 5950X [MT MCP] speed: 3685 MHz min/max: 2200/3400 MHz Graphics: Device-1: AMD RV370 [Radeon X600/X600 SE] driver: radeon v: kernel Display: x11 server: X.Org 1.20.14 driver: ati,radeon unloaded: fbdev,modesetting resolution: 1920x1080~60Hz OpenGL: renderer: ATI RV370 v: 2.1 Mesa 22.0.0-devel (git-8b3d947267) Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 # lspci 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Starship/Matisse IOMMU 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61) 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 0 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 1 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 2 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 3 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 4 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 5 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 6 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 7 01:00.0 Non-Volatile memory controller: Sandisk Corp WD Blue SN550 NVMe SSD (rev 01) 02:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset USB 3.1 XHCI Controller (rev 01) 02:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller (rev 01) 02:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Bridge (rev 01) 03:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) 03:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) 03:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) 05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) 07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X600/X600 SE] 07:00.1 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV380 [Radeon X300/X550/X1050 Series] (Secondary) 08:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function 09:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP 09:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP 09:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller # lspci -s 07:00.0 -vv 07:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X600/X600 SE] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X600/X600 SE] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 59 IOMMU group: 2 Region 0: Memory at e8000000 (64-bit, prefetchable) [size=128M] Region 2: Memory at fce30000 (64-bit, non-prefetchable) [size=64K] Region 4: I/O ports at e000 [size=256] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v1) Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset- SlotPowerLimit 75.000W DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <256ns, L1 <2us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes, Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x16 (ok) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee01000 Data: 0022 Capabilities: [100 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr- AERCap: First Error Pointer: 00, ECRCGenCap- ECRCGenEn- ECRCChkCap- ECRCChkEn- MultHdrRecCap- MultHdrRecEn- TLPPfxPres- HdrLogCap- HeaderLog: 04000001 0000200f 07070000 b8cdf5fd Kernel driver in use: radeon Kernel modules: radeon -- 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 4

← Newer
1
...
57
58
59
60
61
62
63
...
85
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2022