dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH] drm/rockchip: dsi: Fix duplicate included linux/phy/phy.h
by Jiapeng Chong 21 Sep '21

21 Sep '21

Clean up the following includecheck warning: ./drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c: linux/phy/phy.h is included more than once. Reported-by: Abaci Robot <abaci(a)linux.alibaba.com> Fixes: 71f68fe7f121 ("drm/rockchip: dsi: add ability to work as a phy instead of full dsi") Signed-off-by: Jiapeng Chong <jiapeng.chong(a)linux.alibaba.com> --- drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c index a2262be..4a6c100 100644 --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c @@ -14,7 +14,6 @@ #include <linux/of_device.h> #include <linux/phy/phy.h> #include <linux/pm_runtime.h> -#include <linux/phy/phy.h> #include <linux/regmap.h> #include <video/mipi_display.h> -- 1.8.3.1

2 1

[PATCH] drm/rockchip: Make use of the helper function devm_platform_ioremap_resource()
by Cai Huoqing 21 Sep '21

21 Sep '21

Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing(a)baidu.com> --- drivers/gpu/drm/rockchip/cdn-dp-core.c | 4 +--- drivers/gpu/drm/rockchip/inno_hdmi.c | 4 +--- drivers/gpu/drm/rockchip/rockchip_lvds.c | 4 +--- 3 files changed, 3 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c b/drivers/gpu/drm/rockchip/cdn-dp-core.c index 8ab3247dbc4a..5dce875dbd11 100644 --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c @@ -697,7 +697,6 @@ static int cdn_dp_parse_dt(struct cdn_dp_device *dp) struct device *dev = dp->dev; struct device_node *np = dev->of_node; struct platform_device *pdev = to_platform_device(dev); - struct resource *res; dp->grf = syscon_regmap_lookup_by_phandle(np, "rockchip,grf"); if (IS_ERR(dp->grf)) { @@ -705,8 +704,7 @@ static int cdn_dp_parse_dt(struct cdn_dp_device *dp) return PTR_ERR(dp->grf); } - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - dp->regs = devm_ioremap_resource(dev, res); + dp->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(dp->regs)) { DRM_DEV_ERROR(dev, "ioremap reg failed\n"); return PTR_ERR(dp->regs); diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchip/inno_hdmi.c index 7afdc54eb3ec..046e8ec2a71c 100644 --- a/drivers/gpu/drm/rockchip/inno_hdmi.c +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c @@ -810,7 +810,6 @@ static int inno_hdmi_bind(struct device *dev, struct device *master, struct platform_device *pdev = to_platform_device(dev); struct drm_device *drm = data; struct inno_hdmi *hdmi; - struct resource *iores; int irq; int ret; @@ -821,8 +820,7 @@ static int inno_hdmi_bind(struct device *dev, struct device *master, hdmi->dev = dev; hdmi->drm_dev = drm; - iores = platform_get_resource(pdev, IORESOURCE_MEM, 0); - hdmi->regs = devm_ioremap_resource(dev, iores); + hdmi->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(hdmi->regs)) return PTR_ERR(hdmi->regs); diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c index 551653940e39..50574649a472 100644 --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c @@ -439,11 +439,9 @@ struct drm_encoder_helper_funcs px30_lvds_encoder_helper_funcs = { static int rk3288_lvds_probe(struct platform_device *pdev, struct rockchip_lvds *lvds) { - struct resource *res; int ret; - res = platform_get_resource(pdev, IORESOURCE_MEM, 0); - lvds->regs = devm_ioremap_resource(lvds->dev, res); + lvds->regs = devm_platform_ioremap_resource(pdev, 0); if (IS_ERR(lvds->regs)) return PTR_ERR(lvds->regs); -- 2.25.1

2 1

[PATCH] drm/rockchip: remove unused psr_list{,_lock}
by Brian Norris 21 Sep '21

21 Sep '21

Some leftover cleanup from commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"). Cc: Heiko Stuebner <heiko(a)sntech.de> Cc: Sean Paul <seanpaul(a)chromium.org> Signed-off-by: Brian Norris <briannorris(a)chromium.org> --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 3 --- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 2 -- 2 files changed, 5 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index bfba9793d238..6fa686e6c7e9 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -138,9 +138,6 @@ static int rockchip_drm_bind(struct device *dev) drm_dev->dev_private = private; - INIT_LIST_HEAD(&private->psr_list); - mutex_init(&private->psr_list_lock); - ret = rockchip_drm_init_iommu(drm_dev); if (ret) goto err_free; diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h index e33c2dcd0d4b..aa0909e8edf9 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h @@ -48,8 +48,6 @@ struct rockchip_drm_private { struct iommu_domain *domain; struct mutex mm_lock; struct drm_mm mm; - struct list_head psr_list; - struct mutex psr_list_lock; }; int rockchip_drm_dma_attach_device(struct drm_device *drm_dev, -- 2.33.0.309.g3052b89438-goog

2 1

[PATCH] drm/rockchip: Check iommu itself instead of it's parent for device_is_available
by Andy Yan 21 Sep '21

21 Sep '21

When iommu itself is disabled in dts, we should fallback to non-iommu buffer, check iommu parent is meanless here. Signed-off-by: Andy Yan <andy.yan(a)rock-chips.com> --- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c index 212bd87c0c4a..0d20c8cc1ffa 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c @@ -366,7 +366,7 @@ static int rockchip_drm_platform_of_probe(struct device *dev) } iommu = of_parse_phandle(port->parent, "iommus", 0); - if (!iommu || !of_device_is_available(iommu->parent)) { + if (!iommu || !of_device_is_available(iommu)) { DRM_DEV_DEBUG(dev, "no iommu attached for %pOF, using non-iommu buffers\n", port->parent); -- 2.25.1

3 3

[PATCH] doc: gpu: drm-internals: Create reference to DRM mm
by Markus Schneider-Pargmann 21 Sep '21

21 Sep '21

This short sentence references nothing for details about memory manager. Replace it with the documentation file for DRM memory management. Cc: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Markus Schneider-Pargmann <msp(a)baylibre.com> --- Documentation/gpu/drm-internals.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 06af044c882f..bdcdfc4ede04 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -126,8 +126,8 @@ Memory Manager Initialization Every DRM driver requires a memory manager which must be initialized at load time. DRM currently contains two memory managers, the Translation Table Manager (TTM) and the Graphics Execution Manager (GEM). This -document describes the use of the GEM memory manager only. See ? for -details. +document describes the use of the GEM memory manager only. See +Documentation/gpu/drm-mm.rst for details. Miscellaneous Device Configuration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- 2.33.0

2 3

[PATCH v3] drm/rockchip: Update crtc fixup to account for fractional clk change
by Chris Morgan 21 Sep '21

21 Sep '21

From: Chris Morgan <macromorgan(a)hotmail.com> After commit 928f9e268611 ("clk: fractional-divider: Hide clk_fractional_divider_ops from wide audience") was merged it appears that the DSI panel on my Odroid Go Advance stopped working. Upon closer examination of the problem, it looks like it was the fixup in the rockchip_drm_vop.c file was causing the issue. The changes made to the clk driver appear to change some assumptions made in the fixup. After debugging the working 5.14 kernel and the no-longer working 5.15 kernel, it looks like this was broken all along but still worked, whereas after the fractional clock change it stopped working despite the issue (it went from sort-of broken to very broken). In the 5.14 kernel the dclk_vopb_frac was being requested to be set to 17000999 on my board. The clock driver was taking the value of the parent clock and attempting to divide the requested value from it (17000000/17000999 = 0), then subtracting 1 from it (making it -1), and running it through fls_long to get 64. It would then subtract the value of fd->mwidth from it to get 48, and then bit shift 17000999 to the left by 48, coming up with a very large number of 7649082492112076800. This resulted in a numerator of 65535 and a denominator of 1 from the clk driver. The driver seemingly would try again and get a correct 1:1 value later, and then move on. Output from my 5.14 kernel (with some printfs for good measure): [ 2.830066] rockchip-drm display-subsystem: bound ff460000.vop (ops vop_component_ops) [ 2.839431] rockchip-drm display-subsystem: bound ff450000.dsi (ops dw_mipi_dsi_rockchip_ops) [ 2.855980] Clock is dclk_vopb_frac [ 2.856004] Scale 64, Rate 7649082492112076800, Oldrate 17000999, Parent Rate 17000000, Best Numerator 65535, Best Denominator 1, fd->mwidth 16 [ 2.903529] Clock is dclk_vopb_frac [ 2.903556] Scale 0, Rate 17000000, Oldrate 17000000, Parent Rate 17000000, Best Numerator 1, Best Denominator 1, fd->mwidth 16 [ 2.903579] Clock is dclk_vopb_frac [ 2.903583] Scale 0, Rate 17000000, Oldrate 17000000, Parent Rate 17000000, Best Numerator 1, Best Denominator 1, fd->mwidth 16 Contrast this with 5.15 after the clk change where the rate of 17000999 was getting passed and resulted in numerators/denomiators of 17001/ 17000. Output from my 5.15 kernel (with some printfs added for good measure): [ 2.817571] rockchip-drm display-subsystem: bound ff460000.vop (ops vop_component_ops) [ 2.826975] rockchip-drm display-subsystem: bound ff450000.dsi (ops dw_mipi_dsi_rockchip_ops) [ 2.843430] Rate 17000999, Parent Rate 17000000, Best Numerator 17018, Best Denominator 17017 [ 2.891073] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000 [ 2.891269] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000 [ 2.891281] Rate 17001000, Parent Rate 17000000, Best Numerator 17001, Best Denominator 17000 I have tested the change extensively on my Odroid Go Advance (Rockchip RK3326) and it appears to work well. However, this change will affect all Rockchip SoCs that use this driver so I believe further testing is warranted. Please note that without this change I can confirm at least all PX30s with DSI panels will stop working with the 5.15 kernel. Upon advice from Doug Anderson <dianders(a)chromium.org> it was decided that we would first check if the clock rate can be set exactly as requested, and only if it could not would we then add 999 to it and attempt the process again. This way we can preserve the behavior for clocks that still need it while resolving the specific issue for the PX30 and DSI panels (since it is using a fractional clock). Changes since v2: - Moved fixes to correct location. Changes since v1: - Made the addition of 999 conditional based on whether the clock subsystem can set the actual clock rate as requested. - Updated the notes in the fixup routine to reflect this new behavior. - Added reference to original commit, as this has technically been broken since then however only now is it an issue due to the clock changes. Fixes: 287422a95fe2 ("drm/rockchip: Round up _before_ giving to the clock framework") Signed-off-by: Chris Morgan <macromorgan(a)hotmail.com> --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 26 ++++++++++----------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index ba9e14da41b4..a25b98b7f5bd 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -1174,26 +1174,24 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc, * * Action plan: * - * 1. When DRM gives us a mode, we should add 999 Hz to it. That way - * if the clock we need is 60000001 Hz (~60 MHz) and DRM tells us to - * make 60000 kHz then the clock framework will actually give us - * the right clock. + * 1. Try to set the exact rate first, and confirm the clock framework + * can provide it. * - * NOTE: if the PLL (maybe through a divider) could actually make - * a clock rate 999 Hz higher instead of the one we want then this - * could be a problem. Unfortunately there's not much we can do - * since it's baked into DRM to use kHz. It shouldn't matter in - * practice since Rockchip PLLs are controlled by tables and - * even if there is a divider in the middle I wouldn't expect PLL - * rates in the table that are just a few kHz different. + * 2. If the clock framework cannot provide the exact rate, we should + * add 999 Hz to the requested rate. That way if the clock we need + * is 60000001 Hz (~60 MHz) and DRM tells us to make 60000 kHz then + * the clock framework will actually give us the right clock. * - * 2. Get the clock framework to round the rate for us to tell us + * 3. Get the clock framework to round the rate for us to tell us * what it will actually make. * - * 3. Store the rounded up rate so that we don't need to worry about + * 4. Store the rounded up rate so that we don't need to worry about * this in the actual clk_set_rate(). */ - rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000 + 999); + rate = clk_round_rate(vop->dclk, adjusted_mode->clock * 1000); + if (rate / 1000 != adjusted_mode->clock) + rate = clk_round_rate(vop->dclk, + adjusted_mode->clock * 1000 + 999); adjusted_mode->clock = DIV_ROUND_UP(rate, 1000); return true; -- 2.25.1

5 4

[PATCH] dt-bindings: panel: ilitek, ili9341: Fix the warning-wrong indentation: expected 10 but found 8 (indentation)
by Cai Huoqing 20 Sep '21

20 Sep '21

Fix indentation for the warning- wrong indentation: expected 10 but found 8 (indentation) Signed-off-by: Cai Huoqing <caihuoqing(a)baidu.com> --- .../devicetree/bindings/display/panel/ilitek,ili9341.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml index 2ed010f91e2d..20ce88ab4b3a 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml @@ -22,7 +22,7 @@ properties: items: - enum: # ili9341 240*320 Color on stm32f429-disco board - - st,sf-tc240t-9370-t + - st,sf-tc240t-9370-t - const: ilitek,ili9341 reg: true -- 2.25.1

2 1

[PATCH 00/15] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
by Fernando Ramos 20 Sep '21

20 Sep '21

Hi all, One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this patch series is about. You will find two types of changes here: - Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate) with "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has already been done in previous commits such as b7ea04d2) - Replacing "drm_modeset_lock_all()" with "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has already been done in previous commits such as 57037094) Most of the changes are straight forward, except for a few cases in the "amd" and "i915" drivers where some extra dancing was needed to overcome the limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be used once inside the same function (the reason being that the macro expansion includes *labels*, and you can not have two labels named the same inside one function) Notice that, even after this patch series, some places remain where "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still present, all inside drm core (which makes sense), except for two (in "amd" and "i915") which cannot be replaced due to the way they are being used. Fernando Ramos (15): dmr: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() dmr/i915: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() dmr/msm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/shmobile: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/omapdrm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/nouveau: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup Documentation/gpu/todo.rst | 17 ------- Documentation/locking/ww-mutex-design.rst | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 13 +++-- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +++++++++---------- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 23 +++++---- drivers/gpu/drm/drm_client_modeset.c | 14 +++--- drivers/gpu/drm/drm_crtc_helper.c | 18 ++++--- drivers/gpu/drm/drm_fb_helper.c | 10 ++-- drivers/gpu/drm/drm_framebuffer.c | 6 ++- drivers/gpu/drm/gma500/psb_device.c | 14 ++++-- drivers/gpu/drm/i915/display/intel_audio.c | 12 +++-- drivers/gpu/drm/i915/display/intel_display.c | 22 +++----- .../drm/i915/display/intel_display_debugfs.c | 35 ++++++++----- drivers/gpu/drm/i915/display/intel_overlay.c | 45 ++++++++--------- drivers/gpu/drm/i915/display/intel_pipe_crc.c | 5 +- drivers/gpu/drm/i915/i915_drv.c | 12 +++-- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 ++- .../gpu/drm/msm/disp/msm_disp_snapshot_util.c | 10 ++-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 12 +++-- drivers/gpu/drm/omapdrm/omap_fb.c | 6 ++- drivers/gpu/drm/radeon/radeon_device.c | 13 +++-- drivers/gpu/drm/radeon/radeon_dp_mst.c | 7 ++- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++- drivers/gpu/drm/tegra/dsi.c | 6 ++- drivers/gpu/drm/tegra/hdmi.c | 5 +- drivers/gpu/drm/tegra/sor.c | 10 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 ++-- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +++-- 28 files changed, 222 insertions(+), 180 deletions(-) -- 2.33.0

4 44

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

20 Sep '21

Hi all, Here is the privacy-screen related code which I last posted in April 2021 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). This is unchanged (except for a rebase on drm-tip), what has changed is that the first userspace consumer of the new properties is now fully ready for merging (it is just waiting for the kernel bits to land first): - https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/-/merge_requests/49 - https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1952 - https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1032 Having a userspace-consumer of the API fully ready for merging, clears the last blocker for this series. It has already has been reviewed before by Emil Velikov, but it could really do with another review. The new API works as designed and 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 (v3) 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 | 65 +++ include/drm/drm_privacy_screen_driver.h | 84 ++++ include/drm/drm_privacy_screen_machine.h | 46 ++ 19 files changed, 1175 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

4 35

[PATCH] drm/i915: fix blank screen booting crashes
by Matthew Brost 20 Sep '21

20 Sep '21

From: Hugh Dickins <hughd(a)google.com> 5.15-rc1 crashes with blank screen when booting up on two ThinkPads using i915. Bisections converge convincingly, but arrive at different and surprising "culprits", none of them the actual culprit. netconsole (with init_netconsole() hacked to call i915_init() when logging has started, instead of by module_init()) tells the story: kernel BUG at drivers/gpu/drm/i915/i915_sw_fence.c:245! with RSI: ffffffff814d408b pointing to sw_fence_dummy_notify(). I've been building with CONFIG_CC_OPTIMIZE_FOR_SIZE=y, and that function needs to be 4-byte aligned. v2: (Jani Nikula) - Change BUG_ON to WARN_ON Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Hugh Dickins <hughd(a)google.com> Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> Reviewed-by: Matthew Brost <matthew.brost(a)intel.com> --- drivers/gpu/drm/i915/gt/intel_context.c | 1 + drivers/gpu/drm/i915/i915_sw_fence.c | 4 +++- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_context.c b/drivers/gpu/drm/i915/gt/intel_context.c index ff637147b1a9..f02c2202da9d 100644 --- a/drivers/gpu/drm/i915/gt/intel_context.c +++ b/drivers/gpu/drm/i915/gt/intel_context.c @@ -362,6 +362,7 @@ static int __intel_context_active(struct i915_active *active) return 0; } +__aligned(4) /* Respect the I915_SW_FENCE_MASK */ static int sw_fence_dummy_notify(struct i915_sw_fence *sf, enum i915_sw_fence_notify state) { diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c b/drivers/gpu/drm/i915/i915_sw_fence.c index c589a681da77..1217b124c1d0 100644 --- a/drivers/gpu/drm/i915/i915_sw_fence.c +++ b/drivers/gpu/drm/i915/i915_sw_fence.c @@ -14,8 +14,10 @@ #if IS_ENABLED(CONFIG_DRM_I915_DEBUG) #define I915_SW_FENCE_BUG_ON(expr) BUG_ON(expr) +#define I915_SW_FENCE_WARN_ON(expr) WARN_ON(expr) #else #define I915_SW_FENCE_BUG_ON(expr) BUILD_BUG_ON_INVALID(expr) +#define I915_SW_FENCE_WARN_ON(expr) BUILD_BUG_ON_INVALID(expr) #endif static DEFINE_SPINLOCK(i915_sw_fence_lock); @@ -242,7 +244,7 @@ void __i915_sw_fence_init(struct i915_sw_fence *fence, const char *name, struct lock_class_key *key) { - BUG_ON(!fn || (unsigned long)fn & ~I915_SW_FENCE_MASK); + I915_SW_FENCE_WARN_ON(!fn || (unsigned long)fn & ~I915_SW_FENCE_MASK); __init_waitqueue_head(&fence->wait, name, key); fence->flags = (unsigned long)fn; -- 2.32.0

3 5

← Newer
1
...
42
43
44
45
46
47
48
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021