dri-devel November 2021

dri-devel@lists.freedesktop.org

340 participants
748 discussions

Re: [PATCH 02/29] drm/i915/gvt: integrate into the main Makefile
by Jani Nikula 02 Nov '21

02 Nov '21

On Tue, 02 Nov 2021, Christoph Hellwig <hch(a)lst.de> wrote: > Remove the separately included Makefile and just use the relative > reference from the main i915 Makefile as for source files in other > subdirectories. > > Signed-off-by: Christoph Hellwig <hch(a)lst.de> Acked-by: Jani Nikula <jani.nikula(a)intel.com> > --- > drivers/gpu/drm/i915/Makefile | 29 ++++++++++++++++++++++++----- > drivers/gpu/drm/i915/gvt/Makefile | 9 --------- > drivers/gpu/drm/i915/gvt/trace.h | 2 +- > 3 files changed, 25 insertions(+), 15 deletions(-) > delete mode 100644 drivers/gpu/drm/i915/gvt/Makefile > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 335ba9f43d8f7..63523032eea26 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -295,11 +295,30 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \ > > # virtual gpu code > i915-y += i915_vgpu.o > - > -ifeq ($(CONFIG_DRM_I915_GVT),y) > -i915-y += intel_gvt.o > -include $(src)/gvt/Makefile > -endif > +i915-$(CONFIG_DRM_I915_GVT) += \ > + intel_gvt.o \ > + gvt/gvt.o \ > + gvt/aperture_gm.o \ > + gvt/handlers.o \ > + gvt/vgpu.o \ > + gvt/trace_points.o \ > + gvt/firmware.o \ > + gvt/interrupt.o \ > + gvt/gtt.o \ > + gvt/cfg_space.o \ > + gvt/opregion.o \ > + gvt/mmio.o \ > + gvt/display.o \ > + gvt/edid.o \ > + gvt/execlist.o \ > + gvt/scheduler.o \ > + gvt/sched_policy.o \ > + gvt/mmio_context.o \ > + gvt/cmd_parser.o \ > + gvt/debugfs.o \ > + gvt/fb_decoder.o \ > + gvt/dmabuf.o \ > + gvt/page_track.o > > obj-$(CONFIG_DRM_I915) += i915.o > obj-$(CONFIG_DRM_I915_GVT_KVMGT) += gvt/kvmgt.o > diff --git a/drivers/gpu/drm/i915/gvt/Makefile b/drivers/gpu/drm/i915/gvt/Makefile > deleted file mode 100644 > index ea8324abc784a..0000000000000 > --- a/drivers/gpu/drm/i915/gvt/Makefile > +++ /dev/null > @@ -1,9 +0,0 @@ > -# SPDX-License-Identifier: GPL-2.0 > -GVT_DIR := gvt > -GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o trace_points.o firmware.o \ > - interrupt.o gtt.o cfg_space.o opregion.o mmio.o display.o edid.o \ > - execlist.o scheduler.o sched_policy.o mmio_context.o cmd_parser.o debugfs.o \ > - fb_decoder.o dmabuf.o page_track.o > - > -ccflags-y += -I $(srctree)/$(src) -I $(srctree)/$(src)/$(GVT_DIR)/ > -i915-y += $(addprefix $(GVT_DIR)/, $(GVT_SOURCE)) > diff --git a/drivers/gpu/drm/i915/gvt/trace.h b/drivers/gpu/drm/i915/gvt/trace.h > index 6d787750d279f..348f57f8301db 100644 > --- a/drivers/gpu/drm/i915/gvt/trace.h > +++ b/drivers/gpu/drm/i915/gvt/trace.h > @@ -379,5 +379,5 @@ TRACE_EVENT(render_mmio, > #undef TRACE_INCLUDE_PATH > #define TRACE_INCLUDE_PATH . > #undef TRACE_INCLUDE_FILE > -#define TRACE_INCLUDE_FILE trace > +#define TRACE_INCLUDE_FILE gvt/trace > #include <trace/define_trace.h> -- Jani Nikula, Intel Open Source Graphics Center

