linux-stable.git/drivers/gpu, branch v5.4.76

drm/panfrost: Fix a deadlock between the shrinker and madvise path

2020-11-10T11:37:33+00:00

commit 7d2d6d01293e6d9b42a6cb410be4158571f7fe9d upstream.

panfrost_ioctl_madvise() and panfrost_gem_purge() acquire the mappings
and shmem locks in different orders, thus leading to a potential
the mappings lock first.

Fixes: bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept")
Cc: 
Cc: Christian Hewitt 
Reported-by: Christian Hewitt 
Signed-off-by: Boris Brezillon 
Reviewed-by: Steven Price 
Link: https://patchwork.freedesktop.org/patch/msgid/20201101174016.839110-1-boris.brezillon@collabora.com
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"

2020-11-10T11:37:31+00:00

[ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ]

we can't use nouveau_bo_ref here as no ttm object was allocated and
nouveau_bo_ref mainly deals with that. Simply deallocate the object.

Signed-off-by: Karol Herbst 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin

drm/nouveau/nouveau: fix the start/end range for migration

2020-11-10T11:37:31+00:00

[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ]

The user level OpenCL code shouldn't have to align start and end
addresses to a page boundary. That is better handled in the nouveau
driver. The npages field is also redundant since it can be computed
from the start and end addresses.

Signed-off-by: Ralph Campbell 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin

drm/vc4: drv: Add error handding for bind

2020-11-10T11:37:31+00:00

[ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ]

There is a problem that if vc4_drm bind fails, a memory leak occurs on
the drm_property_create side. Add error handding for drm_mode_config.

Signed-off-by: Hoegeun Kwon 
Signed-off-by: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com
Signed-off-by: Sasha Levin

drm/amdgpu: add DID for navi10 blockchain SKU

2020-11-10T11:37:30+00:00

[ Upstream commit 8942881144a7365143f196f5eafed24783a424a3 ]

Reviewed-by: Alex Deucher 
Reviewed-by: Guchun Chen 
Signed-off-by: Tianci.Yin 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin

drm/sun4i: frontend: Fix the scaler phase on A33

2020-11-10T11:37:29+00:00

[ Upstream commit e3190b5e9462067714d267c40d8c8c1d0463dda3 ]

The A33 has a different phase parameter in the Allwinner BSP on the
channel1 than the one currently applied. Fix this.

Signed-off-by: Maxime Ripard 
Acked-by: Jernej Skrabec 
Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-maxime@cerno.tech
Signed-off-by: Sasha Levin

drm/sun4i: frontend: Reuse the ch0 phase for RGB formats

2020-11-10T11:37:29+00:00

[ Upstream commit 2db9ef9d9e6ea89a9feb5338f58d1f8f83875577 ]

When using the scaler on the A10-like frontend with single-planar formats,
the current code will setup the channel 0 filter (used for the R or Y
component) with a different phase parameter than the channel 1 filter (used
for the G/B or U/V components).

This creates a bleed out that keeps repeating on of the last line of the
RGB plane across the rest of the display. The Allwinner BSP either applies
the same phase parameter over both channels or use a separate one, the
condition being whether the input format is YUV420 or not.

Since YUV420 is both subsampled and multi-planar, and since YUYV is
subsampled but single-planar, we can rule out the subsampling and assume
that the condition is actually whether the format is single or
multi-planar. And it looks like applying the same phase parameter over both
channels for single-planar formats fixes our issue, while we keep the
multi-planar formats working properly.

Reported-by: Taras Galchenko 
Signed-off-by: Maxime Ripard 
Acked-by: Jernej Skrabec 
Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-maxime@cerno.tech
Signed-off-by: Sasha Levin

drm/sun4i: frontend: Rework a bit the phase data

2020-11-10T11:37:29+00:00

[ Upstream commit 84c971b356379c621df595bd00c3114579dfa59f ]

The scaler filter phase setup in the allwinner kernel has two different
cases for setting up the scaler filter, the first one using different phase
parameters for the two channels, and the second one reusing the first
channel parameters on the second channel.

The allwinner kernel has a third option where the horizontal phase of the
second channel will be set to a different value than the vertical one (and
seems like it's the same value than one used on the first channel).
However, that code path seems to never be taken, so we can ignore it for
now, and it's essentially what we're doing so far as well.

Since we will have always the same values across each components of the
filter setup for a given channel, we can simplify a bit our frontend
structure by only storing the phase value we want to apply to a given
channel.

Signed-off-by: Maxime Ripard 
Acked-by: Jernej Skrabec 
Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-1-maxime@cerno.tech
Signed-off-by: Sasha Levin

drm/i915: Drop runtime-pm assert from vgpu io accessors

2020-11-10T11:37:23+00:00

commit 5c6c13cd1102caf92d006a3cf4591c0229019daf upstream.

The "mmio" writes into vgpu registers are simple memory traps from the
guest into the host. We do not need to assert in the guest that the
device is awake for the io as we do not write to the device itself.

However, over time we have refactored all the mmio accessors with the
result that the vgpu reuses the gen2 accessors and so inherits the
assert for runtime-pm of the native device. The assert though has
actually been there since commit 3be0bf5acca6 ("drm/i915: Create vGPU
specific MMIO operations to reduce traps").

References: 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps")
Signed-off-by: Chris Wilson 
Cc: Yan Zhao 
Cc: Zhenyu Wang 
Reviewed-by: Zhenyu Wang 
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200811092532.13753-1-chris@chris-wilson.co.uk
(cherry picked from commit 0e65ce24a33c1d37da4bf43c34e080334ec6cb60)
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Greg Kroah-Hartman

drm/i915/gt: Delay execlist processing for tgl

2020-11-10T11:37:23+00:00

commit 9b99e5ba3e5d68039bd6b657e4bbe520a3521f4c upstream.

When running gem_exec_nop, it floods the system with many requests (with
the goal of userspace submitting faster than the HW can process a single
empty batch). This causes the driver to continually resubmit new
requests onto the end of an active context, a flood of lite-restore
preemptions. If we time this just right, Tigerlake hangs.

Inserting a small delay between the processing of CS events and
submitting the next context, prevents the hang. Naturally it does not
occur with debugging enabled. The suspicion then is that this is related
to the issues with the CS event buffer, and inserting an mmio read of
the CS pointer status appears to be very successful in preventing the
hang. Other registers, or uncached reads, or plain mb, do not prevent
the hang, suggesting that register is key -- but that the hang can be
prevented by a simple udelay, suggests it is just a timing issue like
that encountered by commit 233c1ae3c83f ("drm/i915/gt: Wait for CSB
entries on Tigerlake"). Also note that the hang is not prevented by
applying CTX_DESC_FORCE_RESTORE, or by inserting a delay on the GPU
between requests.

Signed-off-by: Chris Wilson 
Cc: Mika Kuoppala 
Cc: Bruce Chang 
Cc: Joonas Lahtinen 
Cc: stable@vger.kernel.org
Acked-by: Mika Kuoppala 
Link: https://patchwork.freedesktop.org/patch/msgid/20201015195023.32346-1-chris@chris-wilson.co.uk
(cherry picked from commit 6ca7217dffaf1abba91558e67a2efb655ac91405)
Signed-off-by: Rodrigo Vivi 
Signed-off-by: Greg Kroah-Hartman