On Fri, Oct 2, 2020 at 8:05 PM Daniel Vetter wrote:
>
> On Tue, Sep 29, 2020 at 05:14:36PM +0200, Thomas Zimmermann wrote:
> > At least sparc64 requires I/O-specific access to framebuffers. This
> > patch updates the fbdev console accordingly.
> >
> >
On Tue, Sep 29, 2020 at 05:14:37PM +0200, Thomas Zimmermann wrote:
> Instances of struct dma_buf_map should be useful throughout DRM's
> memory management code. Furthermore, several drivers can now use
> generic fbdev emulation.
>
> Signed-off-by: Thomas Zimmermann
Acked-by
On Thu, Oct 22, 2020 at 10:37:56AM +0200, Thomas Zimmermann wrote:
> Hi
>
> On 22.10.20 10:05, Daniel Vetter wrote:
> > On Tue, Oct 20, 2020 at 02:20:46PM +0200, Thomas Zimmermann wrote:
> >> At least sparc64 requires I/O-specific access to framebuffers. This
> >>
_vmap() receive a copy of the value in
> the call's supplied arguments. It can be accessed and modified with
> dma_buf_map interfaces.
>
> Signed-off-by: Thomas Zimmermann
> Reviewed-by: Daniel Vetter
> Tested-by: Sam Ravnborg
> ---
>
dependencies on the fbdev module. Some of the
> +helpers could further benefit from using struct dma_buf_map instead of
> +raw pointers.
> +
> +Contact: Thomas Zimmermann , Daniel Vetter
> +
> +Level: Advanced
> +
> +
> drm_framebuffer_funcs and drm_mode_config_funcs.f
(everyone else
is way too much).
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: Christian König
Cc: Eric Anholt
Cc: Maxime Ripard
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
(everyone else
is way too much).
v2: Fix one misplaced const static, should be static const (0day)
Cc: kernel test robot
Acked-by: Maxime Ripard
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex
On Thu, Oct 22, 2020 at 11:18 AM Thomas Zimmermann wrote:
>
> Hi
>
> On 22.10.20 10:49, Daniel Vetter wrote:
> > On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote:
> >> Kernel DRM clients now store their framebuffer address in an instance
> >&
On Tue, Oct 27, 2020 at 01:17:23PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> Use the helper that checks for overflows internally instead of manually
> calculating the size of the new array.
>
> Signed-off-by: Bartosz Golaszewski
Acked-by: Daniel Vette
On Sun, Oct 25, 2020 at 11:23 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Fri, Oct 23, 2020 at 06:04:44PM +0200, Daniel Vetter wrote:
> > Only the following drivers aren't converted:
> > - amdgpu, because of the driver_feature mangling due to virt support
> > -
On Mon, Oct 26, 2020 at 9:43 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 23.10.20 um 14:28 schrieb Daniel Vetter:
> > Only the following drivers aren't converted:
> > - amdgpu, because of the driver_feature mangling due to virt support
> > - nouveau, becau
bo->hw_res_handle,
> plane->state->crtc_w, plane->state->crtc_h,
> @@ -178,6 +179,7 @@ static void virtio_gpu_primary_plane_update(struct
> drm_plane *plane,
> plane->state->src_h >> 16,
>
ga ports any more to avoid that happening.
>
> Signed-off-by: Gerd Hoffmann
Does what it says on the label.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/qx
Exactly matches the one in the helpers.
This avoids me having to roll out dma-fence critical section
annotations to this copy.
Signed-off-by: Daniel Vetter
Cc: David Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
---
drivers/gpu/drm/virtio/virtgpu_display.c | 20
On Thu, Jul 09, 2020 at 04:05:31PM +0200, Sam Ravnborg wrote:
> On Thu, Jul 09, 2020 at 02:33:39PM +0200, Daniel Vetter wrote:
> > Exactly matches the one in the helpers.
> >
> > This avoids me having to roll out dma-fence critical section
> > annotations to thi
ude/drm/drm_gem_shmem_helper.h
> index 434328d8a0d9..3f59bdf749aa 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -114,7 +114,9 @@ void drm_gem_shmem_put_pages(struct drm_gem_shmem_object
> *shmem);
> int drm_gem_shmem_pin(stru
nmap operations in VRAM helpers are therefore unused
> and can be removed.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_gem_vram_helper.c | 98 ---
> include/drm/drm_gem_vram_helper.h | 2 -
> 2 files
On Mon, Jan 11, 2021 at 05:53:41PM +0100, Daniel Vetter wrote:
> On Fri, Jan 08, 2021 at 10:43:32AM +0100, Thomas Zimmermann wrote:
> > Damage handling in mgag200 requires a short-term mapping of the source
> > BO. Use drm_gem_shmem_vmap_local().
> >
> > Signe
on't we
vmap/vunmap these in prepare/cleanup_fb? Generally we'd want a long-term
vmap here to make sure this all works nicely.
Since it's nothing new, on this patch:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/tiny/cirrus.c | 10 --
> 1 file changed, 8 insertions(+), 2 d
.
-Daniel
> vunmap:
> - drm_gem_shmem_vunmap(fb->obj[0], );
> + drm_gem_shmem_vunmap_local(fb->obj[0], );
> put_fb:
> drm_framebuffer_put(fb);
> gm12u320->fb_update.fb = NULL;
> --
> 2.29.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Fri, Jan 08, 2021 at 10:43:32AM +0100, Thomas Zimmermann wrote:
> Damage handling in mgag200 requires a short-term mapping of the source
> BO. Use drm_gem_shmem_vmap_local().
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/mgag
On Mon, Jan 11, 2021 at 06:00:42PM +0100, Daniel Vetter wrote:
> On Fri, Jan 08, 2021 at 10:43:33AM +0100, Thomas Zimmermann wrote:
> > Damage handling in cirrus requires a short-term mapping of the source
> > BO. Use drm_gem_shmem_vmap_local().
> >
> > Signed-off-by:
t drm_plane
> *plane,
> data_size = width * height * 4 + mask_size;
>
> copy_cursor_image(src, vbox->cursor_data, width, height, mask_size);
> - drm_gem_vram_vunmap(gbo, );
> + drm_gem_vram_vunmap_local(gbo, );
> + dma_resv_unlock(obj->resv)
On Tue, Jan 12, 2021 at 08:54:02AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.21 um 18:06 schrieb Daniel Vetter:
> > On Fri, Jan 08, 2021 at 10:43:38AM +0100, Thomas Zimmermann wrote:
> > > Cursor updates in vboxvideo require a short-term mapping of
On Tue, Jan 12, 2021 at 02:11:24PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.21 um 17:50 schrieb Daniel Vetter:
> > On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote:
> > > Implementations of the vmap/vunmap GEM callbacks may perform pinning
> &g
On Thu, Jan 7, 2021 at 11:28 AM Thomas Zimmermann wrote:
>
> Hi Daniel
>
> Am 11.12.20 um 10:50 schrieb Daniel Vetter:
> [...]
> >> +/**
> >> + * drm_gem_shmem_vmap_local - Create a virtual mapping for a shmem GEM
> >> object
> >> + * @shmem:
On Thu, Dec 03, 2020 at 03:06:20AM +, Zack Rusin wrote:
>
>
> > On Dec 2, 2020, at 11:03, Daniel Vetter wrote:
> >
> > On Wed, Dec 2, 2020 at 4:37 PM Zack Rusin wrote:
> >>
> >>
> >>
> >>> On Dec 2, 2020, at 09:27, Thomas
you're OK with that, I'd merge the vmwgfx patch through
> > drm-misc-next as well.
>
> Sounds good. I’ll make sure to rebase our latest patch set on top of it when
> it’s in. Thanks!
btw if you want to avoid multi-tree coordination headaches, we can
also manage vmwgfx in
5e6daa1c982f..1281f26de494 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -151,6 +151,26 @@ struct drm_gem_object_funcs {
>*/
> void (*vunmap)(struct drm_gem_object *obj, struct dma_buf_map *map);
>
> + /**
> + * @vm
vc4_bo *bo = to_vc4_bo(obj);
> +
> + if (bo->validated_shader) {
This freaks me out. It should be impossible to export a validated shader
as a dma-buf, and indeed the check exists already.
All the wrapper functions here are imo pointless. Either we should remove
them, or replace the i
cal.
^^established
> + *
> + * This callback is optional.
> + */
> + void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> };
>
> /**
> @@ -506,4 +538,6 @@ int
On Wed, Dec 09, 2020 at 03:25:20PM +0100, Thomas Zimmermann wrote:
> Vmapping the cursor source BO contains an implicit pin operation,
> so there's no need to do this manually.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ast
ret = mutex_lock_interruptible(>vmap_lock);
This bites. You need to check for shmem->import_attach and call
dma_buf_vmap_local directly here before you take any shmem helper locks.
Real fix would be to replace both vmap_lock and pages_lock with dma_resv
lock, but that's more work.
ap_local() with the returned address to
> unmap and
> + * unpin the GEM VRAM object.
> + *
> + * The function is called with the BO's reservation object locked. For
> short-term
> + * mappings, callers must hold the lock until after unmapping the buffer. For
"the lock" is
On Fri, Dec 11, 2020 at 10:40:00AM +0100, Daniel Vetter wrote:
> On Wed, Dec 09, 2020 at 03:25:24PM +0100, Thomas Zimmermann wrote:
> > Implementations of the vmap/vunmap GEM callbacks may perform pinning
> > of the BO and may acquire the associated reservation object's lock.
> &
in commit description
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Christian König
Acked-by: Daniel Vetter
Now there's a pretty big issue here though: We can't take dma_resv_lock in
commit_tail, because of possible deadlocks on at least gpus that do real
async rendering b
On Fri, Dec 11, 2020 at 11:49:48AM +0100, Thomas Zimmermann wrote:
>
>
> Am 11.12.20 um 11:18 schrieb Daniel Vetter:
> > On Wed, Dec 09, 2020 at 03:25:21PM +0100, Thomas Zimmermann wrote:
> > > The HW cursor's BO used to be mapped permanently into the kernel's
> &g
s a virtual mapping that wa sestablished by @vmap_local.
> + *
> + * This callback is optional.
> + */
> + void (*vunmap_local)(struct dma_buf *dmabuf, struct dma_buf_map *map);
> };
>
> /**
> @@ -506,4 +538,6 @@ int dma_buf_mmap(struct dma_buf *, stru
On Fri, Dec 11, 2020 at 11:16:25AM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.12.20 um 11:01 schrieb Daniel Vetter:
> > On Wed, Dec 09, 2020 at 03:25:27PM +0100, Thomas Zimmermann wrote:
> > > Fbdev emulation has to lock the BO into place while flushing the shadow
&g
ease
delete. That will also make it clearer in the diff what's going on and
that it makes sense to have the client and fb-helper part in one patch.
With that: Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_client.c| 91 +
>
On Thu, Oct 29, 2020 at 02:33:47PM +0100, Daniel Vetter wrote:
> These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
> emulation code").
>
> v2: Somehow these structs provided the struct qxl_device pre-decl,
> reorder the header to not anger compi
These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
emulation code").
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_drv.h | 14 ---
These are leftovers from 13aff184ed9f ("drm/qxl: remove dead qxl fbdev
emulation code").
v2: Somehow these structs provided the struct qxl_device pre-decl,
reorder the header to not anger compilers.
Acked-by: Gerd Hoffmann
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Ho
Cc: kernel test robot
Acked-by: Maxime Ripard
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc: Christian König
Cc: Eric Anholt
Cc: Maxime Ripard
Cc: Ben Skeggs
pens, this might be the only thing that
manages to get the oops to the user.
Unless someone really starts caring about fbcon acceleration I really
wouldn't bother. Ok maybe it also matters for fbdev, but the problem is
that the page fault intercepting alone is already expensive, so
message (Sam)
Acked-by: Sam Ravnborg
Cc: kernel test robot
Acked-by: Maxime Ripard
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualization@lists.linux-foundation.org
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc
full use cases on Android's closed stacks. And it is uapi.
Tech debt isn't measured in lines of code, but in how expensive it's going
to be to fix up the mess in the future. uapi is expensive no matter how
few lines are used to implement it.
So yeah this needs to be properly thought out,
them. Setting it
to 0 kinda defeats the warning.
-Daniel
>
> Not calling ttm_bo_unpin() makes ttm_bo_release() throw
> a WARN() because of the pin.
>
> Clearing pin_count (which is how ttm fixes things up
> in the error path) wor
On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 12:41 AM Yiwei Zhang wrote:
> > >
> > > On the success of virtio_gpu_object_create, add size of newly allocated
On Wed, Jan 20, 2021 at 10:51 AM Yiwei Zhang wrote:
>
> On Wed, Jan 20, 2021 at 1:11 AM Daniel Vetter wrote:
> >
> > On Tue, Jan 19, 2021 at 11:08:12AM -0800, Yiwei Zhang wrote:
> > > On Mon, Jan 18, 2021 at 11:03 PM Daniel Vetter wrote:
> > > >
> &g
md_unref_resource(vgdev, bo);
> virtio_gpu_notify(vgdev);
> /* completion handler calls virtio_gpu_cleanup_object() */
> @@ -265,6 +283,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device
> *vgdev,
>
On Wed, Jan 27, 2021 at 01:08:05PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 11.01.21 um 17:50 schrieb Daniel Vetter:
> > On Fri, Jan 08, 2021 at 10:43:31AM +0100, Thomas Zimmermann wrote:
> > > Implementations of the vmap/vunmap GEM callbacks may perform pinning
> &g
int qxl_release_bo_alloc(struct qxl_device *qdev,
> @@ -344,6 +345,7 @@ int qxl_alloc_release_reserved(struct qxl_device *qdev,
> unsigned long size,
> *rbo = NULL;
> return idr_ret;
> }
> + atomic_inc(>release_count);
>
>
le_display_pipe *pipe,
> + struct drm_plane_state
> *plane_state);
> +
> +/**
> + * DRM_GEM_SHMEM_SIMPLE_DISPLAY_PIPE_SHADOW_PLANE_FUNCS -
> + * Initializes struct drm_simple_display_pipe_funcs for SHMEM shadow planes
> + *
>
On Wed, Feb 3, 2021 at 3:26 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 03.02.21 um 15:01 schrieb Daniel Vetter:
> > On Wed, Feb 03, 2021 at 02:10:42PM +0100, Thomas Zimmermann wrote:
> >> Several drivers use GEM SHMEM buffer objects as shadow buffers for
> >>
> Signed-off-by: Thomas Zimmermann
Really nice! On the series:
Acked-by: Daniel Vetter
I think I've found one missing static below.
Cheers, Daniel
> ---
> MAINTAINERS | 2 +-
> drivers/gpu/drm/Kconfig | 2 -
> drivers/gpu/drm/Makefile
On Mon, Apr 26, 2021 at 02:18:05PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.04.21 um 10:46 schrieb Daniel Vetter:
> > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote:
> > > Hi Thomas,
> > >
> > > On Fri, Apr 16, 2021 a
he host side (like displays I guess?
or maybe video encode if this is for cloug gaming?), then using virtio-gpu
in render mode should also allow you to pass the dma_fence back
Which we'll need too, not just the dma-buf.
So at a first guess I'd say "render-only virtio-gpu mode" sounds like
s
buf(struct virtio_vdmabuf_info *info,
> + struct virtio_vdmabuf_buf *new)
> +{
> + hash_add(info->buf_list, >node, new->buf_id.id);
> + return 0;
> +}
> +
> +/* comparing two vdmabuf IDs */
> +static inline bool
> +is_same_buf(virtio_vdmabuf_bu
On Fri, Apr 09, 2021 at 09:54:03AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 08.04.21 um 11:48 schrieb Daniel Vetter:
> > On Thu, Mar 18, 2021 at 11:29:15AM +0100, Thomas Zimmermann wrote:
> > > Platform devices might operate on firmware framebuffers, such as VESA or
&g
On Fri, Apr 09, 2021 at 09:06:56AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 08.04.21 um 11:48 schrieb Daniel Vetter:
> >
> > Maybe just me, but to avoid overstretching the attention spawn of doc
> > readers I'd avoid this example here. And maybe make the recommendat
On Thu, Apr 15, 2021 at 08:56:20AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 09.04.21 um 11:22 schrieb Daniel Vetter:
> > > Is it that easy? simepldrm's detach function has code to synchronize with
> > > concurrent hotplug removals. If we can use drm_dev_unp
On Thu, Apr 15, 2021 at 09:12:14PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 15.04.21 um 14:57 schrieb Daniel Vetter:
> > On Thu, Apr 15, 2021 at 08:56:20AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 09.04.21 um 11:22 schrieb Daniel Vett
here's not much
userspace for it. In other words, it would work as well as current offb
would, but that's at least that.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Tue, Apr 20, 2021 at 11:16:09AM +0200, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> On Tue, Apr 20, 2021 at 10:46 AM Daniel Vetter wrote:
> > On Mon, Apr 19, 2021 at 10:00:56AM +0200, Geert Uytterhoeven wrote:
> > > On Fri, Apr 16, 2021 at 11:00 AM Thomas
bool deferred_setup;
>
> + /**
> +* @no_dpms_blank:
> +*
> +* A flag indicating that the driver doesn't support blanking.
> + * Then fbcon core code falls back to its generic handler.
> +*/
> + bool no_dpms_blank;
> +
>
re 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.
Acked-by: D
+#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 the
-over, so on
> >>>> many Laptops running say Fedora workstation the fbcon code is actually
> >>>> unused
> >>>> until the user manually switches to another virtual-console to log in in
> >>>> text-mode:
> >>>>
> >>&
clude/drm/drm_gem_ttm_helper.h | 5 ++-
> include/drm/drm_gem_vram_helper.h | 7 +---
> 12 files changed, 45 insertions(+), 103 deletions(-)
>
> --
> 2.30.2
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_
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
rd drm_poll (and is meant to work perfectly fine
with standard drm_poll).
So if it's buggy on top of questionable I think revert might be the right
choice irrespective of whether there's some fixes in-flight.
So if you end up pushing that revert:
References:
https://lore.kernel.org/dri-dev
.
It's ofc not going to be perfect, but better than nothing.
With that, on the series:
Acked-by: Daniel Vetter
But maybe wait for some more acks/reviews from driver folks.
-Daniel
> */
>
> static const struct drm_gem_object_funcs drm_gem_shmem_funcs = {
> - .free = drm_gem_shmem_f
iewed-by: Muchun Song
On the 5 drm patches (I counted 2 ttm and 3 drivers) for merging through
some other tree (since I'm assuming that's how this will land):
Acked-by: Daniel Vetter
> ---
> drivers/gpu/drm/ttm/ttm_pool.c | 15 +++
> include/linux/shrinker.h |
d long (*purge)(struct drm_gem_object *obj);
> };
>
> /**
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index d0a57853c188..455254f131f6 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.
On Thu, May 12, 2022 at 10:04:53PM +0300, Dmitry Osipenko wrote:
> On 5/12/22 20:04, Daniel Vetter wrote:
> > On Thu, 12 May 2022 at 13:36, Dmitry Osipenko
> > wrote:
> >>
> >> On 5/11/22 22:09, Daniel Vetter wrote:
> >>> On Wed, May 11, 20
On Thu, 12 May 2022 at 13:36, Dmitry Osipenko
wrote:
>
> On 5/11/22 22:09, Daniel Vetter wrote:
> > On Wed, May 11, 2022 at 07:06:18PM +0300, Dmitry Osipenko wrote:
> >> On 5/11/22 16:09, Daniel Vetter wrote:
> >>>>>>> I'd like to ask you
On Thu, May 12, 2022 at 09:29:35AM +0200, Christian König wrote:
> Am 11.05.22 um 21:05 schrieb Daniel Vetter:
> > [SNIP]
> > > > > It's unclear to me which driver may ever want to do the mapping under
> > > > > the dma_resv_lock. But if we will ever have
t; are also pinned on attachment, hence maybe this lock is indeed
> > unnecessary.. I'll re-check it.
>
> I'm not worried about contention with export/import/etc, but
> contention between multiple threads hitting the shrinker in parallel.
> I guess since you are using trylock,
t you are avoiding evicting and immediately swapping back in, in
> a rare case, at the cost of serializing multiple threads trying to
> reclaim pages in parallel.
Yeah this sounds really bad. Plus this is a per-device lock, and doing
those with trylock means the shrinker will fail to find shrinkable m
t; +* 1 is not-needed/can-be-purged
> * A negative value is the object is purged.
> -* Positive values are driver specific and not used by the helpers.
> */
> int madv;
>
> @@ -91,6 +102,39 @@ struct drm_gem_shmem_object {
> * @map_
On Sun, 5 Jun 2022 at 20:32, Rob Clark wrote:
>
> On Sun, Jun 5, 2022 at 9:47 AM Daniel Vetter wrote:
> >
> > On Fri, 27 May 2022 at 01:55, Dmitry Osipenko
> > wrote:
> > >
> > > Introduce a common DRM SHMEM shrinker framework that allows to reduc
rm_gem_shmem_object *shmem);
>
> -int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem);
> void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem);
> int drm_gem_shmem_pin(struct drm_gem_shmem_object *shmem);
> void drm_
On Wed, Apr 13, 2022 at 06:12:59PM +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Instead of relying on it getting pulled in indirectly.
>
> Signed-off-by: Michel Dänzer
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/tiny/bochs.c | 1 +
> 1 file changed,
gt; >> and Lima drivers use vmap() and they do it in the slow code paths,
> >> hence there was no practical justification for the usage of separate
> >> lock in the vmap().
> >>
> >> Suggested-by: Daniel Vetter
> >> Signed-off-by: Dmitry Osipenko
&g
m/sched and fences are installed.
But I think a lot of current shmem users just pin as part of execbuf, so
this won't work quite so well right out of the box.
Anyway with that design I don't think there should ever be a need to
disable shrinking.
> >> +
> >> + /**
>
On Thu, Apr 28, 2022 at 09:20:15PM +0300, Dmitry Osipenko wrote:
> 27.04.2022 18:03, Daniel Vetter wrote:
> >> ...
> >>>> @@ -172,6 +172,41 @@ struct drm_gem_object_funcs {
> >>>> * This is optional but necessary for mmap support.
On Thu, Apr 28, 2022 at 09:31:00PM +0300, Dmitry Osipenko wrote:
> Hello Daniel,
>
> 27.04.2022 17:50, Daniel Vetter пишет:
> > On Mon, Apr 18, 2022 at 10:18:54PM +0300, Dmitry Osipenko wrote:
> >> Hello,
> >>
> >> On 4/18/22 21:38, Thomas Zimmermann wro
desktop.org
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 9a9c29b1d3e1..9a64fa4c7530 100644
On Tue, May 10, 2022 at 04:39:53PM +0300, Dmitry Osipenko wrote:
> On 5/9/22 16:42, Daniel Vetter wrote:
> > On Fri, May 06, 2022 at 01:49:12AM +0300, Dmitry Osipenko wrote:
> >> On 5/5/22 11:12, Daniel Vetter wrote:
> >>> On Wed, May 04, 2022 at 06:56:09P
On Tue, May 10, 2022 at 04:47:52PM +0300, Dmitry Osipenko wrote:
> On 5/9/22 16:49, Daniel Vetter wrote:
> > On Fri, May 06, 2022 at 03:10:43AM +0300, Dmitry Osipenko wrote:
> >> On 5/5/22 11:34, Thomas Zimmermann wrote:
> >>> Hi
> >>>
> >
On Wed, May 11, 2022 at 04:24:28PM +0200, Christian König wrote:
> Am 11.05.22 um 15:00 schrieb Daniel Vetter:
> > On Tue, May 10, 2022 at 04:39:53PM +0300, Dmitry Osipenko wrote:
> > > [SNIP]
> > > Since vmapping implies implicit pinning, we can't use a separate lock
On Wed, May 11, 2022 at 06:14:00PM +0300, Dmitry Osipenko wrote:
> On 5/11/22 17:24, Christian König wrote:
> > Am 11.05.22 um 15:00 schrieb Daniel Vetter:
> >> On Tue, May 10, 2022 at 04:39:53PM +0300, Dmitry Osipenko wrote:
> >>> [SNIP]
> >>> Since vmapp
ort requires page fault handler to be aware of the
> evicted pages, what should we do about it? The page fault handling is a
> part of memory management, hence to me drm-shmem is already kinda a MM.
Hm I still don't get that part, why does that also not go through the
shmem helpers? I'm s
On Fri, May 06, 2022 at 01:49:12AM +0300, Dmitry Osipenko wrote:
> On 5/5/22 11:12, Daniel Vetter wrote:
> > On Wed, May 04, 2022 at 06:56:09PM +0300, Dmitry Osipenko wrote:
> >> On 5/4/22 11:21, Daniel Vetter wrote:
> >> ...
> >>>>> - Maybe also
On Wed, May 04, 2022 at 06:56:09PM +0300, Dmitry Osipenko wrote:
> On 5/4/22 11:21, Daniel Vetter wrote:
> ...
> >>> - Maybe also do what you suggest and keep a separate lock for this, but
> >>> the fundamental issue is that this doesn't really work - if you s
system.
> > +*
> > +* Returns the number of pages that have been freed by purging the GEM
> > object.
> > +*
> > +* This callback is used by the GEM shrinker.
> > +*/
> > + unsigned long (*purge)(struct drm_gem_object *ob
On Wed, May 11, 2022 at 06:40:32PM +0300, Dmitry Osipenko wrote:
> On 5/11/22 18:29, Daniel Vetter wrote:
> > On Wed, May 11, 2022 at 06:14:00PM +0300, Dmitry Osipenko wrote:
> >> On 5/11/22 17:24, Christian König wrote:
> >>> Am 11.05.22 um 15:00 schrieb Daniel Vette
On Wed, May 11, 2022 at 07:06:18PM +0300, Dmitry Osipenko wrote:
> On 5/11/22 16:09, Daniel Vetter wrote:
> >>>>> I'd like to ask you to reduce the scope of the patchset and build the
> >>>>> shrinker only for virtio-gpu. I know that I first sugges
DMA_ATTR_FORCE_CONTIGUOUS;
> > struct ttm_pool_dma *dma;
> > + unsigned int i;
> > void *vaddr;
> > #ifdef CONFIG_X86
> > @@ -142,6 +163,8 @@ static void ttm_pool_free_page(struct ttm_pool *pool,
> > enum ttm_caching caching,
> > if (caching != ttm_cached && !PageHighMem(p))
> > set_pages_wb(p, 1 << order);
> > #endif
> > + for (i = 1; i < 1 << order; i++)
> > + page_ref_dec(p + i);
> > if (!pool || !pool->use_dma_alloc) {
> > __free_pages(p, order);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
301 - 400 of 412 matches
Mail list logo