1 0

[PATCH v2 0/2] drm/i915: Failsafe migration blits
by Thomas Hellström 02 Nov '21

02 Nov '21

This patch series introduces failsafe migration blits. The reason for this seemingly strange concept is that if the initial clearing or readback of LMEM fails for some reason[1], and we then set up either GPU- or CPU ptes to the allocated LMEM, we can expose old contents from other clients. So after each migration blit to LMEM, attach a dma-fence callback that checks the migration fence error value and if it's an error, performs a memcpy blit, instead. Patch 1 splits out the TTM move code into separate files Patch 2 implements the failsafe blits and related self-tests [1] There are at least two ways we could trigger exposure of uninitialized LMEM assuming the migration blits themselves never trigger a gpu hang. a) A gpu operation preceding a pipelined eviction blit resets and sets the error fence to -EIO, and the error is propagated across the TTM manager to the clear / swapin blit of a newly allocated TTM resource. It aborts and leaves the memory uninitialized. b) Something wedges the GT while a migration blit is submitted. It ends up never executed and TTM can fault user-space cpu-ptes into uninitialized memory. Thomas Hellström (2): drm/i915/ttm: Reorganize the ttm move code drm/i915/ttm: Failsafe migration blits drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 328 ++--------- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 35 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 520 ++++++++++++++++++ drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h | 43 ++ .../drm/i915/gem/selftests/i915_gem_migrate.c | 24 +- 6 files changed, 670 insertions(+), 281 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c create mode 100644 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.h -- 2.31.1

2 5

Re: [PATCH 02/29] drm/i915/gvt: integrate into the main Makefile
by Jason Gunthorpe 02 Nov '21

02 Nov '21

On Tue, Nov 02, 2021 at 08:05:34AM +0100, Christoph Hellwig wrote: > Remove the separately included Makefile and just use the relative > reference from the main i915 Makefile as for source files in other > subdirectories. > > Signed-off-by: Christoph Hellwig <hch(a)lst.de> > --- > drivers/gpu/drm/i915/Makefile | 29 ++++++++++++++++++++++++----- > drivers/gpu/drm/i915/gvt/Makefile | 9 --------- > drivers/gpu/drm/i915/gvt/trace.h | 2 +- > 3 files changed, 25 insertions(+), 15 deletions(-) > delete mode 100644 drivers/gpu/drm/i915/gvt/Makefile Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> > - > -ifeq ($(CONFIG_DRM_I915_GVT),y) > -i915-y += intel_gvt.o > -include $(src)/gvt/Makefile > -endif > +i915-$(CONFIG_DRM_I915_GVT) += \ > + intel_gvt.o \ > + gvt/gvt.o \ > + gvt/aperture_gm.o \ > + gvt/handlers.o \ > + gvt/vgpu.o \ > + gvt/trace_points.o \ > + gvt/firmware.o \ > + gvt/interrupt.o \ > + gvt/gtt.o \ > + gvt/cfg_space.o \ > + gvt/opregion.o \ > + gvt/mmio.o \ > + gvt/display.o \ > + gvt/edid.o \ > + gvt/execlist.o \ > + gvt/scheduler.o \ > + gvt/sched_policy.o \ > + gvt/mmio_context.o \ > + gvt/cmd_parser.o \ > + gvt/debugfs.o \ > + gvt/fb_decoder.o \ > + gvt/dmabuf.o \ > + gvt/page_track.o nit, nicer to sort makefile lists Jason

1 0

[PATCH v3 1/3] arm64: dts: qcom: sc7280: add display dt nodes
by Sankeerth Billakanti 02 Nov '21

02 Nov '21

