From: Dave Airlie
This lock is just protecting the umem list so name it as such.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/include/nvkm/core/client.h | 2 +-
drivers/gpu/drm/nouveau/nvkm/core/client.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/umem.c | 12
From: Dave Airlie
It appears the client object tree has no locking unless I've missed
something else. Fix races around adding/removing client objects,
mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address
0x6677ed422bceb80c: [#1] PREEMPT SMP
On Tue, Feb 27, 2024 at 05:27:54PM +, Timur Tabi wrote:
> On Tue, 2024-02-27 at 15:20 +0100, Danilo Krummrich wrote:
> > Hi Timur,
> >
> > thanks for re-working this patch!
> >
> > On 2/26/24 22:02, Timur Tabi wrote:
> > > The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: f303a3e2bcfba900efb5aee55236d17030e9f882 Add linux-next specific
files for 20240229
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402292319.ehmsyi8l-...@intel.com
https
Previously we would never try to move a BO into the preferred placements
when it ever landed in a busy placement since those were considered
compatible.
Rework the whole handling and finally unify the idle and busy handling.
ttm_bo_validate() is now responsible to try idle placement first and
Try to fill up VRAM as well by setting the busy flag on GTT allocations.
This fixes the issue that when VRAM was evacuated for suspend it's never
filled up again unless the application is restarted.
Signed-off-by: Christian König
Reviewed-by: Zack Rusin
---
