On 6/24/2021 00:05, Matthew Brost wrote:
If submission is disabled by the backend for any reason, reset the GPU
immediately in the heartbeat code as the backend can't be reenabled
until the GPU is reset.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/intel
Hi all,
Quick new version since the previous one was a bit too broken:
- dropped the bug-on patch to avoid breaking amdgpu's gpu reset failure
games
- another attempt at splitting job_init/arm, hopefully we're getting
there.
Note that Christian has brought up a bikeshed on the new functions t
It might be good enough on x86 with just READ_ONCE, but the write side
should then at least be WRITE_ONCE because x86 has total store order.
It's definitely not enough on arm.
Fix this proplery, which means
- explain the need for the barrier in both places
- point at the other side in each commen
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into the scheduler. It would be nice if that's a bit
clearer in the interface.
But the real reason is that I want to push the dependency tracking
helpe
I found a few too many things that are tricky and not documented, so I
started typing.
I found a few more things that looked broken while typing, see the
varios FIXME in drm_sched_entity.
Also some of the usual logics:
- actually include sched_entity.c declarations, that was lost in the
move he
Instead of just a callback we can just glue in the gem helpers that
panfrost, v3d and lima currently use. There's really not that many
ways to skin this cat.
On the naming bikeshed: The idea for using _await_ to denote adding
dependencies to a job comes from i915, where that's used quite
extensive
Nothing special going on here.
Aside reviewing the code, it seems like drm_sched_job_arm() should be
moved into lima_sched_context_queue_task and put under some mutex
together with drm_sched_push_job(). See the kerneldoc for
drm_sched_push_job().
Signed-off-by: Daniel Vetter
Cc: Qiang Yu
Cc: Su
Just deletes some code that's now more shared.
Note that thanks to the split into drm_sched_job_init/arm we can now
easily pull the _init() part from under the submission lock way ahead
where we're adding the sync file in-fences as dependencies.
v2: Correctly clean up the partially set up job, no
Prep work for using the scheduler dependency handling. We need to call
drm_sched_job_init earlier so we can use the new drm_sched_job_await*
functions for dependency handling here.
v2: Slightly better commit message and rebase to include the
drm_sched_job_arm() call (Emma).
v3: Cleanup jobs under
We need to pull the drm_sched_job_init much earlier, but that's very
minor surgery.
v2: Actually fix up cleanup paths by calling drm_sched_job_init, which
I wanted to to in the previous round (and did, for all other drivers).
Spotted by Lucas.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Ru
Originally a job was only bound to the queue when we pushed this, but
now that's done in drm_sched_job_init, making that parameter entirely
redundant.
Remove it.
The same applies to the context parameter in
lima_sched_context_queue_task, simplify that too.
Reviewed-by: Steven Price (v1)
Signed-
With the prep work out of the way this isn't tricky anymore.
Aside: The chaining of the various jobs is a bit awkward, with the
possibility of failure in bad places. I think with the
drm_sched_job_init/arm split and maybe preloading the
job->dependencies xarray this should be fixable.
Cc: Melissa
Integrated into the scheduler now and all users converted over.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linar
This is essentially part of drm_sched_dependency_optimized(), which
only amdgpu seems to make use of. Use it a bit more.
This would mean that as-is amdgpu can't use the dependency helpers, at
least not with the current approach amdgpu has for deciding whether a
vm_flush is needed. Since amdgpu als
You really need to hold the reservation here or all kinds of funny
things can happen between grabbing the dependencies and inserting the
new fences.
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Daniel Vetter
Cc: Luben Tuikov
Cc: Andrey Grodzovsky
Cc: Alex Deucher
Cc: Jack Zhang
--
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore th
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore t
Specifically document the new/clarified rules around how the shared
fences do not have any ordering requirements against the exclusive
fence.
But also document all the things a bit better, given how central
struct dma_resv to dynamic buffer management the docs have been very
inadequat.
- Lots mor
No longer used, the last user disappeared with
commit d07f0e59b2c762584478920cd2d11fba2980a94a
Author: Chris Wilson
Date: Fri Oct 28 13:58:44 2016 +0100
drm/i915: Move GEM activity tracking into a common struct reservation_object
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: "T
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore th
On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Hold a reference to the intel_context over life of an i915_request.
> > Without this an i915_request can exist after the context has been
> > destroyed (e.g. request retired, context closed
On Mon, Jul 12, 2021 at 11:11:48AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > From: John Harrison
> >
> > The serial number tracking of engines happens at the backend of
> > request submission and was expecting to only be given physical
> > engines. However, in GuC
On 6/24/2021 00:05, Matthew Brost wrote:
Add disable GuC interrupts to intel_guc_sanitize(). Part of this
requires moving the guc_*_interrupt wrapper function into header file
intel_guc.h.
Signed-off-by: Matthew Brost
Cc: Daniele Ceraolo Spurio
Reviewed-by: John Harrison
---
drivers/gpu/d
On Mon, Jul 12, 2021 at 1:01 PM Daniel Vetter wrote:
>
> This is a very confusingly named function, because not just does it
> init an object, it arms it and provides a point of no return for
> pushing a job into the scheduler. It would be nice if that's a bit
> clearer in the interface.
>
> But t
On Mon, Jul 12, 2021 at 11:05:59AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Update GuC debugfs to support the new GuC structures.
> >
> > Signed-off-by: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |
On 2021-07-10 15:19, Dmitry Baryshkov wrote:
We are preparing to support two independent DSI hosts in the DSI/DPU
code. To remove possible confusion (as both configurations can be
referenced as dual DSI) let's rename old "dual DSI" (two DSI hosts
driving single device, with clocks being locked) t
On 2021-07-10 15:20, Dmitry Baryshkov wrote:
Add three helper functions to be used by display drivers for setting up
encoders.
Signed-off-by: Dmitry Baryshkov
I think there is a kbot error in this patch, with that fixed
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.c |
On 2021-07-10 15:20, Dmitry Baryshkov wrote:
Move setting up encoders from set_encoder_mode to
_dpu_kms_initialize_dsi() / _dpu_kms_initialize_displayport(). This
allows us to support not only "single DSI" and "bonded DSI" but also
"two
independent DSI" configurations. In future this would also
On 12/07/2021 17:50, Laurent Pinchart wrote:
> Hi Steven,
>
> Thank you for the patch.
>
> On Mon, Jul 12, 2021 at 04:57:58PM +0100, Steven Price wrote:
>> When bailing out due to the sanity check the iterator value needs to be
>> freed because the early return prevents for_each_child_of_node() f
On Mon, Jul 12, 2021 at 08:05:30PM +, Matthew Brost wrote:
> On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
> > On 6/24/2021 00:04, Matthew Brost wrote:
> > > Hold a reference to the intel_context over life of an i915_request.
> > > Without this an i915_request can exist after t
On 7/12/2021 13:59, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:05:59AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Update GuC debugfs to support the new GuC structures.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/i
On Mon, Jul 12, 2021 at 11:10:40AM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Add intel_context tracing. These trace points are particular helpful
> > when debugging the GuC firmware and can be enabled via
> > CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config optio
On 7/12/2021 14:36, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 08:05:30PM +, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:23:14AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Hold a reference to the intel_context over life of an i915_request.
Without this an i9
On 7/12/2021 14:47, Matthew Brost wrote:
On Mon, Jul 12, 2021 at 11:10:40AM -0700, John Harrison wrote:
On 6/24/2021 00:04, Matthew Brost wrote:
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
CONFIG_DRM_I915_LOW_LEVEL_
Hi Steven,
On Mon, Jul 12, 2021 at 10:31:52PM +0100, Steven Price wrote:
> On 12/07/2021 17:50, Laurent Pinchart wrote:
> > On Mon, Jul 12, 2021 at 04:57:58PM +0100, Steven Price wrote:
> >> When bailing out due to the sanity check the iterator value needs to be
> >> freed because the early return
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings. Add a check for
vm_flags & VM_WRITE to avoid mmap failures on private read-only or
PROT_NONE mappings.
v2: protect against mprotect making a mapping writable after the fact
v3: update dri
Hi!
> From: Xie Yongji
>
> [ Upstream commit 17f46f488a5d82c5568e6e786cd760bba1c2ee09 ]
>
> The dev->dev_private might not be allocated if virtio_gpu_pci_quirk()
> or virtio_gpu_init() failed. In this case, we should avoid the cleanup
> in virtio_gpu_release().
The check is in wrong place at l
On 6/24/2021 00:05, Matthew Brost wrote:
The new GuC interface introduces an MMIO H2G command,
INTEL_GUC_ACTION_RESET_CLIENT, which is used to implement suspend. This
MMIO tears down any active contexts generating a context reset G2H CTB
for each. Once that step completes the GuC tears down the C
On 6/24/2021 00:05, Matthew Brost wrote:
GuC will issue a reset on detecting an engine hang and will notify
the driver via a G2H message. The driver will service the notification
by resetting the guilty context to a simple state or banning it
completely.
Cc: Matthew Brost
Cc: John Harrison
Sig
On 6/24/2021 00:05, Matthew Brost wrote:
GuC will notify the driver, via G2H, if it fails to
reset an engine. We recover by resorting to a full GPU
reset.
Signed-off-by: Matthew Brost
Signed-off-by: Fernando Pacheco
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h
On 6/24/2021 00:05, Matthew Brost wrote:
The GuC can implement execution qunatums, detect hung contexts and
other such things but it requires the timer expired interrupt to do so.
Signed-off-by: Matthew Brost
CC: John Harrison
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_
On 6/24/2021 00:05, Matthew Brost wrote:
We receive notification of an engine reset from GuC at its
completion. Meaning GuC has potentially cleared any HW state
we may have been interested in capturing. GuC resumes scheduling
on the engine post-reset, as the resets are meant to be transparent,
fu
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to rec
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() c
Hi Ryan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20210712]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.14-rc1 v5.13 v5.13-rc7 v5.14-rc1]
[If your patch
On 7/10/2021 7:27 AM, Michal Wajdeczko wrote:
Hi Vinay,
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Add macros to check for slpc support. This feature is currently supported
for gen12+ and enabled whenever guc submission is enabled/selected.
please try to use consistent names across all p
These refinements include using standard mailbox callback interface,
timeout detection, and a fixed cmdq_handle.
Chun-Kuang Hu (4):
drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb
drm/mediatek: Remove struct cmdq_client
drm/mediatek: Detect CMDQ execution timeout
drm/mediatek
rx_callback is a standard mailbox callback mechanism and could cover the
function of proprietary cmdq_task_cb, so use the standard one instead of
the proprietary one.
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 16 +---
1 file changed, 13 insertions(+),
In mailbox rx_callback, it pass struct mbox_client to callback
function, but it could not map back to mtk_drm_crtc instance
because struct cmdq_client use a pointer to struct mbox_client:
struct cmdq_client {
struct mbox_client client;
struct mbox_chan *chan;
};
struct mtk_drm_crt
One mtk_crtc need just one cmdq_handle, so add one cmdq_handle
in mtk_crtc to prevent frequently allocation and free of
cmdq_handle.
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 28 -
1 file changed, 18 insertions(+), 10 deletions(-)
diff --
CMDQ is used to update display register in vblank period, so
it should be execute in next vblank. If it fail to execute
in next 2 vblank, tiemout happen.
Signed-off-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
Hi, Yongqiang:
Yongqiang Niu 於 2021年7月12日 週一 下午2:42寫道：
>
> In cmdq mode, packet may be flushed before it is executed, so
> the pending flag should be cleared after cmdq packet is done.
I would like this patch to base on the series [1] because that series
use the standard mailbox callback interfa
On 7/10/2021 7:35 AM, Michal Wajdeczko wrote:
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Declare header and source files for SLPC, along with init and
enable/disable function templates.
later you claim that "disable" is not needed
Changed.
Signed-off-by: Vinay Belgaumkar
Signed-
Hi Ryan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20210712]
[also build test WARNING on v5.14-rc1]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.14
Hi Ryan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20210712]
[also build test ERROR on v5.14-rc1]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.14-rc1 v5.13
Hi Ryan,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on next-20210712]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
drm/drm-next v5.14-rc1 v5.13 v5.13-rc7 v5.14-rc1]
[If your
On Sun, Jul 11, 2021 at 10:17 AM Joe Perches wrote:
>
> On Sat, 2021-07-10 at 23:49 -0600, Jim Cromie wrote:
> > whitespace only, to diff-minimize a later commit.
> > no functional changes
> []
> > diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> []
> > @@ -524,19 +524,24 @@ void _
On Friday, July 2, 2021 12:22:58 PM PDT Daniel Vetter wrote:
> On Fri, Jul 02, 2021 at 03:31:08PM +0100, Tvrtko Ursulin wrote:
> >
> > On 01/07/2021 16:10, Matthew Auld wrote:
> > > The CPU domain should be static for discrete, and on DG1 we don't need
> > > any flushing since everything is alread
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
It might be good enough on x86 with just READ_ONCE, but the write side
should then at least be WRITE_ONCE because x86 has total store order.
It's definitely not enough on arm.
Fix this proplery, which means
- explain the need for the barrier in both p
Am 12.07.21 um 19:53 schrieb Daniel Vetter:
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into the scheduler. It would be nice if that's a bit
clearer in the interface.
But the real reason is tha
On Tue, Jul 13, 2021 at 8:35 AM Christian König
wrote:
>
> Am 12.07.21 um 19:53 schrieb Daniel Vetter:
> > It might be good enough on x86 with just READ_ONCE, but the write side
> > should then at least be WRITE_ONCE because x86 has total store order.
> >
> > It's definitely not enough on arm.
> >
On Tue, Jul 13, 2021 at 8:40 AM Christian König
wrote:
>
> Am 12.07.21 um 19:53 schrieb Daniel Vetter:
> > This is a very confusingly named function, because not just does it
> > init an object, it arms it and provides a point of no return for
> > pushing a job into the scheduler. It would be nice
Am 13.07.21 um 00:06 schrieb Felix Kuehling:
KFD Thunk maps invisible VRAM BOs with PROT_NONE, MAP_PRIVATE.
is_cow_mapping returns true for these mappings. Add a check for
vm_flags & VM_WRITE to avoid mmap failures on private read-only or
PROT_NONE mappings.
v2: protect against mprotect makin
101 - 163 of 163 matches
Mail list logo
