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>
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>
Add support for gathering and dumping the a6xx GPU state including
registers, GMU registers, indexed registers, shader blocks,
context clusters and debugbus.
v2: Fix bugs discovered by Sharat Masetty
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
If the GPU target doesn't define a list of registers then gracefully skip
capturing and/or printing them. This is used by more complex targets like
6xx that have other means of capturing register values.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
The gpu_poll_timeout() function can be useful to multiple targets so
mvoe it into adreno_gpu.h from the a5xx code.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Instead of trying to store all the tagged buffers from a hanging
submit only store the command buffers that were not imported.
This cuts down on the amount of data stored in the GPU state to
the base minimum of useful information.
The downside is that this will make it more difficult to
successfully replay a hang with just the GPU state but there
isn't any reason why that functionality can't be added back
in later once we've figured out how to better communicate
such massive amounts of data.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add trace events to track the progress of a GPU submission
msm_gpu_submit occurs at the beginning of the submissions,
msm_gpu_submit_flush happens when the submission is put on
the ringbuffer and msm_submit_flush_retired is sent when
the operation is retired.
To make it easier to track the operations a unique sequence
number is assigned to each submission and displayed in each
event output so a human or a script can easily associate
the events related to a specific submission.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add infrastructure to track statistics for GPU submissions
by sampling certain perfcounters before and after a submission.
To store the statistics, the per-ring memptrs region is
expanded to include room for up to 64 entries - this should
cover a reasonable amount of inflight submissions without
worrying about losing data. The target specific code inserts
PM4 commands to sample the counters before and after
submission and store them in the data region. The CPU can
access the data after the submission retires to make sense
of the statistics and communicate them to the user.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
If any of the function calls in _msm_gem_kernel_new fail we need
to make sure to dereference the GEM object with the appropriate
function for the current locking state.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Allocate the correct buffer size for the GPU memptrs. The incorrect
size hasn't affected us thus far since the incorrect size was larger
than the intended size and we're still stuck on page sized
granularity anyway but technically correct is the best kind of
correct.
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Specify geometry for DPU iommu domain which sets
the address space for gem allocations.
Signed-off-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Suggested-by: Jordan Crouse <jcrouse@codeaurora.org>
Suggested-by: Vivek Gautam <vivek.gautam@codeaurora.org>
Acked-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Use DRM_DEV_INFO/ERROR/WARN instead of dev_info/err/debug to generate
drm-formatted specific log messages so that it will be easy to
differentiate in case of multiple instances of driver.
Signed-off-by: Mamta Shukla <mamtashukla555@gmail.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
They're not needed.
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Local variable is not needed and condition can't be hit.
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
I noticed an empty label while driving by and decided to use
coccinelle to see if there were any more. Here's the spatch and the
invocation:
---
@@
identifier lbl;
expression E;
@@
- goto lbl;
+ return E;
...
- lbl:
return E;
@@
identifier lbl;
@@
- goto lbl;
+ return;
...
- lbl:
- return;
---
spatch --allow-inconsistent-paths --sp-file file.spatch --dir
drivers/gpu/drm/msm/disp/dpu1 --in-place
---
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Per chapter 15 of coding-style, removing 'inline' keyword from functions
that are larger than a typical macro. In a couple of cases I've
simplified the function and kept the inline.
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, remove it.
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
These functions aren't used anywhere, remove them.
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
We call out of the virt encoder into phys only to call back into the
virt for hw reset. So remove the indirection and just call the virt
function directly.
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since we removed all suspend logic from the crtc code (see patch 3/4),
dpu_crtc_reset does the same things as drm_atomic_helper_crtc_reset, so let's
just replace it with a call to the atomic helper.
v3: added patch to patchset
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Bruce Wang <bzwang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Since drm core's modeset locks serialize atomic commits, we don't need to
track whether or not we're in a suspended state from inside the crtc for
dpu_crtc_enable/disable. This patch removes the suspend logic from the crtc and
removes the relevant tracing from dpu_trace. Since we removed all calls
to dpu_kms_is_suspend_state, we can remove that function and the
suspend_state field of dpu_kms as well.
v2: added patch to patchset
v3: reworded commit body and moved deletion of dpu_kms_is_suspend_state and
suspend_state to this patch
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Bruce Wang <bzwang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Removes the traces of the non-atomic helper calls in
msm_pm_suspend/resume since we just deleted those functions (see patch
1). Also removes the drm_kms_helper_poll_disable/enable calls, since
the DRM_CONNECTOR_POLL_CONNECT flag is never set so periodic polling
doesn't happen anyways.
v2: reorganized patch order
v3: made error checks less severe
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Bruce Wang <bzwang@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
PM resume was crashing during dpu_kms_pm_resume. This patch removes
dpu_kms_pm_suspend/resume so that msm_pm_suspend/resume uses the atomic
helpers instead (see next patch). This patch also removes
dpu_kms_is_suspend_blocked since it is never called.
v2: Reorganized patches in patchset
Signed-off-by: Bruce Wang <bzwang@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
I found these tracepoints useful for debugging cursor/ctl, someone else
might find them useful too
Reviewed-by: Jeykumar Sankaran <jsanka@codeaurora.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
This completes "drm/syncobj: Drop add/remove_callback from driver
interface" and cleans up the implementation a bit.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Link: https://patchwork.freedesktop.org/patch/266255/
The fence seqno is now 64bit, fixes build warning.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/267136/
If CS is submitted using guilty ctx, we terminate amdgpu_cs_parser_init
before locking ctx->lock, latter in amdgpu_cs_parser_fini we still are
trying to release the lock just becase parser->ctx != NULL.
Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Modify description to match actual argument list.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
There is a spelling mistake in a pr_err message, fix this.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
This reverts commit 7f3ef5dedb.
It causes new warnings [1] on shutdown when running the Google Kevin or
Scarlet (RK3399) boards under Chrome OS. Presumably our usage of DRM is
different than what Marc and Heiko test.
We're looking at a different approach (e.g., [2]) to replace this, but
IMO the revert should be taken first, as it already propagated to
-stable.
[1] Report here:
http://lkml.kernel.org/lkml/20181205030127.GA200921@google.com
WARNING: CPU: 4 PID: 2035 at drivers/gpu/drm/drm_mode_config.c:477 drm_mode_config_cleanup+0x1c4/0x294
...
Call trace:
drm_mode_config_cleanup+0x1c4/0x294
rockchip_drm_unbind+0x4c/0x8c
component_master_del+0x88/0xb8
rockchip_drm_platform_remove+0x2c/0x44
rockchip_drm_platform_shutdown+0x20/0x2c
platform_drv_shutdown+0x2c/0x38
device_shutdown+0x164/0x1b8
kernel_restart_prepare+0x40/0x48
kernel_restart+0x20/0x68
...
Memory manager not clean during takedown.
WARNING: CPU: 4 PID: 2035 at drivers/gpu/drm/drm_mm.c:950 drm_mm_takedown+0x34/0x44
...
drm_mm_takedown+0x34/0x44
rockchip_drm_unbind+0x64/0x8c
component_master_del+0x88/0xb8
rockchip_drm_platform_remove+0x2c/0x44
rockchip_drm_platform_shutdown+0x20/0x2c
platform_drv_shutdown+0x2c/0x38
device_shutdown+0x164/0x1b8
kernel_restart_prepare+0x40/0x48
kernel_restart+0x20/0x68
...
[2] https://patchwork.kernel.org/patch/10556151/https://www.spinics.net/lists/linux-rockchip/msg21342.html
[PATCH] drm/rockchip: shutdown drm subsystem on shutdown
Fixes: 7f3ef5dedb ("drm/rockchip: Allow driver to be shutdown on reboot/kexec")
Cc: Jeffy Chen <jeffy.chen@rock-chips.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Vicente Bergas <vicencb@gmail.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: stable@vger.kernel.org
Signed-off-by: Brian Norris <briannorris@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20181205181657.177703-1-briannorris@chromium.org
New registers.
Currently uncertain how exactly to mask fault buffer interrupts. This will
likely be corrected at around the same time as the new MC interrupt stuff
has been properly figured out and implemented.
For the moment, it shouldn't matter too much.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Things are a bit different here on Turing, and will require further changes
yet once I've investigated them more thoroughly.
For now though, the existing GP100 code is compatible enough with one small
hack to forward on fault buffer interrupts.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The token will also contain runlist ID on Turing, so instead expose it as
an opaque value from NVKM so the client doesn't need to care.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The GPU saves off some stuff to the address specified in this part of RAMFC
when the channel faults, so we should probably point it at a valid address.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This is needed for Turing, but we're supposed to wait for completion after
re-writing the value on older GPUs anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Aside from being a nice cleanup, these will to allow the upcoming direct
page mapping interfaces to play nicely with normal mappings.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The GPU will continually fire interrupts while a fault buffer GET != PUT,
and to stop the spurious interrupts while the handler does its thing, we
were disabling the fault buffer temporarily.
This is not actually a great idea to begin with, and made worse by Volta
resetting GET/PUT when it's reactivated. So, let's not do that.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Various structures are accessed by the GPU through BAR2 for some reason
on newer GPUs. This commit makes it more convenient to handle.
Will be used for GP100- fault buffers, and GV100- fault method buffers.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This makes debugging with DP tracing a lot harder to interpret, so name
each i2c based off the name of the encoder that it's for
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need to actually make sure we check this on resume since otherwise we
won't know whether or not the topology is still there once we've
resumed, which will cause us to still think the topology is connected
even after it's been removed if the removal happens mid-suspend.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
With this, nvbios /sys/kernel/debug/dri/*/vbios.rom now works!
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Since we already expose the vbios.rom file here, why not also expose the
strap_peek?
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
As part of commit cfea88a4d8 ("drm/nouveau: Start using new drm_dev
initialization helpers"), the initialization of the Nouveau DRM device
was reworked and along the way the platform driver initialization was
left incomplete. Add a call to nouveau_drm_device_init() to make sure
all of the structures are properly initialized.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Make sure i2c msgs we're asked to transfer conform to the
requirements of REMOTE_I2C_READ. We were only checking that the
last message is a read, but we must also check that the preceding
messages are all writes. Also check that the length of each
message isn't too long.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180928180403.22499-2-ville.syrjala@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
We aren't supposed to force a stop+start between every i2c msg
when performing multi message transfers. This should eg. cause
the DDC segment address to be reset back to 0 between writing
the segment address and reading the actual EDID extension block.
To quote the E-DDC spec:
"... this standard requires that the segment pointer be
reset to 00h when a NO ACK or a STOP condition is received."
Since we're going to touch this might as well consult the
I2C_M_STOP flag to determine whether we want to force the stop
or not.
Cc: Brian Vincent <brainn@gmail.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=108081
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180928180403.22499-1-ville.syrjala@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Instead of EVV cks-off voltages, avfs cks-off voltages can avoid
the overshoot voltages when switching sclk.
Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Some new variants require different firmwares.
Signed-off-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
New vega10 ids.
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function 'gfx_v8_0_pre_soft_reset':
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:4950:27: warning:
variable 'srbm_soft_reset' set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function 'gfx_v8_0_post_soft_reset':
drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:5054:27: warning:
variable 'srbm_soft_reset' set but not used [-Wunused-but-set-variable]
It never used since introduction in commit d31a501ead ("drm/amdgpu: add
pre_soft_reset ip func") and e4ae0fc336 ("drm/amdgpu: implement
gfx8 post_soft_reset")
Reviewed-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
driver need to reserve resource for each ctx for
some hw features. so add this limitation.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
RLC will go wrong in soft_reset under sriov
Workaroound: only need to init RLC csb, and skip RLC stop, reset, start
this is because host-driver has already done full initialization on RLC
v2: squash in build fix
Signed-off-by: Tiecehng Zhou <Tiecheng.Zhou@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/ast/ast_fb.c: In function 'astfb_create':
drivers/gpu/drm/ast/ast_fb.c:194:17: warning:
variable 'bo' set but not used [-Wunused-but-set-variable]
It never used since introduction in commit 312fec1405 ("drm: Initial KMS
driver for AST (ASpeed Technologies) 2000 series (v2)")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1544258185-50430-1-git-send-email-yuehaibing@huawei.com
When everyone implements it exactly the same way, among all 4
implementations, there's not really a need to overwrite this at all.
Aside: drm_kms_helper_hotplug_event is pretty much core functionality
at this point. Probably should move it there.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128221234.15054-1-daniel.vetter@ffwll.ch
Add support for X/Y reflection when the plane is using linear or
T-tiled formats. X/Y reflection hasn't been tested on SAND formats, so
we reject them until proper testing/debugging has been done.
Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20181207083606.15449-2-boris.brezillon@bootlin.com
The GMC/VM subsystem is causing the faults, so move the handling here as
well.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
printk_ratelimit() is much better suited to limit the number of reported
VM faults.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This allows us to filter out VM faults in the GMC code.
v2: don't filter out all faults
v3: fix copy&paste typo, send all IV to the KFD, don't change message level
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This allows user mode to map doorbell pages into GPUVM address space.
That way GPUs can submit to user mode queues (self-dispatch).
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is used for interoperability between ROCm compute and graphics
APIs. It allows importing graphics driver BOs into the ROCm SVM
address space for zero-copy GPU access.
The API is split into two steps (query and import) to allow user mode
to manage the virtual address space allocation for the imported buffer.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
top_dev->gpu is NULL for CPUs. Avoid dereferencing it if NULL.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We don't want KFD processes evicting each other over VRAM usage.
Therefore prevent overcommitting VRAM among KFD applications with
a per-GPU limit. Also leave enough room for page tables on top
of the application memory usage.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Eric Huang <JinHuiEric.Huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Avoid including mmu_context.h in amdgpu_amdkfd.h since that may be
included in other header files that define traces. This leads to
conflicts due to traces defined in other headers included via
mmu_context.h.
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[WHY] clarify dal input parameters to pplib interface, remove
un-used parameters. dal knows exactly which parameters needed
and their effects at pplib and smu sides.
current dal sequence for dcn1_update_clock to pplib:
1.smu10_display_clock_voltage_request for dcefclk
2.smu10_display_clock_voltage_request for fclk
3.phm_store_dal_configuration_data {
set_min_deep_sleep_dcfclk
set_active_display_count
store_cc6_data --- this data never be referenced
new sequence will be:
1. set_display_count --- need add new pplib interface
2. set_min_deep_sleep_dcfclk -- new pplib interface
3. set_hard_min_dcfclk_by_freq
4. set_hard_min_fclk_by_freq
after this code refactor, smu10_display_clock_voltage_request,
phm_store_dal_configuration_data will not be needed for rv.
[HOW] step 1: add new functions at pplib interface
step 2: add new functions at amdgpu dm and dc
Signed-off-by: hersen wu <hersenxs.wu@amd.com>
Reviewed-by: Rex Zhu <Rex.Zhu@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
amdgpu_ring_soft_recovery would have Call-Trace,
when s_fence->parent was NULL inside amdgpu_job_timedout.
Check fence first, as drm_sched_hw_job_reset did.
Signed-off-by: Wentao Lou <Wentao.Lou@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
PSP ring need to be destroy before starting reinit for vf.
This patche move it from hypervisor driver into guest.
Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Signed-off-by: Frank Min <Frank.Min@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
PSP only support VMR ring for SRIOV vf since v45 and all commands will
be send to VMR ring for executing.
VMR ring use C2PMSG 101 ~ 103 instead of C2PMSG 64 ~ 71.
Signed-off-by: Xiangliang Yu <Xiangliang.Yu@amd.com>
Acked-by: Alex Deucher <alexander.deucher@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: Xiangliang Yu <Xiangliang.Yu@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This allows us to drop the extra reserve in TTM.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
And drop the now superflous extra reservations.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It is perfectly possible that the BO list is created before the BO is
exported. While at it clean up setting shared to one instead of true.
v2: add comment and simplify logic
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Acked-by: Junwei Zhang <Jerry.Zhang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Let's support simultaneous submissions to multiple engines.
v2: rename the field to num_shared and fix up all users
v3: rebased
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com>
Reviewed-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
For Picasso && AM4 SOCKET board, we use picasso_rlc_am4.bin
For Picasso && FP5 SOCKET board, we use picasso_rlc.bin
Judgment method:
PCO AM4: revision >= 0xC8 && revision <= 0xCF
or revision >= 0xD8 && revision <= 0xDF
otherwise is PCO FP5
Signed-off-by: Aaron Liu <aaron.liu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher at amd.com>
Reviewed-by: Huang Rui <ray.huang at amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Check if the MC firmware supports FFC and tell the SMC so
mclk switching is handled properly.
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