From: Krishna Manikandan <quic_mkrishn(a)quicinc.com> Add mdss and mdp DT nodes for sc7280. Signed-off-by: Krishna Manikandan <quic_mkrishn(a)quicinc.com> Reported-by: kernel test robot <lkp(a)intel.com> Reviewed-by: Stephen Boyd <swboyd(a)chromium.org> Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Sankeerth Billakanti <quic_sbillaka(a)quicinc.com> --- Changes in v3: None Changes in v2: - Rename display dt nodes (Stephen Boyd) - Add clock names one per line for readability (Stephen Boyd) arch/arm64/boot/dts/qcom/sc7280.dtsi | 90 ++++++++++++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi index 365a2e0..a4536b6 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -2704,6 +2704,96 @@ #power-domain-cells = <1>; }; + mdss: display-subsystem@ae00000 { + compatible = "qcom,sc7280-mdss"; + reg = <0 0x0ae00000 0 0x1000>; + reg-names = "mdss"; + + power-domains = <&dispcc DISP_CC_MDSS_CORE_GDSC>; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", + "ahb", + "core"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>; + assigned-clock-rates = <300000000>; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + interconnects = <&mmss_noc MASTER_MDP0 0 &mc_virt SLAVE_EBI1 0>; + interconnect-names = "mdp0-mem"; + + iommus = <&apps_smmu 0x900 0x402>; + + #address-cells = <2>; + #size-cells = <2>; + ranges; + + status = "disabled"; + + mdp: display-controller@ae01000 { + compatible = "qcom,sc7280-dpu"; + reg = <0 0x0ae01000 0 0x8f030>, + <0 0x0aeb0000 0 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&gcc GCC_DISP_SF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", + "nrt_bus", + "iface", + "lut", + "core", + "vsync"; + assigned-clocks = <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>; + assigned-clock-rates = <300000000>, + <19200000>, + <19200000>; + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmhpd SC7280_CX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + status = "disabled"; + + mdp_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + required-opps = <&rpmhpd_opp_low_svs>; + }; + + opp-300000000 { + opp-hz = /bits/ 64 <300000000>; + required-opps = <&rpmhpd_opp_svs>; + }; + + opp-380000000 { + opp-hz = /bits/ 64 <380000000>; + required-opps = <&rpmhpd_opp_svs_l1>; + }; + + opp-506666667 { + opp-hz = /bits/ 64 <506666667>; + required-opps = <&rpmhpd_opp_nom>; + }; + }; + }; + }; + pdc: interrupt-controller@b220000 { compatible = "qcom,sc7280-pdc", "qcom,pdc"; reg = <0 0x0b220000 0 0x30000>; -- 2.7.4

1 2

[PATCH v5 0/3] drm/i915: Prepare error capture for asynchronous migration
by Thomas Hellström 02 Nov '21

02 Nov '21

