linux-stable.git/drivers/gpu/drm, branch v6.0.8

drm/i915/sdvo: Setup DDC fully before output init

2022-11-10T17:17:40+00:00

commit e79762512120f11c51317570519a1553c70805d8 upstream.

Call intel_sdvo_select_ddc_bus() before initializing any
of the outputs. And before that is functional (assuming no VBT)
we have to set up the controlled_outputs thing. Otherwise DDC
won't be functional during the output init but LVDS really
needs it for the fixed mode setup.

Note that the whole multi output support still looks very
bogus, and more work will be needed to make it correct.
But for now this should at least fix the LVDS EDID fixed mode
setup.

Cc: stable@vger.kernel.org
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula 
(cherry picked from commit 64b7b557dc8a96d9cfed6aedbf81de2df80c025d)
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Greg Kroah-Hartman

drm/i915/sdvo: Filter out invalid outputs more sensibly

2022-11-10T17:17:40+00:00

commit 3e206b6aa6df7eed4297577e0cf8403169b800a2 upstream.

We try to filter out the corresponding xxx1 output
if the xxx0 output is not present. But the way that is
being done is pretty awkward. Make it less so.

Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula 
(cherry picked from commit cc1e66394daaa7e9f005e2487a84e34a39f9308b)
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Update DSC capabilitie for DCN314

2022-11-10T17:17:40+00:00

commit 341421084d705475817f7f0d68e130370d10b20d upstream.

dcn314 has 4 DSC - conflicted hardware document updated and confirmed.

Tested-by: Mark Broadworth 
Reviewed-by: Charlene Liu 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Leo Chen 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org # 6.0.x
Signed-off-by: Greg Kroah-Hartman

drm/amd/display: Update latencies on DCN321

2022-11-10T17:17:40+00:00

commit c580d758ba1b79de9ea7a475d95a6278736ae462 upstream.

Update DF related latencies based on new measurements.

Tested-by: Mark Broadworth 
Reviewed-by: Jun Lei 
Acked-by: Rodrigo Siqueira 
Signed-off-by: Dillon Varone 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org # 6.0.x
Signed-off-by: Greg Kroah-Hartman

drm/amdgpu: disable GFXOFF during compute for GFX11

2022-11-10T17:17:39+00:00

commit a3e5ce56f3d260f2ec8e5242c33f57e60ae9eba7 upstream.

Temporary workaround to fix issues observed in some compute applications
when GFXOFF is enabled on GFX11.

Signed-off-by: Graham Sider 
Acked-by: Alex Deucher 
Reviewed-by: Harish Kasiviswanathan 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org # 6.0.x
Signed-off-by: Greg Kroah-Hartman

drm/rockchip: dsi: Force synchronous probe

2022-11-10T17:17:39+00:00

commit 81e592f86f7afdb76d655e7fbd7803d7b8f985d8 upstream.

We can't safely probe a dual-DSI display asynchronously
(driver_async_probe='*' or driver_async_probe='dw-mipi-dsi-rockchip'
cmdline), because dw_mipi_dsi_rockchip_find_second() pokes one DSI
device's drvdata from the other device without any locking.

Request synchronous probe, at least until this driver learns some
appropriate locking for dual-DSI initialization.

Cc: 
Signed-off-by: Brian Norris 
Signed-off-by: Heiko Stuebner 
Link: https://patchwork.freedesktop.org/patch/msgid/20221019170255.2.I6b985b0ca372b7e35c6d9ea970b24bcb262d4fc1@changeid
Signed-off-by: Greg Kroah-Hartman

drm/rockchip: dsi: Clean up 'usage_mode' when failing to attach

2022-11-10T17:17:39+00:00

commit 0be67e0556e469c57100ffe3c90df90abc796f3b upstream.

If we fail to attach the first time (especially: EPROBE_DEFER), we fail
to clean up 'usage_mode', and thus will fail to attach on any subsequent
attempts, with "dsi controller already in use".

Re-set to DW_DSI_USAGE_IDLE on attach failure.

This is especially common to hit when enabling asynchronous probe on a
duel-DSI system (such as RK3399 Gru/Scarlet), such that we're more
likely to fail dw_mipi_dsi_rockchip_find_second() the first time.

