linux.git/drivers/gpu, branch v5.4.148

drm/etnaviv: add missing MMU context put when reaping MMU mapping

2021-09-22T10:26:40+00:00

commit f2faea8b64125852fa9acc6771c07fc0311a039b upstream.

When we forcefully evict a mapping from the the address space and thus the
MMU context, the MMU context is leaked, as the mapping no longer points to
it, so it doesn't get freed when the GEM object is destroyed. Add the
mssing context put to fix the leak.

Cc: stable@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach 
Tested-by: Michael Walle 
Tested-by: Marek Vasut 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: reference MMU context when setting up hardware state

2021-09-22T10:26:40+00:00

commit d6408538f091fb22d47f792d4efa58143d56c3fb upstream.

Move the refcount manipulation of the MMU context to the point where the
hardware state is programmed. At that point it is also known if a previous
MMU state is still there, or the state needs to be reprogrammed with a
potentially different context.

Cc: stable@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach 
Tested-by: Michael Walle 
Tested-by: Marek Vasut 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: fix MMU context leak on GPU reset

2021-09-22T10:26:40+00:00

commit f978a5302f5566480c58ffae64a16d34456801bd upstream.

After a reset the GPU is no longer using the MMU context and may be
restarted with a different context. While the mmu_state proeprly was
cleared, the context wasn't unreferenced, leading to a memory leak.

Cc: stable@vger.kernel.org # 5.4
Reported-by: Michael Walle 
Signed-off-by: Lucas Stach 
Tested-by: Michael Walle 
Tested-by: Marek Vasut 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: exec and MMU state is lost when resetting the GPU

2021-09-22T10:26:40+00:00

commit 725cbc7884c37f3b4f1777bc1aea6432cded8ca5 upstream.

When the GPU is reset both the current exec state, as well as all MMU
state is lost. Move the driver side state tracking into the reset function
to keep hardware and software state from diverging.

Cc: stable@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach 
Tested-by: Michael Walle 
Tested-by: Marek Vasut 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: keep MMU context across runtime suspend/resume

2021-09-22T10:26:39+00:00

commit 8f3eea9d01d7b0f95b0fe04187c0059019ada85b upstream.

The MMU state may be kept across a runtime suspend/resume cycle, as we
avoid a full hardware reset to keep the latency of the runtime PM small.

Don't pretend that the MMU state is lost in driver state. The MMU
context is pushed out when new HW jobs with a different context are
coming in. The only exception to this is when the GPU is unbound, in
which case we need to make sure to also free the last active context.

Cc: stable@vger.kernel.org # 5.4
Reported-by: Michael Walle 
Signed-off-by: Lucas Stach 
Tested-by: Michael Walle 
Tested-by: Marek Vasut 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: stop abusing mmu_context as FE running marker

2021-09-22T10:26:39+00:00

commit 23e0f5a57d0ecec86e1fc82194acd94aede21a46 upstream.

While the DMA frontend can only be active when the MMU context is set, the
reverse isn't necessarily true, as the frontend can be stopped while the
MMU state is kept. Stop treating mmu_context being set as a indication that
the frontend is running and instead add a explicit property.

Cc: stable@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach 
Tested-by: Michael Walle 
Tested-by: Marek Vasut 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: put submit prev MMU context when it exists

2021-09-22T10:26:39+00:00

commit cda7532916f7bc860b36a1806cb8352e6f63dacb upstream.

The prev context is the MMU context at the time of the job
queueing in hardware. As a job might be queued multiple times
due to recovery after a GPU hang, we need to make sure to put
the stale prev MMU context from a prior queuing, to avoid the
reference and thus the MMU context leaking.

Cc: stable@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach 
Tested-by: Michael Walle 
Tested-by: Marek Vasut 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Greg Kroah-Hartman

drm/etnaviv: return context from etnaviv_iommu_context_get

2021-09-22T10:26:39+00:00

commit 78edefc05e41352099ffb8f06f8d9b2d091e29cd upstream.

Being able to have the refcount manipulation in an assignment makes
it much easier to parse the code.

Cc: stable@vger.kernel.org # 5.4
Signed-off-by: Lucas Stach 
Tested-by: Michael Walle 
Tested-by: Marek Vasut 
Reviewed-by: Christian Gmeiner 
Signed-off-by: Greg Kroah-Hartman

drm/amd/amdgpu: Increase HWIP_MAX_INSTANCE to 10

2021-09-22T10:26:39+00:00

commit 67a44e659888569a133a8f858c8230e9d7aad1d5 upstream.

Seems like newer cards can have even more instances now.
Found by UBSAN: array-index-out-of-bounds in
drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:318:29
index 8 is out of range for type 'uint32_t *[8]'

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1697
Cc: stable@vger.kernel.org
Signed-off-by: Ernst Sjöstrand 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/panfrost: Clamp lock region to Bifrost minimum

2021-09-22T10:26:38+00:00

commit bd7ffbc3ca12629aeb66fb9e28cf42b7f37e3e3b upstream.

When locking a region, we currently clamp to a PAGE_SIZE as the minimum
lock region. While this is valid for Midgard, it is invalid for Bifrost,
where the minimum locking size is 8x larger than the 4k page size. Add a
hardware definition for the minimum lock region size (corresponding to
KBASE_LOCK_REGION_MIN_SIZE_LOG2 in kbase) and respect it.

Signed-off-by: Alyssa Rosenzweig 
Tested-by: Chris Morgan 
Reviewed-by: Steven Price 
Reviewed-by: Rob Herring 
Cc: 
Signed-off-by: Steven Price 
Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-4-alyssa.rosenzweig@collabora.com
Signed-off-by: Greg Kroah-Hartman