similar to: [PATCH -next] drm/nouveu: remove unused variable

fixed the following warnings drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] Signed-off-by: Tian Tao <tiantao6 at hisilicon.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 -- 1 file changed, 2 deletions(-)

Am 20.11.20 um 07:49 schrieb Tian Tao: > fixed the following warnings > drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ?dev? > set but not used [-Wunused-but-set-variable] > drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ?dev? > set but not used [-Wunused-but-set-variable] > > Signed-off-by: Tian Tao <tiantao6 at hisilicon.com> The

Removes common code found in numerous vendor drivers and places it higher up in the TTM tree. Signed-off-by: Tom St Denis <tom.stdenis at amd.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 37 ++---------------------------------- 1 file changed, 2 insertions(+), 35 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index

On Thu, Jul 31, 2014 at 06:09:42PM +0900, Alexandre Courbot wrote: > The DMA API is the recommended way to map pages no matter what the > underlying bus is. Use the DMA functions for page mapping and remove > currently existing wrappers. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > Cc: Daniel Vetter <daniel at ffwll.ch> > --- > Changes since

The DMA API is the recommended way to map pages no matter what the underlying bus is. Use the DMA functions for page mapping and remove currently existing wrappers. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> Cc: Daniel Vetter <daniel at ffwll.ch> --- Changes since v4: - Patch against the Nouveau tree instead of the kernel - Separated this patch from the rest of the

Fixes coccicheck warning: drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:103:23-30: WARNING opportunity for kmemdup drivers/gpu/drm/nouveau/nvkm/subdev/acr/hsfw.c:113:22-29: WARNING opportunity for kmemdup Fixes: 22dcda45a3d1 ("drm/nouveau/acr: implement new subdev to replace "secure boot"") Reported-by: Hulk Robot <hulkci at huawei.com> Signed-off-by: Zou Wei

The T124 generation of Tegra GPUs uses the Kepler architecture and can thus be driven by Nouveau. However, they are declared as platform devices using the Device Tree, and Nouveau has a very strong dependency on PCI. This patch makes Nouveau core able to handle platform devices as well as PCI devices. Commonly-used PCI functions include resource range query and page mapping. These functions are

drm-next reverted the changes to ttm_tt_create() to do the NULL check inside the function, but drm-misc-next adds new users of this approach. Re-apply the NULL check change inside the function to fix this. Signed-off-by: Christian K?nig <christian.koenig at amd.com> Reviewed-by: Dave Airlie <airlied at redhat.com> Link: https://patchwork.freedesktop.org/patch/386628/ ---

Ping? Am 27.02.2018 um 13:07 schrieb Christian König: > Hi guys, > > at least on amdgpu and radeon the page array allocated by > ttm_dma_tt_init is completely unused in the case of DMA-buf sharing. > So I'm trying to get rid of that by only allocating the DMA address > array. > > Now the only other user of DMA-buf together with ttm_dma_tt_init is > Nouveau. So

Hi guys, at least on amdgpu and radeon the page array allocated by ttm_dma_tt_init is completely unused in the case of DMA-buf sharing. So I'm trying to get rid of that by only allocating the DMA address array. Now the only other user of DMA-buf together with ttm_dma_tt_init is Nouveau. So my question is are you guys using the page array anywhere in your kernel driver in case of a

Hi folks, Currently, when the device is removed (or the driver is unbound) the nouveau_drm structure de-allocated. However, it's still accessible from and used by some DRM layer callbacks. For example, file handles can be closed after the device has been removed (physically or otherwise). This series converts the Nouveau device structure to be allocated and de-allocated with the

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

Upcoming mobile Kepler GPUs (such as GK20A) use the platform bus instead of PCI to which Nouveau is tightly dependent. This patch allows Nouveau to handle platform devices by: - abstracting PCI-dependent functions that were typically used for resource querying and page mapping, - introducing a nv_device_is_pci() function that allows to make PCI-dependent code conditional, - providing a

It has been a couple of months since v4 - apologies for this. v4 has not received many comments, but this version addresses them and makes a new attempt at pushing the critical bit for GK20A and Nouveau on ARM in general. As a reminder, this series addresses the memory coherency issue that we are seeing on ARM platforms. Contrary to x86 which invalidates the PCI caches whenever a write is made by

http://bugs.freedesktop.org/show_bug.cgi?id=10572 ------- Comment #2 from madman2003 at gmail.com 2007-09-08 06:30 PST ------- Is this still an issue? NV4x cards should work well with MigrationHeuristic "always" these days. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the

Am 08.04.19 um 13:59 schrieb Thomas Zimmermann: [SNIP] > If not for TTM, what would be the alternative? One VMA manager per > memory region per device? Since everybody vital seems to be on this mail thread anyway, let's use it a bit for brain storming what a possible replacement for TTM should look like. Well for simple drivers like qemu/bochs and cirrus the answer is to not use it

https://bugs.freedesktop.org/show_bug.cgi?id=83021 Priority: medium Bug ID: 83021 Assignee: nouveau at lists.freedesktop.org Summary: Separate X screens --> Xvideo is vsynced to primary screen only QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux

On Fri, Jul 12, 2013 at 10:45 PM, Maarten Lankhorst <maarten.lankhorst at canonical.com> wrote: > I have no idea what this bogus restriction on placement is, but it breaks decoding 1080p > VDPAU at boot speed. With this patch applied I only need to bump the vdec clock to > get real-time 1080p decoding. It prevents a lot of VRAM <-> VRAM buffer moves. It's not bogus, and is

No problemos with x86_64, however on i686 kworker/u16:57: page allocation failure: order:0, mode:0x284000 CPU: 0 PID: 1425 Comm: kworker/u16:57 Not tainted 3.18.0-0.rc5.git0.1.fc22.i686+debug #1 Workqueue: events_unbound async_run_entry_fn Call Trace: [<c0b2b55a>] dump_stack+0x48/0x60 [<c056f3d4>] warn_alloc_failed+0xd4/0x110 [<c0571ade>] __alloc_pages_nodemask+0x81e/0xc30

The DMA API has different semantics on different architectures. Currently on arm64, it can only provide memory from a small pool which dries up quickly if we attempt to allocate big buffers from it. Do not consider that option when running on non-x86, since regular TTM buffers are the (current) best-fit for ARM platforms. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- To be