dri-devel February 2021

dri-devel@lists.freedesktop.org

314 participants
684 discussions

[PATCH] drm/amd/display: Fix an uninitialized index variable
by Arnd Bergmann 02 Mar '21

02 Mar '21

From: Arnd Bergmann <arnd(a)arndb.de> clang points out that the new logic uses an always-uninitialized array index: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9810:38: warning: variable 'i' is uninitialized when used here [-Wuninitialized] timing = &edid->detailed_timings[i]; ^ drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:9720:7: note: initialize the variable 'i' to silence this warning My best guess is that the index should have been returned by the parse_hdmi_amd_vsdb() function that walks an array here, so do that. Fixes: f9b4f20c4777 ("drm/amd/display: Add Freesync HDMI support to DM") Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index b19b93c74bae..667c0d52dbfa 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -9736,7 +9736,7 @@ static bool parse_edid_cea(struct amdgpu_dm_connector *aconnector, return false; } -static bool parse_hdmi_amd_vsdb(struct amdgpu_dm_connector *aconnector, +static int parse_hdmi_amd_vsdb(struct amdgpu_dm_connector *aconnector, struct edid *edid, struct amdgpu_hdmi_vsdb_info *vsdb_info) { uint8_t *edid_ext = NULL; @@ -9746,7 +9746,7 @@ static bool parse_hdmi_amd_vsdb(struct amdgpu_dm_connector *aconnector, /*----- drm_find_cea_extension() -----*/ /* No EDID or EDID extensions */ if (edid == NULL || edid->extensions == 0) - return false; + return -ENODEV; /* Find CEA extension */ for (i = 0; i < edid->extensions; i++) { @@ -9756,14 +9756,15 @@ static bool parse_hdmi_amd_vsdb(struct amdgpu_dm_connector *aconnector, } if (i == edid->extensions) - return false; + return -ENODEV; /*----- cea_db_offsets() -----*/ if (edid_ext[0] != CEA_EXT) - return false; + return -ENODEV; valid_vsdb_found = parse_edid_cea(aconnector, edid_ext, EDID_LENGTH, vsdb_info); - return valid_vsdb_found; + + return valid_vsdb_found ? i : -ENODEV; } void amdgpu_dm_update_freesync_caps(struct drm_connector *connector, @@ -9781,7 +9782,6 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector *connector, struct amdgpu_device *adev = drm_to_adev(dev); bool freesync_capable = false; struct amdgpu_hdmi_vsdb_info vsdb_info = {0}; - bool hdmi_valid_vsdb_found = false; if (!connector->state) { DRM_ERROR("%s - Connector has no state", __func__); @@ -9857,8 +9857,8 @@ void amdgpu_dm_update_freesync_caps(struct drm_connector *connector, } } } else if (edid && amdgpu_dm_connector->dc_sink->sink_signal == SIGNAL_TYPE_HDMI_TYPE_A) { - hdmi_valid_vsdb_found = parse_hdmi_amd_vsdb(amdgpu_dm_connector, edid, &vsdb_info); - if (hdmi_valid_vsdb_found && vsdb_info.freesync_supported) { + i = parse_hdmi_amd_vsdb(amdgpu_dm_connector, edid, &vsdb_info); + if (i >= 0 && vsdb_info.freesync_supported) { timing = &edid->detailed_timings[i]; data = &timing->data.other_data; -- 2.29.2

3 4

[PATCH v3 0/7] drm: sun4i: dsi: Convert drm bridge
by Jagan Teki 02 Mar '21

02 Mar '21

This series convert Allwinner DSI controller to full functional drm bridge driver for supporting slave panel, bridges. Here, are the previous version changes[1]. The key concern about these changes is about kms hotplug which indeed not compatible with bridge conversion. However, I did try several ways to support hotplug with the bridge but it's resulting in a deadlock where bind never attach bridge until bridge pointer found and bridge pointer cannot found until bind finishes. Any inputs on this would be appreciated. [1] https://lwn.net/Articles/783127/ Any inputs? Jagan. Jagan Teki (7): drm: sun4i: dsi: Use drm_of_find_panel_or_bridge drm: sun4i: dsi: Add bridge support drm: sun4i: dsi: Convert to bridge driver drm: sun4i: dsi: Separate code for bridge pre_enable drm: bridge: Queue the bridge chain instead of stacking drm: sun4i: dsi: Use drm_panel_bridge, connector API [DO NOT MERGE] ARM: dts: sun8i: bananapi-m2m: Enable S070WV20-CT16 panel arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 85 ++++++++++++ drivers/gpu/drm/drm_bridge.c | 4 +- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 128 +++++++++---------- drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 11 +- 4 files changed, 150 insertions(+), 78 deletions(-) -- 2.25.1

4 12

[PATCH] drm/fb-helper: only unmap if buffer not null
by Tong Zhang 02 Mar '21

02 Mar '21

drm_fbdev_cleanup() can be called when fb_helper->buffer is null, hence fb_helper->buffer should be checked before calling drm_client_buffer_vunmap(). This buffer is also checked in drm_client_framebuffer_delete(), so we should also do the same thing for drm_client_buffer_vunmap(). [ 199.128742] RIP: 0010:drm_client_buffer_vunmap+0xd/0x20 [ 199.129031] Code: 43 18 48 8b 53 20 49 89 45 00 49 89 55 08 5b 44 89 e0 41 5c 41 5d 41 5e 5d c3 0f 1f 00 53 48 89 fb 48 8d 7f 10 e8 73 7d a1 ff <48> 8b 7b 10 48 8d 73 18 5b e9 75 53 fc ff 0 f 1f 44 00 00 48 b8 00 [ 199.130041] RSP: 0018:ffff888103f3fc88 EFLAGS: 00010282 [ 199.130329] RAX: 0000000000000001 RBX: 0000000000000000 RCX: ffffffff8214d46d [ 199.130733] RDX: 1ffffffff079c6b9 RSI: 0000000000000246 RDI: ffffffff83ce35c8 [ 199.131119] RBP: ffff888103d25458 R08: 0000000000000001 R09: fffffbfff0791761 [ 199.131505] R10: ffffffff83c8bb07 R11: fffffbfff0791760 R12: 0000000000000000 [ 199.131891] R13: ffff888103d25468 R14: ffff888103d25418 R15: ffff888103f18120 [ 199.132277] FS: 00007f36fdcbb6a0(0000) GS:ffff88815b400000(0000) knlGS:0000000000000000 [ 199.132721] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 199.133033] CR2: 0000000000000010 CR3: 0000000103d26000 CR4: 00000000000006f0 [ 199.133420] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 199.133807] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 199.134195] Call Trace: [ 199.134333] drm_fbdev_cleanup+0x179/0x1a0 [ 199.134562] drm_fbdev_client_unregister+0x2b/0x40 [ 199.134828] drm_client_dev_unregister+0xa8/0x180 [ 199.135088] drm_dev_unregister+0x61/0x110 [ 199.135315] mgag200_pci_remove+0x38/0x52 [mgag200] [ 199.135586] pci_device_remove+0x62/0xe0 [ 199.135806] device_release_driver_internal+0x148/0x270 [ 199.136094] driver_detach+0x76/0xe0 [ 199.136294] bus_remove_driver+0x7e/0x100 [ 199.136521] pci_unregister_driver+0x28/0xf0 [ 199.136759] __x64_sys_delete_module+0x268/0x300 [ 199.137016] ? __ia32_sys_delete_module+0x300/0x300 [ 199.137285] ? call_rcu+0x3e4/0x580 [ 199.137481] ? fpregs_assert_state_consistent+0x4d/0x60 [ 199.137767] ? exit_to_user_mode_prepare+0x2f/0x130 [ 199.138037] do_syscall_64+0x33/0x40 [ 199.138237] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 199.138517] RIP: 0033:0x7f36fdc3dcf7 Signed-off-by: Tong Zhang <ztong0001(a)gmail.com> --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index b9a616737c0e..f6baa2046124 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -2048,7 +2048,7 @@ static void drm_fbdev_cleanup(struct drm_fb_helper *fb_helper) if (shadow) vfree(shadow); - else + else if (fb_helper->buffer) drm_client_buffer_vunmap(fb_helper->buffer); drm_client_framebuffer_delete(fb_helper->buffer); -- 2.25.1

2 3

[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

[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. The fourth patch adds CEC support to the OMAP5 driver and the last patch adds the missing cec clock to the dra7 and omap5 device tree. Tested with a Pandaboard and a Beagle X15 board. Regards, Hans Hans Verkuil (5): drm: drm_bridge: add cec_init/exit bridge ops drm/omap: hdmi4: switch to the cec bridge ops drm/omap: hdmi4: simplify CEC Phys Addr handling drm/omap: hdmi5: add CEC support ARM: dts: dra7/omap5: add cec clock arch/arm/boot/dts/dra7.dtsi | 5 +- arch/arm/boot/dts/omap5.dtsi | 5 +- drivers/gpu/drm/drm_bridge_connector.c | 23 +++ drivers/gpu/drm/omapdrm/dss/Kconfig | 8 + drivers/gpu/drm/omapdrm/dss/Makefile | 1 + drivers/gpu/drm/omapdrm/dss/hdmi.h | 1 + drivers/gpu/drm/omapdrm/dss/hdmi4.c | 41 ++--- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.c | 12 +- drivers/gpu/drm/omapdrm/dss/hdmi4_cec.h | 12 +- drivers/gpu/drm/omapdrm/dss/hdmi5.c | 63 +++++-- drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c | 201 +++++++++++++++++++++++ drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h | 42 +++++ drivers/gpu/drm/omapdrm/dss/hdmi5_core.c | 28 +++- drivers/gpu/drm/omapdrm/dss/hdmi5_core.h | 33 +++- include/drm/drm_bridge.h | 31 ++++ 15 files changed, 453 insertions(+), 53 deletions(-) create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.c create mode 100644 drivers/gpu/drm/omapdrm/dss/hdmi5_cec.h -- 2.30.0

5 20

[PATCH V2 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 1 to 0 after FSC and brightness update. As per hardware team recommendation the FSC and brightness sync takes place from 0 to 1 transition. The patch 2/2 fies this issue. Changes from V1: 1. Updated the cover letter. 2. Updated the description of the patches as per Daniel's suggestion. Kiran Gunda (2): backlight: qcom-wled: Fix FSC update issue for WLED5 backlight: qcom-wled: Correct the sync_toggle sequence drivers/video/backlight/qcom-wled.c | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

3 6

[PATCH] MAINTAINERS: update drm bug reporting URL
by Pavel Turinský 01 Mar '21

01 Mar '21

The original bugzilla seems to be read-only now, linking to the gitlab for new bugs. Signed-off-by: Pavel Turinský <ledoian(a)kam.mff.cuni.cz> Cc: trivial(a)kernel.org --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index bfc1b86e3e73..434adb869522 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5793,7 +5793,7 @@ M: David Airlie <airlied(a)linux.ie> M: Daniel Vetter <daniel(a)ffwll.ch> L: dri-devel(a)lists.freedesktop.org S: Maintained -B: https://bugs.freedesktop.org/ +B: https://gitlab.freedesktop.org/drm C: irc://chat.freenode.net/dri-devel T: git git://anongit.freedesktop.org/drm/drm F: Documentation/devicetree/bindings/display/ -- 2.20.1

2 1

[PATCH 0/2] enable HDCP in Cadence MHDP bridge driver
by Parshuram Thombare 01 Mar '21

01 Mar '21

This patch series enables HDCP in Cadence MHDP DPI/DP bridge driver. Parshuram Thombare (2): dt-bindings: drm/bridge: MHDP8546 bridge binding changes for HDCP drm: bridge: cdns-mhdp8546: Enable HDCP .../display/bridge/cdns,mhdp8546.yaml | 20 +- drivers/gpu/drm/bridge/cadence/Makefile | 2 +- .../drm/bridge/cadence/cdns-mhdp8546-core.c | 105 +++- .../drm/bridge/cadence/cdns-mhdp8546-core.h | 21 + .../drm/bridge/cadence/cdns-mhdp8546-hdcp.c | 578 ++++++++++++++++++ .../drm/bridge/cadence/cdns-mhdp8546-hdcp.h | 89 +++ 6 files changed, 796 insertions(+), 19 deletions(-) create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.c create mode 100644 drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-hdcp.h -- 2.25.1

3 5

[PATCH v5] drm: Use USB controller's DMA mask when importing dmabufs
by Thomas Zimmermann 01 Mar '21

01 Mar '21

USB devices cannot perform DMA and hence have no dma_mask set in their device structure. Therefore importing dmabuf into a USB-based driver fails, which breaks joining and mirroring of display in X11. For USB devices, pick the associated USB controller as attachment device. This allows the DRM import helpers to perform the DMA setup. If the DMA controller does not support DMA transfers, we're out of luck and cannot import. Our current USB-based DRM drivers don't use DMA, so the actual DMA device is not important. Drivers should use DRM_GEM_SHMEM_DROVER_OPS_USB to initialize their instance of struct drm_driver. Tested by joining/mirroring displays of udl and radeon un der Gnome/X11. v5: * provide a helper for USB interfaces (Alan) * add FIXME item to documentation and TODO list (Daniel) v4: * implement workaround with USB helper functions (Greg) * use struct usb_device->bus->sysdev as DMA device (Takashi) v3: * drop gem_create_object * use DMA mask of USB controller, if any (Daniel, Christian, Noralf) v2: * move fix to importer side (Christian, Daniel) * update SHMEM and CMA helpers for new PRIME callbacks Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 6eb0233ec2d0 ("usb: don't inherity DMA properties for USB devices") Tested-by: Pavel Machek <pavel(a)ucw.cz> Acked-by: Christian König <christian.koenig(a)amd.com> Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> # v5.10+ --- Documentation/gpu/todo.rst | 15 ++++++++++ drivers/gpu/drm/drm_prime.c | 45 ++++++++++++++++++++++++++++++ drivers/gpu/drm/tiny/gm12u320.c | 2 +- drivers/gpu/drm/udl/udl_drv.c | 2 +- drivers/usb/core/usb.c | 31 ++++++++++++++++++++ include/drm/drm_gem_shmem_helper.h | 16 +++++++++++ include/drm/drm_prime.h | 5 ++++ include/linux/usb.h | 24 ++++++++++++++++ 8 files changed, 138 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index f872d3d33218..c185e0a2951e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -617,6 +617,21 @@ Contact: Daniel Vetter Level: Intermediate +Remove automatic page mapping from dma-buf importing +---------------------------------------------------- + +When importing dma-bufs, the dma-buf and PRIME frameworks automatically map +imported pages into the importer's DMA area. This is a problem for USB devices, +which do not support DMA operations. By default, importing fails for USB +devices. USB-based drivers work around this problem by employing +drm_gem_prime_import_usb(). To fix the issue, automatic page mappings should +be removed from the buffer-sharing code. + +Contact: Thomas Zimmermann <tzimmermann(a)suse.de>, Daniel Vetter + +Level: Advanced + + Better Testing ============== diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c index 2a54f86856af..59013bb1cd4b 100644 --- a/drivers/gpu/drm/drm_prime.c +++ b/drivers/gpu/drm/drm_prime.c @@ -29,6 +29,7 @@ #include <linux/export.h> #include <linux/dma-buf.h> #include <linux/rbtree.h> +#include <linux/usb.h> #include <drm/drm.h> #include <drm/drm_drv.h> @@ -1055,3 +1056,47 @@ void drm_prime_gem_destroy(struct drm_gem_object *obj, struct sg_table *sg) dma_buf_put(dma_buf); } EXPORT_SYMBOL(drm_prime_gem_destroy); + +/** + * drm_gem_prime_import_usb - helper library implementation of the import callback for USB devices + * @dev: drm_device to import into + * @dma_buf: dma-buf object to import + * + * This is an implementation of drm_gem_prime_import() for USB-based devices. + * USB devices cannot perform DMA directly. This function selects the USB host + * controller as DMA device instead. Drivers can use this as their + * &drm_driver.gem_prime_import implementation. + * + * See also drm_gem_prime_import(). + * + * FIXME: The dma-buf framework expects to map the exported pages into + * the importer's DMA area. USB devices don't support DMA, and + * importing would fail. Foir the time being, this function provides + * a workaround by using the USB controller's DMA area. The real + * solution is to remove page-mapping operations from the dma-buf + * framework. + * + * Returns: A GEM object on success, or a pointer-encoder errno value otherwise. + */ +#ifdef CONFIG_USB +struct drm_gem_object *drm_gem_prime_import_usb(struct drm_device *dev, + struct dma_buf *dma_buf) +{ + struct device *dmadev; + struct drm_gem_object *obj; + + if (!dev_is_usb(dev->dev)) + return ERR_PTR(-ENODEV); + + dmadev = usb_intf_get_dma_device(to_usb_interface(dev->dev)); + if (drm_WARN_ONCE(dev, !dmadev, "buffer sharing not supported")) + return ERR_PTR(-ENODEV); + + obj = drm_gem_prime_import_dev(dev, dma_buf, dmadev); + + put_device(dmadev); + + return obj; +} +EXPORT_SYMBOL(drm_gem_prime_import_usb); +#endif diff --git a/drivers/gpu/drm/tiny/gm12u320.c b/drivers/gpu/drm/tiny/gm12u320.c index 0b4f4f2af1ef..99e7bd36a220 100644 --- a/drivers/gpu/drm/tiny/gm12u320.c +++ b/drivers/gpu/drm/tiny/gm12u320.c @@ -611,7 +611,7 @@ static const struct drm_driver gm12u320_drm_driver = { .minor = DRIVER_MINOR, .fops = &gm12u320_fops, - DRM_GEM_SHMEM_DRIVER_OPS, + DRM_GEM_SHMEM_DRIVER_OPS_USB, }; static const struct drm_mode_config_funcs gm12u320_mode_config_funcs = { diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c index 9269092697d8..2db483b2b199 100644 --- a/drivers/gpu/drm/udl/udl_drv.c +++ b/drivers/gpu/drm/udl/udl_drv.c @@ -39,7 +39,7 @@ static const struct drm_driver driver = { /* GEM hooks */ .fops = &udl_driver_fops, - DRM_GEM_SHMEM_DRIVER_OPS, + DRM_GEM_SHMEM_DRIVER_OPS_USB, .name = DRIVER_NAME, .desc = DRIVER_DESC, diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c index 8f07b0516100..5e07921e87ba 100644 --- a/drivers/usb/core/usb.c +++ b/drivers/usb/core/usb.c @@ -748,6 +748,37 @@ void usb_put_intf(struct usb_interface *intf) } EXPORT_SYMBOL_GPL(usb_put_intf); +/** + * usb_get_dma_device - acquire a reference on the usb device's DMA endpoint + * @udev: usb device + * + * While a USB device cannot perform DMA operations by itself, many USB + * controllers can. A call to usb_get_dma_device() returns the DMA endpoint + * for the given USB device, if any. The returned device structure should be + * released with put_device(). + * + * See also usb_intf_get_dma_device(). + * + * Returns: A reference to the usb device's DMA endpoint; or NULL if none + * exists. + */ +struct device *usb_get_dma_device(struct usb_device *udev) +{ + struct device *dmadev; + + if (!udev->bus) + return NULL; + + dmadev = get_device(udev->bus->sysdev); + if (!dmadev || !dmadev->dma_mask) { + put_device(dmadev); + return NULL; + } + + return dmadev; +} +EXPORT_SYMBOL_GPL(usb_get_dma_device); + /* USB device locking * * USB devices and interfaces are locked using the semaphore in their diff --git a/include/drm/drm_gem_shmem_helper.h b/include/drm/drm_gem_shmem_helper.h index 434328d8a0d9..ea8144f33c1f 100644 --- a/include/drm/drm_gem_shmem_helper.h +++ b/include/drm/drm_gem_shmem_helper.h @@ -162,4 +162,20 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_object *obj); .gem_prime_mmap = drm_gem_prime_mmap, \ .dumb_create = drm_gem_shmem_dumb_create +#ifdef CONFIG_USB +/** + * DRM_GEM_SHMEM_DRIVER_OPS_USB - Default shmem GEM operations for USB devices + * + * This macro provides a shortcut for setting the shmem GEM operations in + * the &drm_driver structure. Drivers for USB-based devices should use this + * macro instead of &DRM_GEM_SHMEM_DRIVER_OPS. + * + * FIXME: Support USB devices with default SHMEM driver ops. See the + * documentation of drm_gem_prime_import_usb() for details. + */ +#define DRM_GEM_SHMEM_DRIVER_OPS_USB \ + DRM_GEM_SHMEM_DRIVER_OPS, \ + .gem_prime_import = drm_gem_prime_import_usb +#endif + #endif /* __DRM_GEM_SHMEM_HELPER_H__ */ diff --git a/include/drm/drm_prime.h b/include/drm/drm_prime.h index 54f2c58305d2..b42e07edd9e6 100644 --- a/include/drm/drm_prime.h +++ b/include/drm/drm_prime.h @@ -110,4 +110,9 @@ int drm_prime_sg_to_page_array(struct sg_table *sgt, struct page **pages, int drm_prime_sg_to_dma_addr_array(struct sg_table *sgt, dma_addr_t *addrs, int max_pages); +#ifdef CONFIG_USB +struct drm_gem_object *drm_gem_prime_import_usb(struct drm_device *dev, + struct dma_buf *dma_buf); +#endif + #endif /* __DRM_PRIME_H__ */ diff --git a/include/linux/usb.h b/include/linux/usb.h index 7d72c4e0713c..e6e0acf6a193 100644 --- a/include/linux/usb.h +++ b/include/linux/usb.h @@ -711,6 +711,7 @@ struct usb_device { unsigned use_generic_driver:1; }; #define to_usb_device(d) container_of(d, struct usb_device, dev) +#define dev_is_usb(d) ((d)->bus == &usb_bus_type) static inline struct usb_device *interface_to_usbdev(struct usb_interface *intf) { @@ -746,6 +747,29 @@ extern int usb_lock_device_for_reset(struct usb_device *udev, extern int usb_reset_device(struct usb_device *dev); extern void usb_queue_reset_device(struct usb_interface *dev); +extern struct device *usb_get_dma_device(struct usb_device *udev); + +/** + * usb_intf_get_dma_device - acquire a reference on the usb interface's DMA endpoint + * @intf: the usb interface + * + * While a USB device cannot perform DMA operations by itself, many USB + * controllers can. A call to usb_intf_get_dma_device() returns the DMA endpoint + * for the given USB interface, if any. The returned device structure should be + * released with put_device(). + * + * See also usb_get_dma_device(). + * + * Returns: A reference to the usb interface's DMA endpoint; or NULL if none + * exists. + */ +static inline struct device *usb_intf_get_dma_device(struct usb_interface *intf) +{ + if (!intf) + return NULL; + return usb_get_dma_device(interface_to_usbdev(intf)); +} + #ifdef CONFIG_ACPI extern int usb_acpi_set_power_state(struct usb_device *hdev, int index, bool enable); -- 2.30.1

6 9

← Newer
1
...
15
16
17
18
19
20
21
...
69
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2021