similar to: [PATCH 0/3] Nouveau fixes for TTM refcount rework

From: Maarten Lankhorst <maarten.lankhorst at ubuntu.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- drivers/gpu/drm/nouveau/core/core/event.c | 4 drivers/gpu/drm/nouveau/nouveau_bo.c | 6 drivers/gpu/drm/nouveau/nouveau_display.c | 4 drivers/gpu/drm/nouveau/nouveau_fence.c | 434 ++++++++++++++++++++---------

> Hi Gerd, > > I've been seeing a regression on Nouveau with recent linux-next releases > and git bisect points at this commit as the first bad one. If I revert > it (there's a tiny conflict with a patch that was merged subsequently), > things are back to normal. > > I think the reason for this issue is that Nouveau doesn't use GEM > objects for all buffer

Hi Maarten Will this stop the stuttering I've been seeing with DRI3 and PRIME? Or will other patches / plumbing be required Cheers Mike On 9 Jul 2014 13:29, "Maarten Lankhorst" <maarten.lankhorst at canonical.com> wrote: > This series applies on top of the driver-core-next branch of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git > >

This series applies on top of the driver-core-next branch of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git Before converting ttm to the new fence interface I had to fix some drivers to require a reservation before poking with fence_obj. After flipping the switch RCU becomes available instead, and the extra reservations can be dropped again. I've done at least basic

Since commit 5e120f6e4b3f35b741c5445dfc755f50128c3c44 "drm/nouveau/fence: convert to exec engine, and improve channel sync" nouveau fence sync implementation for nv17-50 and nvc0+ started to rely on state of fence buffer left by previous sync operation. But as pinned bo's (where fence state is stored) are not saved+restored across suspend/resume, we need to do it manually. nvc0+ was

Hello Danilo Krummrich, Commit bf32a3a12686 ("drm/nouveau: use GEM references instead of TTMs") from Jul 18, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/gpu/drm/nouveau/dispnv50/disp.c:2818 nv50_display_destroy() error: we previously assumed 'disp->sync' could be null (see line 2816) drivers/gpu/drm/nouveau/dispnv50/disp.c 2804

These objects leak VRAM - but only on module unload. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/nv04_crtc.c | 6 +++++- drivers/gpu/drm/nouveau/nv10_fence.c | 7 ++++++- drivers/gpu/drm/nouveau/nv50_display.c | 21 ++++++++++++++++++--- drivers/gpu/drm/nouveau/nv50_fence.c | 5 ++++- drivers/gpu/drm/nouveau/nvc0_fence.c | 7 ++++++-

This will allow the nouveau module to only include support for nv04-nv50, nv50-nvc0, nvc0+ cards individually (or in any combination). Only compiling one of the card types at a time reduces the size of the nouveau module, from 1.3M to 700-800K, depending on the type (including symbols/etc). It should also yield a reduction in compile time as a lot fewer files are compiled. Here are the sizes

On Fri, Feb 14, 2014 at 7:38 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > So... I was wondering what the impact of splitting up the card compilation by > e.g. generation would be. Depending on the split things would get fairly > intertwined, so I thought I'd start small. This just splits NVC0 from > everything else. I figure that for the people this matters the most to,

On 1/9/24 10:59, Jani Nikula wrote: > On Mon, 08 Jan 2024, Danilo Krummrich <dakr at redhat.com> wrote: >> On 1/4/24 21:16, Jani Nikula wrote: >>> Including drm_edid.h from nouveau_connector.h causes the rebuild of 15 >>> files when drm_edid.h is modified, while there are only a few files that >>> actually need to include drm_edid.h. >>>

Am 22.06.23 um 17:07 schrieb Danilo Krummrich: > On 6/22/23 17:04, Danilo Krummrich wrote: >> On 6/22/23 16:42, Christian K?nig wrote: >>> Am 22.06.23 um 16:22 schrieb Danilo Krummrich: >>>> On 6/22/23 15:54, Christian K?nig wrote: >>>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich: >>>>>> Hi Christian, >>>>>>

On 6/22/23 17:04, Danilo Krummrich wrote: > On 6/22/23 16:42, Christian K?nig wrote: >> Am 22.06.23 um 16:22 schrieb Danilo Krummrich: >>> On 6/22/23 15:54, Christian K?nig wrote: >>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich: >>>>> Hi Christian, >>>>> >>>>> On 6/20/23 08:45, Christian K?nig wrote:

On 6/23/23 09:16, Christian K?nig wrote: > Am 22.06.23 um 17:07 schrieb Danilo Krummrich: >> On 6/22/23 17:04, Danilo Krummrich wrote: >>> On 6/22/23 16:42, Christian K?nig wrote: >>>> Am 22.06.23 um 16:22 schrieb Danilo Krummrich: >>>>> On 6/22/23 15:54, Christian K?nig wrote: >>>>>> Am 20.06.23 um 14:23 schrieb Danilo Krummrich:

On Sat, Jun 8, 2024 at 11:16?PM Asahi Lina <lina at asahilina.net> wrote: > > > > On 5/22/24 6:23 AM, Rob Herring wrote: > > On Mon, May 20, 2024 at 07:20:50PM +0200, Danilo Krummrich wrote: > >> From: Asahi Lina <lina at asahilina.net> > >> > >> Add abstractions for DRM drivers and devices. These go together in one > >> commit

On Mon, Feb 5, 2018 at 12:19 PM, Danilo Krummrich <danilokrummrich at dk-develop.de> wrote: > On 2018-02-05 02:39, Ben Skeggs wrote: >> >> On 5 February 2018 at 11:37, Ben Skeggs <skeggsb at gmail.com> wrote: >>> >>> On 5 February 2018 at 11:22, Danilo Krummrich >>> <danilokrummrich at dk-develop.de> wrote: >>>>

Hi Am 12.08.24 um 14:17 schrieb Danilo Krummrich: > On 8/12/24 10:28 AM, Thomas Zimmermann wrote: >> Replace the call to drm_fb_helper_output_poll_changed() with a call >> to drm_client_dev_hotplug(). It is equivalent in functionality, but >> uses the DRM client infrastructure. >> >> v2: >> - fix commit description >> >> Signed-off-by: Thomas

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 +0100, Danilo Krummrich wrote: > > > > > On 2/5/24 22:08, Dave Airlie wrote: > > >

Fix build with CONFIG_NOUVEAU_PLATFORM_DRIVER enabled: ../drivers/gpu/drm/nouveau/nouveau_platform.c: In function ?nouveau_platform_probe?: ../drivers/gpu/drm/nouveau/nouveau_platform.c:29:13: error: unused variable ?ret? [-Werror=unused-variable] 29 | int ret; | ^~~ Fixes: 961ae5f9807b ("drm/nouveau: handle pci/tegra drm_dev_{alloc, register} from common

On Fri, Jun 07, 2024 at 09:11:32PM +0900, FUJITA Tomonori wrote: > Hi, > > On Fri, 31 May 2024 11:59:47 +0200 > Danilo Krummrich <dakr at redhat.com> wrote: > > > Once we get to a conclusion I can send a series with only the device and firmare > > abstractions such that we can get them in outside of the scope of the reset of > > both series to get your

Hi Boris, On Fri, Jul 28, 2023 at 02:26:12PM +0200, Boris Brezillon wrote: > On Fri, 28 Jul 2023 13:31:36 +0200 > Maxime Ripard <mripard at kernel.org> wrote: > > > Hi Danilo, > > > > On Thu, Jul 20, 2023 at 02:14:22AM +0200, Danilo Krummrich wrote: > > > Add infrastructure to keep track of GPU virtual address (VA) mappings > > > with a