dri-devel January 2021

dri-devel@lists.freedesktop.org

322 participants
737 discussions

[Bug 211033] New: [bisected][regression] amdgpu: *ERROR* Restoring old state failed with -12
by bugzilla-daemon＠bugzilla.kernel.org 08 Mar '21

08 Mar '21

https://bugzilla.kernel.org/show_bug.cgi?id=211033 Bug ID: 211033 Summary: [bisected][regression] amdgpu: *ERROR* Restoring old state failed with -12 Product: Drivers Version: 2.5 Kernel Version: 5.10.4 Hardware: x86-64 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: zaltys(a)inbox.ru Regression: No I have AMD RX560 GPU which is connected to LG 27UD-88 display via ATEN CS782DP displayPort KVM switch. I can't reliably switch KVM port to the machine running Kernel 5.10.4 with previously mentioned GPU. Screen is usually blank and display even goes to standby after the first try, however sometimes (if I switch KVM ports quickly a few times) it turns on, but with wrong resolution. dmesg complains with: [drm:dm_restore_drm_connector_state] *ERROR* Restoring old state failed with -12 for every failed port switch. KVM switch is configured to "redetect display" - basically it emulates replugging when port is switched. I have been using it for 4 years with the same GPU and it worked correctly until Kernel 5.10.4 I did a bisect, and it showed the first bad commit was: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/dri… Reverting this commit fixed my issue (it works like pre 5.10.4) -- 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 19

[Bug 210849] New: Black screen after resume from long suspend. Open/Close lid. AMDGPU
by bugzilla-daemon＠bugzilla.kernel.org 08 Mar '21

08 Mar '21

https://bugzilla.kernel.org/show_bug.cgi?id=210849 Bug ID: 210849 Summary: Black screen after resume from long suspend. Open/Close lid. AMDGPU Product: Drivers Version: 2.5 Kernel Version: >=5.9 Hardware: All 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: xrootware(a)gmail.com Regression: No Created attachment 294295 --> https://bugzilla.kernel.org/attachment.cgi?id=294295&action=edit cut of dmesg Bug on kernel greater than 5.9 on Fedora 33. Black screen after resume from long suspend. Open/Close lid. More error like this https://bugzilla.redhat.com/show_bug.cgi?id=1884180 HARD RESET (power button 5 seconds) required to normal boot. System encountered a non-fatal error in drm_dev_register() WARNING: CPU: 2 PID: 323 at drivers/gpu/drm/drm_mode_config.c:617 drm_mode_config_validate+0x178/0x200 [drm] backtrace [-M-O] 33 L:[ 14+15 29/ 43] *(3144/3968b) 0010 0x00A [*][X] FС: 00007f051daef4c0(0000) GS:ffff8a3fb8a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22b257b56c CR3: 000000012ed8a000 CR4: 00000000003506f0 Call Trace: ? generic_reg_get+0x1d/0x30 [amdgpu] drm_get_last_vbltimestamp+0x8a/0xa0 [drm] drm_reset_vblank_timestamp+0x4b/0xb0 [drm] drm_crtc_vblank_on+0x7b/0x130 [drm] amdgpu_dm_atomic_commit_tail+0xd00/0x24c0 [amdgpu] commit_tail+0x94/0x130 [drm_kms_helper] drm_atomic_helper_commit+0x113/0x140 [drm_kms_helper] drm_atomic_helper_set_config+0x70/0xb0 [drm_kms_helper] drm_mode_setcrtc+0x1d3/0x6f0 [drm] ? avc_has_extended_perms+0x18d/0x3e0 ? drm_mode_getcrtc+0x180/0x180 [drm] drm_ioctl_kernel+0x86/0xd0 [drm] drm_ioctl+0x20f/0x3a0 [drm] ? drm_mode_getcrtc+0x180/0x180 [drm] amdgpu_drm_ioctl+0x49/0x80 [amdgpu] __x64_sys_ioctl+0x83/0xb0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f0521a5938b Code: 89 d8 49 8d 3c 1c 48 f7 d8 49 39 c4 72 b5 e8 1c ff ff ff 85 c0 78 ba 4c 89 e0 5b 5d 41 5c c3 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3 RSP: 002b:00007ffc9abfb628 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007ffc9abfb660 RCX: 00007f0521a5938b RDX: 00007ffc9abfb660 RSI: 00000000c06864a2 RDI: 0000000000000009 RBP: 00000000c06864a2 R08: 0000000000000000 R09: 0000556b0af88830 R10: 0000000000000000 R11: 0000000000000246 R12: 0000556b083821e0 R13: 0000000000000009 R14: 00007f0504006650 R15: 0000556b0afa2980 BOOT_IMAGE=(hd0,gpt5)/boot/vmlinuz-5.10.0-0.rc4.78.fc34.x86_64 root=UUID=1ede796f-5c84-4fb0-8a9e-c97e1b102ec4 ro resume=UUID=1dad1a43-257 -- 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 20