This patch series prepares error capture for asynchronous migration, where the vma pages may not reflect the pages the GPU is currently executing from but may be several migrations ahead. The first patch introduces vma state snapshots that record the vma state at request submission time. It also takes additional measures to make sure that the capture list and request is not disappearing from under us while capturing. The latter may otherwise happen if a heartbeat triggered parallel capture is running during a manual reset which retires the request. The second patch changes the allocation mode during capture to reflect that capturing is typically done in the fence signalling critical path. More details on the patch itself. Finally the last patch is more of a POC patch and not strictly needed yet, but will be (or at least something very similar) soon for async unbinding. It will make sure that unbinding doesn't complete or signal completion before capture is done. Async reuse of memory can't happen until unbinding signals complete and without waiting for capture done, we might capture contents of reused memory. Before the last patch the vma active is instead still keeping the vma alive, but that will not work with async unbinding anymore, and also it is still not clear how we guarantee keeping the vma alive long enough to even grab an active reference during capture. v2: - Mostly Fixes for selftests and rebinding. See patch 3. v3: - Honor the unbind fence also when evicting for suspend on gen6. - Minor cleanups on patch 3. v4: - Break out patch 2 from patch 1. v5: - Ditch a patch from the since it's already commited. - Use __GFP_KSWAPD_RECLAIM rather than GFP_NOWAIT in patch 2. Thomas Hellström (3): drm/i915: Update error capture code to avoid using the current vma state drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code drm/i915: Initial introduction of vma resources drivers/gpu/drm/i915/Makefile | 1 + .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 137 ++++++++++-- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +- .../drm/i915/gt/intel_execlists_submission.c | 2 +- drivers/gpu/drm/i915/i915_gpu_error.c | 180 ++++++++++----- drivers/gpu/drm/i915/i915_request.c | 63 ++++-- drivers/gpu/drm/i915/i915_request.h | 20 +- drivers/gpu/drm/i915/i915_vma.c | 206 +++++++++++++++++- drivers/gpu/drm/i915/i915_vma.h | 20 +- drivers/gpu/drm/i915/i915_vma_snapshot.c | 131 +++++++++++ drivers/gpu/drm/i915/i915_vma_snapshot.h | 112 ++++++++++ drivers/gpu/drm/i915/i915_vma_types.h | 5 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 98 +++++---- 13 files changed, 837 insertions(+), 146 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.c create mode 100644 drivers/gpu/drm/i915/i915_vma_snapshot.h -- 2.31.1

1 3

amdgpu on Ryzen 5600G -- 'purple' background [WAS: Re: amdgpu "Fatal error during GPU init"; Ryzen 5600G integrated GPU + kernel 5.14.13}
by PGNet Dev 02 Nov '21

02 Nov '21

