dri-devel March 2021

dri-devel@lists.freedesktop.org

326 participants
867 discussions

Re: [PATCH] dma-buf: heaps: Set VM_PFNMAP in mmap for system and cma heaps
by John Stultz 02 Mar '21

02 Mar '21

On Sat, Feb 27, 2021 at 1:44 AM Christoph Hellwig <hch(a)infradead.org> wrote: > > On Fri, Feb 26, 2021 at 08:36:55AM +0100, Daniel Vetter wrote: > > Also given that both deal with struct page there's a ton of divergence > > between these two that doesn't make much sense. Maybe could even share > > the code fully, aside from how you allocate the struct pages. > > I've been saying that since the code was first submitted. Once pages > are allocated from CMA … [View More]

1 0

[RFC 00/24] drm/msm/dsi: refactor MSM DSI PHY/PLL drivers
by Dmitry Baryshkov 01 Mar '21

01 Mar '21

This is an RFC attempt to restructure MSM DSI PHY drivers. What started as an attempt to grok the overcomplicated PHY drivers, has lead up to the idea of merging PHY and PLL code, reducing abstractions, code duplication, dropping dead code, etc. The patches were mainly tested on RB5 (sm8250, 7nm) and lightly tested on RB3 (sdm845, 10nm), DB410c (apq8016, 28nm-lp). The following changes since commit fe07bfda2fb9cdef8a4d4008a409bb02f35f1bd8: Linux 5.12-rc1 (2021-02-28 16:05:19 -0800) are … [View More]available in the Git repository at: ssh://git@git.linaro.org/people/dmitry.baryshkov/kernel.git dsi-phy-rfc for you to fetch changes up to 819a9071587f1acba14a6780f422d78fdb55d671: arm64: dts: qcom: sdm845: assign DSI clock source parents (2021-03-02 02:23:14 +0300) ---------------------------------------------------------------- Dmitry Baryshkov (24): drm/msm/dsi: fuse dsi_pll_* code into dsi_phy_* code drm/msm/dsi: drop multiple pll enable_seq support drm/msm/dsi: move all PLL callbacks into PHY config struct drm/msm/dsi: move min/max PLL rate to phy config drm/msm/dsi: remove msm_dsi_pll_set_usecase drm/msm/dsi: stop setting clock parents manually arm64: dts: qcom: sm8250: assign DSI clock source parents drm/msm/dsi: push provided clocks handling into a generic code clk: mux: provide devm_clk_hw_register_mux() clk: divider: add devm_clk_hw_register_divider drm/msm/dsi: use devm_clk_*register to registe DSI PHY clocks drm/msm/dsi: use devm_of_clk_add_hw_provider drm/msm/dsi: replace PHY's init callback with configurable data drm/msm/dsi: make save/restore_state phy-level functions drm/msm/dsi: limit vco_delay to 28nm PHY drm/msi/dsi: inline msm_dsi_pll_helper_clk_prepare/unprepare drm/msm/dsi: make save_state/restore_state callbacks accept msm_dsi_phy drm/msm/dsi: drop msm_dsi_pll abstracton drm/msm/dsi: drop PLL accessor functions drm/msm/dsi: move ioremaps to dsi_phy_driver_probe drm/msm/dsi: remove duplicate fields from dsi_pll_Nnm instances drm/msm/dsi: remove temp data from global pll structure drm/msm/dsi: drop global msm_dsi_phy_type enumaration arm64: dts: qcom: sdm845: assign DSI clock source parents arch/arm64/boot/dts/qcom/sdm845.dtsi | 6 + arch/arm64/boot/dts/qcom/sm8250.dtsi | 6 + drivers/clk/clk-mux.c | 35 + drivers/gpu/drm/msm/Kconfig | 8 - drivers/gpu/drm/msm/Makefile | 9 - drivers/gpu/drm/msm/dsi/dsi.h | 56 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 51 -- drivers/gpu/drm/msm/dsi/dsi_manager.c | 18 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 129 +-- drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 31 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 741 ++++++++++++++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 925 ++++++++++++++++++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c | 3 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 662 +++++++++++++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 476 +++++++++- drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 769 +++++++++++++++- drivers/gpu/drm/msm/dsi/pll/dsi_pll.c | 184 ---- drivers/gpu/drm/msm/dsi/pll/dsi_pll.h | 130 --- drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 881 ------------------ drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c | 1096 ----------------------- drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c | 643 ------------- drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c | 526 ----------- drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c | 912 ------------------- include/linux/clk-provider.h | 30 + 24 files changed, 3678 insertions(+), 4649 deletions(-) delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_14nm.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm_8960.c delete mode 100644 drivers/gpu/drm/msm/dsi/pll/dsi_pll_7nm.c [View Less]

