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>
Allow the PHY drivers to get the ref clock from the DT.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Document the new amd,imageon compatible, used for non-qcom hardware that
uses the drm/msm driver (iMX5).
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Rob Herring <robh@kernel.org>
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>
Fix the dsi clock names in the DSI 10nm PLL driver to
match the names in the dispcc driver as those are
according to the clock plan of the chipset.
Changes in v2:
- Update the clock diagram with the new clock name
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Abhinav Kumar <abhinavk@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
otherwise, priv->kms is non-NULL and msm_drm_uninit will cause a panic.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add the mdp5_cfg_hw entry for MDP5 version v1.15 found on msm8917.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@gmail.com>
derived from the a3xx driver and tested on the following hardware:
imx51-zii-rdu1 (a200 with 128kb gmem)
imx53-qsrb (a200)
msm8060-tenderloin (a220)
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Makes it possible to have MMU for GPU but not display.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@gmail.com>
For allocation in contiguous memory when the GPU has MMU but not mdp4.
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Rob Clark <robdclark@gmail.com>
To lower CPU overhead, future userspace will be switching to pinning
iova and avoiding the use of relocs, and only include cmds table entries
for IB1 level cmdstream (but not IB2 or state-groups).
This leaves the kernel unsure what to dump for rd/hangrd cmdstream
dumping. So add a MSM_SUBMIT_BO_DUMP flag so userspace can indicate
buffers that contain cmdstream (or are otherwise important to dump).
Signed-off-by: Rob Clark <robdclark@gmail.com>
When the userspace tries to read the crashstate dump, the read side
implementation in the driver currently ascii85 encodes all the binary
buffers and it does this each time the read system call is called.
A userspace tool like cat typically does a page by page read and the
number of read calls depends on the size of the data captured by the
driver. This is certainly not desirable and does not scale well with
large captures.
This patch encodes the buffer only once in the read path. With this there
is an immediate >10X speed improvement in crashstate save time.
Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
For reasons that I'm sure made perfect sense at the time we were
opting to defer the iova alloc / pin on the ringbuffer until HW
init time so when we moved to iova reference counting we ended
up adding a reference count every time the hardware started.
Not that it mattered (because the ring is always around) but
it did make the debug output look odd. Allocate and pin the iova
at create time instead.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
For debugging purposes it is useful to assign descriptions
to buffers so that we know what they are used for. Add
a field to the buffer object and use that to name the various
kernel side allocations which ends up looking like like this
in /d/dri/X/gem:
flags id ref offset kaddr size madv name
00040000: I 0 ( 1) 00000000 0000000070b79eca 00004096 memptrs
vmas: [gpu: 01000000,mapped,inuse=1]
00020000: I 0 ( 1) 00000000 0000000031ed4074 00032768 ring0
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a reference count to track how many times a particular
chunk of iova memory is pinned (mapped) in the iomu and
add msm_gem_unpin_iova to give up references.
It is important to note that msm_gem_unpin_iova replaces
msm_gem_put_iova because the new implicit behavior
that an assigned iova in a given vma is now valid for the
life of the buffer and what we are really focusing on is
the use of that iova.
For now the unmappings are lazy; once the reference counts
go to zero they *COULD* be unmapped dynamically but that
will require an outside force such as a shrinker or
mm_notifiers. For now, we're just focusing on getting
the counting right and setting ourselves up to be ready
for the future.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a new function to get and pin the iova memory in one
step (basically renaming the old msm_gem_get_iova function)
and switch msm_gem_get_iova() to only allocate an iova but
not map it in the IOMMU. This is only currently used by
msm_ioctl_gem_info() since all other users of of the iova
expect that the memory be immediately available.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add headers for the 'gem' debugfs file to make it easier to remember
what all the values mean and move the list of virtual address regions
to the next line and add the name and map status to make it clearer
what we are looking at.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Split the operation of msm_gem_get_iova into two operations:
1) allocate an iova and 2) map (pin) the backing memory int the
iommu. This is the first step toward allowing memory pinning
to occur independently of the iova management.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The scatter gather table doesn't need to be passed in for the
MMU unmap function.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Buffer objects allocated with msm_gem_kernel_new() are mostly
freed the same way so we can save a few lines of code with a
common function.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The a6xx GPU state allocates a LOT of memory. Add a bit of
infrastructure to track the memory allocations in the GPU structure
and delete them when the state is destroyed much the same way
that devm works with the device model as a whole. This protects
against the developer accidentally forgetting to add a kfree() to
an ever growing list.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
