dri-devel May 2021

dri-devel@lists.freedesktop.org

348 participants
807 discussions

[PATCH AUTOSEL 5.10 001/100] drm: Added orientation quirk for OneGX1 Pro
by Sasha Levin 03 May '21

03 May '21

From: Jared Baldridge <jrb(a)expunge.us> [ Upstream commit 81ad7f9f78e4ff80e95be8282423f511b84f1166 ] The OneGX1 Pro has a fairly unique combination of generic strings, but we additionally match on the BIOS date just to be safe. Signed-off-by: Jared Baldridge <jrb(a)expunge.us> Reviewed-by: Hans de Goede <hdegoede(a)redhat.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/41288ccb-1012-486b-81c1-a24c3… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/drm_panel_orientation_quirks.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c b/drivers/gpu/drm/drm_panel_orientation_quirks.c index 58f5dc2f6dd5..f6bdec7fa925 100644 --- a/drivers/gpu/drm/drm_panel_orientation_quirks.c +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c @@ -84,6 +84,13 @@ static const struct drm_dmi_panel_orientation_data itworks_tw891 = { .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP, }; +static const struct drm_dmi_panel_orientation_data onegx1_pro = { + .width = 1200, + .height = 1920, + .bios_dates = (const char * const []){ "12/17/2020", NULL }, + .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP, +}; + static const struct drm_dmi_panel_orientation_data lcd720x1280_rightside_up = { .width = 720, .height = 1280, @@ -211,6 +218,13 @@ static const struct dmi_system_id orientation_data[] = { DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Lenovo ideapad D330-10IGM"), }, .driver_data = (void *)&lcd1200x1920_rightside_up, + }, { /* OneGX1 Pro */ + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "SYSTEM_MANUFACTURER"), + DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "SYSTEM_PRODUCT_NAME"), + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "Default string"), + }, + .driver_data = (void *)&onegx1_pro, }, { /* VIOS LTH17 */ .matches = { DMI_EXACT_MATCH(DMI_SYS_VENDOR, "VIOS"), -- 2.30.2

1 22

[PATCH AUTOSEL 5.11 001/115] drm: Added orientation quirk for OneGX1 Pro
by Sasha Levin 03 May '21

03 May '21

1 26

[PATCH AUTOSEL 5.12 001/134] drm: Added orientation quirk for OneGX1 Pro
by Sasha Levin 03 May '21

03 May '21

1 32

[PATCH] drm/i915/display Try YCbCr420 color when RGB fails
by Werner Sembach 03 May '21

03 May '21

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied from my commit message of the AMDGPU patch. On some setups, while the monitor and the gpu support display modes with pixel clocks of up to 600MHz, the link encoder might not. This prevents YCbCr444 and RGB encoding for 4k60Hz, but YCbCr420 encoding might still be possible. However, which color mode is used is decided before the link encoder capabilities are checked. This patch fixes the problem by retrying to find a display mode with YCbCr420 enforced and using it, if it is valid. I'm not entierly sure if the second "if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv))" check in intel_hdmi_compute_config(...) after forcing ycbcr420 is necessary. I included it to better be safe then sorry. Signed-off-by: Werner Sembach <wse(a)tuxedocomputers.com> Cc: <stable(a)vger.kernel.org> --- Rebased from 5.12 to drm-tip and resend to resolve merge conflict. >From 876c1c8d970ff2a411ee8d08651bd4edbe9ecb3d Mon Sep 17 00:00:00 2001 From: Werner Sembach <wse(a)tuxedocomputers.com> Date: Thu, 29 Apr 2021 13:59:30 +0200 Subject: [PATCH] Retry using YCbCr420 encoding if clock setup for RGB fails --- drivers/gpu/drm/i915/display/intel_hdmi.c | 80 +++++++++++++++++------ 1 file changed, 60 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 46de56af33db..c9b5a7d7f9c6 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -1861,6 +1861,30 @@ static int intel_hdmi_port_clock(int clock, int bpc) return clock * bpc / 8; } +static enum drm_mode_status +intel_hdmi_check_bpc(struct intel_hdmi *hdmi, int clock, bool has_hdmi_sink, struct drm_i915_private *dev_priv) +{ + enum drm_mode_status status; + + /* check if we can do 8bpc */ + status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 8), + true, has_hdmi_sink); + + if (has_hdmi_sink) { + /* if we can't do 8bpc we may still be able to do 12bpc */ + if (status != MODE_OK && !HAS_GMCH(dev_priv)) + status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 12), + true, has_hdmi_sink); + + /* if we can't do 8,12bpc we may still be able to do 10bpc */ + if (status != MODE_OK && DISPLAY_VER(dev_priv) >= 11) + status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 10), + true, has_hdmi_sink); + } + + return status; +} + static enum drm_mode_status intel_hdmi_mode_valid(struct drm_connector *connector, struct drm_display_mode *mode) @@ -1891,23 +1915,18 @@ intel_hdmi_mode_valid(struct drm_connector *connector, if (drm_mode_is_420_only(&connector->display_info, mode)) clock /= 2; - /* check if we can do 8bpc */ - status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 8), - true, has_hdmi_sink); + status = intel_hdmi_check_bpc(hdmi, clock, has_hdmi_sink, dev_priv); - if (has_hdmi_sink) { - /* if we can't do 8bpc we may still be able to do 12bpc */ - if (status != MODE_OK && !HAS_GMCH(dev_priv)) - status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 12), - true, has_hdmi_sink); + if (status != MODE_OK) { + if (drm_mode_is_420_also(&connector->display_info, mode)) { + /* if we can't do full color resolution we may still be able to do reduced color resolution */ + clock /= 2; - /* if we can't do 8,12bpc we may still be able to do 10bpc */ - if (status != MODE_OK && DISPLAY_VER(dev_priv) >= 11) - status = hdmi_port_clock_valid(hdmi, intel_hdmi_port_clock(clock, 10), - true, has_hdmi_sink); + status = intel_hdmi_check_bpc(hdmi, clock, has_hdmi_sink, dev_priv); + } + if (status != MODE_OK) + return status; } - if (status != MODE_OK) - return status; return intel_mode_valid_max_plane_size(dev_priv, mode, false); } @@ -1990,14 +2009,17 @@ static bool hdmi_deep_color_possible(const struct intel_crtc_state *crtc_state, static int intel_hdmi_ycbcr420_config(struct intel_crtc_state *crtc_state, - const struct drm_connector_state *conn_state) + const struct drm_connector_state *conn_state, + const bool force_ycbcr420) { struct drm_connector *connector = conn_state->connector; struct drm_i915_private *i915 = to_i915(connector->dev); const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode; - if (!drm_mode_is_420_only(&connector->display_info, adjusted_mode)) + if (!(drm_mode_is_420_only(&connector->display_info, adjusted_mode) || + (force_ycbcr420 && + drm_mode_is_420_also(&connector->display_info, adjusted_mode)))) return 0; if (!connector->ycbcr_420_allowed) { @@ -2126,7 +2148,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder, struct drm_display_mode *adjusted_mode = &pipe_config->hw.adjusted_mode; struct drm_connector *connector = conn_state->connector; struct drm_scdc *scdc = &connector->display_info.hdmi.scdc; - int ret; + int ret, ret_saved; if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) return -EINVAL; @@ -2141,7 +2163,7 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder, if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK) pipe_config->pixel_multiplier = 2; - ret = intel_hdmi_ycbcr420_config(pipe_config, conn_state); + ret = intel_hdmi_ycbcr420_config(pipe_config, conn_state, false); if (ret) return ret; @@ -2155,8 +2177,26 @@ int intel_hdmi_compute_config(struct intel_encoder *encoder, intel_hdmi_has_audio(encoder, pipe_config, conn_state); ret = intel_hdmi_compute_clock(encoder, pipe_config); - if (ret) - return ret; + if (ret) { + ret_saved = ret; + + ret = intel_hdmi_ycbcr420_config(pipe_config, conn_state, true); + if (ret) + return ret; + + if (pipe_config->output_format != INTEL_OUTPUT_FORMAT_YCBCR420) + return ret_saved; + + pipe_config->limited_color_range = + intel_hdmi_limited_color_range(pipe_config, conn_state); + + if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv)) + pipe_config->has_pch_encoder = true; + + ret = intel_hdmi_compute_clock(encoder, pipe_config); + if (ret) + return ret; + } if (conn_state->picture_aspect_ratio) adjusted_mode->picture_aspect_ratio = -- 2.25.1

