dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

[PATCH v10 0/4] Add MIPI rx DPI support
by Xin Ji 05 Aug '21

05 Aug '21

Hi all, this patch series implement MIPI rx DPI feature. Please help to review. This is the v10 version, rebase all patches on the latest code. Any mistakes, please let me know, I'll fix it in the next series. Change history: v10: Fix Rob Herring and Laurent Pinchart comments - Add more description about lane swing configuration in commit message v9: Fix Neil Amstrong comment - use macro define 'V4L2_FWNODE_BUS_TYPE_PARALLEL' instead of fixing value. v8: Fix Laurent Pinchart comment - Expand the commit message v7: - Rebase DT on the latest branch 'drm-misc-next'. - Remove HDCP patch. v6: Fix kernel robot compile warning v5: Fix Rob Herring, Hsin-Yi, Robert Foss comments - Rebase code on the branch 'drm-misc-next', refer video-interfaces.yaml - Seprate HDCP function to a new patch - Fix driver not correctly get 'bus-type' 'data-lanes' - Add audio HDMI codec function support v4: Fix Rob Herring comment - Rebase code on the branch 'drm-misc-next' - Change 'analogix,hdcp-support' type to boolean v3: Fix Rob Herring, Dan Carpenter, Nicolas comment - Split the patch, fix not correct return data - Fix several coding format - Split DP tx swing register setting to two property - Add HDCP support vender flag - remove 'analogix,swing-setting' and 'analogix,mipi-dpi-in' property v2: Fix Rob Herring comment - Fix yamllint warnings/errors in analogix,anx7625.yaml - Fix kernel robot compile warning v1: initial MIPI rx DPI feature support Xin Ji (4): dt-bindings:drm/bridge:anx7625:add vendor define flags drm/bridge: anx7625: fix not correct return value drm/bridge: anx7625: add MIPI DPI input feature drm/bridge: anx7625: add HDMI audio function .../display/bridge/analogix,anx7625.yaml | 55 ++- drivers/gpu/drm/bridge/analogix/anx7625.c | 458 ++++++++++++++++-- drivers/gpu/drm/bridge/analogix/anx7625.h | 23 +- 3 files changed, 482 insertions(+), 54 deletions(-) -- 2.25.1

2 6

[PATCH v2 0/9] drm: Extend COMPILE_TEST support to some ARM drivers
by Laurent Pinchart 05 Aug '21

05 Aug '21

Hello, This patch series stems from subsystem-wide changes I wanted to compile-test with an ARM64 cross-compiler. My laziness to fire a 32-bit ARM build definitely resulted in more time being spent writing these patches, but hopefully they'll turn out to be useful for more people. Patches 1/9 to 3/7 are fixes for compilation warnings on 64-bit platforms in the omapdrm and sti-drm drivers. They are a dependency for the Kconfig changes that follow to avoid introducing build warnings, but could also be merged before. Patches 3/9 to 8/9 enable compilation of the imx-dcss, omapdrm, sti-drm and tegra-drm drivers on all architectures with COMPILE_TEST. I have tested compilation on arm64 and x86, with W=1. The patches are independent from each other, so they can be picked by their respective maintainers. The last patch, 9/9, extends COMPILE_TEST support for the tilcdc driver to ARM64. The driver doesn't compile on x86 due to a missing __iowmb(), and I haven't taken the time to investigate how to solve this properly. The main change since v1 is the extension of COMPILE_TEST to all platforms instead of only ARM and ARM64. Please feel free to pick patches individually for the driver(s) you maintain. Laurent Pinchart (9): drm/omap: Use correct printk format specifiers for size_t drm/omap: Cast pointer to integer without generating warning drm/sti: Use correct printk format specifiers for size_t drm/imx/dcss: Enable COMPILE_TEST on all architectures drm/omap: Enable COMPILE_TEST on all architectures drm/rcar-du: Enable COMPILE_TEST on all architectures drm/sti: Enable COMPILE_TEST on all architectures drm/tegra: Enable COMPILE_TEST on all architectures drm/tilcdc: Enable COMPILE_TEST on all ARM64 platforms drivers/gpu/drm/imx/dcss/Kconfig | 3 ++- drivers/gpu/drm/omapdrm/Kconfig | 2 +- drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++-- drivers/gpu/drm/omapdrm/omap_drv.c | 2 +- drivers/gpu/drm/rcar-du/Kconfig | 1 - drivers/gpu/drm/sti/Kconfig | 3 ++- drivers/gpu/drm/sti/sti_hqvdp.c | 4 ++-- drivers/gpu/drm/tegra/Kconfig | 2 +- drivers/gpu/drm/tilcdc/Kconfig | 3 ++- drivers/gpu/host1x/Kconfig | 2 +- 10 files changed, 14 insertions(+), 12 deletions(-) -- Regards, Laurent Pinchart