Fixes: 71f68fe7f121 ("drm/rockchip: dsi: add ability to work as a phy instead of full dsi")
Cc: 
Signed-off-by: Brian Norris 
Signed-off-by: Heiko Stuebner 
Link: https://patchwork.freedesktop.org/patch/msgid/20221019170255.1.Ia68dfb27b835d31d22bfe23812baf366ee1c6eac@changeid
Signed-off-by: Greg Kroah-Hartman

drm/i915: stop abusing swiotlb_max_segment

2022-11-10T17:17:28+00:00

[ Upstream commit d3f6bacfca86f6cf6bf85be1e8b54083d68d8195 ]

swiotlb_max_segment used to return either the maximum size that swiotlb
could bounce, or for Xen PV PAGE_SIZE even if swiotlb could bounce buffer
larger mappings.  This made i915 on Xen PV work as it bypasses the
coherency aspect of the DMA API and can't cope with bounce buffering
and this avoided bounce buffering for the Xen/PV case.

So instead of adding this hack back, check for Xen/PV directly in i915
for the Xen case and otherwise use the proper DMA API helper to query
the maximum mapping size.

Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider max_segment
only if CONFIG_SWIOTLB is enabled. There can be other (iommu related)
causes of specific max segment sizes.

Fixes: a2daa27c0c61 ("swiotlb: simplify swiotlb_max_segment")
Reported-by: Marek Marczykowski-Górecki 
Signed-off-by: Robert Beckett 
Signed-off-by: Christoph Hellwig 
[hch: added the Xen hack, rewrote the changelog]
Reviewed-by: Tvrtko Ursulin 
Signed-off-by: Tvrtko Ursulin 
Link: https://patchwork.freedesktop.org/patch/msgid/20221020110308.1582518-1-hch@lst.de
(cherry picked from commit 78a07fe777c42800bd1adaec12abe5dcee43919e)
Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Sasha Levin

drm/rockchip: fix fbdev on non-IOMMU devices

2022-11-10T17:17:28+00:00

[ Upstream commit ab78c74cfc5a3caa2bbb7627cb8f3bca40bb5fb0 ]

When switching to the generic fbdev infrastructure, it was missed that
framebuffers were created with the alloc_kmap parameter to
rockchip_gem_create_object() set to true.  The generic infrastructure
calls this via the .dumb_create() driver operation and thus creates a
buffer without an associated kmap.

alloc_kmap only makes a difference on devices without an IOMMU, but when
it is missing rockchip_gem_prime_vmap() fails and the framebuffer cannot
be used.

Detect the case where a buffer is being allocated for the framebuffer
and ensure a kernel mapping is created in this case.

Fixes: 24af7c34b290 ("drm/rockchip: use generic fbdev setup")
Reported-by: Johan Jonker 
Cc: Thomas Zimmermann 
Signed-off-by: John Keeping 
Signed-off-by: Heiko Stuebner 
Link: https://patchwork.freedesktop.org/patch/msgid/20221020181248.2497065-1-john@metanate.com
Signed-off-by: Sasha Levin

drm/rockchip: dw_hdmi: filter regulator -EPROBE_DEFER error messages

2022-11-10T17:17:28+00:00

[ Upstream commit bfab00b94bd8569cdb84a6511d6615e6a8104e9c ]

When the avdd-0v9 or avdd-1v8 supply are not yet available, EPROBE_DEFER
is returned by rockchip_hdmi_parse_dt(). This causes the following error
message to be printed multiple times:

    dwhdmi-rockchip fe0a0000.hdmi: [drm:dw_hdmi_rockchip_bind [rockchipdrm]] *ERROR* Unable to parse OF data

Fix that by not printing the message when rockchip_hdmi_parse_dt()
returns -EPROBE_DEFER.

Fixes: ca80c4eb4b01 ("drm/rockchip: dw_hdmi: add regulator support")
Signed-off-by: Aurelien Jarno 
Reviewed-by: Dmitry Osipenko 
Signed-off-by: Heiko Stuebner 
Link: https://patchwork.freedesktop.org/patch/msgid/20220926203752.5430-1-aurelien@aurel32.net
Signed-off-by: Sasha Levin