On Fri, Jul 23, 2021 at 05:43:35PM -0500, Bjorn Helgaas wrote:
> On Fri, Jul 23, 2021 at 10:27:08AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 23, 2021 at 06:51:59AM +0100, Christoph Hellwig wrote:
> > > On Thu, Jul 22, 2021 at 04:29:11PM -0500, Bjorn Helgaas wrote:
> >
On Fri, Jul 23, 2021 at 07:22:46PM +0200, Sam Ravnborg wrote:
> On Fri, Jul 23, 2021 at 10:57:56AM +0200, Daniel Vetter wrote:
> > On Fri, Jul 23, 2021 at 11:12:49AM +0800, lichenyang wrote:
> > > From: Chenyang Li
> > >
> > > This patch adds an initial
, add log messages to
> drm_framebuffer_remove (Daniel)
>
> Signed-off-by: Simon Ser
> Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_framebuffer.c | 22 +-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/driver
On Tue, Jul 27, 2021 at 11:09:13AM +0300, Pekka Paalanen wrote:
> On Mon, 26 Jul 2021 07:50:32 +
> Simon Ser wrote:
>
> > Since there's no struct to attach the docs to, document the IOCTL
> > definition.
> >
> > Signed-off-by: Simon Ser
> > Cc: D
the mesa/media-driver patches exist somewhere? Afaiui this isn't
very useful without those bits in place too.
-Daniel
>
>
> John Harrison (1):
> drm/i915/guc: Add fetch of hwconfig table
>
> Rodrigo Vivi (1):
> drm/i915/uapi: Add query for hwconfig table
&
fers
> support")
> Reported-by: kernel test robot
> Signed-off-by: Javier Martinez Canillas
Whacked onto drm-next so we're welcome again in linux-next.
-Daniel
> ---
>
> Changes in v2:
> - Add a Fixes tag to the changelog.
>
> drivers/firmware/Kconfig | 2
(because atm drm-next isn't in
linux-next because of this).
drm-next also has -rc3 backmerge for the nouveau fix, so I think a good
time to backmerge the entire pile into drm-misc-next?
-Daniel
>
>
> ... and maybe a few more of the CCs below
>
> Cc: Javier Martinez Canill
On Fri, Jul 23, 2021 at 10:34:56AM +0200, Daniel Vetter wrote:
> There's two stages of manual upload/invalidate displays:
> - just handling dirtyfb and uploading the entire fb all the time
> - looking at damage clips
>
> In the latter case we support it through fbdev emulat
Adding a few more people to this bikeshed.
On Mon, Jul 12, 2021 at 10:02 PM Daniel Vetter wrote:
> @@ -349,6 +367,13 @@ int drm_sched_job_init(struct drm_sched_job *job,
>struct drm_sched_entity *entity,
>void *owner);
> void drm_s
On Mon, Jul 26, 2021 at 10:51:26AM -0500, Jason Ekstrand wrote:
> On Fri, Jul 23, 2021 at 2:29 PM Daniel Vetter wrote:
> >
> > No longer used.
> >
> > Cc: Jason Ekstrand
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Jason Ekstrand
>
> But
misc-fixes, which makes sense, not in drm-misc-next like I assumed
at first drm-misc means.
-Daniel
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstr
table this now becomes trivial.
Reviewed-by: Jason Ekstrand
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f282064
0day)
Reviewed-by: Jason Ekstrand
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_buddy.c | 25 -
drivers/gpu/drm/i915/i915_buddy.h | 3 ++-
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_pci.c | 2 ++
4 fi
0day)
Reviewed-by: Jason Ekstrand
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_active.c | 31 ++---
drivers/gpu/drm/i915/i915_active.h | 3 +++
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_globals.h | 1 -
y)
Reviewed-by: Jason Ekstrand
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gt/intel_context.c | 25 -
drivers/gpu/drm/i915/gt/intel_context.h | 3 +++
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_globals.h | 1
ic (Jason, 0day)
Reviewed-by: Jason Ekstrand
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 26 +++---
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +++
drivers/gpu/drm/i915/i915_globals.c| 1 -
drivers/gpu/drm/i915
v2: Make slab static (Jason, 0day)
Reviewed-by: Jason Ekstrand
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/i915_request.c | 47 -
drive
y)
Reviewed-by: Jason Ekstrand
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 25 +++--
drivers/gpu/drm/i915/gem/i915_gem_context.h | 3 +++
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_globals
ties.
v2: Make slab static (Jason, 0day)
Reviewed-by: Jason Ekstrand
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_globals.c | 2 --
drivers/gpu/drm/i915/i915_globals.h | 2 --
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/i915_s
No longer used.
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile | 1 -
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 1 -
drivers/gpu/drm/i915/i915_globals.c | 53 ---
drivers/gpu/drm/i915/i915_globals.h | 25
rv.h include in i915_globals otherwise there's
nothing anymore that pulls in GEM_BUG_ON.
v2: Make slab static (Jason, 0day)
Reviewed-by: Jason Ekstrand
Cc: Jason Ekstrand
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_globals.c | 3 +--
drivers/gpu/drm/i915/i915_globals.h | 3 ---
i915_pci.c.
The downside is that have to drop the error path check Jason added to
catch when we set up the pci driver too early. I think that risk is
acceptable for this pretty nice include.
Cc: Jason Ekstrand
Cc: Tvrtko Ursulin
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/Makefile | 1
lessor that it releases upon
> + * being destroyed in drm_lease_destroy().
> + *
> + * See also the :ref:`section on display resource leasing
> + * `.
>*/
> -
> struct drm_master *lessor;
> +
> + /**
> + * @lessee_id:
> +
n use the
> drm_file.master_lookup_lock that sits at the bottom of the lock
> hierarchy.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond Cheong Zhi Xi
> Reviewed-by: Daniel Vetter
Applied to drm-misc-next, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_auth.c | 9 +---
Harrison
Please also update the comment in the header for i915_request. That is
back from 2016 or so, when the context was actually fully refcounted
...
It would also be good to record a bit more the history here and all
the back&forth (and maybe why).
Don't ask why I've stumbled
On Wed, Jul 28, 2021 at 1:29 PM Christian König
wrote:
> Am 27.07.21 um 13:09 schrieb Daniel Vetter:
> > Adding a few more people to this bikeshed.
> >
> > On Mon, Jul 12, 2021 at 10:02 PM Daniel Vetter
> > wrote:
> >
> >> @@ -349,6 +367,13 @@ int dr
On Tue, Jul 27, 2021 at 04:37:22PM +0200, Peter Zijlstra wrote:
> On Thu, Jul 22, 2021 at 12:38:10PM +0200, Daniel Vetter wrote:
> > On Thu, Jul 22, 2021 at 05:29:27PM +0800, Desmond Cheong Zhi Xi wrote:
> > > Inside drm_is_current_master, using the outer drm_device.master_mute
e dma_fence structure intentionally so that it is only 64
> > >>>>> bytes.
> > >>>> Hmm, then I guess you wouldn't be a fan of also adding an hrtimer?
> > >>>>
> > >>>> We could push the ktime_t (and timer) down into the der
t; >>> hardware you are completely killing of such features.
> > >>>
> > >>> For composing use cases that makes sense, but certainly not for full
> > >>> screen applications as far as I can see.
> > >> Even for fullscreen, the curren
he lifetime of lessors and leases.
>
> 3. Add an overview DOC: section in drm-uapi.rst that defines the
> terminology for drm leasing, and explains how leases work and why
> they're used.
>
> Signed-off-by: Desmond Cheong Zhi Xi
> Reviewed-by: Daniel Vetter
Pushed to
On Wed, Jul 28, 2021 at 01:52:42PM -0700, Rob Clark wrote:
> Hi Dave & Daniel,
>
> An early pull for v5.15 (there'll be more coming in a week or two),
> consisting of the drm/scheduler conversion and a couple other small
> series that one was based one. Mostly sendi
ut can you perhaps keep that part?
Other pieces lgtm.
-Daniel
> ---
> drivers/dma-buf/dma-fence.c | 44 +--
> drivers/dma-buf/st-dma-fence.c| 12 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 10 +-
> drivers/gpu/drm/radeon/
the kernel if it's ever used?
Also for testing we use vgem now, which enforces a timeout.
-Daniel
> ---
> drivers/dma-buf/Kconfig | 13 --
> drivers/dma-buf/Makefile | 1 -
> drivers/dma-buf/sw_sync.c| 412 ---
> drivers/dma
On Thu, Jul 29, 2021 at 09:03:28AM +0200, Christian König wrote:
> Entirely unused.
>
> Signed-off-by: Christian König
Acked-by: Daniel Vetter
> ---
> drivers/dma-buf/Makefile | 2 +-
> drivers/dma-buf/seqno-fence.c | 71 --
> include/linux/
idn't happen in 5 years it aint
suddenly happening in the next few, and the abstraction layer should be
sunset.
Also yes structuring it more as a helper layer with some
unions/subclassing than full blown backend abstractor layer would be a
good idea too I guess (it usually is the right thing to do).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jul 29, 2021 at 10:17:43AM +0200, Michel Dänzer wrote:
> On 2021-07-29 9:09 a.m., Daniel Vetter wrote:
> > On Wed, Jul 28, 2021 at 08:34:13AM -0700, Rob Clark wrote:
> >> On Wed, Jul 28, 2021 at 6:24 AM Michel Dänzer wrote:
> >>> On 2021-07-28 3:13 p.m., Ch
On Thu, Jul 29, 2021 at 10:38 AM Christian König
wrote:
> Am 29.07.21 um 09:23 schrieb Daniel Vetter:
> > On Thu, Jul 29, 2021 at 09:03:30AM +0200, Christian König wrote:
> >> As we now knew controlling dma_fence synchronization from userspace is
> >> extremely dangerou
On Thu, Jul 29, 2021 at 12:21 PM Christian König
wrote:
> Am 29.07.21 um 11:03 schrieb Daniel Vetter:
> > On Thu, Jul 29, 2021 at 10:38 AM Christian König
> > wrote:
> >> Am 29.07.21 um 09:23 schrieb Daniel Vetter:
> >>> On Thu, Jul 29, 2021 at 09:03:30AM +02
there's a need a module param for debugging,
but otherwise can't we just pick the right default?
And it very much sounds like the right default here is "enable it
unconditionally if we have iommu support".
-Daniel
> * Move to helper for easier handling of kernel build o
unsigned int depth_offset;
> > + unsigned int depth_pitch;
> >
> > - unsigned int texture_offset[MGA_NR_TEX_HEAPS];
> > - unsigned int texture_size[MGA_NR_TEX_HEAPS];
> > + unsigned int texture_offset[MGA_NR_TEX_HEAPS];
> > + unsigned int texture_size[MGA_NR_TEX_HEAPS];
> > + );
> >
> > unsigned long fb_offset;
> > unsigned long mmio_offset;
> > @@ -302,6 +317,8 @@ typedef struct drm_mga_init {
> > unsigned long buffers_offset;
> > } drm_mga_init_t;
> >
> > +#undef __struct_group
> > +
>
> Why can you use __struct_group in this uapi header, but not the
> networking one?
If there's others, maybe we can stuff the uapi __struct_group into
linux/types.h where all the other __ uapi types hang out?
Anyway mga is very dead, I don't anyone cares.
Acked-by: Daniel Vetter
I'm assuming this goes in through a topic pull from you?
I'll leave the drm/amd one to figure out between you and Alex.
-Daniel
>
> thanks,
>
> greg k-h
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
On Thu, Jul 29, 2021 at 12:37:32PM +0300, Pekka Paalanen wrote:
> On Thu, 29 Jul 2021 11:03:36 +0200
> Daniel Vetter wrote:
>
> > On Thu, Jul 29, 2021 at 10:17:43AM +0200, Michel Dänzer wrote:
> > > On 2021-07-29 9:09 a.m., Daniel Vetter wrote:
> > > > On W
On Thu, Jul 29, 2021 at 2:21 PM Tvrtko Ursulin
wrote:
> On 29/07/2021 13:07, Daniel Vetter wrote:
> > On Thu, Jul 29, 2021 at 1:19 PM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Usage of Transparent Hugepages was disabled
On Thu, Jul 29, 2021 at 2:25 PM Christian König
wrote:
>
> Am 29.07.21 um 13:59 schrieb Daniel Vetter:
> > On Thu, Jul 29, 2021 at 12:21 PM Christian König
> > wrote:
> >> Am 29.07.21 um 11:03 schrieb Daniel Vetter:
> >>> On Thu, Jul 29, 2021 at 10:38 AM
On Thu, Jul 29, 2021 at 3:00 PM Pekka Paalanen wrote:
> On Thu, 29 Jul 2021 14:18:29 +0200
> Daniel Vetter wrote:
>
> > On Thu, Jul 29, 2021 at 12:37:32PM +0300, Pekka Paalanen wrote:
> > > On Thu, 29 Jul 2021 11:03:36 +0200
> > > Daniel Vetter wrote:
> >
; IOMMU off) to ~2% (same comparison but with THP on).
>
> v2:
> * Add Kconfig dependency to transparent hugepages and some help text.
> * Move to helper for easier handling of kernel build options.
>
> v3:
> * Drop Kconfig. (Daniel)
>
> References: b901bb89324a ("drm/
On Thu, Jul 29, 2021 at 5:19 PM Rob Clark wrote:
>
> On Thu, Jul 29, 2021 at 12:03 AM Daniel Vetter wrote:
> >
> > On Wed, Jul 28, 2021 at 10:58:51AM -0700, Rob Clark wrote:
> > > On Wed, Jul 28, 2021 at 10:23 AM Christian König
> > > wrote:
> > > &
() to make the new check happy.
Since there's a lot of duplicated mock code already copy-pasted into
each test I've also refactored this a bit to trim it down.
Signed-off-by: Daniel Vetter
Fixes: c7fcbf251397 ("drm/plane: check that fb_damage is set up when used")
Cc: José
* if connectors are attached and a mode is set.
I think replacing the if with "implies that" is clearer.
The other typo fixes look all good to me (but there's a lot and I kinda
got blurry-eyed, thanks for doing this). Can you pls respin with that one
change?
-Daniel
>
ant some kind of (maybe per-crtc) recommended queue
depth property so compositors know how many buffers to keep in flight.
Not sure about that.
It's a bit more work, but also a lot less hacking around infrastructure in
dubious ways.
Thoughts?
Cheers, Daniel
>
> Cc: Daniel Vett
On Fri, Jul 30, 2021 at 02:50:10PM +0200, Michel Dänzer wrote:
> On 2021-07-30 12:25 p.m., Daniel Vetter wrote:
> > On Thu, Jul 29, 2021 at 01:16:55AM -0700, Vivek Kasireddy wrote:
> >> By separating the OUT_FENCE signalling from pageflip completion allows
> >> a Gues
On Mon, Aug 02, 2021 at 06:51:33AM +, Kasireddy, Vivek wrote:
> Hi Daniel,
>
> >
> > On Thu, Jul 29, 2021 at 01:16:55AM -0700, Vivek Kasireddy wrote:
> > > By separating the OUT_FENCE signalling from pageflip completion allows
> > > a Guest compositor to
On Fri, Jul 30, 2021 at 09:27:29PM +0800, Cai Huoqing wrote:
> fix typo for drm
>
> v1->v2:
> respin with the change "iff ==> implies that"
>
> Reviewed-by: Daniel Vetter
I did not give you a Reviewed-by: tag, please dont forge them. At least
in the linux ke
fe to replace with
> strscpy(), as the destination buffer is copied to userspace with
> strscpy_pad(). However, given that this isn't in a hot path, let's avoid
> future data leaks in case someone copies the whole char array blindly.
+1 on just playing it safe.
> Signed-off-by:
.master to explain
> the use of lockdep_assert(). As suggested by Boqun Feng.
>
> Link:
> https://lore.kernel.org/lkml/20210722092929.244629-2-desmondcheon...@gmail.com/
> [1]
Can you pls also cc: this to intel-gfx so the local CI there can pick it
up and verify? Just to check we got it al
rty_enum, add ref to "Modeset Base
> Object Abstraction" (Daniel)
>
> Signed-off-by: Simon Ser
> Acked-by: Pekka Paalanen
> Cc: Daniel Vetter
> Cc: Leandro Ribeiro
Acked-by: Daniel Vetter
> ---
>
> I couldn't figure out how to linkify that ref, s
to verify.
Personally I'd say add a check to reject this, since testing this and
making sure it really works everywhere is probably a bit much on this old
hw.
-Daniel
>
> Thanks,
> Christian.
>
> >
> > Cc: Alex Deucher
> > Cc: "Christian König"
>
On Mon, Aug 02, 2021 at 10:49:37AM +0200, Michel Dänzer wrote:
> On 2021-08-02 9:59 a.m., Daniel Vetter wrote:
> > On Fri, Jul 30, 2021 at 02:50:10PM +0200, Michel Dänzer wrote:
> >> On 2021-07-30 12:25 p.m., Daniel Vetter wrote:
> >>> On Thu, Jul 29, 2021 at 01:
ms
driver flip completion. If you just have the fence then the jitter from
going through all the layers will most likely make it unusable.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
r whatever it's called)
would go from guest to host to host-compositor (over wayland protocol)
to host-side kms, and the timestamp could travel all the way back.
But yeah making this all work correctly is going to be a pile of work.
Also I have no idea how well compositors take it when a
ogether the full
history.
References to relevant commits throughout the series.
Cheers, Daniel
Daniel Vetter (9):
drm/i915: Drop code to handle set-vm races from execbuf
drm/i915: Rename i915_gem_context_get_vm_rcu to
i915_gem_context_get_eb_vm
drm/i915: Use i915_gem_context_get_eb_vm
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
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:
xt->vm or gt->vm,
which is always set.
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 Ekstran
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:
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).
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 La
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
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: Daniel Vetter
Cc: "Thomas Hellström"
Cc: Matthew Auld
Cc: Lionel Landwerlin
Cc:
ory
> options, etc...).
Matt Auld has an igt series which fixes a lot of this stuff, would be
good to do at least a Test-With run with that.
Also I'm assuming that for ADL-P we'll get this equivalent patch set
soon, and there we should be able to get real results?
-Daniel
>
> T
less confusing
diff. Also given how much headaches this code has caused in the past,
letting this soak for a bit seems justified.
Acked-by: Dave Airlie
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Joonas Lahtin
It's already removed, this just garbage collects it all.
v2: Rebase over s/GEN/GRAPHICS_VER/
v3: Also ditch eb.reloc_pool and eb.reloc_context (Maarten)
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
Cc: Chris Wilson
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Joonas Lahtinen
Cc: &q
ain valid by the time they are actually used(Tvrtko).
> > >>> - Add a small comment for the hole finding logic(Jason).
> > >>> - Move the param next to all the other params which just return true.
> > >>>
> > >>> Testcase: igt/gem_userptr_bli
On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote:
>
> On Mon, Mar 22, 2021 at 6:34 AM Christian König
> wrote:
> >
> > Hi Daniel,
> >
> > Am 22.03.21 um 10:38 schrieb Daniel Gomez:
> > > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling
> > > wro
evres functions will also kfree the allocated data,
> resulting in double free/memory corruption. Just call
> clk_hw_unregister() instead, leaving kfree() to devres code.
Doh.
Sorry for not spotting this when I wrote the patch.
Thank you for cleaning up after
drm_aperture private
> * rebase onto existing drm_aperture.h header file
> * use MIT license only for simplicity
> * documentation
>
> Signed-off-by: Thomas Zimmermann
> Tested-by: nerdopolis
Bunch of bikesheds for your considerations below, but overall lgtm.
A
> +#include
> +
> +/**
> + * drm_fb_helper_remove_conflicting_framebuffers - remove
> firmware-configured framebuffers
Annoying bikeshed, but I'd give them drm_aperture_ prefixes, for ocd
consistency. Also make them real functions, they're quite big and will
grow more in
b->cpu_addr) + TRACE_BUFFER_ENTRY_OFFSET);
Uh I build test, but always ignore the warnings :-/
-Daniel
>
> Dave.
>
> On Sat, 27 Mar 2021 at 05:16, Zhuo, Qingqing wrote:
> >
> > [AMD Public Use]
> >
> > On Thu, Feb 18, 2021 at 11:15 PM Alex Deucher wrote:
&
On Mon, Mar 29, 2021 at 10:31:01AM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 16, 2021 at 04:33:03PM +0100, Daniel Vetter wrote:
> > Both kvm (in bd2fae8da794 ("KVM: do not assume PTE is writable after
> > follow_pfn")) and vfio (in 07956b6269d3 ("vfio/type1: Use
sees no changes, other then the spinner appearing
> >>>> (note the active VT is now in graphical mode)
> >>>> 5. From here on not flickering is a userspace problem
> >>>>
> >>>> AFAICT this should work fine with simplekms too, unless it
On Fri, Mar 26, 2021 at 10:31:10AM +, Tvrtko Ursulin wrote:
>
> On 26/03/2021 09:10, Daniel Vetter wrote:
> > On Wed, Mar 24, 2021 at 12:13:28PM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > "Watchdog" aka "
of exporting
>remap_pfn_range_notrack
> - switch to plain remap_pfn_range for remap_sg as it does not use
>a pre-verified pgprot from an iomap
I'm burried under patches and stuff so no in-depth review. But from a
quick scan lgtm. On the series:
Acked-by: Daniel Vetter
I
Usually for pseudo-code I go with blockquotes (started with :: at the end
of the previous line, plus indenting), that gives you also a nice
fixed-width font and everything.
Aside from the hyperlink stuff plain English works best in the text parts.
-Daniel
>
> --Imre
>
> > >
&g
On Fri, Mar 26, 2021 at 10:35:33AM +, Simon Ser wrote:
> Reviewed-by: Simon Ser
>
> I'll push this shortly to drm-misc-next.
I also pushed the 2nd patch, seems to have been lost in the applying?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http:/
tle, do a topic branch with a common ancestor
> between drm-next and drm-misc-next, apply there, merge the topic branch
> to drm-misc-next, and let all drivers merge the topic branch as
> needed. Due to the timing, otherwise we might have to carry the
> conflicts for quite a while.
ntf
>
> Signed-off-by: Tian Tao
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/panel/panel-tpo-td043mtea1.c
> b/drivers/gpu/drm/panel/panel-tp
-866,7 +866,7 @@ static int zynqmp_dp_train(struct zynqmp_dp *dp)
> > return ret;
> >
> > zynqmp_dp_write(dp, ZYNQMP_DP_SCRAMBLING_DISABLE, 1);
> > - memset(dp->train_set, 0, 4);
> > + memset(dp->train_set, 0, sizeof(dp->train_set));
> &
On Thu, Apr 01, 2021 at 04:17:03PM +0800, Wan Jiabing wrote:
> struct drm_gem_object is declared twice. One is declared
> at 40th line. The blew one is not needed. Remove the duplicate.
>
> Signed-off-by: Wan Jiabing
Pushed to drm-misc-next, thanks for your patch.
-Daniel
> ---
r);
> extern void free_prealloced_shrinker(struct shrinker *shrinker);
> +extern void sync_shrinkers(void);
> #endif
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 562e87cbd7a1..46cd9c215d73 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -408,6 +408,16 @@ void
something like this for ttm (well
different shades of grey). i915 is going to adopt ttm, at least for
discrete.
The locking is also an utter pain, and msm seems to still live a lot in
its own land here. I think as much as possible a standard approach here
would be really good, ideally ma
On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote:
> The implementation of drm_driver.dumb_map_offset is the same for several
> TTM-based drivers. Provide a common function in GEM-TTM helpers.
Out of curiosity, why does this not fit for radeon/amdgpu?
-Daniel
>
ere was some custom limit for ttm drivers once to allow
co-existing with ums drivers, but that's never really been a thing since
forever ...
-Daniel
>
> With the GEM drivers converted, vmwgfx is the only user of
> ttm_bo_mmap() and related infrastructure. So move everything into
>
lied to drm-misc-next, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/gma500/power.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
> index 56ef88237ef6..f07641dfa5a4 100644
> --
re meaning than is actually there.
> Is it also so that passing MOD_INVALID to the explicit modifier uAPI
> (ADDFB2) is invalid argument? Do we have that documented?
We'd need to check that, currently it's an out-of-band flag in the struct.
Atm DRM_FORMAT_MOD_INVALID is entirely an i
On Thu, Apr 08, 2021 at 01:17:32PM +0200, Christian König wrote:
> Am 08.04.21 um 13:08 schrieb Daniel Vetter:
> > On Thu, Apr 01, 2021 at 03:54:13PM +0200, Christian König wrote:
> > > Switch back to using a spinlock again by moving the IOMMU unmap outside
> >
some kernel metadata passed around in private ioctls on the render
node).
Maybe for more context, what's the problem you've hit and trying to
clarify here?
-Daniel
>
> Leandro Ribeiro (2):
> drm/doc: document drm_mode_get_plane
> drm/doc: emphasize difference between pl
fig ui tends
to suck.
If you want to change this, we need automatic conflict resolution like apt
and other package managers have, with suggestions how to fix the config if
you want to enable a driver, but some of its requirements are missing. The
current approach of hiding driver symbols complete
On Thu, Apr 08, 2021 at 01:34:03PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 08.04.21 um 13:16 schrieb Daniel Vetter:
> > On Tue, Apr 06, 2021 at 10:29:38AM +0200, Thomas Zimmermann wrote:
> > > The implementation of drm_driver.dumb_map_offset is the same for several
ere also an igt patch to enforce this in the drm_syncobj testcases?
Would be really good to have that too.
-Daniel
> ---
> drivers/dma-buf/dma-fence.c | 33 -
> drivers/gpu/drm/drm_syncobj.c | 28
> include/linux/dma-
On Thu, Apr 08, 2021 at 01:38:59PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 08.04.21 um 13:19 schrieb Daniel Vetter:
> > On Tue, Apr 06, 2021 at 11:08:55AM +0200, Thomas Zimmermann wrote:
> > > Implement mmap via struct drm_gem_object_functions.mmap for amdgpu,
> &
201 - 300 of 26156 matches
Mail list logo