Now I'm just guessing. TBH, I've no idea what's causing this reproducible 'purple' background with `amdgpu` on Ryzen 5XXXG. All I can definitively say is that it's real, reproducible, seen elsewhere in the wild for radeon/amd Possibly related to driver defaulting to HDMI YCbCr color, rather than RGB. I'll add more info as requested when someone with better knowledge of what's needed chimes in. For now, here's the last bits of info I've found. This issue https://community.amd.com/t5/drivers-software/purple-ish-desktop-screen-aft… suggests in 2019, Microsoft fixed driver for this purple-hue issue on Ryzen https://support.microsoft.com/en-ca/help/4505903/windows-10-update-kb4505903 Seems like this had to do with the driver selecting YCbCr for HDMI rather than RGB ... Here, Setting the amdgpu HDMI Pixel Format on Linux https://www.wezm.net/v2/posts/2020/linux-amdgpu-pixel-format/ mentions "... I looked for a way to change the pixel format output from the HDMI port of my RX560 graphics card. Turns out this is super easy on Windows, but the amdgpu driver on Linux does not support changing it. ..." and refers to an EDID hack/fix https://www.wezm.net/v2/posts/2020/linux-amdgpu-pixel-format/#the-fix More digging led to AMDGPU fails to properly parse EDID information from display, causing weird resolution setting issues https://gitlab.freedesktop.org/drm/amd/-/issues/1589 with a familiar 'purple' display, https://gitlab.freedesktop.org/drm/amd/uploads/2e2b485aed26d77a9066ca9ea516… and points to an amd issue "Created 3 years ago", no color format choice in amdgpu https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_852860 and finally, a patch [PATCH] drm/amdgpu/dc: Pixel encoding DRM property and module parameter https://www.spinics.net/lists/amd-gfx/msg53281.html which suggests adding pixel_encoding=rgb checking hwinfo --gfxcard | egrep "Model|SysFS ID" SysFS ID: /devices/pci0000:00/0000:00:08.1/0000:30:00.0 Model: "ATI VGA compatible controller" SysFS ID: /devices/pci0000:00/0000:00:01.1/0000:10:00.0 Model: "nVidia GP108 [GeForce GT 1030]" ls -ald /sys/class/drm/card* | grep 30: lrwxrwxrwx 1 root root 0 Oct 30 09:56 /sys/class/drm/card0 -> ../../devices/pci0000:00/0000:00:08.1/0000:30:00.0/drm/card0/ lrwxrwxrwx 1 root root 0 Oct 30 09:56 /sys/class/drm/card0-DP-1 -> ../../devices/pci0000:00/0000:00:08.1/0000:30:00.0/drm/card0/card0-DP-1/ lrwxrwxrwx 1 root root 0 Oct 30 09:56 /sys/class/drm/card0-HDMI-A-1 -> ../../devices/pci0000:00/0000:00:08.1/0000:30:00.0/drm/card0/card0-HDMI-A-1/ lrwxrwxrwx 1 root root 0 Oct 30 09:56 /sys/class/drm/card0-HDMI-A-2 -> ../../devices/pci0000:00/0000:00:08.1/0000:30:00.0/drm/card0/card0-HDMI-A-2/ ( why are there *2* HDMI for card0, when only 1 phy output? ) next, added to kernel cmdline video=HDMI-A-1:2560x1440@60:pixel_encoding=rgb video=HDMI-A-2:2560x1440@60:pixel_encoding=rgb and, for good measure, cat /etc/modprobe.d/amdgpu.conf re-gen'd initrd, and rebooted. STILL getting the purple screen :-/ dmesg, after boot completion, dmesg | grep encod ... [ 1.650090] amdgpu: unknown parameter 'pixel_encoding' ignored ... Paying close(r) attention, screen output after grub-select starts out with black-as-usual background, but switches to purple immediately after: dmesg ... >> [ 1.268709] systemd[1]: Starting dracut initqueue hook... ... where, dmesg | egrep -i "atpx|vga|drm|amdgpu|initqueue" [ 0.329804] ACPI BIOS Error (bug): Failure creating named object [\_SB.PCI0.GPP0.VGA], AE_ALREADY_EXISTS (20210604/dswload2-326) [ 0.351328] pci 0000:10:00.0: vgaarb: VGA device added: decodes=io+mem,owns=none,locks=none [ 0.351328] pci 0000:30:00.0: vgaarb: setting as boot VGA device [ 0.351328] pci 0000:30:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none [ 0.351328] pci 0000:10:00.0: vgaarb: bridge control possible [ 0.351328] pci 0000:30:00.0: vgaarb: bridge control possible [ 0.351328] vgaarb: loaded [ 0.410851] fb0: EFI VGA frame buffer device [ 1.264753] ACPI: video: Video Device [VGA] (multi-head: yes rom: no post: no) [ 1.265256] ACPI: video: Video Device [VGA1] (multi-head: yes rom: no post: no) [ 1.268709] systemd[1]: Starting dracut initqueue hook... [ 1.650090] amdgpu: unknown parameter 'pixel_encoding' ignored [ 1.650094] amdgpu: unknown parameter 'modeset' ignored [ 1.650416] [drm] amdgpu kernel modesetting enabled. [ 1.650432] vga_switcheroo: detected switching method \_SB_.PCI0.GP17.VGA_.ATPX handle [ 1.650720] ATPX version 1, functions 0x00000001 [ 1.650751] ATPX Hybrid Graphics [ 1.656232] amdgpu: Virtual CRAT table created for CPU [ 1.656240] amdgpu: Topology: Add CPU node [ 1.656299] fb0: switching to amdgpudrmfb from EFI VGA [ 1.656413] amdgpu 0000:30:00.0: vgaarb: deactivate vga console [ 1.656503] [drm] initializing kernel modesetting (RENOIR 0x1002:0x1638 0x1002:0x1636 0xC9). [ 1.656516] amdgpu 0000:30:00.0: amdgpu: Trusted Memory Zone (TMZ) feature enabled [ 1.656548] [drm] register mmio base: 0xFCB00000 [ 1.656548] [drm] register mmio size: 524288 [ 1.656550] [drm] PCIE atomic ops is not supported [ 1.657578] [drm] add ip block number 0 <soc15_common> [ 1.657579] [drm] add ip block number 1 <gmc_v9_0> [ 1.657581] [drm] add ip block number 2 <vega10_ih> [ 1.657581] [drm] add ip block number 3 <psp> [ 1.657582] [drm] add ip block number 4 <smu> [ 1.657583] [drm] add ip block number 5 <gfx_v9_0> [ 1.657584] [drm] add ip block number 6 <sdma_v4_0> [ 1.657585] [drm] add ip block number 7 <dm> [ 1.657586] [drm] add ip block number 8 <vcn_v2_0> [ 1.657587] [drm] add ip block number 9 <jpeg_v2_0> [ 1.663332] [drm] BIOS signature incorrect 0 0 [ 1.663360] amdgpu 0000:30:00.0: amdgpu: Fetched VBIOS from ROM BAR [ 1.663363] amdgpu: ATOM BIOS: 113-CEZANNE-018 [ 1.664115] [drm] VCN decode is enabled in VM mode [ 1.664117] [drm] VCN encode is enabled in VM mode [ 1.664118] [drm] JPEG decode is enabled in VM mode [ 1.664147] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit [ 1.664153] amdgpu 0000:30:00.0: amdgpu: VRAM: 512M 0x000000F400000000 - 0x000000F41FFFFFFF (512M used) [ 1.664155] amdgpu 0000:30:00.0: amdgpu: GART: 1024M 0x0000000000000000 - 0x000000003FFFFFFF [ 1.664156] amdgpu 0000:30:00.0: amdgpu: AGP: 267419648M 0x000000F800000000 - 0x0000FFFFFFFFFFFF [ 1.664161] [drm] Detected VRAM RAM=512M, BAR=512M [ 1.664162] [drm] RAM width 128bits DDR4 [ 1.664200] [drm] amdgpu: 512M of VRAM memory ready [ 1.664201] [drm] amdgpu: 3072M of GTT memory ready. [ 1.664206] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 1.664285] [drm] PCIE GART of 1024M enabled. [ 1.664286] [drm] PTB located at 0x000000F400900000 [ 1.668403] amdgpu 0000:30:00.0: amdgpu: PSP runtime database doesn't exist [ 1.684148] [drm] Loading DMUB firmware via PSP: version=0x01010019 [ 1.699355] [drm] Found VCN firmware Version ENC: 1.14 DEC: 5 VEP: 0 Revision: 20 [ 1.699368] amdgpu 0000:30:00.0: amdgpu: Will use PSP to load VCN firmware [ 2.119364] nvidia 0000:10:00.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=none:owns=none [ 2.371596] [drm] [nvidia-drm] [GPU ID 0x00001000] Loading driver [ 2.425174] [drm] reserve 0x400000 from 0xf41f800000 for PSP TMR [ 2.506778] amdgpu 0000:30:00.0: amdgpu: RAS: optional ras ta ucode is not available [ 2.515189] amdgpu 0000:30:00.0: amdgpu: RAP: optional rap ta ucode is not available [ 2.515191] amdgpu 0000:30:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available [ 2.515540] amdgpu 0000:30:00.0: amdgpu: SMU is initialized successfully! [ 2.516855] [drm] kiq ring mec 2 pipe 1 q 0 [ 2.517561] [drm] Display Core initialized with v3.2.141! [ 2.517981] [drm] DMUB hardware initialized: version=0x01010019 [ 2.577117] [drm] VCN decode and encode initialized successfully(under DPG Mode). [ 2.577132] [drm] JPEG decode initialized successfully. [ 2.578072] kfd kfd: amdgpu: Allocated 3969056 bytes on gart [ 2.707339] amdgpu: HMM registered 512MB device memory [ 2.707361] amdgpu: SRAT table not found [ 2.707361] amdgpu: Virtual CRAT table created for GPU [ 2.708098] amdgpu: Topology: Add dGPU node [0x1638:0x1002] [ 2.708103] kfd kfd: amdgpu: added device 1002:1638 [ 2.708170] amdgpu 0000:30:00.0: amdgpu: SE 1, SH per SE 2, CU per SH 18, active_cu_number 27 [ 2.709057] [drm] fb mappable at 0x90CD2000 [ 2.709059] [drm] vram apper at 0x90000000 [ 2.709059] [drm] size 14745600 [ 2.709059] [drm] fb depth is 24 [ 2.709060] [drm] pitch is 10240 [ 2.896150] fbcon: amdgpu (fb0) is primary device [ 3.000331] amdgpu 0000:30:00.0: [drm] fb0: amdgpu frame buffer device [ 3.009001] amdgpu 0000:30:00.0: amdgpu: ring gfx uses VM inv eng 0 on hub 0 [ 3.009004] amdgpu 0000:30:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0 [ 3.009006] amdgpu 0000:30:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0 [ 3.009006] amdgpu 0000:30:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 5 on hub 0 [ 3.009007] amdgpu 0000:30:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 6 on hub 0 [ 3.009008] amdgpu 0000:30:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 7 on hub 0 [ 3.009009] amdgpu 0000:30:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 8 on hub 0 [ 3.009010] amdgpu 0000:30:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 9 on hub 0 [ 3.009010] amdgpu 0000:30:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 10 on hub 0 [ 3.009011] amdgpu 0000:30:00.0: amdgpu: ring kiq_2.1.0 uses VM inv eng 11 on hub 0 [ 3.009012] amdgpu 0000:30:00.0: amdgpu: ring sdma0 uses VM inv eng 0 on hub 1 [ 3.009013] amdgpu 0000:30:00.0: amdgpu: ring vcn_dec uses VM inv eng 1 on hub 1 [ 3.009014] amdgpu 0000:30:00.0: amdgpu: ring vcn_enc0 uses VM inv eng 4 on hub 1 [ 3.009015] amdgpu 0000:30:00.0: amdgpu: ring vcn_enc1 uses VM inv eng 5 on hub 1 [ 3.009016] amdgpu 0000:30:00.0: amdgpu: ring jpeg_dec uses VM inv eng 6 on hub 1 [ 3.155840] [drm] Initialized nvidia-drm 0.0.0 20160202 for 0000:10:00.0 on minor 1 [ 3.156216] [drm] Initialized amdgpu 3.42.0 20150101 for 0000:30:00.0 on minor 0 [ 4.598742] systemd[1]: Finished dracut initqueue hook. [ 5.043799] systemd[1]: dracut-initqueue.service: Deactivated successfully. [ 5.043873] systemd[1]: Stopped dracut initqueue hook. [ 10.007951] systemd[1]: Starting Load Kernel Module drm... [ 10.170619] systemd[1]: modprobe(a)drm.service: Deactivated successfully. [ 10.170718] systemd[1]: Finished Load Kernel Module drm. [ 13.750415] snd_hda_intel 0000:10:00.1: Handle vga_switcheroo audio client [ 13.750632] snd_hda_intel 0000:30:00.1: Handle vga_switcheroo audio client [ 13.879276] snd_hda_intel 0000:30:00.1: bound 0000:30:00.0 (ops amdgpu_dm_audio_component_bind_ops [amdgpu]) Is that kernel/modconfig config incorrect? Not relevant to the problem? Something else(where) needed?