5 14

[PATCH 0/7] drm/i915: Migrate memory to SMEM when imported cross-device
by Jason Ekstrand 04 Aug '21

04 Aug '21

This patch series fixes an issue with discrete graphics on Intel where we allowed dma-buf import while leaving the object in local memory. This breaks down pretty badly if the import happened on a different physical device. Jason Ekstrand (5): drm/i915/gem: Check object_can_migrate from object_migrate drm/i915/gem: Refactor placement setup for i915_gem_object_create* drm/i915/gem: Unify user object creation drm/i915/gem/ttm: Place new BOs in the requested region drm/i915/gem/ttm: Respect the objection region in placement_from_obj Thomas Hellström (2): drm/i915/gem: Correct the locking and pin pattern for dma-buf (v6) drm/i915/gem: Migrate to system at dma-buf attach time (v6) drivers/gpu/drm/i915/gem/i915_gem_create.c | 159 ++++++++------- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 64 ++++-- drivers/gpu/drm/i915/gem/i915_gem_object.c | 13 +- drivers/gpu/drm/i915/gem/i915_gem_object.h | 4 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 11 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 184 +++++++++++++++++- .../drm/i915/gem/selftests/i915_gem_migrate.c | 15 -- 7 files changed, 324 insertions(+), 126 deletions(-) -- 2.31.1

5 34

[Bug 208981] New: trace with B550I AORUS PRO AX and AMD Ryzen 5 PRO 4650G
by bugzilla-daemon＠bugzilla.kernel.org 04 Aug '21

04 Aug '21