1 24

Re: [PATCH v6 3/3] drm: Add GUD USB Display driver
by Peter Stuge 01 Mar '21

01 Mar '21

Hi Noralf, Peter Stuge wrote: > I'll prepare a test setup for the RGB-TFT on the weekend. So implementing a GUD and looking at the protocol from yet another angle gives more new insights - surprise. :) Here are some thoughts so far: * GUD_REQ_SET_VERSION does still rub me wrong; it seems potentially quite complex to maintain compatibility in two places; both for host and device. I don't want to insist on removing it, but at a minimum it's quite unusual. Part of the idea in USB is … [View More]

2 1

[Bug 209713] New: amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_link_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state
by bugzilla-daemon＠bugzilla.kernel.org 01 Mar '21

01 Mar '21

https://bugzilla.kernel.org/show_bug.cgi?id=209713 Bug ID: 209713 Summary: amdgpu drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_l ink_encoder.c:483 dcn10_get_dig_frontend+0x9e/0xc0 [amdgpu] when resuming from S3 state Product: Drivers Version: 2.5 Kernel Version: 5.8.13-arch1-1 Hardware: x86-64 OS: Linux Tree: Mainline Status: … [View More]

1 21

rcar_du_kms.c:781:24: error: passing argument 1 of '__drmm_add_action' from incompatible pointer type
by Naresh Kamboju 01 Mar '21

01 Mar '21

On stable rc 5.11 the x86_64 build failed due to below errors/warnings. drivers/gpu/drm/rcar-du/rcar_du_kms.c: In function 'rcar_du_modeset_cleanup': drivers/gpu/drm/rcar-du/rcar_du_kms.c:754:32: error: implicit declaration of function 'to_rcar_du_device'; did you mean 'to_rtc_device'? [-Werror=implicit-function-declaration] struct rcar_du_device *rcdu = to_rcar_du_device(dev); ^~~~~~~~~~~~~~~~~ to_rtc_device drivers/gpu/drm/… [View More]

3 3

[Bug 208115] New: amdgpu (likely) - power management and display connection problems with an RX590 card
by bugzilla-daemon＠bugzilla.kernel.org 01 Mar '21

01 Mar '21

https://bugzilla.kernel.org/show_bug.cgi?id=208115 Bug ID: 208115 Summary: amdgpu (likely) - power management and display connection problems with an RX590 card Product: Drivers Version: 2.5 Kernel Version: 5.x.x Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) … [View More]Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: h_mailinglists(a)posteo.de Regression: No Created attachment 289583 --> https://bugzilla.kernel.org/attachment.cgi?id=289583&action=edit excerpt from dmesg grepping amdgpu Bug report - power management and display connection problems with an RX590 card Hello developer team Please bear with me, it is my first bug report on the actual kernel. It _might_ partially be related to https://bugzilla.kernel.org/show_bug.cgi?id=201139 background / generic info: I have an AMD RX 590, which is giving me some severe troubles. I have a multitude of ATI/AMD cards/APUs in use for years, mostly Gentoo Linux, a few Deb. derivatives and W32. RX 590 (PCIe) RX 560 (PCIe) HD 5770 (PCIe) HD 5670 (PCIe) HD 5450 and the likes (PCI, PCIe) HD 3870 (PCIe) Kabini (Athlon 5350) (AM1) Kabini E-2100 (soldered/BGA) E-350 (soldered/BGA) Geode LX ;-) (soldered/BGA / companion chip) and more the very chip/card in question: Sapphire Nitro+ Radeon RX 590 8G 50th Anniversary, 8192 MB GDDR5 (the golden one) the following setup it is currently dysfunctional: RX 590 Zen+ 2700 MSI PC-Mate B-350 (latest FW) 16 GiB RAM PSU BeQuiet DarkPowerPro 550 (should be strong enough, and problems are on the low power state side) Monitor: Eizo EV2436W hooked up via DP The setup works _nicely_ with a different GPU (e.g. HD 5450, okay, that's not amdgpu driver, but anyway). My other actual amdgpu card, the RX 560 (Polaris 11) works like a charm in an FX 6300 setup. The very (Eizo) screen also works flawless on my Kabini (though there I have to use a HDMI-2-DVI adapter connection); also an old Geode LX runs fairly well via VGA. software (Gentoo) Linux (5.x.x kernel; tried various versions over time, dind't really get much better), libdrm 2.4.9x / 2.4.10x, mesa 19.3.2 or later, xf86-video-amdgpu 19.1.0 I built a box based on a Ryzen Zen+ 2700, MSI PC-Mate B-350 mainboard. While I was setting it up I ran my elderly HD 5670 in it and everything was fine. All other cards in that ZEN+ system I tried so far worked like a charm. Severe video transcoding (CPU based), just "desktopping around", severe compiling (<-Gentoo): No problem! Power management? No problem! With the RX 590 it's a sheer pain. problems: * GPU not coming back once monitor goes into powersaving * link lost on every second power save (screen blanking / suspend / off / BACO) relation to #201139 ? * reading EDID problems message I found once in dmesg could be a hint (but it seems all others (cards or different boxes) can obtain the EDID) * Sometimes it seems I can still send commands via keyboard / work blindly and thus I might try to start a xrandr script to switch on/off ("reset") the digital outputs? * occasionally switching to VT (and back) helps, sometimes not, and the hardware is frozen; even REISUB (!) won't work. * once I also got it back - but - in max. 800 x 600 resolution * sometimes I can re-gain a signal by replugging the cable switching monitor on/off * freezes (which seem power management related) e.g. running a standard compile job host system had little to do, compilation was running inside a chroot env. (amd64 on amd64) next morning: LEDs on mainboard/GPU still glowing, fans spinning, system entirely frozen, not even REISUB would help nothing in the logs from /var/log/emerge.log it must have stopped somewhere in the middle of a harmless compile (iirc. it was sys-fs/fuse or something), and I don't use strange CFLAGs which might throw illegeal opcodes or something * power consumption is too high during idle * strange power readings in "sensors" at least 33 W (should be 10 W on idling and 3 W in BACO / zero core) * hint: also the W32 / W64 blob showed quite high consumption during desktop idle (AMD blob / GPU-Z) * wall measured might be slightly better but whole system (Zen+, GPU, 2 SSDs and one HDD, hardly any USB periphery no other cards in slots one BD/DVD/CDROM) never drops below 55 W, it's rather higher Is there something I might have missed? Should I try to obtain more verbose logs? Is there any "x-trace" tool that I could run? Radeontop information outputs? I'll attach one of the few logs I could obtain which might contains some hints towards what is happening. on my to-do list: * try a different monitor (though that very EIZO monitor worked like a charm with everything else I threw at it) * try HDMI instead of DP, but I think I don't have HDMI monitors at hand * try the RX590 in a different box (e.g. my FX 6300 unit, which currently runs flawless with an RX 560) - and see if it still misbehaves... Sorry for the wall of text. keywords: link lost, power management problems, powerplay, device reset reinitialization, system freeze, x86-64 amd64, amdgpu, AMD RX 590 RX590 Polaris -- You are receiving this mail because: You are watching the assignee of the bug. [View Less]