1 1

[PATCH v2 0/2] Add a drm.disable_native_drivers command line option
by Javier Martinez Canillas 02 Nov '21

02 Nov '21

This patch-series add a drm.disable_native_drivers option that can be used to prevent native DRM drivers to be probed. That way, the simpledrm driver won't be removed which can be useful to troubleshoot DRM drivers problems. Patch #1 is just a small preparatory patch that moves the logic to remove the conflicting fbdev frame buffer to a helper function. Patch #2 adds the new kernel command line option and if set, prevents the drm_aperture_remove_conflicting_framebuffers() function to succeed. This is a v2 that addresses the issues pointed out by Thomas and Neal. Best regards, Javier Changes in v2: - Rename command line parameter to drm.disable_native_drivers. - Return -EBUSY instead of -EINVAL when the function fails. - Invert the parameter logic and make it false by default. Javier Martinez Canillas (2): drm/aperture: Move conflicting fbdev frame buffer removal to a helper drm/aperture: Prevent conflicting framebuffers removal if option is set drivers/gpu/drm/drm_aperture.c | 54 ++++++++++++++++++++++++++-------- 1 file changed, 42 insertions(+), 12 deletions(-) -- 2.31.1

2 3

[PATCH v4 0/5] Add support for eDP controller on SC7280
by Sankeerth Billakanti 02 Nov '21

