similar to: [PATCH] drm/nouveau: remove limit on gart

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 not used [-Wunused-but-set-variable] They are not used

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,

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

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,

On Sun, 2013-08-11 at 17:06 +1000, Benjamin Herrenschmidt wrote: > I think I found at least two cases where "12" was used where it should > have been PAGE_SHIFT (basically ttm_mem_reg->num_pages). This > is only the tip of the iceberg, so this isn't a formal patch submission, > but I would appreciate your thought as to whether the below is correct > (and thus

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

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 Sun, 2013-08-11 at 11:02 +0200, Maarten Lankhorst wrote: > > diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > index 5c7433d..c314a5f 100644 > > --- a/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > +++ b/drivers/gpu/drm/nouveau/core/engine/fifo/nv40.c > > @@ -190,8 +190,8 @@

Drivers have no business looking into dma-mapping internals and check what backend is used. Unfortunstely the DRM core is still broken and tries to do plain page allocations instead of using DMA API allocators by default and uses various bandaids on when to use dma_alloc_coherent. Switch nouveau to use the same (broken) scheme as amdgpu and radeon to remove the last driver user of

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"

Second version of this patchset addressing Ben's comments and fixing a few extra things. This patchset proposes to introduce a "staging" module option to dynamically enable features (mostly ioctls) that are merged but may be refined before they are declared "stable". The second patch illustrates the use of this staging option with the SET_TILING ioctl, which can be used to

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.

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, so this patch moves the io_reserve_lru handling into Nouveau instead. The patch should be functional correct, but is only compile

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. v2: don't call ttm_bo_unmap_virtual in nouveau_ttm_io_mem_reserve v3: rebased and use both base and offset in the check v4:

On Mon, Sep 30, 2019 at 03:12:53PM +0200, Christian König wrote: > 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

v2 was doing some pretty nasty things with the DMA API, so I took a different approach for this v3. As suggested, this version uses ttm_dma_populate() to populate BOs. The reason for doing this was that it would entitle us to using the DMA sync functions, but since the memory returned is already coherent anyway, we do not even need to call these functions anymore. So this series has turned into

These 4 patches fix two issues that existed on Tegra regarding DMA: 1) The bit indicating whether to use an IOMMU or not was hardcoded ; make this a platform property and use it in instmem 2) The DMA mask was not set for platform devices. Fix this by converting more pci_dma* to the DMA API, and use that more generic code to set the DMA mask properly for all platforms. Tested on both x86

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 all, this little series removes the last swiotlb API exposed to modules. Diffstat: arch/x86/include/asm/xen/swiotlb-xen.h | 6 ------ arch/x86/kernel/pci-dma.c | 28 ++++------------------------ drivers/gpu/drm/nouveau/nouveau_ttm.c | 10 +++------- drivers/pci/xen-pcifront.c | 6 ------ kernel/dma/swiotlb.c | 1 - 5 files changed, 7