2 3

Display notch support
by Caleb Connolly 03 May '21

03 May '21

With many more non-desktop form factor devices landing in the kernel, we're starting to run up against some limitations. Notably devices with display notches, cutouts and rounded corners. Given that the DRI subsystem already deals with physical display properties like panel orientation which is fixed in device tree, it would make sense to also define other properties like parts of the display which are obscured there too. This can then be read by desktop environments and UI elements can be suitably adjusted. Android already deals with non-square displays, however they also keep the device configuration in userspace: https://developer.android.com/guide/topics/display-cutout A solution to make this configuration generic and exposed by the kernel would standardise this across Linux and potentially Android too which would be extremely beneficial to the mobile Linux community at large. Does this seem like a feasible solution to solving the notch problem and avoiding a situation where every compositor have their own method of describing cutouts and rounded corners? Regards, Caleb

5 6

[PATCH] drm/etnaviv: rework linear window offset calculation
by Lucas Stach 03 May '21

03 May '21

The current calculation based on the required_dma mask can be significantly off, so that the linear window only overlaps a small part of the DRAM address space. This can lead to the command buffer being unmappable, which is obviously bad. Rework the linear window offset calculation to be based on the command buffer physical address, making sure that the command buffer is always mappable. Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 52 +++++++++++++-------------- 1 file changed, 26 insertions(+), 26 deletions(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c index c6404b8d067f..a454b13e8106 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c @@ -27,10 +27,6 @@ #include "state_hi.xml.h" #include "cmdstream.xml.h" -#ifndef PHYS_OFFSET -#define PHYS_OFFSET 0 -#endif - static const struct platform_device_id gpu_ids[] = { { .name = "etnaviv-gpu,2d" }, { }, @@ -724,6 +720,7 @@ static void etnaviv_gpu_hw_init(struct etnaviv_gpu *gpu) int etnaviv_gpu_init(struct etnaviv_gpu *gpu) { struct etnaviv_drm_private *priv = gpu->drm->dev_private; + dma_addr_t cmdbuf_paddr; int ret, i; ret = pm_runtime_get_sync(gpu->dev); @@ -766,28 +763,6 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) if (ret) goto fail; - /* - * Set the GPU linear window to be at the end of the DMA window, where - * the CMA area is likely to reside. This ensures that we are able to - * map the command buffers while having the linear window overlap as - * much RAM as possible, so we can optimize mappings for other buffers. - * - * For 3D cores only do this if MC2.0 is present, as with MC1.0 it leads - * to different views of the memory on the individual engines. - */ - if (!(gpu->identity.features & chipFeatures_PIPE_3D) || - (gpu->identity.minor_features0 & chipMinorFeatures0_MC20)) { - u32 dma_mask = (u32)dma_get_required_mask(gpu->dev); - if (dma_mask < PHYS_OFFSET + SZ_2G) - priv->mmu_global->memory_base = PHYS_OFFSET; - else - priv->mmu_global->memory_base = dma_mask - SZ_2G + 1; - } else if (PHYS_OFFSET >= SZ_2G) { - dev_info(gpu->dev, "Need to move linear window on MC1.0, disabling TS\n"); - priv->mmu_global->memory_base = PHYS_OFFSET; - gpu->identity.features &= ~chipFeatures_FAST_CLEAR; - } - /* * If the GPU is part of a system with DMA addressing limitations, * request pages for our SHM backend buffers from the DMA32 zone to @@ -804,6 +779,31 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu) goto fail; } + /* + * Set the GPU linear window to cover the cmdbuf region, as the GPU + * won't be able to start execution otherwise. The alignment to 128M is + * chosen arbitrarily but helps in debugging, as the MMU offset + * calculations are much more straight forward this way. + * + * On MC1.0 cores the linear window offset is ignored by the TS engine, + * leading to inconsistent memory views. Avoid using the offset on those + * cores if possible, otherwise disable the TS feature. + */ + cmdbuf_paddr = ALIGN_DOWN(etnaviv_cmdbuf_get_pa(&gpu->buffer), SZ_128M); + + if (!(gpu->identity.features & chipFeatures_PIPE_3D) || + (gpu->identity.minor_features0 & chipMinorFeatures0_MC20)) { + if (cmdbuf_paddr >= SZ_2G) + priv->mmu_global->memory_base = SZ_2G; + else + priv->mmu_global->memory_base = cmdbuf_paddr; + } else if (cmdbuf_paddr + SZ_128M >= SZ_2G) { + dev_info(gpu->dev, + "Need to move linear window on MC1.0, disabling TS\n"); + gpu->identity.features &= ~chipFeatures_FAST_CLEAR; + priv->mmu_global->memory_base = SZ_2G; + } + /* Setup event management */ spin_lock_init(&gpu->event_spinlock); init_completion(&gpu->event_free); -- 2.29.2

3 2

[PATCHv1] drm/omap: get fbdev working for manually updated display
by Sebastian Reichel 03 May '21

03 May '21

Running a legacy application, which directly uses /dev/fb0 currently results in display not being refreshed when the application mmaps the memory instead of calling write(). Deferred IO support will also schedule dirty_work with the damage collected from the mmap page writes and thus gets some more legacy applications working. Delay frequency settings have been taken over from drm_fb_helper_generic_probe(). Reported-by: Carl Philipp Klemm <philipp(a)uvos.xyz> Tested-by: Carl Philipp Klemm <philipp(a)uvos.xyz> Signed-off-by: Sebastian Reichel <sebastian.reichel(a)collabora.com> --- Hi, I still need to fix my Droid 4, so I only compile tested this myself. -- Sebastian --- drivers/gpu/drm/omapdrm/omap_fbdev.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c b/drivers/gpu/drm/omapdrm/omap_fbdev.c index 42eac6ad12bd..fc3897d2d7cc 100644 --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c @@ -87,6 +87,11 @@ static const struct fb_ops omap_fb_ops = { .fb_imageblit = drm_fb_helper_sys_imageblit, }; +static struct fb_deferred_io omap_fb_defio = { + .delay = HZ / 20, + .deferred_io = drm_fb_helper_deferred_io, +}; + static int omap_fbdev_create(struct drm_fb_helper *helper, struct drm_fb_helper_surface_size *sizes) { @@ -176,6 +181,9 @@ static int omap_fbdev_create(struct drm_fb_helper *helper, drm_fb_helper_fill_info(fbi, helper, sizes); + fbi->fbdefio = &omap_fb_defio; + fb_deferred_io_init(fbi); + dev->mode_config.fb_base = dma_addr; fbi->screen_buffer = omap_gem_vaddr(fbdev->bo); base-commit: 152d32aa846835987966fd20ee1143b0e05036a0 -- 2.30.2

3 2

[PATCH v2 0/1] drm/i915: Use the correct max source link rate for MST
by Nikola Cornij 03 May '21

03 May '21

This is a follow-up change to fix incorrectly used max link rate source capability at MST init time. Change history: v1: - Initial v2: - Use local variabale for improved code readability - Fix the comment to point to the correct sub-directory Nikola Cornij (1): drm/i915: Use the correct max source link rate for MST drivers/gpu/drm/i915/display/intel_dp_mst.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.25.1

4 4

[PATCH 0/7] drm: Completely remove struct drm_device.pdev
by Thomas Zimmermann 03 May '21

03 May '21

The pdev field in struct drm_device was recently moved into the legacy section. Remove it entirely. References are replaced with upcasts from the structure's dev field. This change only affects legacy drivers for userspace modesetting. Thomas Zimmermann (7): drm/i810: Remove references to struct drm_device.pdev drm/mga: Remove references to struct drm_device.pdev drm/r128: Remove references to struct drm_device.pdev drm/savage: Remove references to struct drm_device.pdev drm/sis: Remove references to struct drm_device.pdev drm/via: Remove references to drm_device.pdev drm: Remove pdev field from struct drm_device drivers/gpu/drm/drm_pci.c | 1 - drivers/gpu/drm/i810/i810_dma.c | 8 +++++--- drivers/gpu/drm/mga/mga_dma.c | 13 +++++++------ drivers/gpu/drm/mga/mga_state.c | 3 ++- drivers/gpu/drm/r128/ati_pcigart.c | 11 ++++++----- drivers/gpu/drm/r128/r128_drv.c | 4 +++- drivers/gpu/drm/r128/r128_state.c | 3 ++- drivers/gpu/drm/savage/savage_bci.c | 26 ++++++++++++++------------ drivers/gpu/drm/sis/sis_drv.c | 3 ++- drivers/gpu/drm/via/via_dmablit.c | 15 +++++++++------ drivers/gpu/drm/via/via_map.c | 3 ++- include/drm/drm_device.h | 3 --- 12 files changed, 52 insertions(+), 41 deletions(-) -- 2.31.1

2 8

[PATCH] drm/msm/dpu: Delete bonkers code
by Rob Clark 03 May '21

03 May '21

From: Rob Clark <robdclark(a)chromium.org> dpu_crtc_atomic_flush() was directly poking it's attached planes in a code path that ended up in dpu_plane_atomic_update(), even if the plane was not involved in the current atomic update. While a bit dubious, this worked before because plane->state would always point to something valid. But now using drm_atomic_get_new_plane_state() we could get a NULL state pointer instead, leading to: [ 20.873273] Call trace: [ 20.875740] dpu_plane_atomic_update+0x5c/0xed0 [ 20.880311] dpu_plane_restore+0x40/0x88 [ 20.884266] dpu_crtc_atomic_flush+0xf4/0x208 [ 20.888660] drm_atomic_helper_commit_planes+0x150/0x238 [ 20.894014] msm_atomic_commit_tail+0x1d4/0x7a0 [ 20.898579] commit_tail+0xa4/0x168 [ 20.902102] drm_atomic_helper_commit+0x164/0x178 [ 20.906841] drm_atomic_commit+0x54/0x60 [ 20.910798] drm_atomic_connector_commit_dpms+0x10c/0x118 [ 20.916236] drm_mode_obj_set_property_ioctl+0x1e4/0x440 [ 20.921588] drm_connector_property_set_ioctl+0x60/0x88 [ 20.926852] drm_ioctl_kernel+0xd0/0x120 [ 20.930807] drm_ioctl+0x21c/0x478 [ 20.934235] __arm64_sys_ioctl+0xa8/0xe0 [ 20.938193] invoke_syscall+0x64/0x130 [ 20.941977] el0_svc_common.constprop.3+0x5c/0xe0 [ 20.946716] do_el0_svc+0x80/0xa0 [ 20.950058] el0_svc+0x20/0x30 [ 20.953145] el0_sync_handler+0x88/0xb0 [ 20.957014] el0_sync+0x13c/0x140 The reason for the codepath seems dubious, the atomic suspend/resume heplers should handle the power-collapse case. If not, the CRTC's atomic_check() should be adding the planes to the atomic update. Reported-by: Stephen Boyd <sboyd(a)kernel.org> Reported-by: John Stultz <john.stultz(a)linaro.org> Fixes: 37418bf14c13 drm: Use state helper instead of the plane state pointer Signed-off-by: Rob Clark <robdclark(a)chromium.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 10 ---------- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 16 ---------------- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h | 6 ------ 3 files changed, 32 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c index 7c29976be243..18bc76b7f1a3 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c @@ -648,16 +648,6 @@ static void dpu_crtc_atomic_flush(struct drm_crtc *crtc, if (unlikely(!cstate->num_mixers)) return; - /* - * For planes without commit update, drm framework will not add - * those planes to current state since hardware update is not - * required. However, if those planes were power collapsed since - * last commit cycle, driver has to restore the hardware state - * of those planes explicitly here prior to plane flush. - */ - drm_atomic_crtc_for_each_plane(plane, crtc) - dpu_plane_restore(plane, state); - /* update performance setting before crtc kickoff */ dpu_core_perf_crtc_update(crtc, 1, false); diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c index df7f3d3afd8b..7a993547eb75 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c @@ -1258,22 +1258,6 @@ static void dpu_plane_atomic_update(struct drm_plane *plane, } } -void dpu_plane_restore(struct drm_plane *plane, struct drm_atomic_state *state) -{ - struct dpu_plane *pdpu; - - if (!plane || !plane->state) { - DPU_ERROR("invalid plane\n"); - return; - } - - pdpu = to_dpu_plane(plane); - - DPU_DEBUG_PLANE(pdpu, "\n"); - - dpu_plane_atomic_update(plane, state); -} - static void dpu_plane_destroy(struct drm_plane *plane) { struct dpu_plane *pdpu = plane ? to_dpu_plane(plane) : NULL; diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h index 03b6365a750c..34e03ac05f4a 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h @@ -84,12 +84,6 @@ bool is_dpu_plane_virtual(struct drm_plane *plane); void dpu_plane_get_ctl_flush(struct drm_plane *plane, struct dpu_hw_ctl *ctl, u32 *flush_sspp); -/** - * dpu_plane_restore - restore hw state if previously power collapsed - * @plane: Pointer to drm plane structure - */ -void dpu_plane_restore(struct drm_plane *plane, struct drm_atomic_state *state); - /** * dpu_plane_flush - final plane operations before commit flush * @plane: Pointer to drm plane structure -- 2.30.2

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2021