02 Nov '21

This series will add eDP controller support for Qualcomm SC7280 platform. These patches are baseline changes with which we can enable eDP display on sc7280. The sc7280 eDP controller driver can also support additional features such as no_hpd detection, PSR, etc. which will be enabled in subsequent patch series. This is based on Bjorn's changes in the below mentioned series to support both eDP and DP programming through the same driver: https://patchwork.kernel.org/project/linux-arm-msm/list/?series=564841 Sankeerth Billakanti (5): dt-bindings: msm/dp: Add DP compatible strings for sc7280 drm/msm/dp: Add DP controllers for sc7280 drm/dp: Add macro to check max_downspread capability drm/msm/dp: Enable downspread for supported DP sinks drm/msm/dp: Enable ASSR for supported DP sinks .../bindings/display/msm/dp-controller.yaml | 2 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 4 ++-- drivers/gpu/drm/msm/dp/dp_ctrl.c | 23 +++++++++++++++++++--- drivers/gpu/drm/msm/dp/dp_display.c | 9 +++++++++ include/drm/drm_dp_helper.h | 7 +++++++ 5 files changed, 40 insertions(+), 5 deletions(-) -- 2.7.4

1 5

[PATCH v3 00/34] component: Make into an aggregate bus
by Stephen Boyd 01 Nov '21