https://bugzilla.kernel.org/show_bug.cgi?id=208981 Bug ID: 208981 Summary: trace with B550I AORUS PRO AX and AMD Ryzen 5 PRO 4650G Product: Drivers Version: 2.5 Kernel Version: 5.8.2 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: florian.laroche(a)gmail.com Regression: No Dear Maintainer, compiling the current Debian source with a linux-5.8.2 kernel gives the following trace on a B550I AORUS PRO AX with an AMD Ryzen 5 PRO 4650G: [ 3.974191] ------------[ cut here ]------------ [ 3.974265] WARNING: CPU: 9 PID: 175 at drivers/gpu/drm/amd/amdgpu/../display/dc/clk_mgr/dcn21/rn_clk_mgr.c:654 rn_clk_mgr_constru ct+0x11e/0x390 [amdgpu] [ 3.974268] Modules linked in: hid_generic(E) usbhid(E) hid(E) amdgpu(E+) gpu_sched(E) i2c_algo_bit(E) ttm(E) drm_kms_helper(E) ce c(E) ahci(E) libahci(E) nvme(E) xhci_pci(E) nvme_core(E) crc32_pclmul(E) xhci_hcd(E) r8169(E) t10_pi(E) crc32c_intel(E) realtek(E) li bata(E) crc_t10dif(E) drm(E) i2c_piix4(E) crct10dif_generic(E) mfd_core(E) crct10dif_pclmul(E) libphy(E) usbcore(E) crct10dif_common( E) scsi_mod(E) usb_common(E) wmi(E) video(E) gpio_amdpt(E) gpio_generic(E) button(E) [ 3.974284] CPU: 9 PID: 175 Comm: systemd-udevd Tainted: G E 5.8.0-trunk-amd64 #1 Debian 5.8.2-1 [ 3.974285] Hardware name: Gigabyte Technology Co., Ltd. B550I AORUS PRO AX/B550I AORUS PRO AX, BIOS F2a 06/16/2020 [ 3.974348] RIP: 0010:rn_clk_mgr_construct+0x11e/0x390 [amdgpu] [ 3.974351] Code: 00 00 00 41 8b 8c c4 80 00 00 00 41 89 c1 89 c7 85 c9 74 10 41 8b 94 c4 84 00 00 00 85 d2 0f 85 87 01 00 00 48 8 3 e8 01 73 d9 <0f> 0b 83 7b 20 01 74 0c 81 bd e8 00 00 00 ff 14 37 00 7f 27 48 8b [ 3.974353] RSP: 0018:ffffa98a8068f850 EFLAGS: 00010297 [ 3.974355] RAX: ffffffffffffffff RBX: ffff9a36d7eb2540 RCX: 0000000000000640 [ 3.974356] RDX: 0000000000000000 RSI: ffffa98a8068f878 RDI: 0000000000000000 [ 3.974357] RBP: ffff9a3625cf9800 R08: 0000000000000000 R09: 0000000000000000 [ 3.974358] R10: 7fc9117fffffffff R11: ffff9a36d7d51000 R12: ffffa98a8068f878 [ 3.974359] R13: ffff9a36d7eb2cc0 R14: ffff9a36bccc0000 R15: ffff9a36d7eb2540 [ 3.974361] FS: 00007f53ebac18c0(0000) GS:ffff9a371f240000(0000) knlGS:0000000000000000 [ 3.974362] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3.974363] CR2: 00007f53ebaaaee0 CR3: 00000003d7f38000 CR4: 0000000000340ee0 [ 3.974365] Call Trace: [ 3.974427] dc_clk_mgr_create+0x179/0x1a0 [amdgpu] [ 3.974488] dc_create+0x238/0x700 [amdgpu] [ 3.974493] ? _cond_resched+0x16/0x40 [ 3.974554] amdgpu_dm_init.isra.0+0x15b/0x1c0 [amdgpu] [ 3.974614] dm_hw_init+0xe/0x20 [amdgpu] [ 3.974676] amdgpu_device_init.cold+0x17a7/0x192b [amdgpu] [ 3.974722] amdgpu_driver_load_kms+0x5c/0x220 [amdgpu] [ 3.974766] amdgpu_pci_probe+0x15f/0x1f0 [amdgpu] [ 3.974770] local_pci_probe+0x42/0x80 [ 3.974772] ? _cond_resched+0x16/0x40 [ 3.974773] pci_device_probe+0xfa/0x1b0 [ 3.974776] really_probe+0x160/0x400 [ 3.974777] driver_probe_device+0xe1/0x150 [ 3.974779] device_driver_attach+0xa1/0xb0 [ 3.974780] __driver_attach+0x8a/0x150 [ 3.974781] ? device_driver_attach+0xb0/0xb0 [ 3.974782] ? device_driver_attach+0xb0/0xb0 [ 3.974784] bus_for_each_dev+0x78/0xc0 [ 3.974786] bus_add_driver+0x12b/0x1e0 [ 3.974787] driver_register+0x8b/0xe0 [ 3.974789] ? 0xffffffffc0a6b000 [ 3.974791] do_one_initcall+0x46/0x200 [ 3.974792] ? _cond_resched+0x16/0x40 [ 3.974794] ? kmem_cache_alloc_trace+0x192/0x220 [ 3.974796] ? do_init_module+0x23/0x250 [ 3.974798] do_init_module+0x5c/0x250 [ 3.974799] __do_sys_finit_module+0xac/0x110 [ 3.974802] do_syscall_64+0x4d/0xc0 [ 3.974804] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 3.974805] RIP: 0033:0x7f53ebf6ba79 [ 3.974807] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e7 53 0c 00 f7 d8 64 89 01 48 [ 3.974809] RSP: 002b:00007ffde26b8228 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 3.974811] RAX: ffffffffffffffda RBX: 000055c5cb205da0 RCX: 00007f53ebf6ba79 [ 3.974812] RDX: 0000000000000000 RSI: 00007f53ec0f6e4d RDI: 0000000000000012 [ 3.974813] RBP: 0000000000020000 R08: 0000000000000000 R09: 000055c5cb205fb8 [ 3.974814] R10: 0000000000000012 R11: 0000000000000246 R12: 00007f53ec0f6e4d [ 3.974815] R13: 0000000000000000 R14: 000055c5cb206e20 R15: 000055c5cb205da0 [ 3.974817] ---[ end trace 071eac41bffe7f9b ]--- best regards, Florian La Roche -- You are receiving this mail because: You are watching the assignee of the bug.

1 10

[PATCH] drm/ast: Update the sequence of Clearing Fast-reset
by KuoHsiang Chou 04 Aug '21

04 Aug '21