[PATCH v3 0/5] phy: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support
by Liu Ying 08 Mar '21

08 Mar '21

Hi, This series adds i.MX8qxp LVDS PHY mode support for the Mixel PHY in the Freescale i.MX8qxp SoC. The Mixel PHY is MIPI DPHY + LVDS PHY combo, which can works in either MIPI DPHY mode or LVDS PHY mode. The PHY mode is controlled by i.MX8qxp SCU firmware. The PHY driver would call a SCU function to configure the mode. The PHY driver is already supporting the Mixel MIPI DPHY in i.MX8mq SoC, where it appears to be a single MIPI DPHY. Patch 1/5 sets PHY mode in the Northwest Logic MIPI DSI host controller bridge driver, since i.MX8qxp SoC embeds this controller IP to support MIPI DSI displays together with the Mixel PHY. Patch 2/5 allows LVDS PHYs to be configured through the generic PHY functions and through a custom structure added to the generic PHY configuration union. Patch 3/5 converts mixel,mipi-dsi-phy plain text dt binding to json-schema. Patch 4/5 adds dt binding support for the Mixel combo PHY in i.MX8qxp SoC. Patch 5/5 adds the i.MX8qxp LVDS PHY mode support in the Mixel PHY driver. Welcome comments, thanks. v2->v3: * Improve readability of mixel_dphy_set_mode() in the Mixel PHY driver. (Guido) * Improve the 'clock-names' property in the PHY dt binding. v1->v2: * Convert mixel,mipi-dsi-phy plain text dt binding to json-schema. (Guido) * Print invalid PHY mode in dmesg from the Mixel PHY driver. (Guido) * Add Guido's R-b tag on the patch for the nwl-dsi drm bridge driver. Liu Ying (5): drm/bridge: nwl-dsi: Set PHY mode in nwl_dsi_enable() phy: Add LVDS configuration options dt-bindings: phy: Convert mixel,mipi-dsi-phy to json-schema dt-bindings: phy: mixel: mipi-dsi-phy: Add Mixel combo PHY support for i.MX8qxp phy: freescale: phy-fsl-imx8-mipi-dphy: Add i.MX8qxp LVDS PHY mode support .../devicetree/bindings/phy/mixel,mipi-dsi-phy.txt | 29 --- .../bindings/phy/mixel,mipi-dsi-phy.yaml | 107 ++++++++ drivers/gpu/drm/bridge/nwl-dsi.c | 6 + drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c | 269 ++++++++++++++++++++- include/linux/phy/phy-lvds.h | 48 ++++ include/linux/phy/phy.h | 4 + 6 files changed, 423 insertions(+), 40 deletions(-) delete mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/mixel,mipi-dsi-phy.yaml create mode 100644 include/linux/phy/phy-lvds.h -- 2.7.4

4 16

[PATCH 0/2] drm/sun4i: fix DCLK and improve its handling
by Giulio Benetti 04 Mar '21

04 Mar '21

First patch is a tested by me fix, while the second need testing to understand if it works correctly with any sunxi SoC with DE peripheral. Already tested SoCs are: - A20 - A33 Need testing: - A10 - A10s - A13 Giulio Benetti (2): drm/sun4i: tcon: fix inverted DCLK polarity drm/sun4i: tcon: improve DCLK polarity handling drivers/gpu/drm/sun4i/sun4i_tcon.c | 20 +------------------- drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + 2 files changed, 2 insertions(+), 19 deletions(-) -- 2.25.1

6 27

[PATCH 00/31] Introduce devm_pm_opp_* API
by Yangtao Li 03 Mar '21

03 Mar '21

