dri-devel August 2021

dri-devel@lists.freedesktop.org

324 participants
762 discussions

[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

[PATCH 0/8] Enable triggered perf query for Xe_HP
by Umesh Nerlige Ramappa 03 Aug '21

03 Aug '21

This is a revival of the patch series to support triggered perf query reports from here - https://patchwork.freedesktop.org/series/83831/ The patches were not pushed earlier because corresponding UMD changes were missing. This revival addresses UMD changes in GPUvis for this series. GPUvis uses the perf library in igt-gpu-tools. Changes to the library are here - https://patchwork.freedesktop.org/series/93355/ GPUvis changes will be posted as a PR once the above library and kernel changes are pushed. Summary of the feature: Current platforms provide MI_REPORT_PERF_COUNT to query a snapshot of perf counters from a batch. This mechanism does not have consistent support on all engines for newer platforms. To support perf query, all new platforms use a mechanism to trigger OA report snapshots into the OA buffer by writing to a HW register from a batch. To lookup this report in the OA buffer quickly, the OA buffer is mmapped into the user space. This series implements the new query mechanism. Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa(a)intel.com> Chris Wilson (3): drm/i915/gt: Refactor _wa_add to reuse wa_index and wa_list_grow drm/i915/gt: Check for conflicting RING_NONPRIV drm/i915/gt: Enable dynamic adjustment of RING_NONPRIV Piotr Maciejewski (1): drm/i915/perf: Ensure observation logic is not clock gated Umesh Nerlige Ramappa (4): drm/i915/gt: Lock intel_engine_apply_whitelist with uncore->lock drm/i915/perf: Whitelist OA report trigger registers drm/i915/perf: Whitelist OA counter and buffer registers drm/i915/perf: Map OA buffer to user space for gen12 performance query drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 269 +++++++++++++----- drivers/gpu/drm/i915/gt/intel_workarounds.h | 7 + .../gpu/drm/i915/gt/selftest_workarounds.c | 237 +++++++++++++++ drivers/gpu/drm/i915/i915_perf.c | 228 ++++++++++++++- drivers/gpu/drm/i915/i915_perf_types.h | 8 + drivers/gpu/drm/i915/i915_reg.h | 30 +- include/uapi/drm/i915_drm.h | 33 +++ 9 files changed, 728 insertions(+), 88 deletions(-) -- 2.20.1

1 10

[PATCH V5 0/2] drm/vkms: Add virtual hardware module
by Sumera Priyadarsini 03 Aug '21

03 Aug '21

This patchset adds support for emulating virtual hardware with VKMS. The virtual hardware mode can be enabled by using the following command while loading the module: sudo modprobe vkms enable_virtual_hw=1 The first patch is prep work for adding virtual_hw mode and refactors the plane composition in vkms by adding a helper function vkms_composer_common() which can be used for both vblank mode and virtual mode. The second patch adds virtual hardware support as a module option. It adds new atomic helper functions for the virtual mode and modifies the existing atomic helpers for usage by the vblank mode This gives us two sets of drm_crtc_helper_funcs struct for both modes, making the code flow cleaner and easier to debug. This patchset has been tested with the igt tests- kms_writeback, kms_atomic, kms_lease, kms_flip, kms_pipe_get_crc and preserves results except for subtests related to crc reads and skips tests that rely on vertical blanking. Sumera Priyadarsini (2): drm/vkms: Refactor vkms_composer_worker() to prep for virtual_hw mode drm/vkms: Add support for virtual hardware mode drivers/gpu/drm/vkms/vkms_composer.c | 93 ++++++++++++++++++---------- drivers/gpu/drm/vkms/vkms_crtc.c | 51 ++++++++++----- drivers/gpu/drm/vkms/vkms_drv.c | 16 +++-- drivers/gpu/drm/vkms/vkms_drv.h | 4 ++ 4 files changed, 112 insertions(+), 52 deletions(-) -- 2.31.1

2 3

[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 AUTOSEL 5.10 9/9] drm/amdgpu/display: only enable aux backlight control for OLED panels
by Sasha Levin 03 Aug '21

03 Aug '21

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit f2ad3accefc63e72e9932e141c21875cc04beec8 ] We've gotten a number of reports about backlight control not working on panels which indicate that they use aux backlight control. A recent patch: commit 2d73eabe2984a435737498ab39bb1500a9ffe9a9 Author: Camille Cho <Camille.Cho(a)amd.com> Date: Thu Jul 8 18:28:37 2021 +0800 drm/amd/display: Only set default brightness for OLED [Why] We used to unconditionally set backlight path as AUX for panels capable of backlight adjustment via DPCD in set default brightness. [How] This should be limited to OLED panel only since we control backlight via PWM path for SDR mode in LCD HDR panel. Reviewed-by: Krunoslav Kovac <krunoslav.kovac(a)amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira(a)amd.com> Signed-off-by: Camille Cho <Camille.Cho(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Changes some other code to only use aux for backlight control on OLED panels. The commit message seems to indicate that PWM should be used for SDR mode on HDR panels. Do something similar for backlight control in general. This may need to be revisited if and when HDR started to get used. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1438 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213715 Reviewed-by: Roman Li <Roman.Li(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 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 6eb308670f48..8d537123e4ad 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2162,9 +2162,9 @@ static void update_connector_ext_caps(struct amdgpu_dm_connector *aconnector) max_cll = conn_base->hdr_sink_metadata.hdmi_type1.max_cll; min_cll = conn_base->hdr_sink_metadata.hdmi_type1.min_cll; - if (caps->ext_caps->bits.oled == 1 || + if (caps->ext_caps->bits.oled == 1 /*|| caps->ext_caps->bits.sdr_aux_backlight_control == 1 || - caps->ext_caps->bits.hdr_aux_backlight_control == 1) + caps->ext_caps->bits.hdr_aux_backlight_control == 1*/) caps->aux_support = true; if (amdgpu_backlight == 0) -- 2.30.2

