similar to: [PATCH -next] drm/ttm: Remove set but not used variable 'mem'

zhengbin (2): drm/nouveau: remove set but not used variable 'pclks','width' drm/nouveau: remove set but not used variable 'mem' drivers/gpu/drm/nouveau/dispnv04/arb.c | 6 ++---- drivers/gpu/drm/nouveau/nouveau_ttm.c | 4 ---- 2 files changed, 2 insertions(+), 8 deletions(-) -- 2.7.4

From: YueHaibing <yuehaibing at huawei.com> [ Upstream commit 2e4534a22794746b11a794b2229b8d58797eccce ] drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new: drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_gart_manager_new:

From: YueHaibing <yuehaibing at huawei.com> [ Upstream commit 2e4534a22794746b11a794b2229b8d58797eccce ] drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new: drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_gart_manager_new:

From: YueHaibing <yuehaibing at huawei.com> [ Upstream commit 2e4534a22794746b11a794b2229b8d58797eccce ] drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new: drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_gart_manager_new:

Reviewed-by: Lyude Paul <lyude at redhat.com> On Fri, 2019-11-15 at 21:42 +0800, zhengbin wrote: > Fixes gcc '-Wunused-but-set-variable' warning: > > drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new: > drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but > not used [-Wunused-but-set-variable] >

Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_vram_manager_new: drivers/gpu/drm/nouveau/nouveau_ttm.c:66:22: warning: variable mem set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/nouveau_ttm.c: In function nouveau_gart_manager_new: drivers/gpu/drm/nouveau/nouveau_ttm.c:106:22: warning: variable mem set but

Prepare to mark sensitive kernel structures for randomization by making sure they're using designated initializers. These were identified during allyesconfig builds of x86, arm, and arm64, with most initializer fixes extracted from grsecurity. Signed-off-by: Kees Cook <keescook at chromium.org> --- drivers/gpu/drm/nouveau/nouveau_ttm.c | 28 ++++++++++++++-------------- 1 file changed,

Most graphics cards nowadays have a multiple of this limit as their vram, so limiting GART doesn't seem to make much sense. Signed-off-by: Maarten >Lnkhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c b/drivers/gpu/drm/nouveau/nouveau_ttm.c index 3a5e19a..41ddecd 100644 --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c +++

On Fri, Dec 16, 2016 at 05:04:42PM -0800, Kees Cook wrote: > Prepare to mark sensitive kernel structures for randomization by making > sure they're using designated initializers. These were identified during > allyesconfig builds of x86, arm, and arm64, with most initializer fixes > extracted from grsecurity. > > Signed-off-by: Kees Cook <keescook at chromium.org>

Without diving in any of the details, your commit message has me curious and concerned... In a "manager" kind of way, despite being neither a manager nor an insider or active contributor. ;-) On 24/01/2020 14:30, Christian K?nig wrote: > From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> > > While working on TTM cleanups I've found that the io_reserve_lru

On Sat, 25 Jan 2020 at 00:30, Christian K?nig <ckoenig.leichtzumerken at gmail.com> wrote: > > From: Christian K?nig <ckoenig.leichtzumerken at gmail.com> > > While working on TTM cleanups I've found that the io_reserve_lru used by > Nouveau is actually not working at all. > > In general we should remove driver specific handling from the memory > management,

While working on TTM cleanups I've found that the io_reserve_lru used by Nouveau is actually not working at all. In general we should remove driver specific handling from the memory management, so this patch moves the io_reserve_lru handling into Nouveau instead. The patch should be functional correct, but is only compile tested! Signed-off-by: Christian König <christian.koenig at

On 23 January 2015 at 08:53, Alexandre Courbot <acourbot at nvidia.com> wrote: > Having a RAM device does not make sense for chips like GK20A which have > no dedicated video memory. The dummy RAM device that we used so far > works as a temporary band-aid, but in the long-term it is desirable for > the driver to be able to work without any kind of VRAM. > > This patch adds a

Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/core/gpuobj.c | 2 +- drivers/gpu/drm/nouveau/core/core/object.c | 8 ++++---- drivers/gpu/drm/nouveau/core/core/option.c | 2 +- .../drm/nouveau/core/engine/copy/fuc/nva3.fuc.h | 4 ++-- .../drm/nouveau/core/engine/copy/fuc/nvc0.fuc.h | 4 ++--

Hi guys, I've already send this out in September last year, but only got a response from Daniel. Could you guys please test this and tell me what you think about it? Basically I'm trying to remove all driver specific features from TTM which don't need to be inside the framework. Thanks, Christian.

Op 11-08-13 07:36, Benjamin Herrenschmidt schreef: > On Sun, 2013-08-11 at 10:41 +1000, Benjamin Herrenschmidt wrote: >> Now, to do that, I need a better understanding of the various things >> in there since I'm not familiar with nouveau at all. What I think I've >> figured out is with a few questions, it would be awesome if you could >> answer them so I can have

Hi everyone, I have been studing the VM code in order to come with a better implementation of my fix for large pages usage on GK20A (https://lkml.org/lkml/2014/6/3/375 ). Following some older threads about this code (http://marc.info/?l=dri-devel&m=137618326022935 ) also left me kind of puzzled, and I wonder if we could not simplify and improve things there. It seems like arbitrary

Hi guys, I already tried this a few month ago, but since I don't have NVidia hardware its rather hard to test for me (need to get some ordered). Dave brought up the topic that we should probably try to move the handling into Nouveau once more, so I tried to fix the problem Ben reported and rebased on top of current drm-misc-next. Dave can you test this? At least in theory the approach

Hi guys, so I got some hardware and tested this and after hammering out tons of typos it now seems to work fine. Could you give it more testing? Thanks in advance, Christian

On Thu, 2013-08-29 at 16:49 +1000, Ben Skeggs wrote: > > Additionally the current code is broken in that the upper layer in > > vm/base.c doesn't increment "pte" by the right amount. > > > > Now, if those two assertions can be made always true: > > > > - Those two functions (map_sg and map_sg_table) never deal with the > > "big"