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

drm/i915/dp: return proper DPRX link training result

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

commit 9af4bf2171c1a9e3f2ebb21140c0e34e60b2a22a upstream.

After DPRX link training, intel_dp_link_train_phy() did not
return the training result properly. If link training failed,
i915 driver would not run into link train fallback function.
And no hotplug uevent would be received by user space application.

Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training")
Cc: Ville Syrjala 
Cc: Imre Deak 
Cc: Jani Nikula 
Cc: Cooper Chiou 
Cc: William Tseng 
Signed-off-by: Lee Shawn C 
Reviewed-by: Imre Deak 
Signed-off-by: Imre Deak 
Link: https://patchwork.freedesktop.org/patch/msgid/20210706152541.25021-1-shawn.c.lee@intel.com
(cherry picked from commit dab1b47e57e053b2a02c22ead8e7449f79961335)
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/rockchip: cdn-dp-core: Make cdn_dp_core_resume __maybe_unused

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

commit 040b8907ccf1c78d020aca29800036565d761d73 upstream.

With the new static annotation, the compiler warns when the functions
are actually unused:

   drivers/gpu/drm/rockchip/cdn-dp-core.c:1123:12: error: 'cdn_dp_resume' defined but not used [-Werror=unused-function]
    1123 | static int cdn_dp_resume(struct device *dev)
         |            ^~~~~~~~~~~~~

Mark them __maybe_unused to suppress that warning as well.

[ Not so 'new' static annotations any more, and I removed the part of
  the patch that added __maybe_unused to cdn_dp_suspend(), because it's
  used by the shutdown/remove code.

  So only the resume function ends up possibly unused if CONFIG_PM isn't
  set     - Linus ]

Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Enric Balletbo i Serra 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

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

2021-09-22T10:39:18+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:39:17+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:39:17+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:39:17+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:39:17+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:39:17+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:39:17+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:39:17+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