1 0

[PATCH AUTOSEL 5.13 09/11] drm/amdgpu/display: only enable aux backlight control for OLED panels
by Sasha Levin 03 Aug '21

03 Aug '21

From: Alex Deucher <alexander.deucher(a)amd.com> [ Upstream commit f2ad3accefc63e72e9932e141c21875cc04beec8 ] We've gotten a number of reports about backlight control not working on panels which indicate that they use aux backlight control. A recent patch: commit 2d73eabe2984a435737498ab39bb1500a9ffe9a9 Author: Camille Cho <Camille.Cho(a)amd.com> Date: Thu Jul 8 18:28:37 2021 +0800 drm/amd/display: Only set default brightness for OLED [Why] We used to unconditionally set backlight path as AUX for panels capable of backlight adjustment via DPCD in set default brightness. [How] This should be limited to OLED panel only since we control backlight via PWM path for SDR mode in LCD HDR panel. Reviewed-by: Krunoslav Kovac <krunoslav.kovac(a)amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira(a)amd.com> Signed-off-by: Camille Cho <Camille.Cho(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Changes some other code to only use aux for backlight control on OLED panels. The commit message seems to indicate that PWM should be used for SDR mode on HDR panels. Do something similar for backlight control in general. This may need to be revisited if and when HDR started to get used. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1438 Bug: https://bugzilla.kernel.org/show_bug.cgi?id=213715 Reviewed-by: Roman Li <Roman.Li(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 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 eeaae1cf2bc2..f02ad2eb154b 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2367,9 +2367,9 @@ static void update_connector_ext_caps(struct amdgpu_dm_connector *aconnector) max_cll = conn_base->hdr_sink_metadata.hdmi_type1.max_cll; min_cll = conn_base->hdr_sink_metadata.hdmi_type1.min_cll; - if (caps->ext_caps->bits.oled == 1 || + if (caps->ext_caps->bits.oled == 1 /*|| caps->ext_caps->bits.sdr_aux_backlight_control == 1 || - caps->ext_caps->bits.hdr_aux_backlight_control == 1) + caps->ext_caps->bits.hdr_aux_backlight_control == 1*/) caps->aux_support = true; if (amdgpu_backlight == 0) -- 2.30.2

1 0

[PATCH v3 0/4] drm/msm/dpu: always use mdp device to scale bandwidth
by Dmitry Baryshkov 03 Aug '21

03 Aug '21

