/dri-devel/20210804185704.624883-1-ja...@jlekstrand.net/
Cheers, Daniel
>---
> drivers/gpu/drm/i915/i915_query.c | 2 ++
> include/uapi/drm/i915_drm.h | 8 +++-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_quer
02,18 @@ struct intel_context {
> /* GuC context blocked fence */
> struct i915_sw_fence guc_blocked;
>
> + /* Head of children list or link in parent's children list */
Kerneldoc layout would be nice, plus explaining when exactly this is
set or the l
On Mon, Aug 09, 2021 at 04:37:55PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:12PM -0700, Matthew Brost wrote:
> > Introduce context parent-child relationship. Once this relationship is
> > created all pinning / unpinning operations are directed to the parent
&
documented. This means a) a comment next to each barrier in the code b)
pointing to its counterparty c) with the overall design also explained
in the kerneldoc for those datastructres.
If you don't know where your barriers are, see above point about "it
should look more li
E_GUC_IDS_EXHAUSTED, &gse->flags);
> }
>
> +/*
> + * We reserve 1/16 of the guc_ids for multi-lrc as these need to be
> contiguous
I think it'd be good to put down the reason here for why. Is this a
requirement of the guc interface, or just an artifact of our curre
argely land all this.
Also: set_bit is an unordered atomic, which means you need barriers, which
meanes ... *insert the full rant about justifying/documenting lockless
algorithms from earlier *
But I think this all falls out with the removal of the guc-id allocation
scheme?
-Danie
patches will use this function */
> +__maybe_unused
Pure bikeshed, but for something this small just squash it in with the
first user. This kinda does nothing alone.
-Daniel
> +static void guc_child_context_destroy(struct kref *kref)
> +{
> + __guc_context_destroy(co
need to emit tracking along the timeline,
> + * we embed the hooks into our request struct -- at the cost of
> + * having to have specialised no-allocation interfaces (which will
> + * be beneficial elsewhere).
> + *
> + * A second benefit to open-coding i915_
c_submission_print_context_info(struct intel_guc *guc,
>struct drm_printer *p)
> {
> struct intel_context *ce;
> unsigned long index;
> xa_for_each(&guc->context_lookup, index, ce) {
xa_for_each
uest link + igt patchwork link because this is uapi please.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 157 +-
> .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 +
> drivers/gpu/drm/i915/gt/intel_context_types.h | 8 +-
> drivers/gpu
this, so you can too.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index
derstanding all the ordering rules drm/sched has, but
I don't think it will be any happier about this kind of submission model.
tldr; what do?
Cheers, Daniel
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 262 +++---
> drivers/gpu/drm/i915/gt/intel_context.
On Mon, Aug 09, 2021 at 04:39:48PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 06:32:42PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:20PM -0700, Matthew Brost wrote:
> > > The GuC must receive requests in the order submitted for contexts in a
t we want/need to switch vma over to
dma_resv_lock. And then it gets really nasty, because you run into a ton
of problems.
To more I read this the less I like this :-/
-Daniel
>
> Signed-off-by: Matthew Brost
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 127
On Mon, Aug 09, 2021 at 07:07:44PM +0200, Daniel Vetter wrote:
> On Tue, Aug 03, 2021 at 03:29:38PM -0700, Matthew Brost wrote:
> > Certain VMA functions in the execbuf IOCTL only need to be called on
> > first or last BB of a multi-BB submission. eb_relocate() on the first
>
&g
s without pin/unpin and layer hacks
over that misdesign.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
> .../i915/gem/selftests/i915_gem_coherency.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +-
> .../drm/i915/gem/selftests/i915_gem_mma
On Sun, Aug 8, 2021 at 2:56 AM Jason Ekstrand wrote:
>
> On August 6, 2021 15:18:59 Daniel Vetter wrote:
>
>> gem context refcounting is another exercise in least locking design it
>> seems, where most things get destroyed upon context closure (which can
>> race with
On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> > On Fri, Aug 06, 2021 at 09:36:56AM +0300, Joonas Lahtinen wrote:
> > > Hi Matt,
> > >
> > > Always use the dim tooling when ap
On Mon, Aug 09, 2021 at 04:12:52PM -0700, John Harrison wrote:
> On 8/6/2021 12:46, Daniel Vetter wrote:
> > Seen this fly by and figured I dropped a few thoughts in here. At the
> > likely cost of looking a bit out of whack :-)
> >
> > On Fri, Aug 6, 2021 at 8:01 P
what
exactly is the actual intention behind all this, and then fix up the tests
to match (if needed). And only then fix up GuC to match whatever we
actually want to do.
-Daniel
>
> As the above tests change the heartbeat value to 0 (off) after the
> context is closed and we have no way
On Mon, Aug 09, 2021 at 06:11:37PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:23:42PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:07PM -0700, Matthew Brost wrote:
> > > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> &
On Mon, Aug 09, 2021 at 06:20:51PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:27:01PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:08PM -0700, Matthew Brost wrote:
> > > Calling switch_to_kernel_context isn't needed if the engine PM reference
&
On Mon, Aug 09, 2021 at 06:28:58PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:28:04PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:10PM -0700, Matthew Brost wrote:
> > > Add logical engine mapping. This is required for split-frame, as
> >
On Mon, Aug 09, 2021 at 06:37:01PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:30:06PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:11PM -0700, Matthew Brost wrote:
> > > Expose logical engine instance to user via query engine info IOCTL. This
>
On Tue, Aug 10, 2021 at 08:21:09AM +, Kasireddy, Vivek wrote:
> Hi Daniel,
>
> > On Fri, Aug 06, 2021 at 07:27:13AM +, Kasireddy, Vivek wrote:
> > > Hi Daniel,
> > >
> > > > > > > >>> The solution:
> > > >
hristian König has
merged a patch set to lift this by reworking the shrinker interaction,
but it had to be reverted again because of some fallout I can't remember
offhand. dma_resv_lock vs shrinkers is very tricky.
So if you want resource limits then you really want cgroups here.
Cheers,
On Mon, Aug 09, 2021 at 06:44:16PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:37:55PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:12PM -0700, Matthew Brost wrote:
> > > Introduce context parent-child relationship. Once this relationship is
> &g
On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 05:17:34PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> > > Implement GuC parent-child context pin / unpin functions in which in any
>
On Tue, Aug 10, 2021 at 10:53:37AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 05:17:34PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:13PM -0700, Matthew Brost wrote:
> > > &
On Mon, Aug 09, 2021 at 07:03:12PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 05:31:38PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:16PM -0700, Matthew Brost wrote:
> > > Assign contexts in parent-child relationship consecutive guc_ids. This
> &
On Mon, Aug 09, 2021 at 07:05:58PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 05:35:25PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:17PM -0700, Matthew Brost wrote:
> > > The heartbeat uses a single instance of a GuC submit engine (GSE) to do
> &
On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > > Display the workqueue status in debugfs for GuC contexts that are in
On Tue, Aug 10, 2021 at 11:23:39AM +0200, Daniel Vetter wrote:
> On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> > On Mon, Aug 09, 2021 at 06:36:44PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 03, 2021 at 03:29:22PM -0700, Matthew Brost wrote:
> > &
the dw-hdmi and also dw-dsi drivers are very much built on
top of component.c and side-step the bridge stuff quite a lot. That
results in quite bad integration pains all around as we add more users of
these.
The other unfortunate thing is that there's not many people working in
this area, so fundamental improvements to the core design take a long time
to make and then even longer to roll out. It's a bit a tough spot, but
also, help very much welcome :-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
rivers for the connected hardware need to probe before
> the main DRM driver. So I need to know that a remote device (connected via
> DT graph) will never probe.
>
> Give me a of_graph_remote_device_driver_will_never_probe() and I'll use
> that.
>
> > Much like the devic
-bool dumpstate = false;
>
> Signed-off-by: zhaoxiao
Subject should start out with drm/msm, not drm/drv - that would indicate a
patch touching the drm_drv.c core files, or things related to that.
-Daniel
> ---
> v2: change the patch description
> drivers/gpu/drm/msm/msm_drv.c |
if you feel
like, that kind of stuff).
At least a get a bit a feeling for big stuff nouveau aint ready yet for
group maintainership, judging from what you're proposing here. This also
allows you to experiment around more with gitlab CI and maybe MR, perhaps
nouveau will got directly to that for group maintainership (with Ben and
Marge bot as sole committers)?
Plus I think offloading and speeding up the simple fixes should help a lot
already in making nouveau more alive and perhaps attracting new
contributors.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Mon, Aug 09, 2021 at 08:47:14PM +0200, Daniel Vetter wrote:
> On Sun, Aug 8, 2021 at 2:56 AM Jason Ekstrand wrote:
> >
> > On August 6, 2021 15:18:59 Daniel Vetter wrote:
> >
> >> gem context refcounting is another exercise in least locking design it
>
regions'.
> > >
> > > Introduced by (one or more of) commits
> > >
> > > 0c1a77cbdafb ("drm/doc: add section for driver uAPI")
> > > 2bc9c04ea702 ("drm/doc/rfc: i915 DG1 uAPI")
> > > 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
> >
> > I am still getting these warning.
>
> Still getting them ...
Matt Auld is on vacation, and the other issue is that the tree where this
is from isn't in linux-next. So will take a bit to get sorted in
linux-next.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
w to make this all compatible.
Also I think we need very precise spec for how this is supposed to work
with DSI panels, and then making sure existing drivers mostly follow this.
Hacking up a shared interface that's used by lots of drivers just to then
fix a bug in one user and one i
riv = drm_crtc_get_priv(crtc);
>
> + if (priv->no_vblank)
> + return -EWOULDBLOCK;
I think other drivers return EINVAL here. I'm not sure exactly this is
specified, but the errno here is visible to userspace.
Maybe would be good to update the kerneldoc for th
; 'bracket'
> > - 'mappinsg' -> 'mappings'
> > - 'fullfills' -> 'fulfills'
> >
> > Signed-off-by: Gal Pressman
>
> Reviewed-by: Randy Dunlap
Applied to drm-misc-next, thanks for patch&review.
-Daniel
>
&g
_object *bo,
> - uint32_t page_flags)
> + u32 page_flags)
It's for the ttm_device_funcs ops table, I thinhk we should fix it there
and across the board?
Otherwise a bit ocd mismatch :-)
-Daniel
> {
> struct ttm_resource_manager
On Mon, Aug 09, 2021 at 07:35:22PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 03:35:26PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 08, 2021 at 11:07:55AM -0700, Matthew Brost wrote:
> > > Resets are notoriously hard to get fully working and notoriously racey,
>
On Mon, Aug 09, 2021 at 07:37:39PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 03:38:38PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 08, 2021 at 11:07:56AM -0700, Matthew Brost wrote:
> > > GuC submission has exposed an existing memory corruption in
> > > liv
On Mon, Aug 09, 2021 at 07:41:29PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 04:03:28PM +0200, Daniel Vetter wrote:
> > On Sun, Aug 08, 2021 at 11:07:57AM -0700, Matthew Brost wrote:
> > > While debugging an issue with full GT resets I went down a rabbit hole
On Tue, Aug 10, 2021 at 08:38:59PM +1000, Stephen Rothwell wrote:
> Hi Daniel,
>
> On Tue, 10 Aug 2021 12:14:38 +0200 Daniel Vetter wrote:
> >
> > Matt Auld is on vacation, and the other issue is that the tree where this
> > is from isn't in linux-next. So
uture if the driver shows
> > > up,
> > > > right?
> > >
> > > Well, the DRM subsystem doesn't really seem to handle hotplug of
> > > hardware.
> > > Right now all the drivers for the connected hardware need to probe
> > > before
> > > the main DRM driver. So I need to know that a remote device
> > > (connected via
> > > DT graph) will never probe.
> >
> > But you never really know that. That is what the recent driver core
> > changes were all about, to handle this very issue. Only when the child
> > device shows up will you need to care about it.
> >
> > > Give me a of_graph_remote_device_driver_will_never_probe() and I'll
> > > use
> > > that.
> > >
> > > > Much like the device link code, have you looked at that?
> > >
> > > I don't see how that would help in any way. The device link code
> > > would allow
> > > me to set a dependency between the remote hardware (HDMI chip,
> > > provider) and
> > > the LCD controller (consumer), but I already have that dependency
> > > though the
> > > DT graph. What I need is a way for the consumer to continue probing
> > > if the
> > > provider is not going to probe.
> >
> > But again, you never know that, probing is async, and could happen in a
> > few milliseconds, or a few hours, your driver should never care about
> > this at all.
> >
> > Just knowing if the kernel configuration is something is not the
> > solution here, please fix this properly like all other driver
> > interactions are in the kernel tree.
>
> A proper fix means reworking the DRM core so that it supports hot-plugging
> bridges. Until then there is nothing else I can do.
The conflict is that drm wants to load the entire driver, including any
bridges.
Paul wants to load just the driver parts he wants to put into the image.
This doesn't work well together.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Aug 10, 2021 at 12:33:04PM +0200, Paul Cercueil wrote:
> Hi Daniel,
>
> Le mar., août 10 2021 at 11:35:43 +0200, Daniel Vetter a
> écrit :
> > On Fri, Aug 06, 2021 at 01:01:33PM +0200, Paul Cercueil wrote:
> > > Hi Greg,
> > >
> > > Le ve
On Tue, Aug 10, 2021 at 01:38:27PM +0200, Karol Herbst wrote:
> On Tue, Aug 10, 2021 at 12:11 PM Daniel Vetter wrote:
> >
> > On Fri, Aug 06, 2021 at 06:53:06PM +0200, Karol Herbst wrote:
> > > Hey everybody,
> > >
> > > so, here is a proposal
rm/doc/rfc: drop the i915_gem_lmem.h header")
Cc: Matthew Auld
Signed-off-by: Daniel Vetter
---
Documentation/gpu/rfc/i915_gem_lmem.rst | 107
1 file changed, 107 deletions(-)
diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst
b/Documentation/gpu/rfc/i915_gem_lmem.rst
index 6
On Tue, Aug 10, 2021 at 1:01 PM Stephen Rothwell wrote:
> Hi Daniel,
>
> On Tue, 10 Aug 2021 12:50:55 +0200 Daniel Vetter wrote:
> >
> > Uh that's not good, I missed that. I'll look into it.
>
> Thanks.
Doc build is taking absolutely forever here, but I thin
and then inline the lopp body too. This
is how all other callers that take the engine lock loop over engines,
it's much simpler.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniel Vetter
Cc: Jason Ekstrand
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Matthew Brost
rand
Tested-by Stephen Rothwell (v1)
References:
https://lore.kernel.org/dri-devel/20210603193242.1ce99...@canb.auug.org.au/
Reported-by: Stephen Rothwell
Cc: Stephen Rothwell
Fixes: 727ecd99a4c9 ("drm/doc/rfc: drop the i915_gem_lmem.h header")
Cc: Matthew Auld
Signed-off-by: Daniel V
if there is a better
> place please say and I'll go there.
>
> Many thanks
>
> John Cox
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Aug 11, 2021 at 10:16:41AM +0300, Jani Nikula wrote:
> On Tue, 10 Aug 2021, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 09:19:39AM -0700, Matt Roper wrote:
> >> On Mon, Aug 09, 2021 at 04:05:59PM +0200, Daniel Vetter wrote:
> >> > On Fri, Aug 06, 20
On Mon, Aug 09, 2021 at 07:32:26PM +, Matthew Brost wrote:
> On Mon, Aug 09, 2021 at 07:17:27PM +0200, Daniel Vetter wrote:
> > On Tue, Aug 03, 2021 at 03:29:43PM -0700, Matthew Brost wrote:
> > > Some workloads use lots of contexts that continually pin / unpin
> &
On Tue, Aug 10, 2021 at 05:29:46PM +, Matthew Brost wrote:
> On Tue, Aug 10, 2021 at 11:27:31AM +0200, Daniel Vetter wrote:
> > On Tue, Aug 10, 2021 at 11:23:39AM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 09, 2021 at 07:13:11PM +, Matthew Brost wrote:
> > > &
ldoc (or even comments) in the relevant datastructures, which is not
great.
> - ce->guc_state.sched_state = 0;
> + ce->guc_state.sched_state &= SCHED_STATE_BLOCKED_MASK;
The patch itself matches the commit message and makes sense. But like I
said, would be cleaner I think if it's
On Thu, Jul 22, 2021 at 08:22:43PM +0200, Thomas Zimmermann wrote:
> Hi,
>
> I'm not knowledgeable enougth to give this a full review. If you can just
> answer my questions, fell free to add an
>
> Acked-by: Thomas Zimmermann
>
> to the patch. :)
>
> Am 13.0
rnel.org/lkml/cakmk7uhi+mg0z0humnt13qccvuturvjpcr0njrl12k-wbwz...@mail.gmail.com/
Acked-by: Christian König
Acked-by: Thomas Zimmermann
Cc: Thomas Zimmermann
Cc: Jason Gunthorpe
Cc: Suren Baghdasaryan
Cc: Matthew Wilcox
Cc: John Stultz
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: "Ch
+0200, Thomas Zimmermann wrote:
> Am 13.07.21 um 22:51 schrieb Daniel Vetter:
> > We want to stop gup, which isn't the case if we use vmf_insert_page
>
> What is gup?
get_user_pages. It pins memory wherever it is, which badly wreaks at least
ttm and could also cause trouble with
y reliably, so maybe
we'd need some kind of GFP_WC flag to do this properly.
v2: Add a TODO comment about what should be done to support this in
other places (Thomas)
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
Cc: Christian König
Cc: "Thomas Hellström"
Cc: Maarten Lan
ing
v7: I absolutely butchered the rebases over the vgem mmap change and
revert and broke the patch. Actually go back to v6 from before the
vgem mmap changes.
Cc: Thomas Zimmermann
Acked-by: Thomas Zimmermann
Cc: John Stultz
Cc: Sumit Semwal
Cc: "Christian König"
Signed-off
On Wed, Aug 11, 2021 at 05:43:23PM +, Matthew Brost wrote:
> On Wed, Aug 11, 2021 at 11:55:48AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 09, 2021 at 07:32:26PM +, Matthew Brost wrote:
> > > On Mon, Aug 09, 2021 at 07:17:27PM +0200, Daniel Vetter wrote:
> > > &
msleep(20);
flush_work or flush_workqueue, beacuse that comes with lockdep
annotations. Dont hand-roll stuff like this if at all possible.
-Daniel
> +
> scrub_guc_desc_for_outstanding_g2h(guc);
> }
>
> --
> 2.32.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Wed, Aug 11, 2021 at 06:06:36PM +, Matthew Brost wrote:
> On Tue, Aug 10, 2021 at 11:07:55AM +0200, Daniel Vetter wrote:
> > On Tue, Aug 10, 2021 at 10:53:37AM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 09, 2021 at 06:58:23PM +, Matthew Brost wrote:
> > > &
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11584
> Cc: Jordan Justen jordan.l.jus...@intel.com
> Cc: Jason Ekstrand ja...@jlekstrand.net
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gem/i915_gem_create.c | 3 ---
> drivers/gpu/drm/i915/i915_pci.c
On Thu, Aug 12, 2021 at 4:45 PM Daniel Vetter wrote:
>
> On Wed, Aug 11, 2021 at 06:06:36PM +, Matthew Brost wrote:
> > On Tue, Aug 10, 2021 at 11:07:55AM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 10, 2021 at 10:53:37AM +0200, Daniel Vetter wrote:
> > > &
On Thu, Aug 12, 2021 at 5:10 PM Jason Ekstrand wrote:
> On Tue, Aug 10, 2021 at 8:05 AM Daniel Vetter wrote:
> >
> > This essentially reverts
> >
> > commit 89ff76bf9b3b0b86e6bbe344bd6378d8661303fc
> > Author: Chris Wilson
> > Date: Thu Apr 2 13:42
u
never miss an update.
I'm feeling like that maybe this would be a semi-reasonable intermediate
option instead of just hard-pinning contexts completely for their entire.
I think that would be a smaller step than perma-pinnned context with their
guc_id, and it would allow us to clean up a l
On Thu, Aug 05, 2021 at 12:46:53PM +0200, Daniel Vetter wrote:
> 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 th
On Thu, Aug 05, 2021 at 12:46:56PM +0200, Daniel Vetter wrote:
> 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, f
On Thu, Aug 05, 2021 at 12:46:57PM +0200, Daniel Vetter wrote:
> drm_sched_job_init is already at the right place, so this boils down
> to deleting code.
>
> Signed-off-by: Daniel Vetter
> Cc: Rob Clark
> Cc: Sean Paul
> Cc: Sumit Semwal
> Cc: "Chri
On Thu, Aug 05, 2021 at 12:46:58PM +0200, Daniel Vetter wrote:
> 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 Ve
On Thu, Aug 12, 2021 at 07:01:44PM +0200, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Thu, Aug 12, 2021 at 03:14:12PM +0200, Daniel Vetter wrote:
> > Aside from deleting lots of code the real motivation here is to switch
> > the mmap over to VM_PFNMAP, to be more consiste
On Thu, Aug 12, 2021 at 03:23:30PM +, Matthew Brost wrote:
> On Thu, Aug 12, 2021 at 04:11:28PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 11, 2021 at 01:16:18AM +, Matthew Brost wrote:
> > > Flush the work queue for GuC generated G2H messages durinr a GT reset.
> >
ret;
>
> mutex_lock(&pxp->tee_mutex);
> pxp->pxp_component = data;
> @@ -88,15 +89,14 @@ static int i915_pxp_tee_component_bind(struct device
> *i915_kdev,
>
> /* the component is required to fully start the PXP HW */
> intel_pxp_init
Daniele Ceraolo Spurio
> Signed-off-by: Bommu Krishnaiah
> Cc: Rodrigo Vivi
> Cc: Chris Wilson
> Cc: Lionel Landwerlin
> Cc: Jason Ekstrand
> Cc: Daniel Vetter
> Reviewed-by: Rodrigo Vivi #v5
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c
On Fri, Aug 13, 2021 at 04:37:53PM +0200, Daniel Vetter wrote:
> On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
> > This api allow user mode to create protected buffers and to mark
> > contexts as making use of such objects. Only when using contexts
>
On Thu, Aug 12, 2021 at 10:38:18PM +, Matthew Brost wrote:
> On Thu, Aug 12, 2021 at 09:47:23PM +0200, Daniel Vetter wrote:
> > On Thu, Aug 12, 2021 at 03:23:30PM +, Matthew Brost wrote:
> > > On Thu, Aug 12, 2021 at 04:11:28PM +0200, Daniel Vetter wrote:
> > > &
missions should call synchronize_srcu before returning.
>
> This ensures that any process that might have seen old permissions are
> flushed out before DROP_MASTER/REVOKE_LEASE/SET_MASTER ioctls return
> to userspace.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond
On Fri, Aug 13, 2021 at 04:54:50PM +0800, Desmond Cheong Zhi Xi wrote:
> Since the last user of drm_ioctl_permit was removed, and it's now only
> used in drm_ioctl.c, unexport the symbol.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond Cheong Zhi Xi
Applied to dr
hat requires some major surgery, and we have
a few i915_gem_context reference counting bugs that need fixing, and
they blow in the current hardirq calling context, so we need a
stop-gap measure.
Put a FIXME comment in when this should be removable again.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfi
ange, is not the case.
Signed-off-by: Daniel Vetter
Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)")
Cc: Jason Ekstrand
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Matthew Brost
Cc: Matthew Auld
Cc: Maarten Lankhorst
Cc: &quo
full-ppgtt platforms. Ditching it all seemed
like a better idea.
References: ccbc1b97948a ("drm/i915/gem: Don't allow changing the VM on running
contexts (v4)")
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: D
s either a full ppgtt stored in gem->ctx, or the ggtt.
We'll make more use of this function later on.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: L
Landwerlin
Cc: Dave Airlie
Fixes: 2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i9
Consolidates the "which is the vm my execbuf runs in" code a bit. We
do some get/put which isn't really required, but all the other users
want the refcounting, and I figured doing a function just for this
getparam to avoid 2 atomis is a bit much.
Signed-off-by: Daniel Vetter
Cc:
r an accident
where we run kernel stuff in userspace vm or the other way round.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc:
xt->vm or gt->vm,
which is always set.
v2: 0day found a testcase that I missed.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc:
e also remove the rcu_barrier in ggtt_cleanup_hw added in
commit 60a4233a4952729089e4df152e730f8f4d0e82ce
Author: Chris Wilson
Date: Mon Jul 29 14:24:12 2019 +0100
drm/i915: Flush the i915_vm_release before ggtt shutdown
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris W
ris Wilson
Date: Fri Aug 30 19:03:25 2019 +0100
drm/i915: Use RCU for unlocked vm_idr lookup
except we have the conversion from idr to xarray in between.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
C
close to anything
that's a hotpath where removing the single spinlock can be measured).
v2: Rebase over the change to move the i915_vm_put() into
i915_gem_context_release().
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: D
-ci.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtinen
Cc: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc: Dave Airlie
Cc: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context
ood).
These kind of internal functions have their declaration in
drm-internal.h - there's already a few there from drm_auth.c
- We know have 3 locks for master state, that feels a bit like
overkill. The spinlock I think we need to keep due to lock inversions,
but the master_mutex and master_rwsem l
On Mon, Aug 16, 2021 at 12:31 PM Desmond Cheong Zhi Xi
wrote:
>
> On 16/8/21 5:04 pm, Daniel Vetter wrote:
> > On Mon, Aug 16, 2021 at 10:53 AM Desmond Cheong Zhi Xi
> > wrote:
> >> On 16/8/21 2:47 am, kernel test robot wrote:
> >>> Hi Desmond,
> >&g
ttps://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#open-source-userspace-requirements
At least one driver is trying to play some very clever games here and
that's not a solid way to make friends ...
-Daniel
>
> > Our first usecase is, we want userspace applications to be able
On Fri, Aug 13, 2021 at 08:18:02AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/13/2021 7:37 AM, Daniel Vetter wrote:
> > On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
> > > This api allow user mode to create protected buffers and to mark
>
On Fri, Aug 13, 2021 at 08:24:44AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/13/2021 7:42 AM, Daniel Vetter wrote:
> > On Fri, Aug 13, 2021 at 04:37:53PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 28, 2021 at 07:01:01PM -0700, Daniele Ceraolo Spurio wrote:
>
601 - 700 of 26159 matches
Mail list logo