[Bug][AST2500] If SCU00 is not unlocked, just enter its password again. It is unnecessary to clear AHB lock condition and restore WDT default setting again, before Fast-reset clearing. Signed-off-by: KuoHsiang Chou <kuohsiang_chou(a)aspeedtech.com> --- drivers/gpu/drm/ast/ast_post.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c index 1f0007daa005..4f194c5fd2c2 100644 --- a/drivers/gpu/drm/ast/ast_post.c +++ b/drivers/gpu/drm/ast/ast_post.c @@ -2030,7 +2030,6 @@ void ast_patch_ahb_2500(struct ast_private *ast) { u32 data; -patch_ahb_lock: /* Clear bus lock condition */ ast_moutdwm(ast, 0x1e600000, 0xAEED1A03); ast_moutdwm(ast, 0x1e600084, 0x00010000); @@ -2044,11 +2043,9 @@ void ast_patch_ahb_2500(struct ast_private *ast) ast_moutdwm(ast, 0x1E78500c, 0x00000033); udelay(1000); } - ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8); do { + ast_moutdwm(ast, 0x1e6e2000, 0x1688A8A8); data = ast_mindwm(ast, 0x1e6e2000); - if (data == 0xffffffff) - goto patch_ahb_lock; } while (data != 1); ast_moutdwm(ast, 0x1e6e207c, 0x08000000); /* clear fast reset */ } -- 2.18.4

3 20

[PATCH 0/8] arm: ep93xx: CCF conversion
by Nikita Shubin 03 Aug '21

03 Aug '21

This series series of patches converts ep93xx to Common Clock Framework. It consists of preparation patches to use clk_prepare_enable where it is needed, instead of clk_enable used in ep93xx drivers prior to CCF and a patch converting mach-ep93xx/clock.c to CCF. Link: https://lore.kernel.org/patchwork/cover/1445563/ Link: https://lore.kernel.org/patchwork/patch/1435884/ Alexander Sverdlin (7): iio: ep93xx: Prepare clock before using it spi: spi-ep93xx: Prepare clock before using it Input: ep93xx_keypad: Prepare clock before using it video: ep93xx: Prepare clock before using it dmaengine: ep93xx: Prepare clock before using it ASoC: cirrus: i2s: Prepare clock before using it pwm: ep93xx: Prepare clock before using it Nikita Shubin (1): ep93xx: clock: convert in-place to COMMON_CLK arch/arm/Kconfig | 2 +- arch/arm/mach-ep93xx/clock.c | 975 ++++++++++++++----------- arch/arm/mach-ep93xx/core.c | 2 +- arch/arm/mach-ep93xx/soc.h | 42 +- drivers/dma/ep93xx_dma.c | 6 +- drivers/iio/adc/ep93xx_adc.c | 6 +- drivers/input/keyboard/ep93xx_keypad.c | 4 +- drivers/pwm/pwm-ep93xx.c | 12 +- drivers/spi/spi-ep93xx.c | 4 +- drivers/video/fbdev/ep93xx-fb.c | 4 +- sound/soc/cirrus/ep93xx-i2s.c | 12 +- 11 files changed, 605 insertions(+), 464 deletions(-) base-commit: 64376a981a0e2e57c46efa63197c2ebb7dab35df -- 2.26.2

4 6

[PATCH v2 0/9] drm: Add privacy-screen class and connector properties
by Hans de Goede 03 Aug '21

03 Aug '21

