On Tue, Feb 13, 2024 at 06:39:20PM +0100, Danilo Krummrich wrote:
> On 2/9/24 19:52, Daniel Vetter wrote:
> > On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote:
> > > On 2/6/24 15:03, Daniel Vetter wrote:
> > > > On Mon, Feb 05, 2024 at 11:00:04PM
On Fri, Feb 09, 2024 at 06:41:32PM +0100, Danilo Krummrich wrote:
> On 2/6/24 15:03, Daniel Vetter wrote:
> > On Mon, Feb 05, 2024 at 11:00:04PM +0100, Danilo Krummrich wrote:
> > > On 2/5/24 22:08, Dave Airlie wrote:
> > > > On Tue, 6 Feb 2024 at
en I think you won't get any splats
because the wq subsystem assumes that WC_MAX_ACTIVE is close enough to
infinity to not matter.
I'm not sure we should care differently, but I guess it'd be good to
annotate it all in case the wq subsystem's idea of how much such deadlocks
are real changes.
Also Teo is on a mission to get rid of all the global wq flushes, so there
should also be no source of deadlocks from that kind of cross-driver
dependency. Or at least shouldn't be in the future, I'm not sure it all
landed.
-Sima
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
eau_fence_get_timeline_name,
> - .enable_signaling = nouveau_fence_enable_signaling,
> + .enable_signaling = nouveau_fence_no_signaling,
I think you can rip nouveau_fence_no_signaling out too, it doesn't do
anything more than what the signalling codepath does too.
But maybe separate p
re fixed function hardware blocks that outright can't cope with
page faults.
There's so many corner cases where it breaks down that I feel like device
driver allocated memory of one flavor or another will stick around for a
very long time.
This isn't even counting the software challenges.
-Sima
> > I'm also not into looking at use-cases that used to be important but
> > might not as important going forward.
>
> Well multimedia applications and OpenGL are still around, but it's not the
> main focus any more.
>
> Christian.
>
> >
> > Dave.
> >
> >
> > > Christian.
> > >
> > > > Dave.
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ngs (I never even had one in my entire life, that's how much I don't
care). But it seems to check all the design boxes around solving annoying
uapi/kms-config issues properly, so
Acked-in-principle-or-something-like-that-by: Daniel Vetter
Cheers, Daniel
>
> To: David Airlie
> To: Danie
-
> >>> drivers/gpu/drm/Kconfig | 2 +
> >>> .../gpu/drm/amd/amdgpu/atombios_encoders.c| 14 +++-
> >>> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++
> >>> .../gpu/drm/i915/display/intel_backlight.c| 7 ++
> >>> drivers/gpu/drm/i915/display/intel_display.c | 1 +
> >>> drivers/gpu/drm/i915/display/intel_opregion.c | 2 +-
> >>> drivers/gpu/drm/nouveau/nouveau_backlight.c | 14
> >>> drivers/gpu/drm/radeon/atombios_encoders.c| 7 ++
> >>> drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++-
> >>> .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 ++
> >>> drivers/platform/x86/acer-wmi.c | 2 +-
> >>> drivers/platform/x86/asus-laptop.c| 2 +-
> >>> drivers/platform/x86/asus-wmi.c | 4 +-
> >>> drivers/platform/x86/compal-laptop.c | 2 +-
> >>> drivers/platform/x86/dell/dell-laptop.c | 2 +-
> >>> drivers/platform/x86/eeepc-laptop.c | 2 +-
> >>> drivers/platform/x86/fujitsu-laptop.c | 4 +-
> >>> drivers/platform/x86/ideapad-laptop.c | 2 +-
> >>> drivers/platform/x86/intel/oaktrail.c | 2 +-
> >>> drivers/platform/x86/msi-laptop.c | 2 +-
> >>> drivers/platform/x86/msi-wmi.c| 2 +-
> >>> drivers/platform/x86/samsung-laptop.c | 2 +-
> >>> drivers/platform/x86/sony-laptop.c| 2 +-
> >>> drivers/platform/x86/thinkpad_acpi.c | 4 +-
> >>> drivers/platform/x86/toshiba_acpi.c | 2 +-
> >>> include/acpi/video.h | 8 ++-
> >>> 28 files changed, 156 insertions(+), 84 deletions(-)
> >>
> >
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
comments were update to
> remove mentions to dma-buf-map.
>
> Since this is not specific to dma-buf anymore, move the documentation to
> the "Bus-Independent Device Accesses" section.
>
> v2:
> - Squash patches
>
> v3:
> - Fix wrong removal
omem;
> > > > + else
> > > > + return lhs->vaddr == rhs->vaddr;
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_is_null - Tests for a iosys mapping to be NULL
> > > > + * @map: The iosys_map structure
> > > > + *
> > > > + * Depending on the state of struct iosys_map.is_iomem, tests if the
> > > > + * mapping is NULL.
> > > > + *
> > > > + * Returns:
> > > > + * True if the mapping is NULL, or false otherwise.
> > > > + */
> > > > +static inline bool iosys_map_is_null(const struct iosys_map *map)
> > > > +{
> > > > + if (map->is_iomem)
> > > > + return !map->vaddr_iomem;
> > > > + return !map->vaddr;
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_is_set - Tests if the iosys mapping has been set
> > > > + * @map: The iosys_map structure
> > > > + *
> > > > + * Depending on the state of struct iosys_map.is_iomem, tests if the
> > > > + * mapping has been set.
> > > > + *
> > > > + * Returns:
> > > > + * True if the mapping is been set, or false otherwise.
> > > > + */
> > > > +static inline bool iosys_map_is_set(const struct iosys_map *map)
> > > > +{
> > > > + return !iosys_map_is_null(map);
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_clear - Clears a iosys mapping structure
> > > > + * @map: The iosys_map structure
> > > > + *
> > > > + * Clears all fields to zero, including struct iosys_map.is_iomem, so
> > > > + * mapping structures that were set to point to I/O memory are
> > > > reset for
> > > > + * system memory. Pointers are cleared to NULL. This is the default.
> > > > + */
> > > > +static inline void iosys_map_clear(struct iosys_map *map)
> > > > +{
> > > > + if (map->is_iomem) {
> > > > + map->vaddr_iomem = NULL;
> > > > + map->is_iomem = false;
> > > > + } else {
> > > > + map->vaddr = NULL;
> > > > + }
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_memcpy_to - Memcpy into iosys mapping
> > > > + * @dst: The iosys_map structure
> > > > + * @src: The source buffer
> > > > + * @len: The number of byte in src
> > > > + *
> > > > + * Copies data into a iosys mapping. The source buffer is in system
> > > > + * memory. Depending on the buffer's location, the helper picks
> > > > the correct
> > > > + * method of accessing the memory.
> > > > + */
> > > > +static inline void iosys_map_memcpy_to(struct iosys_map *dst,
> > > > const void *src,
> > > > + size_t len)
> > > > +{
> > > > + if (dst->is_iomem)
> > > > + memcpy_toio(dst->vaddr_iomem, src, len);
> > > > + else
> > > > + memcpy(dst->vaddr, src, len);
> > > > +}
> > > > +
> > > > +/**
> > > > + * iosys_map_incr - Increments the address stored in a iosys mapping
> > > > + * @map: The iosys_map structure
> > > > + * @incr: The number of bytes to increment
> > > > + *
> > > > + * Increments the address stored in a iosys mapping. Depending on the
> > > > + * buffer's location, the correct value will be updated.
> > > > + */
> > > > +static inline void iosys_map_incr(struct iosys_map *map, size_t incr)
> > > > +{
> > > > + if (map->is_iomem)
> > > > + map->vaddr_iomem += incr;
> > > > + else
> > > > + map->vaddr += incr;
> > > > +}
> > > > +
> > > > +#endif /* __IOSYS_MAP_H__ */
> > >
> > > --
> > > Thomas Zimmermann
> > > Graphics Driver Developer
> > > SUSE Software Solutions Germany GmbH
> > > Maxfeldstr. 5, 90409 Nürnberg, Germany
> > > (HRB 36809, AG Nürnberg)
> > > Geschäftsführer: Ivo Totev
> >
> >
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 2 ++
> .../gpu/drm/selftests/test-drm_framebuffer.c | 1 -
> include/drm/drm_mode_config.h | 18 +--
> include/drm/drm_plane.h | 3 +++
> 14 files changed, 45 insertions(+), 32 deletions(-)
>
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
/gpu/drm/radeon/radeon_display.c | 2 ++
> .../gpu/drm/selftests/test-drm_framebuffer.c | 1 -
> include/drm/drm_mode_config.h | 18 +--
> include/drm/drm_plane.h | 3 +++
> 14 files changed, 45 insertions(+), 32 deletions(-)
>
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
ert
> users at leisure, though with a bunch of churn, while using names that
> collide with existing ones requires the changes to happen in one go.
>
> What I do mind is grinding this series to a halt once again. I sent a
> handful of versions of this three years ago, with inconclusiv
gt; + bool fb_modifiers_not_supported;
> +
> /**
>* @normalize_zpos:
>*
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 0c1102dc4d88..cad641b1f797 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -803,6 +803,9 @@ void *__drmm_universal_plane_alloc(struct drm_device *dev,
> *
> * The @drm_plane_funcs.destroy hook must be NULL.
> *
> + * For drivers supporting modifiers, all planes will advertise
> + * DRM_FORMAT_MOD_LINEAR support, if @format_modifiers is not set.
> + *
> * Returns:
> * Pointer to new plane, or ERR_PTR on failure.
> */
> --
> 2.17.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
encing issue in userspace, and somehow ignoring fences ensures that the
Xorg copy/blt completes before we get around to clearing stuff.
I'm assuming we're rendering with glamour, so is nouveau relying on kernel
implicit sync or doing it's own fencing in userspace?
-Daniel
>
> > Please test if that patch changes anything.
> >
> > Thanks,
> > Christian.
> >
> > >
> > > Cheers,
> > >
> > > -- Dan
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Skeggs
> Cc: Lyude Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Signed-off-by: Karol Herbst
Acked-by: Daniel Vetter
> ---
> MAINTAINERS | 9 -
> 1 file changed, 8 insertions(+),
quot;%s",
Please add a comment here that drmfb is uapi because pm-utils matches
against it ...
Otherwise this will be lost in time again :-(
-Daniel
> > + snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb",
> > fb_helper->dev->driver->name);
> >
> > }
> > --
> > 2.31.1
>
> --
> Ville Syrjälä
> Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
| 6 ++-
> drivers/gpu/drm/radeon/radeon_device.c| 13 +++--
> drivers/gpu/drm/radeon/radeon_dp_mst.c| 7 ++-
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 ++-
> drivers/gpu/drm/tegra/dsi.c | 6 ++-
> drivers/gpu/drm/tegra/hdmi.c | 5 +-
> drivers/gpu/drm/tegra/sor.c | 10 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 ++--
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 +++--
> 28 files changed, 222 insertions(+), 180 deletions(-)
>
> --
> 2.33.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
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
oup 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 Fri, Jul 23, 2021 at 12:16:31PM +0200, Arnd Bergmann wrote:
> On Fri, Jul 23, 2021 at 11:25 AM Daniel Vetter wrote:
> >
> > On Fri, Jul 23, 2021 at 11:15 AM Arnd Bergmann wrote:
> > >
> > > From: Arnd Bergmann
> > >
> > > When the backl
nfo);
> +
> if (ret < 0)
> NV_ERROR(drm, "Failed to disable backlight on
> [CONNECTOR:%d:%s]: %d\n",
> nv_connector->base.base.id,
> nv_connector->base.name, ret);
> }
> +#endif
>
>
t_pc 8139cp parport
> > [ 58.798016] CR2: 0000017c
> > [ 58.798147] ---[ end trace 732829d39ed65de9 ]---
> >
> >
> > d02117f8efaa5fbc37437df1ae955a147a2a424a is the first bad commit
> >
> > --
> > Ondrej Zary
> >
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
0x04
> > #define VGA_RSRC_NORMAL_MEM0x08
> > -/* Passing that instead of a pci_dev to use the system "default"
> > - * device, that is the one used by vgacon. Archs will probably
> > - * have to provide their own vga_default_device();
> > - */
looks like that hasn't happened yet.
>
> Even Linus already pinged me where the fix for qxl got stuck.
Yeah there was some missed patches. drm-misc-fixes is now in drm-fixes,
and drm-misc-next-fixes is included in drm-misc-fixes, for which Thomas
will do a pull request on Thu so it
> [1]
> https://lore.kernel.org/dri-devel/20210608090301.4752-1-tzimmerm...@suse.de/
On the series:
Acked-by: Daniel Vetter
But I've only done a very light reading of this, so please wait for driver
folks to have some time to check their own before merging.
I think a devm_ version of drm_irq_ins
On Mon, Jun 21, 2021 at 5:53 PM Daniel Vetter wrote:
>
> On Mon, Jun 21, 2021 at 5:49 PM Christian König
> wrote:
> >
> > Am 21.06.21 um 16:54 schrieb Daniel Vetter:
> > > On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
> > >> We actual
On Mon, Jun 21, 2021 at 5:49 PM Christian König
wrote:
>
> Am 21.06.21 um 16:54 schrieb Daniel Vetter:
> > On Mon, Jun 21, 2021 at 03:03:26PM +0200, Christian König wrote:
> >> We actually need to wait for the moving fence after pinning
> >> the BO to make
+ int r;
>
> /* pin buffer into GTT */
> - return amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
> + r = amdgpu_bo_pin(bo, AMDGPU_GEM_DOMAIN_GTT);
> + if (r)
> + return r;
> +
> + if (bo->tbo.moving) {
dma-buf.c guarantees we have the rese
nt++;
> -
> + if (unlikely(ret))
> + goto error;
> +
> + if (bo->tbo.moving) {
> + ret = dma_fence_wait(bo->tbo.moving, false);
Here we wait whil holding the reservation, so we should be all fine. Maybe
not the nicest
nouveau_bo_unpin(nvbo);
> + }
> +
> + return ret;
> }
>
> void nouveau_gem_prime_unpin(struct drm_gem_object *obj)
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
t; drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> 26 files changed, 80 insertions(+), 82 deletions(-)
>
> Cc: Adam Jackson
> Cc: Ajay Kumar
> Cc: Akshu Agarwal
> Cc: Alex Deucher
> Cc: Alistair Popple
> Cc: amd-...@lists.freedesktop.org
> Cc: AngeloGioacchi
.
/me out
-Daniel
>
> David
> ________
> From: Daniel Vetter
> Sent: Wednesday, May 19, 2021 11:23 AM
> To: Tvrtko Ursulin
> Cc: Daniel Stone ; jhubb...@nvidia.com
> ; nouveau@lists.freedesktop.org
> ; Intel Graphics Development
> ; Mali
ng that on anything remotely realistic
it's an actual problem. Until we've demonstrated it's a real problem
we don't need to solve it.
E.g. top with any sorting enabled also parses way more than it
displays on every update. It seems to be doing Just Fine (tm).
>
is the case here.
Note that this fixes an inconsistency: We've set the cap everywhere,
but only nv50+ supports modifiers. Hence cc stable, but not further
back then the patch from Paul.
Cc: sta...@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Ben Skeggs
Cc: nouveau
On Wed, Apr 21, 2021 at 09:01:00AM +0200, Christian König wrote:
> Am 20.04.21 um 22:53 schrieb Daniel Vetter:
> > On Tue, Apr 20, 2021 at 10:23 PM Felix Kuehling
> > wrote:
> > >
> > > Am 2021-04-20 um 4:51 a.m. schrieb Daniel Vetter:
> > > > >
On Tue, Apr 20, 2021 at 10:23 PM Felix Kuehling wrote:
>
>
> Am 2021-04-20 um 4:51 a.m. schrieb Daniel Vetter:
> >>> Whole series is Reviewed-by: Christian König
> >> Thanks a lot. If I'm not mistaken, the patches at [1] need to go in first.
> >> So
rg/series/88822/
>
> >
> > Thanks for the nice cleanup,
> > Christian.
> >
> > >
> > > Regards,
> > > Christian.
> > >
> > > > + if (unlikely(ret != 0))
> > > > + goto out_unref;
> > > &
On Thu, Apr 15, 2021 at 12:17:34PM +0200, Thomas Zimmermann wrote:
> Drivers may want to set their own callbacks for a VM area. Only set
> TTM's callbacks if the vm_ops field is clear.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/t
is the case here.
Note that this fixes an inconsistency: We've set the cap everywhere,
but only nv50+ supports modifiers. Hence cc stable, but not further
back then the patch from Paul.
Cc: sta...@vger.kernel.org # v5.1 +
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Ben Skeggs
Cc: nouveau
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,
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
u/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 ---
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c| 51 ++-
> include/drm/ttm/ttm_bo_api.h| 13
> include/drm/ttm/ttm_device.h| 15 -
> 22 files changed, 212 insertions(+), 365 deletions(-)
>
>
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
___
c | 27 +-
> > drivers/gpu/drm/radeon/atombios_dp.c | 5 +-
> > drivers/gpu/drm/tegra/dpaux.c | 12 +-
> > drivers/gpu/drm/xlnx/zynqmp_dp.c | 5 +-
> > include/drm/drm_dp_dual_mode_helper.h | 14 +-
> > include/drm/drm_dp_helper.h | 61 +--
> > + igt_plane_set_fb(cursor, >fb);
> > > > > > + igt_plane_set_size(cursor, w, h);
> > > > > > + igt_fb_set_size(>fb, cursor, w, h);
> > > > > > +
> > > > > > + /* Test if the kernel supports the given cursor size or not
> > > > > > */
> > > > > > + ret = igt_display_try_commit_atomic(display,
> > > > > > +
> > > > > > DRM_MODE_ATOMIC_TEST_ONLY |
> > > > > > +
> > > > > > DRM_MODE_ATOMIC_ALLOW_MODESET,
> > > > > > + NULL);
> > > > >
> > > > > Would be better to not depend on atomic. We have platforms
> > > > > that don't expose it yet.
> > > >
> > > > Do you have any other ideas how we could probe for this then? it seems
> > > > like
> > > > the
> > > > only alternative would be to add intel-specific checks to fix that, or
> > > > add
> > > > some
> > > > ioctl for querying the minimum cursor size (which sounds preferable
> > > > imo).
> > > > would
> > > > the latter work for you, or do you have another idea?
> > >
> > > Just do it for real instead of TEST_ONLY.
> >
> > ah-and it'll still fail in that case I assume?
>
> Yeah, should fail just the same if the driver doesn't like it.
Doing the atomic TEST_ONLY first would be good, if atomic support
exists, since it's faster. Doing modesets just to figure out whether
we should test something is a bit expensive, best not to inflict on
that on new machines.
-Daniel
>
> --
> Ville Syrjälä
> Intel
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Fri, Mar 19, 2021 at 08:24:07AM +, Lee Jones wrote:
> On Thu, 18 Mar 2021, Daniel Vetter wrote:
>
> > On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote:
> > >
> > > On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
> > > >
&g
On Wed, Mar 17, 2021 at 9:32 PM Daniel Vetter wrote:
>
> On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
> >
> > On Thu, 11 Mar 2021, Lee Jones wrote:
> >
> > > On Thu, 11 Mar 2021, Daniel Vetter wrote:
> > >
> > > > On Mon, Mar 08, 2021
On Wed, Mar 17, 2021 at 9:17 AM Lee Jones wrote:
>
> On Thu, 11 Mar 2021, Lee Jones wrote:
>
> > On Thu, 11 Mar 2021, Daniel Vetter wrote:
> >
> > > On Mon, Mar 08, 2021 at 09:19:32AM +, Lee Jones wrote:
> > > > On Fri, 05 Mar 2021, Roland Scheidegge
gain (they
are queued up for 5.13 in drm-misc-next, I checked that).
Sorry for the confusion here.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
_PCI_AGP_H__
> > #define __NVKM_PCI_AGP_H__
> >
> > +/* SPDX-License-Identifier: MIT */
> > +#include "priv.h"
> > +#if IS_ENABLED(CONFIG_AGP)
> > void nvkm_agp_ctor(struct nvkm_pci *);
> > void nvkm_agp_dtor(struct nvkm_pci *);
> > vo
gt;
> > drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
> > drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
> > drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
> > 3 files changed, 3 insertions(+), 3 deletions(-)
> >
>
--
Daniel Vetter
Software Engin
On Tue, Feb 09, 2021 at 12:53:27PM -0800, John Hubbard wrote:
> On 2/9/21 5:37 AM, Daniel Vetter wrote:
> > On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote:
> > >
> > > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > > >
On Tue, Feb 9, 2021 at 2:35 PM Jason Gunthorpe wrote:
>
> On Tue, Feb 09, 2021 at 11:57:28PM +1100, Alistair Popple wrote:
> > On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > > >
> > > > Recent changes to pin_user_pages()
On Tue, Feb 9, 2021 at 1:57 PM Alistair Popple wrote:
>
> On Tuesday, 9 February 2021 9:27:05 PM AEDT Daniel Vetter wrote:
> > >
> > > Recent changes to pin_user_pages() prevent the creation of pinned pages in
> > > ZONE_MOVABLE. This series allows pinned page
| 1 +
> mm/migrate.c | 82 +---
> tools/testing/selftests/vm/hmm-tests.c| 49 +
> 14 files changed, 524 insertions(+), 101 deletions(-)
>
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
On Mon, Jan 18, 2021 at 03:09:45PM +, Lee Jones wrote:
> On Mon, 18 Jan 2021, Daniel Vetter wrote:
>
> > On Fri, Jan 15, 2021 at 06:27:15PM +, Zack Rusin wrote:
> > >
> > > > On Jan 15, 2021, at 13:15, Lee Jones wrote:
> > > >
> >
-misc-next, but some patch
monkey help would be really great :-)
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
oller if they're stuck).
Note that we have some build issue on some of the configs sfr uses, so drm
trees are still stuck on old versions in linux-next. Hopefully should get
resolved soon, the bugfix is in some subtree I've heard.
-Daniel
--
Daniel Vetter
Sof
t; +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
> >> @@ -142,7 +142,7 @@ int amdgpu_driver_load_kms(struct amdgpu_device
> >> *adev, unsigned long flags)
> >> (amdgpu_is_atpx_hybrid() ||
> >>amdgpu_has_atpx_dgpu_power_cntl()) &&
> >&g
:1390:42: error:
> > > > 'struct drm_device' has no member named 'pdev'; did you mean
> > > > 'dev'?
> > > > 1390 | dma_free_coherent(>dev_priv->dev->pdev->dev,
> > > > | ^~
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
On Fri, Nov 27, 2020 at 05:35:28PM +0100, Daniel Vetter wrote:
> Purely conjecture, but I think the original locking inversion with the
> legacy page flip code between flipping and ttm's bo move function
> shoudn't exist anymore with atomic: With atomic the bo pinning and
> actual mo
+0200
drm/nouveau: make flipping lockdep safe
Acked-by: Ben Skeggs
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: nouveau@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 5 -
1 file changed, 4
On Mon, Nov 23, 2020 at 10:51:25AM +0100, Daniel Vetter wrote:
> On Fri, Nov 20, 2020 at 4:23 PM Matti Hamalainen wrote:
> >
> > Commit 03e0d26fcf79 ("drm/nouveau: slowpath for pushbuf ioctl") included
> > a logic-bug which results in the relocations not actu
hed code had a leftover u_free() call,
> which, after fixing the logic, now got called and resulted in a
> double-free. Fix by removing one u_free(), moving the other
> and adding check for errors.
>
> Cc: Daniel Vetter
> Cc: Ben Skeggs
> Cc: nouveau@lists.freedesktop.org
>
t'
>
> Cc: Ben Skeggs
Ben fyi I smashed this into drm-misc-next, seemed trivial enough to not be
a bother.
-Daniel
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Signed-off-by: Lee Jones
> ---
> drivers
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 the only
real
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: virtualizat...@lists.linux-foundation.org
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex Deucher
Cc
Cc: kernel test robot
Acked-by: Maxime Ripard
Signed-off-by: Daniel Vetter
Cc: Sam Ravnborg
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@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
On Fri, Oct 30, 2020 at 9:30 AM Tomi Valkeinen wrote:
>
> On 29/10/2020 15:22, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> > features, e.g. 5014
Slaby
Cc: Bartlomiej Zolnierkiewicz
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: Jiri Slaby
Cc: "Gustavo A. R. Silva"
Cc: Tetsuo Handa
Cc: Peilin Ye
Cc: George Kennedy
Cc: Nathan Chancellor
Cc:
Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: Jiri Slaby
Cc: "Gustavo A. R. Silva"
Cc: Tetsuo Handa
Cc: Peilin Ye
Cc: George Kennedy
Cc: Nathan Chancellor
Cc: Peter Rosin
Signed-off-by: Daniel Vetter
On Wed, Oct 28, 2020 at 7:50 PM Sam Ravnborg wrote:
>
> Hi Daniel.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code
On Wed, Oct 28, 2020 at 8:02 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 28.10.20 um 17:06 schrieb Daniel Vetter:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to just delete code and remove
> >
On Wed, Oct 28, 2020 at 5:45 PM Sam Ravnborg wrote:
>
> Hi Daniel et al.
>
> On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
> > So ever since syzbot discovered fbcon, we have solid proof that it's
> > full of bugs. And often the solution is to jus
Bartlomiej Zolnierkiewicz
Cc: Greg Kroah-Hartman
Cc: Linus Torvalds
Cc: Ben Skeggs
Cc: nouveau@lists.freedesktop.org
Cc: Tomi Valkeinen
Cc: Daniel Vetter
Cc: Jiri Slaby
Cc: "Gustavo A. R. Silva"
Cc: Tetsuo Handa
Cc: Peilin Ye
Cc: George Kennedy
Cc: Nathan Chancellor
Cc: Pet
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
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
> > -
(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: virtualizat...@lists.linux-foundation.org
Cc: Harry Wentland
Cc: Leo Li
Cc: Alex
On Thu, Oct 01, 2020 at 08:46:59AM +1000, Ben Skeggs wrote:
> On Wed, 30 Sep 2020 at 19:37, Daniel Vetter wrote:
> >
> > On Wed, Sep 30, 2020 at 10:45:05AM +1000, Ben Skeggs wrote:
> > > On Wed, 30 Sep 2020 at 00:52, Daniel Vetter
> > > wrote:
> > >
(everyone else
is way too much).
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@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: nouveau@lists.freedesktop.org
+0200
drm/nouveau: make flipping lockdep safe
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Ben Skeggs
Cc: Dave Airlie
Cc: nouveau@lists.freedesktop.org
---
I might be totally wrong, so this definitely needs testing :-)
Cheers, Daniel
---
drivers/gpu
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
> >&
_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
> ---
>
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
> >>
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
_bo_mmap_obj - mmap memory backed by a ttm buffer object.
> > > > *
> > > > diff --git a/include/linux/dma-buf-map.h b/include/linux/dma-buf-map.h
> > > > index fd1aba545fdf..2e8bbecb5091 100644
> > > > --- a/include/linux/dma-buf-map.h
> > > >
invidual page (again using the
dma_buf_map stuff).
I'll let Christian with the details, but at a high level this is
definitely
Acked-by: Daniel Vetter
Thanks a lot for doing all this.
-Daniel
>
> >
> > Signed-off-by: Thomas Zimmermann
> > ---
>
On Thu, Oct 8, 2020 at 11:25 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.10.20 um 20:44 schrieb Daniel Vetter:
> > 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:
> >>&g
On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 02.10.20 um 11:58 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> >> wrote:
> >&g
On Wed, Oct 7, 2020 at 3:25 PM Christian König wrote:
>
> Am 07.10.20 um 15:20 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 07.10.20 um 15:10 schrieb Daniel Vetter:
> >> On Wed, Oct 7, 2020 at 2:57 PM Thomas Zimmermann
> >> wrote:
> >>> Hi
On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> wrote:
> >
> > Am 30.09.20 um 11:47 schrieb Daniel Vetter:
> > > On Wed, Sep 30, 2020 at 10:34:31AM +0200, Christian König wrote:
> > >&
gt; + * .. code-block:: c
> + *
> + * const void *src = ...; // source buffer
> + * size_t len = ...; // length of src
> + *
> + * dma_buf_map_memcpy_to(, src, len);
> + * dma_buf_map_incr(, len); // go to first byte after the memcpy
> */
>
> /**
>
On Tue, Sep 29, 2020 at 05:14:31PM +0200, Thomas Zimmermann wrote:
> The parameters map and is_iomem are always of the same value. Removed them
> to prepares the function for conversion to struct dma_buf_map.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Daniel Vetter
> ---
On Fri, Oct 2, 2020 at 1:30 PM Christian König
wrote:
>
> Am 02.10.20 um 11:58 schrieb Daniel Vetter:
> > On Wed, Sep 30, 2020 at 02:51:46PM +0200, Daniel Vetter wrote:
> >> On Wed, Sep 30, 2020 at 2:34 PM Christian König
> >> wrote:
> >>>
gt; */
> int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map *map)
> {
> struct drm_gem_object *obj = dma_buf->priv;
> - void *vaddr;
>
> - vaddr = drm_gem_vmap(obj);
> - if (IS_ERR(vaddr))
> - return PTR_ERR(vaddr);
> -
uffer
> + * @map: Virtual address for the buffer
>*/
> - void *vaddr;
> + struct dma_buf_map map;
>
> /**
>* @fb: DRM framebuffer
> @@ -155,7 +156,7 @@ struct drm_client_buffer *
> drm_client_framebuffer_create(struct drm_client_d
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 Tue, Sep 29, 2020 at 05:14:33PM +0200, Thomas Zimmermann wrote:
> This patch replaces the vmap/vunmap's use of raw pointers in GEM object
> functions with instances of struct dma_buf_map. GEM backends are
> converted as well.
>
> For most GEM backends, this simply change the returned type. GEM
1 - 100 of 474 matches
Mail list logo
