similar to: [PATCH 05/10] drm/nouveau: quiet some static-related sparse noise

Op 11-08-13 10:04, Benjamin Herrenschmidt schreef: > 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

On Sun, Aug 11, 2013 at 7:35 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > 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 >> > ---

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

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 @@

On Fri, Nov 29, 2013 at 4:01 PM, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote: > 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

--- drivers/gpu/drm/nouveau/core/include/subdev/ltcg.h | 7 + drivers/gpu/drm/nouveau/core/subdev/fb/nvc0.c | 55 +++++---- drivers/gpu/drm/nouveau/core/subdev/ltcg/nvc0.c | 129 +++++++++++++++++++- drivers/gpu/drm/nouveau/core/subdev/vm/nvc0.c | 58 +++++++++- 4 files changed, 220 insertions(+), 29 deletions(-) diff --git

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 115

Adapt the NVC0 BAR driver to make it able to support chips that do not expose a BAR3. When this happens, BAR1 is then used for USERD mapping and the BAR alloc() functions is disabled, making GPU objects unable to rely on BAR for data access and falling back to PRAMIN. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/subdev/bar/nvc0.c | 101

On Sat, Feb 1, 2014 at 1:16 PM, Alexandre Courbot <acourbot at nvidia.com> wrote: > Adapt the NVC0 BAR driver to make it able to support chips that do not > expose a BAR3. When this happens, BAR1 is then used for USERD mapping > and the BAR alloc() functions is disabled, making GPU objects unable > to rely on BAR for data access and falling back to PRAMIN. > >

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"

The refcount was not protected by the vm lock, fix this.. ------------[ cut here ]------------ WARNING: CPU: 2 PID: 2008 at drivers/gpu/drm/nouveau/core/core/mm.c:242 nouveau_mm_fini+0x4f/0x56 [nouveau]() Modules linked in: adt7475 ebtable_nat ebtables nouveau ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_CHECKSUM iptable_mangle bridge stp llc snd_hda_codec_hdmi kvm_intel ttm kvm

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

Commit 'drm/nv50-nvc0/vm: support unsnooped system memory' caused a regression on certain nv50 IGP due to not passing the correct target type to nv50_vm_addr() Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=45746 Reported-by: Johannes Obermayr <johannesobermayr at gmx.de> Tested-by: Johannes Obermayr <johannesobermayr at gmx.de> Signed-off-by: Emil Velikov

Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- drivers/gpu/drm/nouveau/core/include/subdev/pwr.h | 2 + drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h | 16 ++ drivers/gpu/drm/nouveau/core/subdev/fb/ramnva3.c | 318 +++++++++++++++++++-- .../gpu/drm/nouveau/core/subdev/pwr/fuc/memx.fuc | 111 +++++++ drivers/gpu/drm/nouveau/core/subdev/pwr/fuc/os.h | 5 +

Hi folks ! So I've been trying to figure out what it would take to make nouveau work properly on architectures where PAGE_SIZE isn't 4k such as most ppc64's. An initial patch from Dave fixed a bogon in nv41.c nv41_vm_map_sg() which was trying to handle the case at that low level, but this isn't enough, and after a bit of digging, I also think that's not the right approach:

On Mon, Jun 3, 2013 at 5:02 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > These chipsets include the VP2 engine which is composed of a bitstream > processor (BSP) that decodes H.264 and a video processor (VP) which can > do iDCT/mo-comp/etc for MPEG1/2, H.264, and VC-1. Both of these are > driven by separate xtensa chips embedded in the hardware. This patch > provides the

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 a shot at fixing it all :-) Ok, a few more questions :-) - in struct

This adds some basic debug information about the internal nouveau state. making it slightly easier to determine which bo belongs to which vm address, as long as that program is still running. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> --- diff --git a/drivers/gpu/drm/nouveau/core/include/subdev/vm.h b/drivers/gpu/drm/nouveau/core/include/subdev/vm.h index

- 'joi' on irc pointed out that this triggers a BUG_ON, because kzalloc could sleep. - The irq handler should restore the value NV03_PFIFO_CACHES, but still it's better if this stuff doesn't happen in the middle of fifo create context. I see no reason in spin locking pgraph create context, it isn't activated at that stage. - Move and rename the lock after some discussion with

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