the time of
> the
> + * next vblank, and inform all the fences of the of the deadline.
s/of the//
Otherwise lgtm, Reviewed-by: Daniel Vetter
> + */
> +static void set_fence_deadline(struct drm_device *dev,
> +struct drm_atomic_state *state)
>
x27;t stuck behind the app rendering
the next frame?
I'm not sure whether you wire that one up as part of the conversion to
drm/sched. Without that I think we might need to ponder how we can do a
prio-boost for these, e.g. within a scheduling class we pick the jobs with
the nearest deadli
On Fri, Aug 13, 2021 at 07:02:55PM +, Matthew Brost wrote:
> On Fri, Aug 13, 2021 at 05:11:59PM +0200, Daniel Vetter wrote:
> > 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:
> > > &
ich the next
patch will address.
v7: Drop the FIXME in msm, after discussions with Rob I agree it shouldn't
be a problem where it is now.
Acked-by: Christian König
Acked-by: Melissa Wen
Cc: Melissa Wen
Acked-by: Emma Anholt
Acked-by: Steven Price (v2)
Reviewed-by: Boris Brezillon (v5)
Sign
lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_gem_submit.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_submit.c
b/drivers/gpu/drm/msm/msm_gem_submit.c
index 4d1c4d5f6a2a..371ed9154e58 100644
--- a/drivers/gpu/
On Mon, Aug 16, 2021 at 08:58:49AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/16/2021 8:15 AM, Daniel Vetter wrote:
> > 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 Mon, Aug 16, 2021 at 03:25:20PM -0700, Rob Clark wrote:
> On Mon, Aug 16, 2021 at 8:38 AM Daniel Vetter wrote:
> >
> > On Mon, Aug 16, 2021 at 12:14:35PM +0200, Christian König wrote:
> > > Am 07.08.21 um 20:37 schrieb Rob Clark:
> > > > From: Rob Clark
&
t; is some real world impact thing I wouldn't put cc:
stable on this.
-Daniel
> ---
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu
s.
- flush_work_sync, which flushes until self-requeues are all done too
- Or more preferred, make you're worker a bit more standard for this
stuff: a) under the spinlock, take the entire list, not just the first
entry, with list_move or similar to a local list b) pr
usy_loop naming scheme, especially here.
Like "why do we want to send a busy loop comand to guc, this doesn't make
sense".
It seems like you're using _busy_loop as a suffix for "this is ok to be
called in atomic context". The linux kernel bikeshed for this is generally
e context, and we don't seem
to hold spinlocks for those, or anything else.
I general I have no idea which of these are defensive programming and
cannot ever happen, and which actually can happen. There's for sure way
too many races going on given that this is all context-local stuff.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Tue, Aug 17, 2021 at 11:47:53AM +0200, Daniel Vetter wrote:
> On Mon, Aug 16, 2021 at 06:51:25AM -0700, Matthew Brost wrote:
> > When unblocking a context, do not enable scheduling if the context is
> > banned, guc_id invalid, or not registered.
> >
> > Fixes:
GFP_NOWARN means we can totally cope with failure, pls don't holler.
GFP_NOWAIT | __GFP_NOWARN would the more consistent one here I think.
gfp.h for all the docs for this.
Separate patch ofc. This one is definitely the right direction, since
GFP_KERNEL from the reset worker is not a go
- } while (!list_empty(&guc->ct.requests.incoming));
> - }
> + flush_work(&guc->ct.requests.worker);
Same thing about flush_work as in an earlier patch.
-Daniel
> +
> scrub_guc_desc_for_outstanding_g2h(guc);
> }
>
> --
> 2.32.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
so these
kind of nestings would be good to document in the kerneldoc too (maybe as
you go even).
-Daniel
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15 ++-
> drivers/gpu/drm/i915/i915_request.h | 5 +
> 2 files changed, 19 ins
latest when your combine your count state with a wait
queue you're very far into "reinventing a mutex/semaphore, badly" land.
I think we really need to look into why we can't just protect this all
with a mutex and make sure the awkward transition states are never visible
to anyone
STERED) &&
> - !(ce->guc_state.sched_state &= ~SCHED_STATE_BLOCKED_MASK);
> + return !(ce->guc_state.sched_state &=
> + ~(SCHED_STATE_BLOCKED_MASK | SCHED_STATE_REGISTERED));
> }
>
> static inline bool
> @@ -236,6 +17
g against a deregistering. So probably needs more
rules on top, and then you have a nice lock inversion in a few places like
here.
3. document it and roll it out.
The other thing is that this is a very tricky iterator, and there's a few
copies of it. That is, if this is the right solution. As-is
s is quite racey. To
> + * avoid races the rules are check for submission being disabled (i.e. check
> for
> + * mid reset) with the appropriate lock being held. If submission is disabled
> + * don't send the H2G or update the context state. The reset code must
> disable
> +
fallthrough;
> case DRM_FORMAT_RGB888:
> - if (!xrgb_emulation_format)
> + if (!gud_xrgb && !xrgb_emulation_format)
> xrgb_emulation_format = info;
Shouldn't the
x27;ve totally ignored endianess on these, which is
not great, because strictly speaking all the drm_fourcc codes should be
little endian. But I'm also not sure that's worth fixing ...
Either way, lgtm:
Reviewed-by: Daniel Vetter
> + ((sbuf[x] & 0xe000)
e ARGB1555
ones and it's permutations.
Anyway it's consistent with what's there.
Reviewed-by: Daniel Vetter
> { .format = DRM_FORMAT_RGB332, .depth = 8,
> .num_planes = 1, .cpp = { 1, 0, 0 }, .hsub = 1, .vsub = 1 },
> { .format = DRM_FO
low dst_pitch == 0 and just automatically pick this one here, and then
paper over the __iomem differences with dma_buf_map we wouldn't need two
different functions.
Just an idea.
Reviewed-by: Daniel Vetter
> +{
> + size_t width = drm_rect_width(clip);
> + size_t src_len = width * size
uld all
get this right, it's the fringe arm drivers that no one tests fully which
get all these details wrong.
So unless someone hollers that this fixes a bug on their hw I'd let these
be.
Upgrade to 5.10 LTS if you care about this stuff, it's been out f
On Tue, Aug 17, 2021 at 03:59:56PM +0200, Daniel Vetter wrote:
> On Tue, Aug 17, 2021 at 02:29:11PM +0200, Noralf Trønnes wrote:
> > Add an entry in drm_format_info for the existing format DRM_FORMAT_R8.
> >
> > Signed-off-by: Noralf Trønnes
> > ---
> > drivers/
On Tue, Aug 17, 2021 at 5:13 PM Matthew Brost wrote:
> On Tue, Aug 17, 2021 at 11:21:27AM +0200, Daniel Vetter wrote:
> > On Mon, Aug 16, 2021 at 06:51:23AM -0700, Matthew Brost wrote:
> > > Progagating errors to dependent fences is wrong, don't do it. Selftest
> >
On Tue, Aug 17, 2021 at 08:26:28AM -0700, Matthew Brost wrote:
> On Tue, Aug 17, 2021 at 12:27:29PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 16, 2021 at 06:51:36AM -0700, Matthew Brost wrote:
> > > Lock the xarray and take ref to the context if needed.
> > >
&
On Tue, Aug 17, 2021 at 09:36:49AM -0700, Matthew Brost wrote:
> On Tue, Aug 17, 2021 at 01:11:41PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 16, 2021 at 06:51:39AM -0700, Matthew Brost wrote:
> > > Add GuC kernel doc for all structures added thus far for GuC submission
> &g
On Tue, Aug 17, 2021 at 07:27:18PM +0200, Michal Wajdeczko wrote:
>
>
> On 17.08.2021 19:20, Daniel Vetter wrote:
> > On Tue, Aug 17, 2021 at 09:36:49AM -0700, Matthew Brost wrote:
> >> On Tue, Aug 17, 2021 at 01:11:41PM +0200, Daniel Vetter wrote:
> >>> On M
ermann
> Cc: Sam Ravnborg
> Cc: Dave Airlie
> Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Vetter
I checked a bit your integer types, and there's a fair bit of
inconsistency for what you're using for clock. unsigned int, long, int
can all be found somewhere. But tha
On Tue, Aug 17, 2021 at 10:41 PM Michal Wajdeczko
wrote:
> On 17.08.2021 19:34, Daniel Vetter wrote:
> > On Tue, Aug 17, 2021 at 07:27:18PM +0200, Michal Wajdeczko wrote:
> >> On 17.08.2021 19:20, Daniel Vetter wrote:
> >>> On Tue, Aug 17, 2021 at 09:36:49AM -0700,
On Wed, Aug 18, 2021 at 2:28 AM John Harrison wrote:
> On 8/9/2021 23:36, Daniel Vetter wrote:
> > 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 thought
e of
making p2p work without dynamic dma-buf. Without that it just doesn't
make a lot of sense really to talk about solutions here.
-Daniel
> ---
> drivers/dma-buf/dma-buf.c | 5 +++--
> drivers/infiniband/core/umem_dmabuf.c | 2 +-
> include/linux/dma-buf.h
On Tue, Aug 17, 2021 at 05:08:02PM -0700, John Harrison wrote:
> On 8/9/2021 23:38, Daniel Vetter wrote:
> > On Wed, Jul 28, 2021 at 05:33:59PM -0700, Matthew Brost wrote:
> > > Should fix below failures with GuC submission for the following tests:
> > > gem_ex
s looks extremely backwards ... what exactly is this fixing? If this
isn't based on a real world compositor usage but some igt, then I'd say
the igt here is very wrong.
-Daniel
> Fixes: b9fc5e01d1ce ("drm: Add helper to implement legacy dirtyfb")
> Cc: Daniel Vetter
>
> Cc: Rodrigo Vivi
> Cc: David Airlie
> Cc: intel-...@lists.freedesktop.org
> Cc: dri-devel@lists.freedesktop.org
> Fixes: a04ea6ae7c67 ("drm/i915: Use a table for i915_init/exit (v2)")
> Signed-off-by: Kees Cook
Applied to drm-intel-gt-next, should show up in linux-next/ne
ed, which means all ioctls and anything else have
finished (they hold a temporary reference).
fpriv->master can change (if the drm_file becomes newly minted master and
wasnt one before through the setmaster ioctl), but it cannot become NULL
before it's completely gone from the system.
-Daniel
&
this section with
> drm_device.master_lookup_lock.
>
> Signed-off-by: Desmond Cheong Zhi Xi
At this points all refcounts to drm_file have disappeared, so yeah this is
a lockless access, but also no one can observe it anymore. See also next
patch.
Hence I think the current code is fine
+ goto unlock;
This is a bit convoluted, since we're in the single-threaded release path
we don't need any locking for file_priv related things. Therefore we can
pull the master check out and just directly return.
But since it's a bit surprising maybe a comment that this can
(dev, file_priv);
> + spin_unlock(&dev->master_lookup_lock);
Similar issue with drm_set_busid, calling kmalloc under a spinlock isn't a
good idea. This one here is at least much easier to fix by pushing the
locking down a lot.
I'm wonderi
o down this path because leases are only supported
with modesetting, and modesetting is only supported for non-legacy
drivers
- the races against dev->open_count due to last_close or ->load callbacks
don't matter, because for the entire ioctl we already have an open
drm_file and th
ong Zhi Xi
Just realized another benefit of pushing the dev->master_rwsem write
locks down into ioctls that need them: We wouldn't need this function here
exported for use in drm. But also I'm not sure that works any better than
the design in your current patch set ...
-Daniel
> ---
&g
tters? Would be realy good to record
that kind of stuff in the commit message instead of just having the
implication that this optimizes stuff.
-Daniel
> >
> > Signed-off-by: Christian König
> > ---
> > drivers/gpu/drm/ttm/ttm_pool.c | 45 --
mpts to load the fbcon
> module, even when this is always built-in since the mentioned change.
>
> Signed-off-by: Javier Martinez Canillas
Nice catch. Merged to drm-misc-next for 5.16, thanks.
-Daniel
> ---
>
> drivers/gpu/drm/drm_kms_helper_common.c | 11 ---
>
#x27;s fine, if it's more then BUG_ON is the better
choice perhaps.
I think the worst choice is just removing all these checks, because a few
code reorgs later you might not Oops immediately afterwards anymore, and
then we'll merge potentially very busted new code. Which is no
from the file descriptor and keeping a
> reference to it while we are busy importing it (e.g. to prevent a race when
> somebody changes the fd at the same time).
>
> As far as I can see this is correct as well.
Yeah the analysis is just high-grade nonsense. The current code looks
corr
t here, not this convoluted jumping through hoops
to fake an error pointer.
With that: Reviewed-by: Daniel Vetter
> return err;
> }
>
> @@ -195,8 +195,8 @@ static int ct_deregister_buffer(struct intel_guc_ct *ct,
> u32 type)
> int err = guc_action_deregister_ct_buffer
27;s not worth it (there's at
least a ton of functions/variants that just arent used).
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/g
(err=%d status=%#X)\n",
> - action[0], ret, status);
> + CT_ERROR(ct, "Sending action %#x failed (%pe) status=%#X\n",
> + action[0], ERR_PTR(ret), status);
errname(), not this, with that:
Reviewed-by: Daniel Vetter
>
iver at
large (i.e. non-static functions), especially for something that's used
all over like CTB will be. But then we're back to responsibilities and
especialy aroung gpu reset, so not sure whether documenting the current
code before that's sorted is the best idea.
Reviewed-by: D
ere's been some solid clarifications around
how this is supposed to work between tdr and main scheduler thread, would
be good to explain how that all fits together. Or should fit together.
-Daniel
> > This reverts commit 135517d3565b48f4def3b1b82008bc17eb5d1c90.
> > v2:
> > ad
* processing timedout_job
> > > */
> > > - list_del_init(&job->list);
> > > + fence = dma_fence_get(job->s_fence->parent);
>
>
> While this is true for amdgpu, it has no meaning for other drivers
On Wed, Aug 18, 2021 at 03:09:41PM +0200, Christian König wrote:
> Am 18.08.21 um 14:32 schrieb Daniel Vetter:
> > On Wed, Aug 18, 2021 at 01:27:13PM +0200, Christian König wrote:
> > > Just a gentle ping?
> > >
> > > Does anybody have any objections?
On Wed, Aug 18, 2021 at 10:36:32AM -0400, Andrey Grodzovsky wrote:
>
> On 2021-08-18 10:32 a.m., Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 10:26:25AM -0400, Andrey Grodzovsky wrote:
> > > On 2021-08-18 10:02 a.m., Alex Deucher wrote:
> > >
> > &g
On Wed, Aug 18, 2021 at 5:37 PM Desmond Cheong Zhi Xi
wrote:
>
> On 18/8/21 6:11 pm, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 03:38:19PM +0800, Desmond Cheong Zhi Xi wrote:
> >> There are three areas where we dereference struct drm_master without
> >> check
On Wed, Aug 18, 2021 at 5:11 PM Michal Wajdeczko
wrote:
>
>
>
> On 18.08.2021 16:20, Daniel Vetter wrote:
> > On Thu, Jul 01, 2021 at 05:55:11PM +0200, Michal Wajdeczko wrote:
> >> Instead of plain error value (%d) print more user friendly error
> >> name (%
On Wed, Aug 18, 2021 at 09:12:32PM +0200, Michal Wajdeczko wrote:
>
>
> On 18.08.2021 18:35, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 5:11 PM Michal Wajdeczko
> > wrote:
> >>
> >>
> >>
> >> On 18.08.2021 16:20, Daniel Vetter wrot
On Wed, Aug 18, 2021 at 04:44:44PM +, Souza, Jose wrote:
> On Wed, 2021-08-18 at 11:54 +0200, Daniel Vetter wrote:
> > On Tue, Aug 17, 2021 at 04:26:04PM -0700, José Roberto de Souza wrote:
> > > Cursors don't have a framebuffer so the fb comparisson was always
> &g
On Thu, Aug 19, 2021 at 03:01:26AM +, Liu, Monk wrote:
> [AMD Official Use Only]
>
> Hi Andrey and Daniel
>
> We worked for a really long time on this new feature to AMD that finally
> can pick up the bad job from all timedout ones, and the change in
> schedu
On Wed, Aug 18, 2021 at 10:51:00AM -0400, Andrey Grodzovsky wrote:
>
> On 2021-08-18 10:42 a.m., Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 10:36:32AM -0400, Andrey Grodzovsky wrote:
> > > On 2021-08-18 10:32 a.m., Daniel Vetter wrote:
> > > > On Wed,
On Thu, Aug 19, 2021 at 12:53 PM Desmond Cheong Zhi Xi
wrote:
>
> On 18/8/21 7:02 pm, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 03:38:22PM +0800, Desmond Cheong Zhi Xi wrote:
> >> In a future patch, a read lock on drm_device.master_rwsem is
> >> held in the
On Fri, Aug 20, 2021 at 1:06 AM Jason Gunthorpe wrote:
> On Wed, Aug 18, 2021 at 11:34:51AM +0200, Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 9:45 AM Gal Pressman wrote:
> > >
> > > Hey all,
> > >
> > > Currently, the RDMA subsystem can on
In
commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
Author: Daniel Vetter
Date: Tue Aug 3 14:48:33 2021 +0200
drm/i915: delete gpu reloc code
I deleted the gpu relocation code and the selftest include and
enabling, but accidentally forgot about the selftest source code.
Fix this
On Fri, Aug 20, 2021 at 7:00 PM Rodrigo Vivi wrote:
>
> On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote:
> > In
> >
> > commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
> > Author: Daniel Vetter
> > Date: Tue Aug 3 14:48:33 2021 +0200
> &g
On Fri, Aug 20, 2021 at 9:23 PM Thomas Zimmermann wrote:
> Hi
>
> Am 20.08.21 um 17:45 schrieb syzbot:
> > syzbot has bisected this issue to:
>
> Good bot!
>
> >
> > commit ea40d7857d5250e5400f38c69ef9e17321e9c4a2
> > Author: Daniel Vetter
specific
solutions for panel/bridges. But nothing that's preventing them from
using component.c itself.
I'm happy to merge a MAINTAINERS patch to clarify the situation if
that's needed.
-Daniel
> It would be really important to avoid it. Is it really needed in the
> first place?
>
> Thanks,
> Ezequiel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
mas Hellström
For next time around I think recording a bit more of the discussions and
git history in these would be really good. At least I'd like to get more
people ramped up on ttm work, and for that to work out things need to be a
bit more accessible ... The above commit message is pr
On Tue, Aug 24, 2021 at 10:12:24AM +0200, Christian König wrote:
> Just a gentle ping. Daniel any more comments on this?
Still haven't seen a patch set to nuke the sw_sync igt tests. Otherwise
this is just going to cause fails and reboots in our ci (we reboot on
taints).
> I'm
ingle workqueue as
> suggested by Daniel now as well then that isn't an issue any more.
Sorry I got massively burried in everything, catching up. Iirc there's a
special function for parking schedulers (which panfrost now uses to handle
its cross-engine reset), would be good to use tha
On Thu, Aug 19, 2021 at 11:25:09AM -0400, Andrey Grodzovsky wrote:
>
> On 2021-08-19 5:30 a.m., Daniel Vetter wrote:
> > On Wed, Aug 18, 2021 at 10:51:00AM -0400, Andrey Grodzovsky wrote:
> > > On 2021-08-18 10:42 a.m., Daniel Vetter wrote:
> > > > On Wed, Aug 18,
i"
Signed-off-by: Daniel Vetter
---
MAINTAINERS | 5 +
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ac58d0032abd..7cdc19815ec4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5707,6 +5707,11 @@ F: Documentation/admin-guide/blockdev/
F: drivers
On Sun, Aug 22, 2021 at 02:57:15PM -0300, Ezequiel Garcia wrote:
> On Sun, 22 Aug 2021 at 13:50, Daniel Vetter wrote:
> >
> > On Wed, Aug 18, 2021 at 4:12 PM Ezequiel Garcia
> > wrote:
> > >
> > > +danvet
> > >
> > > Hi,
> >
ternals
> directly here?
Imo we should just emebed ttm_resource_mager into our own and not try to
abstract this all away that much. At least in upstream there is just not
going to be another memory region implementation, and for backporting I'm
not sure these abstractions really help that much - we're touching all the
same code still in the end.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
f-by: Lukas Bulwahn
Except the amdgpu patch all merged to drm-misc-next. amdgpu should get
picked up by Alex.
-Daniel
> ---
> drivers/gpu/drm/omapdrm/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig
&
flag set in its &polled member.
> + *
> + * This helper function is useful for drivers which can track hotplug
> + * interrupts for a single connector.
> + *
> + * This function must be called with the mode setting locks held.
> + *
> + * Note that a connector can b
4 drivers/gpu/drm/zte/zx_vga.c
> > delete mode 100644 drivers/gpu/drm/zte/zx_vga_regs.h
> > delete mode 100644 drivers/gpu/drm/zte/zx_vou.c
> > delete mode 100644 drivers/gpu/drm/zte/zx_vou.h
> > delete mode 100644 drivers/gpu/drm/zte/zx_vou_regs.h
> >
>
> Acked-by: Rob Herring
I just merged another patch to delete the zte driver.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
sts.freedesktop.org
Cc: freedr...@lists.freedesktop.org
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/msm_gem_submit.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_s
master_release in
> drm_close_helper, and remove drm_master_release from drm_file_free to
> avoid the null ptr dereference.
>
> Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Daniel Vetter
I guess we should also have a cc: stable on this one? I think this bug
existed since pr
; - drm_master.magic_map
>
> There is a clear separation between functions that read or change
> these attributes. Hence, convert master_mutex into a rwsem to enable
> concurrent readers.
>
> Signed-off-by: Desmond Cheong Zhi Xi
Reviewed-by: Daniel Vetter
&
tl for this so it's extremely clear it's
the same condition in both?
Either way: Reviewed-by: Daniel Vetter
> + mutex_lock(&drm_global_mutex);
> +
> retcode = drm_ioctl_permit(flags, file_priv);
> if (unlikely(retcode))
> - return
On Thu, Aug 26, 2021 at 11:51:44AM +0200, Thomas Hellström wrote:
> On Thu, 2021-08-26 at 11:16 +0200, Daniel Vetter wrote:
> > On Thu, Aug 19, 2021 at 09:32:20AM +0200, Thomas Hellström wrote:
> > > On Wed, 2021-08-18 at 15:58 +0100, Matthew Auld wrote:
> > > > Th
On Thu, Aug 26, 2021 at 12:03:29PM +0200, Daniel Vetter wrote:
> On Thu, Aug 26, 2021 at 11:51:44AM +0200, Thomas Hellström wrote:
> > On Thu, 2021-08-26 at 11:16 +0200, Daniel Vetter wrote:
> > > On Thu, Aug 19, 2021 at 09:32:20AM +0200, Thomas Hellström wrote:
> > > &g
ast why a separate vm
compared to the gt->vm we have already?
Even on chips with bazillions of copy engines the plan is that we only
reserve a single one for kernel migrations, so there's not really a need
for quite this much generality I think. Maybe check with Jon Bloomfield on
this.
ich is at least
somewhat well-known from the windows side.
Also would be good to polish the commit message a bit, there's a few typos
and confusing wording.
-Daniel
>
> Christian.
>
> >
> > Thanks
> >
> > --
> >
On Thu, Aug 26, 2021 at 12:11:04PM +0200, Christian König wrote:
>
>
> Am 26.08.21 um 10:49 schrieb Daniel Vetter:
> > On Mon, Aug 23, 2021 at 01:15:20PM +0200, Thomas Hellström wrote:
> > > On Mon, 2021-08-23 at 13:05 +0200, Christian König wrote:
> > &
On Thu, Aug 26, 2021 at 07:53:58PM +0800, Desmond Cheong Zhi Xi wrote:
> On 26/8/21 5:53 pm, Daniel Vetter wrote:
> > On Thu, Aug 26, 2021 at 10:01:16AM +0800, Desmond Cheong Zhi Xi wrote:
> > > drm_master_release can be called on a drm_file without a master, which
> >
that holds a write lock, like drm_mode_create_lease_ioctl
> which eventually calls drm_master_open), we remove the DRM_MASTER flag
> and push the master_rwsem lock and permissions check into the ioctl.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond Cheong Zhi Xi
>
,9 @@ struct drm_object_properties {
> return "(unknown)"; \
> }
>
> +struct drm_mode_object *__drm_mode_object_find(struct drm_device *dev,
> + struct drm_file *file_priv,
>
st read mode we have a bug. And the right way to fix such a bug is to
grab the rwsem sufficiently high up in the callchain. That way I think we
should be able to avoid all these tedious changes to everything, including
touching i915 and vmwgfx drivers.
Or am I missing something big time?
-Daniel
>
l
> implementation for every alloc/free operation.
>
> v2: rework the commit message to make clear why we need this
>
> Signed-off-by: Christian König
> Acked-by: Huang Rui
> Reviewed-by: Daniel Vetter
> ---
> include/linux/shrinker.h | 1 +
> mm/vmscan.c
On Thu, Aug 26, 2021 at 03:27:30PM +0200, Daniel Vetter wrote:
> On Fri, Aug 20, 2021 at 02:05:27PM +0200, Christian König wrote:
> > From: Christian König
> >
> > While unplugging a device the TTM shrinker implementation
> > needs a barrier to make sure that all concu
_bit(CONTEXT_BANNED, &ce->flags);
> +}
>
> - trace_intel_context_ban(ce);
> - if (ce->ops->ban)
> - ce->ops->ban(ce, rq);
> +static inline bool intel_context_is_exiting(const struct intel_context *ce)
> +{
> + return test_bit(CONTE
On Thu, Aug 26, 2021 at 03:59:30PM +0200, Thomas Hellström wrote:
> On Thu, 2021-08-26 at 14:44 +0200, Daniel Vetter wrote:
> > On Thu, Aug 26, 2021 at 12:45:14PM +0200, Thomas Hellström wrote:
> > > Pinned contexts, like the migrate contexts need reset after resume
> > >
On Thu, Aug 26, 2021 at 04:58:06PM +0200, Christian König wrote:
> Am 26.08.21 um 15:28 schrieb Daniel Vetter:
> > On Thu, Aug 26, 2021 at 03:27:30PM +0200, Daniel Vetter wrote:
> > > On Fri, Aug 20, 2021 at 02:05:27PM +0200, Christian König wrote:
> > &
cy on memory allocations and dma fences (i915_requests).
> Requests depend on resets, thus now we have a circular dependency. To
> work around this, allocate the error capture in a nowait context.
>
> v2:
> (Daniel Vetter)
> - Use GFP_NOWAIT instead GFP_ATOMIC
>
>
On Thu, Aug 26, 2021 at 12:56:26PM +0200, Greg Kroah-Hartman wrote:
> On Thu, Aug 26, 2021 at 11:13:43AM +0200, Daniel Vetter wrote:
> > dri-devel is the main user, and somehow there's been the assumption
> > that component stuff is unmaintained.
> >
> > Referenc
On Fri, Aug 20, 2021 at 07:59:04PM +0200, Daniel Vetter wrote:
> On Fri, Aug 20, 2021 at 7:00 PM Rodrigo Vivi wrote:
> >
> > On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote:
> > > In
> > >
> > > commit 8e02cceb1f1f4f254625e5338dd997ff61ab40
repping this on radeon and it looks horrible.
atomic_t is unordered in linux, so whatever was built there for radeon
does not wokr like a lock. It's missing all the barriers afiui. Good
riddance at least for amdgpu.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_dev
On Wed, Feb 03, 2021 at 04:40:38PM +0100, Christian König wrote:
> Am 03.02.21 um 16:29 schrieb Daniel Vetter:
> > Recently there was a fairly long thread about recoreable hardware page
> > faults, how they can deadlock, and what to do about that.
> >
> > While the
can't directly use the gpu buffers. If we can track
directly in the gpu buffers, maybe even as some kind of overlay over the
vma, we could avoid that copy.
Otoh no one cares about fbcon performance, so *shrug*.
Cheers, Daniel
> ---
> v2: Delete local variable de
701 - 800 of 26156 matches
Mail list logo