01 Nov '21

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. I sent this to gregkh which may be incorrect but I don't know what better tree to send it all through. Maybe drm? 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 (34): component: Introduce struct aggregate_device component: Remove most references to 'master' 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 drm/zte: 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 | 540 ++++++++++-------- .../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 | 17 +- 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/gpu/drm/zte/zx_drm_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/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, 767 insertions(+), 486 deletions(-) Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> 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> base-commit: e4e737bb5c170df6135a127739a9e6148ee3da82 -- https://chromeos.dev

3 39

[PATCH] drm/msm/dsi: set default num_data_lanes
by Philip Chen 01 Nov '21

01 Nov '21

If "data_lanes" property of the dsi output endpoint is missing in the DT, num_data_lanes would be 0 by default, which could cause dsi_host_attach() to fail if dsi->lanes is set to a non-zero value by the bridge driver. According to the binding document of msm dsi controller, the input/output endpoint of the controller is expected to have 4 lanes. So let's set num_data_lanes to 4 by default. Signed-off-by: Philip Chen <philipchen(a)chromium.org> --- drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index c86b5090fae6..a32eb33dfc14 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -1696,6 +1696,8 @@ static int dsi_host_parse_lane_data(struct msm_dsi_host *msm_host, if (!prop) { DRM_DEV_DEBUG(dev, "failed to find data lane mapping, using default\n"); + /* Set the number of date lanes to 4 by default. */ + msm_host->num_data_lanes = 4; return 0; } -- 2.33.1.1089.g2158813163f-goog

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel November 2021