Hi All, Here is v2 of my series to add a privacy-screen class and connector properties. The only significantly changed patch in this v2 is: [2/9] drm: Add privacy-screen class (v2) which was modified to fix the dependency issues which the lkp kernel test robot, see the patches changelog for details. Here is the v1 cover-letter which is still up2date: Here is the privacy-screen related code which I last posted in August of last year. To the best of my knowledge there is consensus about / everyone is in agreement with the new userspace API (2 connector properties) this patch-set add (patch 1 of the series). The blocker the last time was that there were no userspace users of the new properties and as a rule we don't add new drm userspace API without users. There now is GNOME userspace code using the new properties: https://hackmd.io/@3v1n0/rkyIy3BOw The new API works as designed for this userspace user and the branches mentioned at the above link add the following features to GNOME: 1. Showing an OSD notification when the privacy-screen is toggled on/off through hotkeys handled by the embedded-controller 2. Allowing control of the privacy-screen from the GNOME control-panel, including the on/off slider shown there updating to match the hw-setting when the setting is changed with the control-panel open. 3. Restoring the last user-setting at login This series consists of a number of different parts: 1. A new version of Rajat's privacy-screen connector properties patch, this adds new userspace API in the form of new properties 2. Since on most devices the privacy screen is actually controlled by some vendor specific ACPI/WMI interface which has a driver under drivers/platform/x86, we need some "glue" code to make this functionality available to KMS drivers. Patches 2-4 add a new privacy-screen class for this, which allows non KMS drivers (and possibly KMS drivers too) to register a privacy-screen device and also adds an interface for KMS drivers to get access to the privacy-screen associated with a specific connector. This is modelled similar to how we deal with e.g. PWMs and GPIOs in the kernel, including separate includes for consumers and providers(drivers). 3. Some drm_connector helper functions to keep the actual changes needed for this in individual KMS drivers as small as possible (patch 5). 4. Make the thinkpad_acpi code register a privacy-screen device on ThinkPads with a privacy-screen (patches 6-8) 5. Make the i915 driver export the privacy-screen functionality through the connector properties on the eDP connector. I believe that it would be best to merge the entire series, including the thinkpad_acpi changes through drm-misc in one go. As the pdx86 subsys maintainer I hereby give my ack for merging the thinkpad_acpi changes through drm-misc. There is one small caveat with this series, which it is good to be aware of. The i915 driver will now return -EPROBE_DEFER on Thinkpads with an eprivacy screen, until the thinkpad_acpi driver is loaded. This means that initrd generation tools will need to be updated to include thinkpad_acpi when the i915 driver is added to the initrd. Without this the loading of the i915 driver will be delayed to after the switch to real rootfs. Regards, Hans Hans de Goede (8): drm: Add privacy-screen class (v2) drm/privacy-screen: Add X86 specific arch init code drm/privacy-screen: Add notifier support drm/connector: Add a drm_connector privacy-screen helper functions platform/x86: thinkpad_acpi: Add hotkey_notify_extended_hotkey() helper platform/x86: thinkpad_acpi: Get privacy-screen / lcdshadow ACPI handles only once platform/x86: thinkpad_acpi: Register a privacy-screen device drm/i915: Add privacy-screen support Rajat Jain (1): drm/connector: Add support for privacy-screen properties (v4) Documentation/gpu/drm-kms-helpers.rst | 15 + Documentation/gpu/drm-kms.rst | 2 + MAINTAINERS | 8 + drivers/gpu/drm/Kconfig | 4 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/drm_atomic_uapi.c | 4 + drivers/gpu/drm/drm_connector.c | 214 +++++++++ drivers/gpu/drm/drm_drv.c | 4 + drivers/gpu/drm/drm_privacy_screen.c | 468 +++++++++++++++++++ drivers/gpu/drm/drm_privacy_screen_x86.c | 86 ++++ drivers/gpu/drm/i915/display/intel_display.c | 5 + drivers/gpu/drm/i915/display/intel_dp.c | 10 + drivers/gpu/drm/i915/i915_pci.c | 12 + drivers/platform/x86/Kconfig | 2 + drivers/platform/x86/thinkpad_acpi.c | 131 ++++-- include/drm/drm_connector.h | 56 +++ include/drm/drm_privacy_screen_consumer.h | 63 +++ include/drm/drm_privacy_screen_driver.h | 84 ++++ include/drm/drm_privacy_screen_machine.h | 46 ++ 19 files changed, 1173 insertions(+), 42 deletions(-) create mode 100644 drivers/gpu/drm/drm_privacy_screen.c create mode 100644 drivers/gpu/drm/drm_privacy_screen_x86.c create mode 100644 include/drm/drm_privacy_screen_consumer.h create mode 100644 include/drm/drm_privacy_screen_driver.h create mode 100644 include/drm/drm_privacy_screen_machine.h -- 2.31.1

5 20

[Bug 205169] New: AMDGPU driver with Navi card hangs Xorg in fullscreen only.
by bugzilla-daemon＠bugzilla.kernel.org 03 Aug '21

03 Aug '21

https://bugzilla.kernel.org/show_bug.cgi?id=205169 Bug ID: 205169 Summary: AMDGPU driver with Navi card hangs Xorg in fullscreen only. Product: Drivers Version: 2.5 Kernel Version: 5.4.0-rc2 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: drjoms(a)gmail.com Regression: No I have another problem logged with Navi + AMDGPU drivers. It's triggered independently and reliable. https://bugzilla.kernel.org/show_bug.cgi?id=204725 With that said, starting strictly and specifically with kernel version 5.4.0* I have new problem. I successfully load into Xorg. I can start OpenGL and Vulkan games in non full screen. But once I start them - input devices hang, screen freezes. Machine is responsive over SSH/ethernet. I can raise skinny elephants. I tried opening a few games in non full screen mode and in full screen mode. And i reliably hit bug everytime anything with OpenGL goes full screen on native resolution of the screen. I noticed, issue is less likely to happen if program goes full screen in non native resolution. I will attach details in files for DMESG, lsmod and some other things directly as message, if they are short enough. -- You are receiving this mail because: You are watching the assignee of the bug.