Hi, This patchset add devm_pm_opp_set_clkname, devm_pm_opp_put_clkname, devm_pm_opp_set_regulators, devm_pm_opp_put_regulators, devm_pm_opp_set_supported_hw, devm_pm_opp_of_add_table and devm_pm_opp_register_notifier. Yangtao Li (31): opp: Add devres wrapper for dev_pm_opp_set_clkname and dev_pm_opp_put_clkname opp: Add devres wrapper for dev_pm_opp_set_regulators and dev_pm_opp_put_regulators opp: Add devres wrapper for dev_pm_opp_set_supported_hw opp: Add devres wrapper for dev_pm_opp_of_add_table opp: Add devres wrapper for dev_pm_opp_register_notifier serial: qcom_geni_serial: fix potential mem leak in qcom_geni_serial_probe() serial: qcom_geni_serial: convert to use devm_pm_opp_* API spi: spi-qcom-qspi: fix potential mem leak in spi_geni_probe() spi: spi-qcom-qspi: fix potential mem leak in spi_geni_probe() qcom-geni-se: remove opp_table mmc: sdhci-msm: fix potential mem leak in sdhci_msm_probe() mmc: sdhci-msm: convert to use devm_pm_opp_* API spi: spi-qcom-qspi: fix potential mem leak in qcom_qspi_probe() spi: spi-qcom-qspi: convert to use devm_pm_opp_* API drm/msm: fix potential mem leak drm/msm: convert to use devm_pm_opp_* API and remove dp_ctrl_put drm/lima: convert to use devm_pm_opp_* API drm/lima: remove unneeded devm_devfreq_remove_device() drm/panfrost: convert to use devm_pm_opp_* API media: venus: fix error check in core_get_v4() media: venus: convert to use devm_pm_opp_* API memory: samsung: exynos5422-dmc: fix return error in exynos5_init_freq_table memory: samsung: exynos5422-dmc: convert to use devm_pm_opp_* API memory: tegra20: convert to use devm_pm_opp_* API memory: tegra30: convert to use devm_pm_opp_* API PM / devfreq: tegra30: convert to use devm_pm_opp_* API PM / devfreq: rk3399_dmc: convert to use devm_pm_opp_* API PM / devfreq: imx8m-ddrc: convert to use devm_pm_opp_* API PM / devfreq: imx-bus: convert to use devm_pm_opp_* API PM / devfreq: exynos: convert to use devm_pm_opp_* API PM / devfreq: convert to devm_pm_opp_register_notifier and remove unused API drivers/devfreq/devfreq.c | 66 +------ drivers/devfreq/exynos-bus.c | 42 +---- drivers/devfreq/imx-bus.c | 14 +- drivers/devfreq/imx8m-ddrc.c | 15 +- drivers/devfreq/rk3399_dmc.c | 22 +-- drivers/devfreq/tegra30-devfreq.c | 21 +-- drivers/gpu/drm/lima/lima_devfreq.c | 45 +---- drivers/gpu/drm/lima/lima_devfreq.h | 2 - drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 31 ++-- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 2 - drivers/gpu/drm/msm/dp/dp_ctrl.c | 29 +-- drivers/gpu/drm/msm/dp/dp_ctrl.h | 1 - drivers/gpu/drm/msm/dp/dp_display.c | 5 +- drivers/gpu/drm/msm/dsi/dsi_host.c | 23 ++- drivers/gpu/drm/panfrost/panfrost_devfreq.c | 34 +--- drivers/gpu/drm/panfrost/panfrost_devfreq.h | 1 - .../media/platform/qcom/venus/pm_helpers.c | 22 +-- drivers/memory/samsung/exynos5422-dmc.c | 13 +- drivers/memory/tegra/tegra20-emc.c | 29 +-- drivers/memory/tegra/tegra30-emc.c | 29 +-- drivers/mmc/host/sdhci-msm.c | 27 ++- drivers/opp/core.c | 173 ++++++++++++++++++ drivers/opp/of.c | 36 ++++ drivers/spi/spi-geni-qcom.c | 23 ++- drivers/spi/spi-qcom-qspi.c | 25 ++- drivers/tty/serial/qcom_geni_serial.c | 31 ++-- include/linux/devfreq.h | 23 --- include/linux/pm_opp.h | 38 ++++ include/linux/qcom-geni-se.h | 2 - 32 files changed, 402 insertions(+), 428 deletions(-) -- 2.25.1

7 51

[PATCH] drm: rcar-du: Use drmm_encoder_alloc() to manage encoder
by Kieran Bingham 02 Mar '21

02 Mar '21