1 3

[PATCH V3 0/2] Fix WLED FSC Sync and brightness Sync settings
by Kiran Gunda 01 Mar '21

01 Mar '21

This patch series has the following two WLED fixes 1. As per the current implementation, for WLED5, after the FSC (Full Scale Current) update the driver is incorrectly toggling the MOD_SYNC register instead of toggling the SYNC register. The patch 1/2 fixes this by toggling the SYNC register after FSC update. 2. Currently, the sync bits are transitioned from set-then-clear after FSC and brightness update. As per hardware team recommendation the FSC and brightness sync … [View More]

3 4

[PATCH 0/5] drm/omap: hdmi: improve hdmi4 CEC, add CEC for hdmi5
by Hans Verkuil 01 Mar '21

01 Mar '21

This series improves the drm_bridge support for CEC by introducing two new bridge ops in the first patch, and using those in the second patch. This makes it possible to call cec_s_conn_info() and set CEC_CAP_CONNECTOR_INFO for the CEC adapter, so userspace can associate the CEC adapter with the corresponding DRM connector. The third patch simplifies CEC physical address handling by using the cec_s_phys_addr_from_edid helper function that didn't exist when this code was originally written. … [View More]

5 20

2021 X.Org Board of Directions Nomination period ends next Sunday
by Harry Wentland 01 Mar '21

01 Mar '21

Unfortunately my previous email seems to not have been received by many people. I will send this email separately to each mailing list to hopefully get better coverage. The nomination period is currently ongoing. So far we have received 3 nominations and will need at least 4 to fill the vacant spots on the board. We hope you will consider putting your nomination forward. To nominate yourself or someone else please send the nomination, along with a personal statement to elections at x dot … [View More]

1 0

[PATCH 5.4 259/340] drm/nouveau/kms: handle mDP connectors
by Greg Kroah-Hartman 01 Mar '21

01 Mar '21

From: Karol Herbst <kherbst(a)redhat.com> commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream. In some cases we have the handle those explicitly as the fallback connector type detection fails and marks those as eDP connectors. Attempting to use such a connector with mutter leads to a crash of mutter as it ends up with two eDP displays. Information is taken from the official DCB documentation. Cc: stable(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: Ben Skeggs <… [View More]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2021