On Sat, Jul 10, 2021 at 03:55:02AM +, Matthew Brost wrote:
> On Fri, Jul 09, 2021 at 05:16:34PM -0700, John Harrison wrote:
> > On 6/24/2021 00:04, Matthew Brost wrote:
> > > When running the GuC the GPU can't be considered idle if the GuC still
> > > has contexts pinned. As such, a call has
On Fri, Jul 16, 2021 at 01:17:19PM -0700, Matthew Brost wrote:
> From: Rahul Kumar Singh
>
> When GuC submission is enabled, the GuC controls engine resets. Rather
> than explicitly triggering a reset, the driver must submit a hanging
> context to GuC and wait for the reset to occur.
>
>
On Fri, Jul 16, 2021 at 01:17:21PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> When GuC submission is enabled, the GuC controls engine resets. Rather
> than explicitly triggering a reset, the driver must submit a hanging
> context to GuC and wait for the reset to occur.
>
>
On Fri, Jul 16, 2021 at 01:46:00PM +0100, Jon Hunter wrote:
> Commit 43636451db8c ("drm/tegra: Implement job submission part of new
> UAPI") added the macro 'SUBMIT_ERR' that in turns makes use of the macro
> '__VA_OPT__'. The '__VA_OPT__' macro is not supported by older versions
> of GCC and so
In i915_exit(), we check i915_pci_driver.driver.owner to detect if
i915_init exited early and don't tear anything down. However, we didn't
have proper tear-down paths for early exits in i915_init().
Most of the time, you would never notice this as driver init failures
are extremely rare and
We should tear down in the opposite order we set up.
Signed-off-by: Jason Ekstrand
Fixes: 537f9c84a427 ("drm/i915/pmu: Fix CPU hotplug with multiple GPUs")
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, Jul 16, 2021 at 01:17:22PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Some testing environments and some heavier tests are slower than
> previous limits allowed for. For example, it can take multiple seconds
> for the 'context has been reset' notification handler to reach the
Am 2021-07-16 um 11:07 a.m. schrieb Theodore Y. Ts'o:
> On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
>> I can think of two ways to test the changes for MEMORY_DEVICE_GENERIC in
>> this patch series in a way that is reproducible without special hardware and
>> firmware:
>>
>> For
Hi William,
Thanks for catching this.
On Fri, Jul 9, 2021 at 11:45 PM Will McVicker wrote:
>
> This is needed for fw_devlink to work properly with MIPI DSI devices.
> Without setting the device's fwnode, the sync state framework isn't able
> to properly track device links between the MIPI DSI
On Fri, Jul 16, 2021 at 01:17:17PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> There are many ways in which the hangcheck selftest can fail. Very few
> of them actually printed an error message to say what happened. So,
> fill in the missing messages.
>
> Signed-off-by: John Harrison
On Fri, Jul 16, 2021 at 01:17:12PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> Changing the reset module parameter has no effect on a running GuC.
> The corresponding entry in the ADS must be updated and then the GuC
> informed via a Host2GuC message.
>
> The new debugfs interface to
From: John Harrison
Some testing environments and some heavier tests are slower than
previous limits allowed for. For example, it can take multiple seconds
for the 'context has been reset' notification handler to reach the
'kill the requests' code in the 'active' version of the 'reset
engines'
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
v2:
(Martin Peres / John H)
- Delete debug message when GuC is disabled by default on certain
platforms
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
Implement a simple static mapping algorithm of the i915 priority levels
(int, -1k to 1k exposed to user) to the 4 GuC levels. Mapping is as
follows:
i915 level < 0 -> GuC low level (3)
i915 level == 0 -> GuC normal level (2)
i915 level < INT_MAX-> GuC high level(1)
From: Rahul Kumar Singh
When GuC submission is enabled, the GuC controls engine resets. Rather
than explicitly triggering a reset, the driver must submit a hanging
context to GuC and wait for the reset to occur.
Signed-off-by: Rahul Kumar Singh
Signed-off-by: John Harrison
Signed-off-by:
Requests may take slightly longer with GuC submission, let's increase
the timeouts in live_requests.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/selftests/i915_request.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
This adds GuC backend support for i915_request_cancel(), which in turn
makes CONFIG_DRM_I915_REQUEST_TIMEOUT work.
Signed-off-by: Matthew Brost
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_context.c | 9 +
drivers/gpu/drm/i915/gt/intel_context.h | 7 +
From: John Harrison
There are many ways in which the hangcheck selftest can fail. Very few
of them actually printed an error message to say what happened. So,
fill in the missing messages.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Cc: Daniele Ceraolo Spurio
---
Ensure G2H response has space in the buffer before sending H2G CTB as
the GuC can't handle any backpressure on the G2H interface.
v2:
(Matthew)
- s/INTEL_GUC_SEND/INTEL_GUC_CT_SEND
v3:
(Matthew)
- Add G2H credit accounting to blocking path, add g2h_release_space
helper
(John H)
-
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,
further muddling our error state.
There is
From: John Harrison
In the case of a full GPU reset (e.g. because GuC has died or because
GuC's hang detection has been disabled), the driver can't rely on GuC
reporting the guilty context. Instead, the driver needs to scan all
active contexts and find one that is currently executing, as per the
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_rps.c | 4
1 file changed, 4
Implement GuC virtual engines. Rather simple implementation, basically
just allocate an engine, setup context enter / exit function to virtual
engine specific functions, set all other variables / functions to guc
versions, and set the engine mask to that of all the siblings.
v2: Update to work
From: John Harrison
It is impossible to seal all race conditions of resets occurring
concurrent to other operations. At least, not without introducing
excesive mutex locking. Instead, don't complain if it occurs. In
particular, don't complain if trying to send a H2G during a reset.
Whatever the
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_engine_heartbeat.c | 63 +++
Add trace points for request dependencies and GuC submit. Extended
existing request trace points to include submit fence value,, guc_id,
and ring tail value.
v2: Fix white space alignment in i915_request_add trace point
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
From: John Harrison
Added the scheduling policy parameters to the 'guc_info' debugfs state
dump.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 14 ++
From: John Harrison
Clear the 'disable resets' flag to allow GuC to reset hung contexts
(detected via pre-emption timeout).
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 3 +--
1 file changed, 1
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| 2 +
From: John Harrison
The media watchdog mechanism involves GuC doing a silent reset and
continue of the hung context. This requires the i915 driver provide a
golden context to GuC in the ADS.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_gt.c
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 submission mode, the decomposition of virtual
to physical engines does not happen in i915. Instead, requests are
submitted
From: Rahul Kumar Singh
When GuC submission is enabled, the GuC controls engine resets. Rather
than explicitly triggering a reset, the driver must submit a hanging
context to GuC and wait for the reset to occur.
Signed-off-by: Rahul Kumar Singh
Signed-off-by: John Harrison
Signed-off-by:
From: John Harrison
The driver must provide GuC with a list of mmio registers
that should be saved/restored during a GuC-based engine reset.
Unfortunately, the list must be dynamically allocated as its size is
variable. That means the driver must generate the list twice - once to
work out the
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 CTB
channels. It is safe to suspend once
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, but user space holds a
reference to the request from an out fence). In the case of GuC
submission + virtual engine,
From: John Harrison
Changing the reset module parameter has no effect on a running GuC.
The corresponding entry in the ADS must be updated and then the GuC
informed via a Host2GuC message.
The new debugfs interface to module parameters allows this to happen.
However, connecting the parameter
Move active request tracking to a backend vfunc rather than assuming all
backends want to do this in the maner. In the case execlists /
ring submission the tracking is on the physical engine while with GuC
submission it is on the context.
Signed-off-by: Matthew Brost
---
Update the bonding extension to return -ENODEV when using GuC submission
as this extension fundamentally will not work with the GuC submission
interface.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +
1 file changed, 5
Sometimes during context pinning a context with the same guc_id is
registered with the GuC. In this a case deregister must be done before
the context can be registered. A fence is inserted on all requests while
the deregister is in flight. Once the G2H is received indicating the
deregistration is
This help the backends clean up when the schedule engine object gets
destroyed.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/i915_scheduler.c | 3 ++-
drivers/gpu/drm/i915/i915_scheduler.h | 4 +---
drivers/gpu/drm/i915/i915_scheduler_types.h | 5 +
3 files changed, 8
Extend the deregistration context fence to fence whne a GuC context has
scheduling disable pending.
v2:
(John H)
- Update comment why we check the pin count within spin lock
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
From: John Harrison
Use the official driver default scheduling policies for configuring
the GuC scheduler rather than a bunch of hardcoded values.
v2:
(Matthew Brost)
- Move I915_ENGINE_WANT_FORCED_PREEMPTION to later patch
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
From: John Harrison
When GuC submission is enabled, the GuC controls engine resets. Rather
than explicitly triggering a reset, the driver must submit a hanging
context to GuC and wait for the reset to occur.
Conversely, one of the tests specifically sends hanging batches to the
engines but
When using GuC submission, if a context gets banned disable scheduling
and mark all inflight requests as complete.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context.h | 13 ++
Disable engine barriers for unpinning with GuC. This feature isn't
needed with the GuC as it disables context scheduling before unpinning
which guarantees the HW will not reference the context. Hence it is
not necessary to defer unpinning until a kernel context request
completes on each engine in
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
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 16
With GuC scheduling, it isn't safe to unpin a context while scheduling
is enabled for that context as the GuC may touch some of the pinned
state (e.g. LRC). To ensure scheduling isn't enabled when an unpin is
done, a call back is added to intel_context_unpin when pin count == 1
to disable
Remove old GuC stage descriptor, add LRC descriptor which will be used
by the new GuC interface implemented in this patch series.
v2:
(John Harrison)
- s/lrc/LRC/g
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h|
Reset implementation for new GuC interface. This is the legacy reset
implementation which is called when the i915 owns the engine hang check.
Future patches will offload the engine hang check to GuC but we will
continue to maintain this legacy path as a fallback and this code path
is also required
If two requests are on the same ring, they are explicitly ordered by the
HW. So, a submission fence is sufficient to ensure ordering when using
the new GuC submission interface. Conversely, if two requests share a
timeline and are on the same physical engine but different context this
doesn't
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.
v2:
(John Harrison)
- Move msg[0] lookup after length check
Cc: Matthew Brost
Implement GuC context operations which includes GuC specific operations
alloc, pin, unpin, and destroy.
v2:
(Daniel Vetter)
- Use msleep_interruptible rather than cond_resched in busy loop
(Michal)
- Remove C++ style comment
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
Add bypass tasklet submission path to GuC. The tasklet is only used if H2G
channel has backpresure.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git
With GuC virtual engines the physical engine which a request executes
and completes on isn't known to the i915. Therefore we can't attach a
request to a physical engines breadcrumbs. To work around this we create
a single breadcrumbs per engine class when using GuC submission and
direct all
Implement GuC submission tasklet for new interface. The new GuC
interface uses H2G to submit contexts to the GuC. Since H2G use a single
channel, a single tasklet submits is used for the submission path.
Also the per engine interrupt handler has been updated to disable the
rescheduling of the
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 option.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
Update GuC debugfs to support the new GuC structures.
v2:
(John Harrison)
- Remove intel_lrc_reg.h include from i915_debugfs.c
(Michal)
- Rename GuC debugfs functions
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 22
When running the GuC the GPU can't be considered idle if the GuC still
has contexts pinned. As such, a call has been added in
intel_gt_wait_for_idle to idle the UC and in turn the GuC by waiting for
the number of unpinned contexts to go to zero.
v2: rtimeout -> remaining_timeout
v3: Drop
Disable preempt busywait when using GuC scheduling. This isn't needed as
the GuC controls preemption when scheduling.
v2:
(John H):
- Fix commit message
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 6 --
1
Semaphores are an optimization and not required for basic GuC submission
to work properly. Disable until we have time to do the implementation to
enable semaphores and tune them for performance. Also long direction is
just to delete semaphores from the i915 so another reason to not enable
these
Add new GuC interface defines and structures while maintaining old ones
in parallel.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 14 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 41 +++
Add LRC descriptor context lookup array which can resolve the
intel_context from the LRC descriptor index. In addition to lookup, it
can determine if the LRC descriptor context is currently registered with
the GuC by checking if an entry for a descriptor index is present.
Future patches in the
As discussed in [1], [2] we are enabling GuC submission support in the
i915. This is a subset of the patches in step 5 described in [1],
basically it is absolute to enable CI with GuC submission on gen11+
platforms.
This series itself will likely be broken down into smaller patch sets to
merge.
On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 18:39, Jason Ekstrand wrote:
> >
> > On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 16:52, Matthew Auld
> > > wrote:
> > > >
> > > > On Fri, 16 Jul 2021 at 15:10, Jason
The pull request you sent on Fri, 16 Jul 2021 13:41:18 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-07-16
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/786cb0a2f9bba267c8a80caf906b94c76d18f7e8
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
>
> Whenever we had a user object (n_placements > 0), we were ignoring
> obj->mm.region and always putting obj->placements[0] as the requested
> region. For LMEM+SMEM objects, this was causing them to get shoved into
> LMEM on every
On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
>
> Instead of hand-rolling the same three calls in each function, pull them
> into an i915_gem_object_create_user helper. Apart from re-ordering of
> the placements array ENOMEM check, there should be no functional change.
>
> v2 (Matthew
On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
>
> This doesn't really fix anything serious since the chances of a client
> creating and destroying a mass of dumb BOs is pretty low. However, it
> is called by the other two create IOCTLs to garbage collect old objects.
> Call it here too for
On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
>
> Since we don't allow changing the set of regions after creation, we can
> make ext_set_placements() build up the region set directly in the
> create_ext and assign it to the object later. This is similar to what
> we did for contexts with
On Fri, 16 Jul 2021 at 18:39, Jason Ekstrand wrote:
>
> On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
> wrote:
> >
> > On Fri, 16 Jul 2021 at 16:52, Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
> > > >
> > > > On Fri, Jul 16, 2021 at 8:54 AM Matthew
Instead of requesting two separate clock and then handling them
separately in various places of the driver, use clk_bulk_*() API.
This permits handling devices with more than "bus"/"core" clock,
like ZynqMP, which has "gpu"/"gpu_pp0"/"gpu_pp1" all as separate
clock.
Signed-off-by: Marek Vasut
On 7/16/21 9:08 AM, Thomas Zimmermann wrote:
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
Acked-by: David Lechner
On Wed, 14 Jul 2021 12:19:36 +0200, Geert Uytterhoeven wrote:
> The "resets" property is not present on R-Car Gen1 SoCs.
> Supporting it would require migrating from renesas,cpg-clocks to
> renesas,cpg-mssr.
>
> Reflect this in the DT bindings by removing the global "required:
> resets". All
On 7/10/2021 10:47 AM, Michal Wajdeczko wrote:
On 10.07.2021 03:20, Vinay Belgaumkar wrote:
Add param set h2g helpers to set the min and max frequencies
for use by SLPC.
Signed-off-by: Sundaresan Sujaritha
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
On Wed, 14 Jul 2021 12:11:37 +0200, Enric Balletbo i Serra wrote:
> Update device tree binding documentation for the dsi to add the optional
> property to reset the dsi controller.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
>
> Changes in v2:
> - Added a new patch to describe the dsi reset
On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 16:52, Matthew Auld
> wrote:
> >
> > On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
> > >
> > > On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
> > > wrote:
> > > >
> > > > On Thu, 15 Jul 2021 at 23:39, Jason
On Sun, Jul 11, 2021 at 10:45:48AM -0700, Joe Perches wrote:
> On Sun, 2021-07-11 at 19:24 +0200, Len Baker wrote:
> > The branches of the "if" statement are the same. So remove the
> > unnecessary if and goto statements.
> >
> > Addresses-Coverity-ID: 1456916 ("Identical code for different
Applied. Thanks!
Alex
On Thu, Jul 15, 2021 at 3:40 PM Harry Wentland wrote:
>
>
>
> On 2021-07-15 3:19 p.m., Mario Kleiner wrote:
> > On Thu, Jul 15, 2021 at 6:10 PM Alex Deucher wrote:
> >>
> >> On Wed, Jul 14, 2021 at 4:15 AM Liviu Dudau wrote:
> >>>
> >>> Commit 72a7cf0aec0c
Hi, Yongqiang:
Yongqiang Niu 於 2021年7月16日 週五 下午2:58寫道：
>
> add time-out cycle setting to make sure time-out interrupt irq
> will happened when instruction time-out for wait and poll
>
> Signed-off-by: Yongqiang Niu
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 11 +++
> 1 file changed,
On Fri, 16 Jul 2021 at 16:52, Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
> >
> > On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
> > wrote:
> > >
> > > On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> > > >
> > > > Whenever we had a user object (n_placements
On Fri, 16 Jul 2021 at 15:10, Jason Ekstrand wrote:
>
> On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
> wrote:
> >
> > On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> > >
> > > Whenever we had a user object (n_placements > 0), we were ignoring
> > > obj->mm.region and always putting
Hi Stefan,
On Wed, Jul 07, 2021 at 08:01:50PM +0200, Stefan Wahren wrote:
> Hi Maxime,
>
> Am 07.07.21 um 15:11 schrieb Maxime Ripard:
> > On Tue, Jul 06, 2021 at 05:45:27PM +0200, Stefan Wahren wrote:
> >> Hi Maxime,
> >>
> >> Am 06.07.21 um 15:21 schrieb Maxime Ripard:
> >>> Hi Stefan,
> >>>
>
On Fri, Jul 16, 2021 at 9:52 AM Tvrtko Ursulin
wrote:
>
>
> On 15/07/2021 11:15, Matthew Auld wrote:
> > The CPU domain should be static for discrete, and on DG1 we don't need
> > any flushing since everything is already coherent, so really all this
> > does is an object wait, for which we have
On Wed, Jun 23, 2021 at 05:49:55PM -0400, Felix Kuehling wrote:
>
> I can think of two ways to test the changes for MEMORY_DEVICE_GENERIC in
> this patch series in a way that is reproducible without special hardware and
> firmware:
>
> For the reference counting changes we could use the dax
On 15/07/2021 11:15, Matthew Auld wrote:
The CPU domain should be static for discrete, and on DG1 we don't need
any flushing since everything is already coherent, so really all this
does is an object wait, for which we have an ioctl. Longer term the
desired caching should be an immutable
On Thu, Jul 15, 2021 at 8:21 PM Kenneth Graunke wrote:
>
> On Thursday, July 15, 2021 4:27:44 AM PDT Tvrtko Ursulin wrote:
> >
> > On 15/07/2021 12:07, Daniel Vetter wrote:
> > > On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
> > >>
> > >> On 15/07/2021 11:15, Matthew Auld wrote:
On 15/07/2021 11:15, Matthew Auld wrote:
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a complete set of pages
upon creation. To be more efficient than simply populating the userptr
using
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
Whenever we had a user object (n_placements > 0), we were ignoring
obj->mm.region and always putting obj->placements[0] as the requested
region. For LMEM+SMEM objects, this was causing them to get shoved into
LMEM on every i915_ttm_get_pages() even when SMEM was requested by, say,
Instead of hand-rolling the same three calls in each function, pull them
into an i915_gem_object_create_user helper. Apart from re-ordering of
the placements array ENOMEM check, there should be no functional change.
v2 (Matthew Auld):
- Add the call to i915_gem_flush_free_objects() from
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()
Since we don't allow changing the set of regions after creation, we can
make ext_set_placements() build up the region set directly in the
create_ext and assign it to the object later. This is similar to what
we did for contexts with the proto-context only simpler because there's
no funny object
We don't roll them together entirely because there are still a couple
cases where we want a separate can_migrate check. For instance, the
display code checks that you can migrate a buffer to LMEM before it
accepts it in fb_create. The dma-buf import code also uses it to do an
early check and
This doesn't really fix anything serious since the chances of a client
creating and destroying a mass of dumb BOs is pretty low. However, it
is called by the other two create IOCTLs to garbage collect old objects.
Call it here too for consistency.
Signed-off-by: Jason Ekstrand
Cc: Matthew Auld
This patch series fixes an issue with discrete graphics on Intel where we
allowed dma-buf import while leaving the object in local memory. This
breaks down pretty badly if the import happened on a different physical
device.
v7:
- Drop "drm/i915/gem/ttm: Place new BOs in the requested region"
-
On Fri, Jul 16, 2021 at 8:54 AM Matthew Auld
wrote:
>
> On Thu, 15 Jul 2021 at 23:39, Jason Ekstrand wrote:
> >
> > Whenever we had a user object (n_placements > 0), we were ignoring
> > obj->mm.region and always putting obj->placements[0] as the requested
> > region. For LMEM+SMEM objects,
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/gm12u320.c | 19 +--
1 file changed, 5 insertions(+), 14
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/repaper.c | 18 --
1 file changed, 4 insertions(+), 14 deletions(-)
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
There's one left-over reference to the imported attachment that we
keep. GEM BOs with imported attachment are considered uncached and
enables
Replace dma_buf_begin_cpu_access() with drm_gem_fb_begin_cpu_access();
same for _end_cpu_access(). Remove some boiler-plate code. No functional
changes.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/tiny/st7586.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
1 - 100 of 148 matches
Mail list logo