The encoder allocation was converted to a DRM managed resource at the same time as the addition of a new helper drmm_encoder_alloc() which simplifies the same process. Convert the custom drm managed resource allocation of the encoder with the helper to simplify the implementation, and prevent hitting a WARN_ON() due to the handling the drm_encoder_init() call directly without registering a .destroy() function op. Fixes: f5f16725edbc ("drm: rcar-du: Use DRM-managed allocation for encoders") Reported-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> --- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 31 +++++------------------ 1 file changed, 6 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c index ba8c6038cd63..ca3761772211 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c @@ -48,21 +48,12 @@ static unsigned int rcar_du_encoder_count_ports(struct device_node *node) static const struct drm_encoder_funcs rcar_du_encoder_funcs = { }; -static void rcar_du_encoder_release(struct drm_device *dev, void *res) -{ - struct rcar_du_encoder *renc = res; - - drm_encoder_cleanup(&renc->base); - kfree(renc); -} - int rcar_du_encoder_init(struct rcar_du_device *rcdu, enum rcar_du_output output, struct device_node *enc_node) { struct rcar_du_encoder *renc; struct drm_bridge *bridge; - int ret; /* * Locate the DRM bridge from the DT node. For the DPAD outputs, if the @@ -101,26 +92,16 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu, return -ENOLINK; } - renc = kzalloc(sizeof(*renc), GFP_KERNEL); - if (renc == NULL) - return -ENOMEM; - - renc->output = output; - dev_dbg(rcdu->dev, "initializing encoder %pOF for output %u\n", enc_node, output); - ret = drm_encoder_init(&rcdu->ddev, &renc->base, &rcar_du_encoder_funcs, - DRM_MODE_ENCODER_NONE, NULL); - if (ret < 0) { - kfree(renc); - return ret; - } + renc = drmm_encoder_alloc(&rcdu->ddev, struct rcar_du_encoder, base, + &rcar_du_encoder_funcs, DRM_MODE_ENCODER_NONE, + NULL); + if (!renc) + return -ENOMEM; - ret = drmm_add_action_or_reset(&rcdu->ddev, rcar_du_encoder_release, - renc); - if (ret) - return ret; + renc->output = output; /* * Attach the bridge to the encoder. The bridge will create the -- 2.25.1

3 6

[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: NEW Severity: low Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: samy(a)lahfa.xyz Regression: No Created attachment 293025 --> https://bugzilla.kernel.org/attachment.cgi?id=293025&action=edit parts of dmesg where the call trace happens during the resume from S3 sleep state. I'm thinking that this bug is a regression since I haven't seen this call trace before on kernel older than 5.8.12-arch1-1 but I have yet to confirm this. The call trace may also happen only in a very specific way, my current computer has a USB-C Dock that is plugged in and the call trace happened when the USB-C was plugged in and the computer was suspended, then resumed. It is a Lenovo Thinkpad T495 model 20NKS28F00 with an AMD Ryzen 7 3700U and a Vega Radeon RX 10. Further comments will confirm if the call trace happens only when the USB-C Dock is plugged. As well as if this call trace happens on kernels older than 5.8.12-arch1-1. The computer does resume successfully and there is a like a minor screen glitch for a millisecond so it's not a very severe bug. -- You are receiving this mail because: You are watching the assignee of the bug.

1 21

[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) 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.

1 3

What ist the standard way to define connector type and bus format with device tree?
by H. Nikolaus Schaller 28 Feb '21

28 Feb '21

Hi, according to bindings/display/panel/panel-common.yaml and by using "panel-simple" as compatible string we can define almost all properties of a DSI panel by a device tree entry. Except the connector and bus format which can only be set by adding the same information to the panel-simple tables. This leads to big problems because DRM can't match the display with any lcd controller. The least issue is a warning: [ 0.313431] panel-simple claa070vc01: Specify missing connector_type Are we missing some documentation or code that reads some "connector-type" and "bus-format" property? BR and thanks, Nikolaus

1 2

[PATCH 1/2] drm: distinguish return value of drm_dp_check_and_send_link_address.
by Xiaogang.Chen 26 Feb '21

26 Feb '21

From: Xiaogang Chen <xiaogang.chen(a)amd.com> drm_dp_check_and_send_link_address discovers MST device topology. It can return both positive and negative values. When it returns positive values there is no error found. If it returns negative values there is error found, such as get NAK , timeout, etc. Following drm_kms_helper_hotplug_event should be called when drm_dp_check_and_send_link_address returns positive value. Signed-off-by: Xiaogang Chen <xiaogang.chen(a)amd.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 17dbed0..3ef5206 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2650,7 +2650,7 @@ static void drm_dp_mst_link_probe_work(struct work_struct *work) drm_dp_mst_topology_put_mstb(mstb); mutex_unlock(&mgr->probe_lock); - if (ret) + if (ret > 0) drm_kms_helper_hotplug_event(dev); } -- 2.7.4

5 12

← Newer
1
...
9
10
11
12
13
14
15
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2021