[Why]
The visual corruption due to low display clock value observed on some
systems
[How]
There was earlier patch for dspclk:
'drm/amd/display: Raise dispclk value for dce_update_clocks'
Adding +15% workaround also to to dce112_update_clocks
Signed-off-by: Roman Li <Roman.Li@amd.com>
Reviewed-by: Leo Li <Sunpeng.Li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
The behavior of drm_atomic_helper_cleanup_planes differs depending on
whether the commit was asynchronous or not. When it's called from
amdgpu_dm_atomic_commit_tail during a typical atomic commit the
plane state has been swapped so it calls cleanup_fb on the old plane
state.
However, in the asynchronous commit codepath the call to
drm_atomic_helper_commit also calls dm_plane_helper_cleanup_fb after
atomic_async_update has been called. Since the plane state is updated
in place and has not been swapped the cleanup_fb call affects the new
plane state.
This results in a use after free for the given sequence:
- Fast update, fb1 pin/ref, fb1 unpin/unref
- Fast update, fb2 pin/ref, fb2 unpin/unref
- Slow update, fb1 pin/ref, fb2 unpin/unref
- Fast update, fb2 pin/ref -> use after free. bug
[How]
Disallow framebuffer changes in the fast path. Since this includes
a NULL framebuffer, this means that only framebuffers that have
been previously pin+ref at least once will be used, preventing a
use after free.
This has a significant throughput reduction for cursor updates where
the framebuffer changes. For most desktop usage this isn't a problem,
but it does introduce performance regressions for two specific IGT
tests:
- cursor-vs-flip-toggle
- cursor-vs-flip-varying-size
Fixes: 2cc751931afc ("drm/amd/display: Add fast path for cursor plane updates")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It should not return 0 for error case as '0' is actually
a special value for index.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
On errors, dma_buf_get returns a negative error code, rather than NULL.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If register value is updating, reset timeout counter.
It improves robustness of SOC15_WAIT_ON_RREG.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Remove bit 31 for scratch2 to indicate the Hardware bug work around is active.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Scan enc/jpeg fences to init dpg pause new state in begin use.
It will help set dpg mode to desire state actively.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Always check all vcn ring status during dpg mode stop, it will help
identify which vcn ring may cause the issue.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It is a bug fix.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Under Dynamic Power Gate mode, UVD_STATUS needn't be checked.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Acked-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Replace vcn_v1_0_stop with vcn_v1_0_set_powergating_state during suspend,
to keep adev->vcn.cur_state update. It will fix VCN S3 hung issue.
Signed-off-by: James Zhu <James.Zhu@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Use page directory based shared buffer implementation
now available as common code for Xen frontend drivers.
Remove flushing of shared buffer on page flip as this
workaround needs a proper fix.
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Lucas writes:
"nothing major this time, mostly some cleanups that were found on the
way of reworking the code in preparation for new feature additions."
Small conflict in drivers/gpu/drm/etnaviv/etnaviv_drv.c because
drm-misc-next also has a patch to switch over to _put() functions.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
From: Lucas Stach <l.stach@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1545130845.5874.23.camel@pengutronix.de
It only written and we don't infer any useful information from
it anymore. Remove it.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The etnaviv_gpu header only needs to know about the pointer types, so
replace by a forward declaration and only include the headers where needed.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
The only event function that is called from IRQ context is event_free,
which is already using atomic bitmap operations, so we can avoid taking
the event spinlock in this function completely. As other the other
functions still using the event spinlock are all called from normal
process context, we can avoid disabling IRQs while holding the spinlock.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
It indicates a pin/unpin imbalance bug somewhere. While the bug isn't
necessarily in the call chain hitting this, it's at least one part
involved.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Page queue is supported on Vega20 with SDMA firmware
123 onwards.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Vega20 uses ring id 1 for page queues EOP irq while previous
ASICs take ring id 3.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need new invalidation engine layout due to new SDMA page
queues added.
V2: fix coding style and add correct return value
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
As two more SDMA page queue rings are added on Vega20.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Reviewed-by: Oak Zeng <Oak.Zeng@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When the fence is already signaled it is perfectly normal to get a NULL
fence here. But since we can't export that we need to use a stub fence.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Currently driver only psp v11 support vmr.
v2: squash in unused variable removal (Alex)
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
If PSP FW is running already, driver will not load PSP FW again and skip
it. So psp fw version is not correct if reading it from FW binary file,
need to get right version from register.
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Reviewed-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
There is no need to access register such as mmSMC_IND_INDEX_11
and mmSMC_IND_DATA_11, PCIE_INDEX, PCIE_DATA through KIQ because
they are VF-copy.
Signed-off-by: Emily Deng <Emily.Deng@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
XGMI hive put kfd_pre_reset into amdgpu_device_lock_adev,
but outside req_full_gpu of sriov.
It would make sriov hang during reset.
Signed-off-by: Wentao Lou <Wentao.Lou@amd.com>
Reviewed-by: Shaoyun Liu <Shaoyun.Liu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The fimd hardware supports different blend modes. Add pixel blend mode
property and make it configurable, by modifying the blend equation.
Tested on TRATS2 with Exynos 4412 CPU, on top of linux-next-20181019.
Signed-off-by: Christoph Manszewski <c.manszewski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
The fimd hardware supports variable plane alpha. Currently planes
are opaque, make this configurable.
Tested on TRATS2 with Exynos 4412 CPU, on top of linux-next-20181019.
Signed-off-by: Christoph Manszewski <c.manszewski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Avoid expensive indirect calls in the fast path DMA mapping
operations by directly calling the dma_direct_* ops if we are using
the directly mapped DMA operations.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Tested-by: Jesper Dangaard Brouer <brouer@redhat.com>
Tested-by: Tony Luck <tony.luck@intel.com>
With the new validation code, a malicious user-space app could
potentially submit command streams with enough buffer-object and resource
references in them to have the resulting allocated validion nodes and
relocations make the kernel run out of GFP_KERNEL memory.
Protect from this by having the validation code reserve TTM graphics
memory when allocating.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
---
v2: Removed leftover debug printouts
This time around, seeing some love for some older hw:
- a2xx gpu support for apq8060 (hp touchpad) and imx5 (headless
gpu-only mode)
- a2xx gpummu support (a2xx was pre-iommu)
- mdp4 display support for apq8060/touchpad
For display/dpu:
- a big pile of continuing dpu fixes and cleanups
On the gpu side of things:
- per-submit statistics and traceevents for better profiling
- a6xx crashdump support
- decouple get_iova() and page pinning.. so we can unpin from
physical memory inactive bo's while using softpin to lower
cpu overhead
- new interface to set debug names on GEM BOs and debugfs
output improvements
- additional submit flag to indicate buffers that are used
to dump (so $debugfs/rd cmdstream dumping is useful with
softpin + state-objects)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rob Clark <robdclark@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvVvLPD9_Z4kyfGe98Y--byj6HbxHivEYSgF7Rq7=bFnw@mail.gmail.com
Mostly just initial support for Turing TU104/TU106 chipsets. Support
for TU102 is missing as I don't yet have HW, but it should be trivial
to add in later in the merge window (in theory).
It's a bit of a rough first pass that'll get improved in future
releases as a finish figuring out some of the other HW changes, but
it's good enough as it stands for modesetting and suspend/resume etc.
Acceleration bring-up is incomplete due to NVIDIA not yet having
provided FW images for me to use, though command submission and copy
engines are functional already.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Ben Skeggs <skeggsb@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv7KmfcQqZcx+wh_1UKjTovp4PH_5UVMfeyxUu-M9WLZfw@mail.gmail.com
These changes contain a couple of minor fixes for host1x and the Falcon
library in Tegra DRM. There are also a couple of missing pieces that
finally enable support for host1x, VIC and display on Tegra194. I've
also added a patch that enables audio over HDMI using the SOR which has
been tested, and works, on both Tegra186 and Tegra194.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlwKeT4THHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zodDYEAC66KbXHSbu1Q4Y4gWA36bDS16F1MS6
rPb0j0WkhsGejuIS5xbays1OSgtraQSMF7g1CE/kBBmiQj+LsEh/+g4QKdTIxCWn
rjsM1ak3Z4uKnHgWt+mpR9wIg2WgnqzzJGVWHbX6mzL9Et5PWhqPtfgqqgUhiGJ9
p/EqbSq0MeHgYs9z3F31P9dtnWrWrrTnlbajpEPeU+fvzBNnDLP75azZDfzE06qt
d3y3e1clSQFHbEPuqqGzZyfs/aM4Fu/lLnJwgUd0bq5fVPLj7RQ8UUFz+ZmRb9py
Z25Mu/Lnm6pw/FUGD50NYWuaseevLT2hmPAw2b2A95ST77TLsLRubu8wREF321GN
yiAECjUNQhrfRX7NQ23ZlRDY5ExOWu57NRCYRleI3atDv+8/Is8faA60+s1EItyv
rTB05GPPixFD/GZ5p2IR0rvUFc4B1Axdbbj2SDY/Ns/tB/he52YJaR1h+SjFaJ2O
OBrErL46S/CTBIt9YLMnT1HjX8XPdZHR0YYZzs7EJ3pMa1hyIjTlbr/wb0VwzaTp
H8j9+mlBTjD/iLW1QfSui/su+59r0DpsTy4n0MPrVC8cvpwSNDVw2u6x3TqAMxKw
r0nb7vl9xF08Fx1ZviCkJ6tBnIWoLUzXqondNQQygwv7tH4dRb2elOTPhKPh3dUV
OZNbiDTYdmH+6Q==
=WHND
-----END PGP SIGNATURE-----
Merge tag 'drm/tegra/for-4.21-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.21-rc1
These changes contain a couple of minor fixes for host1x and the Falcon
library in Tegra DRM. There are also a couple of missing pieces that
finally enable support for host1x, VIC and display on Tegra194. I've
also added a patch that enables audio over HDMI using the SOR which has
been tested, and works, on both Tegra186 and Tegra194.
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Thierry Reding <thierry.reding@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207134712.32683-1-thierry.reding@gmail.com
[airlied: make etnaviv build again]
amdgpu:
- DC trace support
- More DC documentation
- XGMI hive reset support
- Rework IH interaction with KFD
- Misc fixes and cleanups
- Powerplay updates for newer polaris variants
- Add cursor plane update fast path
- Enable gpu reset by default on CI parts
- Fix config with KFD/HSA not enabled
amdkfd:
- Limit vram overcommit
- dmabuf support
- Support for doorbell BOs
ttm:
- Support for simultaneous submissions to multiple engines
scheduler:
- Add helpers for hw with preemption support
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207233119.16861-1-alexander.deucher@amd.com
[Why]
Legacy cursor plane updates from drm helpers go through the full
atomic codepath. A high volume of cursor updates through this slow
code path can cause subsequent page-flips to skip vblank intervals
since each individual update is slow.
This problem is particularly noticeable for the compton compositor.
[How]
A fast path for cursor plane updates is added by using DRM asynchronous
commit support provided by async_check and async_update. These don't do
a full state/flip_done dependency stall and they don't block other
commit work.
However, DC still expects itself to be single-threaded for anything
that can issue register writes. Screen corruption or hangs can occur
if write sequences overlap. Every call that potentially perform
register writes needs to be guarded for asynchronous updates to work.
The dc_lock mutex was added for this.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106175
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Since this is not needed any more on the latest SMC firmware.
Signed-off-by: Evan Quan <evan.quan@amd.com>
Acked-by: Feifei Xu <Feifei.Xu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
I retested Bonaire (gfx7 dGPU) and it works fine.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The return statement is redundant as there is a return statement
immediately before it so we have dead code that can be removed.
Also remove the unused declaration of ret.
Detected by CoverityScan, CID#1473793 ("Structurally dead code")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Adding an extra MI_STORE_DWORD_IMM to the gpu relocation path for gen3
was good, but still not good enough. To survive 24+ hours under test we
needed to perform not one, not two but three extra store-dw. Doing so
for each GPU relocation was a little unsightly and since we need to
worry about userspace hitting the same issues, we should apply the dummy
store-dw into the EMIT_FLUSH.
Fixes: 7dd4f6729f ("drm/i915: Async GPU relocation processing")
References: 7fa28e1469 ("drm/i915: Write GPU relocs harder with gen3")
Testcase: igt/gem_tiled_fence_blits # blb/pnv
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207134037.11848-1-chris@chris-wilson.co.uk
(cherry picked from commit a889580c08)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Currently we allocate a scratch page for each engine, but since we only
ever write into it for post-sync operations, it is not exposed to
userspace nor do we care for coherency. As we then do not care about its
contents, we can use one page for all, reducing our allocations and
avoid complications by not assuming per-engine isolation.
For later use, it simplifies engine initialisation (by removing the
allocation that required struct_mutex!) and means that we can always rely
on there being a scratch page.
v2: Check that we allocated a large enough scratch for I830 w/a
Fixes: 06e562e7f515 ("drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5") # v4.18.20
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108850
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181204141522.13640-1-chris@chris-wilson.co.uk
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.18.20+
(cherry picked from commit 5179749925)
[Joonas: Use new function in gen9_init_indirectctx_bb too]
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Braswell is really picky about having our writes posted to memory before
we execute or else the GPU may see stale values. A wmb() is insufficient
as it only ensures the writes are visible to other cores, we need a full
mb() to ensure the writes are in memory and visible to the GPU.
The most frequent failure in flushing before execution is that we see
stale PTE values and execute the wrong pages.
References: 987abd5c62 ("drm/i915/execlists: Force write serialisation into context image vs execution")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181206084431.9805-3-chris@chris-wilson.co.uk
(cherry picked from commit 490b8c65b9)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Noticed this while working on redoing the reference counting scheme in
the DP MST helpers. Nouveau doesn't attempt to call
drm_dp_mst_topology_mgr_destroy() at all, which leaves it leaking all of
the resources for drm_dp_mst_topology_mgr and it's children mstbs+ports.
Fixes: f479c0ba4a ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream")
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: <stable@vger.kernel.org> # v4.10+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Should hopefully fix a regression some people have been seeing since EVO
push buffers were moved to VRAM by default on Pascal GPUs.
Fixes: d00ddd9da ("drm/nouveau/kms/nv50-: allocate push buffers in vidmem on pascal")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: <stable@vger.kernel.org> # 4.19+
[Why]
These properties aren't being carried over when the atomic state.
This tricks atomic check and commit tail into performing underscan
and scaling operations when they aren't needed.
With the patch that forced scaling/RMX_ASPECT on by default this
results in many unnecessary surface updates and hangs under certain
conditions.
[How]
Duplicate the properties.
Fixes: 91b66c47ba ("drm/amd/display: Set RMX_ASPECT as default")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[Why]
If the "max bpc" isn't explicitly set in the atomic state then it
have a value of 0. This has the correct behavior of limiting a panel
to 8bpc in the case where the panel supports 8bpc. In the case of eDP
panels this isn't a true assumption - there are panels that can only
do 6bpc.
Banding occurs for these displays.
[How]
Initialize the max_bpc when the connector resets to 8bpc. Also carry
over the value when the state is duplicated.
Bugzilla: https://bugs.freedesktop.org/108825
Fixes: 307638884f72 ("drm/amd/display: Support amdgpu "max bpc" connector property")
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This reverts commit 91b66c47ba.
Forcing RMX_ASPECT as default uses the preferred/native mode's timings
for any mode the user selects and scales the image. This provides a
a consistently nicer result in the case where the selected mode's
refresh rate matches the native mode's refresh but this isn't always
the case.
For example, if the monitor is 1080p@144Hz and the preferred mode is
60Hz then even if the user selects 1080p@144Hz as their selected mode
they'll get 1080p@60Hz.
Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Leo Li <sunpeng.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This function was renamed in a previous commit. Update the stub
function name for builds with CONFIG_HSA_AMD disabled.
Fixes: 611736d844 ("drm/amdgpu: Add KFD VRAM limit checking")
Acked-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
In case of msm drm bind failure, pm runtime put sync
is called from dsi driver which issues an asynchronous
put on mdss device. Subsequently when dpu_mdss_destroy
is triggered the change will make sure to put the mdss
device in suspend and clearing pending work if not
scheduled.
Signed-off-by: Jayant Shekhar <jshekhar@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Do some cleanup in the static inline functions defined in
dpu_media_info.h by cleaning up gotos and unneeded local
variables.
v3: Added spaces between operators per Seal Paul and Sam Ravnborg
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Remove more static inline functions that are lightly used and/or
very simple and easy to build into the calling functions.
v3: Fix a nit from Sean Paul
v2: Removed another unused function from dpu_hw_lm.c and add back
dpu_crtc_get_client_type() since there was a question regarding
its usefulness.
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Do some debugfs cleanups from across the DPU driver. The DRM
destroy functions will do a recursive delete on the entire
debugfs node so there is no need to store dentry pointers for
the debugfs files that are persistent for the life of the
driver. This also means that the destroy functions can go
away too.
Also, use standard API functions where applicable instead of
using hand written code.
v3: No changes
v2: Add more code; most of the dpu debugfs files should be
addressed now.
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
dpu_irq.c does some unneeded checks and passes control
to dpu_core_irq.c The simple functions can be defined
in the same file where we use them and the files and
their associated hangers on can be deleted.
Additionally the postinstall hook isn't used even
in dpu_core_irq.c so zap that entire path.
v3: No changes
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Allow the KMS operation 'irq_postinstall' to be optional
so that the target display drivers don't need to define
a dummy function if they don't need one.
v3: No changes
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Outside of superfluous parameter checks the dpu_hw_blk_init()
doesn't have any failure paths. Switch it over to be a void
function and we can remove error handling paths in all the functions
that call it. While we're in those functions remove unneeded
initialization for a static variable.
v3: No changes
v2: Removed a cleanup intended for a different patch
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Remove some unused container_of() helper functions.
v3: No changes
v2: Retained still used helper functions in the name of readability
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The static inline function dpu_crtc_enabled() is only called once
and the function that calls it in turn is only called once and
the return value can be easily checked in the calling functions
so collapse everything down.
v3: No changes
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
dpu_crtc_get_mixer_height() is only used once and the value it
returns can be easily derived from the calling function.
v3: No changes
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The functions in dpu_dbg.c aren't used. The two main dump functions
fail after a lookup from dpu_dbg_base.reg_base_list which turns out
to never be populated and once those are removed the rest of the
file doesn't make any sense.
v3: No changes
v2: Moved some unrelated changes to another patch
Reviewed-by: Sean Paul <sean@poorly.run>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Each time it's called we're holding the crtc modeset lock, so it's
redundant.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
It's just for debugfs output, we don't need it
Changes in v2:
- None
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Instead of assigning/clearing the crtc on vblank enable/disable, we can
just assign and clear the crtc on modeset. That allows us to just toggle
the encoder's vblank interrupts on vblank_enable.
So why is this important? Previously the driver was using the legacy
pointers to assign/clear the crtc. Legacy pointers are cleared _after_
disabling the hardware, so the legacy pointer was valid during
vblank_disable, but that's not something we should rely on.
Instead of relying on the core ordering the legacy pointer assignments
just so, we'll assign the crtc in dpu_crtc enable/disable. This is the
only place that mapping can change, so we're covered there.
We're also taking advantage of drm_crtc_vblank_on/off. By using this, we
ensure that vblank_enable/disable can never be called while the crtc is
off (which means the assigned crtc will always be valid). As such, we
don't need to use modeset locks or the crtc_lock in the
vblank_enable/disable routine to be sure state is consistent.
...I think.
Changes in v2:
- Changed crtc check in toggle_vblank to != (Jeykumar)
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
[dpu_crtc.c change needed to be manually applied b/c of the dpu_crtc_reset change]
Signed-off-by: Rob Clark <robdclark@gmail.com>
The drm_crtc_vblank_on/off calls in enable/disable guarantee that we
won't call this function when crtc is not enabled.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Matches dpu_crtc_enable and we'll need the old state in a future patch
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The indirection of registering a callback and opaque pointer isn't reall
useful when there's only one callsite. So instead of having the
vblank_cb registration, just give encoder a crtc and let it directly
call the vblank handler.
In a later patch, we'll make use of this further.
Changes in v2:
- None
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
I think the intention here was to protect the enc->crtc access, but
that's insufficient to avoid enc->crtc changing. Fortunately we're
already holding the modeset lock when this is called (from
atomic_check), so remove the crtc_lock and add a modeset lock check.
While we're at it, use the encoder mask from crtc state instead of
legacy pointer.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
There are 4 times that _dpu_crtc_vblank_enable_no_lock() is called:
1- crtc enable
2- crtc disable
3- crtc vblank enable
4- crtc vblank disable
When we enable or disable the crtc, we call drm_crtc_vblank_on and
drm_crtc_vblank_off respectively. That will gate vblank enables and
disables to only being called when the crtc is active. That means that
we can just enable/disable pm runtime in crtc enable/disable. This will
be beneficial in trying to eliminate blocking calls from the vblank call
chain.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add modeset lock checks to functions that could be called outside the
core atomic stack.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
It's for legacy drivers, for atomic drivers crtc->state->encoder_mask
should be used to map encoder to crtc.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
[seanpaul resolved conflict with async param of dpu_encoder_kickoff]
Signed-off-by: Rob Clark <robdclark@gmail.com>
This patch wraps dpu_core_perf_crtc_release_bw() with modeset locks
since it digs into the state objects.
Changes in v2:
- None
Changes in v3:
- Use those nifty new DRM_MODESET_LOCK_ALL_* helpers (Daniel)
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Now that runtime resume is handled in encoder, we don't need to worry
about crtc_lock recursion when calling pm_runtime_(get|put). So drop the
lock drops in _dpu_crtc_vblank_enable_no_lock().
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The crtc runtime resume doesn't actually operate on the crtc, but rather
its encoders. The problem with this is that we need to inspect the crtc
state to get the currently connected encoders. Since runtime resume
isn't guaranteed to be called while holding the modeset locks (although
it sometimes is), this presents a race condition.
Now that we have ->enabled on the virtual encoders, and a lock to
protect it, just call resume on each encoder and only restore the ones
that are enabled.
Changes in v2:
- None
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a bool to dpu_encoder_virt to track whether the encoder is enabled
or not. Repurpose the enc_lock mutex to ensure that it is consistent
with the hw state.
Changes in v2:
- None
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
enc_spinlock instead of enc_spin_lock.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Now that we don't have any event handlers, remove dpu_power_handle!
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
It's only used in core_perf, so stick it there (and change the name to
reflect that).
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
It's needed for struct dss_module_power, and is currently being pulled
in by dpu_power_handle.h
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
It's unused
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Instead of registering through dpu_power_handle just to get a call on
runtime_resume, call the crtc function directly.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
power_events are only used for pm_runtime, and that's all handled in
dpu_kms. So just call vbif_init_memtypes at the correct times.
Changes in v2:
- Removed obsolete comment (Jeykumar)
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
There's only one client -- core, and it's only used for runtime pm which
is already refcounted.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
It's only used for debugfs, so just output the enum value instead.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since dpu_crtc subclasses crtc_state, we need a custom .reset hook in
order to allocate the right amount of memory to accommodate the
additional struct members in dpu_crtc_state. So bring it [partially]
back.
Relevant KASAN splat:
[ 10.333382] ==================================================================
[ 10.344288] BUG: KASAN: slab-out-of-bounds in kmemdup+0x50/0x80
[ 10.350390] Read of size 736 at addr ffffffc0d9f06080 by task frecon/394
[ 10.358861] CPU: 6 PID: 394 Comm: frecon Tainted: G W 4.19.4 #121
[ 10.366476] Hardware name: Google Cheza (rev2) (DT)
[ 10.371514] Call trace:
[ 10.374087] dump_backtrace+0x0/0x194
[ 10.377878] show_stack+0x20/0x28
[ 10.381330] dump_stack+0xa0/0xc8
[ 10.384783] print_address_description+0x78/0x2e0
[ 10.389639] kasan_report+0x290/0x2d0
[ 10.393428] check_memory_region+0x20/0x14c
[ 10.397740] __asan_loadN+0x14/0x1c
[ 10.401345] kmemdup+0x50/0x80
[ 10.404524] dpu_crtc_duplicate_state+0x58/0xa0
[ 10.409228] drm_atomic_get_crtc_state+0xac/0x178
[ 10.414095] __drm_atomic_helper_set_config+0x54/0x4a4
[ 10.419393] drm_atomic_helper_set_config+0x60/0xb4
[ 10.424435] drm_mode_setcrtc+0x720/0x760
[ 10.428570] drm_ioctl_kernel+0xd8/0x13c
[ 10.432617] drm_ioctl+0x380/0x4f4
[ 10.436150] drm_compat_ioctl+0x54/0x13c
[ 10.440219] __arm64_compat_sys_ioctl+0x1d8/0xef4
[ 10.445086] el0_svc_common+0xd8/0x138
[ 10.448961] el0_svc_compat_handler+0x58/0x68
[ 10.453463] el0_svc_compat+0x8/0x18
[ 10.458712] Allocated by task 56:
[ 10.462148] kasan_kmalloc.part.4+0x48/0xf4
[ 10.466465] kasan_kmalloc+0x8c/0xa0
[ 10.470165] kmem_cache_alloc_trace+0x25c/0x27c
[ 10.474848] drm_atomic_helper_crtc_reset+0x68/0x98
[ 10.479877] drm_mode_config_reset+0xc4/0x19c
[ 10.484383] msm_drm_bind+0x814/0x8dc
[ 10.488169] try_to_bring_up_master.part.7+0x48/0xac
[ 10.493282] component_master_add_with_match+0x158/0x198
[ 10.498758] msm_pdev_probe+0x328/0x348
[ 10.502736] platform_drv_probe+0x74/0xc8
[ 10.506877] really_probe+0x1ac/0x35c
[ 10.510659] driver_probe_device+0xd4/0x118
[ 10.514975] __device_attach_driver+0xc8/0xf4
[ 10.519477] bus_for_each_drv+0xb4/0xe4
[ 10.523439] __device_attach+0xd0/0x158
[ 10.527394] device_initial_probe+0x24/0x30
[ 10.531715] bus_probe_device+0x50/0xe4
[ 10.535681] deferred_probe_work_func+0xac/0xdc
[ 10.540376] process_one_work+0x3f0/0x6d4
[ 10.544521] worker_thread+0x3f4/0x520
[ 10.548399] kthread+0x1b4/0x1c8
[ 10.551740] ret_from_fork+0x10/0x18
[ 10.556986] Freed by task 0:
[ 10.559967] (stack is not available)
[ 10.565216] The buggy address belongs to the object at ffffffc0d9f06080
which belongs to the cache kmalloc-1024 of size 1024
[ 10.578268] The buggy address is located 0 bytes inside of
1024-byte region [ffffffc0d9f06080, ffffffc0d9f06480)
[ 10.590248] The buggy address belongs to the page:
[ 10.595195] page:ffffffbf0367c000 count:1 mapcount:0 mapping:ffffffc0de40f680 index:0x0 compound_mapcount: 0
[ 10.605321] flags: 0x4000000000008100(slab|head)
[ 10.610100] raw: 4000000000008100 ffffffbf0369fa08 ffffffbf0367f008 ffffffc0de40f680
[ 10.618077] raw: 0000000000000000 0000000000150015 00000001ffffffff 0000000000000000
[ 10.626049] page dumped because: kasan: bad access detected
[ 10.633341] Memory state around the buggy address:
[ 10.638282] ffffffc0d9f06180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 10.645710] ffffffc0d9f06200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 10.653139] >ffffffc0d9f06280: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc
[ 10.660571] ^
[ 10.665774] ffffffc0d9f06300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 10.673210] ffffffc0d9f06380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 10.680639] ==================================================================
Fixes: a6ba45afda41 (drm/msm/dpu: Replace dpu_crtc_reset by atomic helper)
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Bruce Wang <bzwang@chromium.org>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Bruce Wang <bzwang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This patch allows using drm/msm without qcom display hardware. It adds a
amd,imageon compatible, which is used instead of qcom,adreno, but does
not require a top level msm node.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This allows controlling which of the 8 lanes are used for 6 bit color.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
A2XX has its own very simple MMU.
Added a msm_use_mmu() function because we can't rely on iommu_present to
decide to use MMU or not.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@gmail.com>
When trying to get the display up on my sdm845 board I noticed that
the display wouldn't probe if I had the dsi1 node marked as "disabled"
even though my board doesn't use dsi1. It looks like the msm code
adds all nodes to its list of components even if they are disabled. I
believe this doesn't work because all registered components need to
come up before we finish probing. Let's do like other DRM code and
only add available components.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a buffer object name for the a6xx crashdumper so it can be
seen with the changes introduced by 7799a98edd
("drm/msm: Add a name field for gem objects").
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
dadb36b7ec42 ("drm/msm: Add a common function to free kernel buffer objects")
missed freeing the crashdumper state for a6xx.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This patch sprinkles a few async/legacy_cursor_update checks
through commit to ensure that cursor updates aren't blocked on vsync.
There are 2 main components to this, the first is that we don't want to
wait_for_commit_done in msm_atomic before returning from atomic_complete.
The second is that in dpu we don't want to wait for frame_done events when
updating the cursor.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
There exists a case where a flush of a plane/dma may have been triggered
& started from an async commit. If that plane/dma is subsequently disabled
by the next commit, the flush register will continue to hold the flush
bit for the disabled plane. Since the bit remains active,
pending_kickoff_cnt will never decrement and we'll miss frame_done
events.
This patch limits the check of flush_register to include only those bits
which have been updated with the latest commit.
Changes in v2:
- None
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
In case of msm drm bind failure, dpu_mdss_destroy is triggered.
In this function, resources are freed and pm runtime disable is
called, which triggers dpu_mdss_disable. Now in dpu_mdss_disable,
driver tries to access a memory which is already freed. This
results in kernel panic. Fix this by ensuring proper sequence
of dpu destroy and disable calls.
Changes in v2:
- Removed double spacings [Jeykumar]
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Jayant Shekhar <jshekhar@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