1 27

[PATCH] drm/vbox: Convert to Linux IRQ interfaces
by Thomas Zimmermann 03 Aug '21

03 Aug '21

Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> --- drivers/gpu/drm/vboxvideo/vbox_drv.c | 1 - drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 - drivers/gpu/drm/vboxvideo/vbox_irq.c | 16 +++++++++++----- 3 files changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c b/drivers/gpu/drm/vboxvideo/vbox_drv.c index 879a2445cc44..2b81cb259d23 100644 --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c @@ -184,7 +184,6 @@ static const struct drm_driver driver = { .lastclose = drm_fb_helper_lastclose, .fops = &vbox_fops, - .irq_handler = vbox_irq_handler, .name = DRIVER_NAME, .desc = DRIVER_DESC, .date = DRIVER_DATE, diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h b/drivers/gpu/drm/vboxvideo/vbox_drv.h index ac7c2effc46f..4903b91d7fe4 100644 --- a/drivers/gpu/drm/vboxvideo/vbox_drv.h +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h @@ -145,7 +145,6 @@ void vbox_mm_fini(struct vbox_private *vbox); int vbox_irq_init(struct vbox_private *vbox); void vbox_irq_fini(struct vbox_private *vbox); void vbox_report_hotplug(struct vbox_private *vbox); -irqreturn_t vbox_irq_handler(int irq, void *arg); /* vbox_hgsmi.c */ void *hgsmi_buffer_alloc(struct gen_pool *guest_pool, size_t size, diff --git a/drivers/gpu/drm/vboxvideo/vbox_irq.c b/drivers/gpu/drm/vboxvideo/vbox_irq.c index b3ded68603ba..903a6c48ee8b 100644 --- a/drivers/gpu/drm/vboxvideo/vbox_irq.c +++ b/drivers/gpu/drm/vboxvideo/vbox_irq.c @@ -10,7 +10,8 @@ */ #include <linux/pci.h> -#include <drm/drm_irq.h> + +#include <drm/drm_drv.h> #include <drm/drm_probe_helper.h> #include "vbox_drv.h" @@ -31,7 +32,7 @@ void vbox_report_hotplug(struct vbox_private *vbox) schedule_work(&vbox->hotplug_work); } -irqreturn_t vbox_irq_handler(int irq, void *arg) +static irqreturn_t vbox_irq_handler(int irq, void *arg) { struct drm_device *dev = (struct drm_device *)arg; struct vbox_private *vbox = to_vbox_dev(dev); @@ -170,16 +171,21 @@ static void vbox_hotplug_worker(struct work_struct *work) int vbox_irq_init(struct vbox_private *vbox) { - struct pci_dev *pdev = to_pci_dev(vbox->ddev.dev); + struct drm_device *dev = &vbox->ddev; + struct pci_dev *pdev = to_pci_dev(dev->dev); INIT_WORK(&vbox->hotplug_work, vbox_hotplug_worker); vbox_update_mode_hints(vbox); - return drm_irq_install(&vbox->ddev, pdev->irq); + /* PCI devices require shared interrupts. */ + return request_irq(pdev->irq, vbox_irq_handler, IRQF_SHARED, dev->driver->name, dev); } void vbox_irq_fini(struct vbox_private *vbox) { - drm_irq_uninstall(&vbox->ddev); + struct drm_device *dev = &vbox->ddev; + struct pci_dev *pdev = to_pci_dev(dev->dev); + + free_irq(pdev->irq, dev); flush_work(&vbox->hotplug_work); } -- 2.32.0

3 3

[PATCH v5] drm/mediatek: add dither 6 setting
by Yongqiang Niu 02 Aug '21

02 Aug '21

Change since v4: - change commit message Yongqiang Niu (1): Fixes: a6b7c98afdca(drm/mediatek: add mtk_dither_set_common() function) drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++ 1 file changed, 2 insertions(+) -- 1.8.1.1.dirty

2 2

← Newer
1
...
17
18
19
20
21
22
23
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021