In 5.13 the DPU driver was changed to vote on the bus bandwidth for all the soc families, however suggested [1] dts changes were for some reason not merged at that time. Let's merge them now. If the bootloader does not setup the bus vote, clock might not be enabled before the driver votes on the MDP bus bandwidth. Originally bus votes were static and happened in MDSS hadling code, while now they are dynamic and are moved to the MDP handling code, thus bus clocks also should belong to the MDP device. [1] https://lore.kernel.org/linux-arm-msm/04b4612dfd3f651ead068725409211a0@code… Changes since v2: - Dropped merged patches - Rephrased commit message for sm8250. Changes since v1: - Add dts changes as requested by Kalyan Thota ---------------------------------------------------------------- Dmitry Baryshkov (2): arm64: dts: sdm845: move bus clock to mdp node for sdm845 target arm64: dts: sm8250: remove bus clock from the mdss node for sm8250 target arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 ++++---- arch/arm64/boot/dts/qcom/sm8250.dtsi | 3 +-- 2 files changed, 5 insertions(+), 6 deletions(-)

1 2

Re: [PATCH 01/21] drm/i915/gvt: integrate into the main Makefile
by Zhenyu Wang 03 Aug '21

03 Aug '21

On 2021.07.21 17:53:35 +0200, 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. > We agreed to make gvt mostly self-contained in its own directory before. Although I don't think we would change files much later, but still need to get ack from i915 maintainers. Thanks > 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 > > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 4f22cac1c49b..2153f67705b8 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -289,11 +289,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 ea8324abc784..000000000000 > --- 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 6d787750d279..348f57f8301d 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> > -- > 2.30.2 > > _______________________________________________ > intel-gvt-dev mailing list > intel-gvt-dev(a)lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev

1 0

[PATCH v2] drm/msm/dp: update is_connected status base on sink count at dp_pm_resume()
by Kuogee Hsieh 03 Aug '21

03 Aug '21

Currently at dp_pm_resume() is_connected state is decided base on hpd connection status only. This will put is_connected in wrongly "true" state at the scenario that dongle attached to DUT but without hmdi cable connecting to it. Fix this problem by adding read sink count from dongle and decided is_connected state base on both sink count and hpd connection status. Changes in v2: -- remove dp_get_sink_count() cand call drm_dp_read_sink_count() Fixes: d9aa6571b28ba ("drm/msm/dp: check sink_count before update is_connected status") Signed-off-by: Kuogee Hsieh <khsieh(a)codeaurora.org> --- drivers/gpu/drm/msm/dp/dp_display.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c index 8b69114..6dcb78e 100644 --- a/drivers/gpu/drm/msm/dp/dp_display.c +++ b/drivers/gpu/drm/msm/dp/dp_display.c @@ -1403,6 +1403,7 @@ static int dp_pm_resume(struct device *dev) struct msm_dp *dp_display = platform_get_drvdata(pdev); struct dp_display_private *dp; u32 status; + int sink_count = 0; dp = container_of(dp_display, struct dp_display_private, dp_display); xlog(__func__, 1,0,0, dp->core_initialized, dp_display->power_on); @@ -1417,15 +1418,26 @@ xlog(__func__, 1,0,0, dp->core_initialized, dp_display->power_on); dp_catalog_ctrl_hpd_config(dp->catalog); - status = dp_catalog_link_is_connected(dp->catalog); + /* + * set sink to normal operation mode -- D0 + * before dpcd read + */ + dp_link_psm_config(dp->link, &dp->panel->link_info, false); + + /* if sink conencted, do dpcd read sink count */ + if ((status = dp_catalog_link_is_connected(dp->catalog))) { + sink_count = drm_dp_read_sink_count(dp->aux); + if (sink_count < 0) + sink_count = 0; + } + dp->link->sink_count = sink_count; /* * can not declared display is connected unless * HDMI cable is plugged in and sink_count of * dongle become 1 */ -xlog(__func__, 0x12,0,0, 0, dp->link->sink_count); - if (status && dp->link->sink_count) + if (dp->link->sink_count) dp->dp_display.is_connected = true; else dp->dp_display.is_connected = false; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project

2 1

[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

← Newer
1
...
69
70
71
72
73
74
75
76
77
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2021