Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GPU virtual addresses are constant now so this should never be getting hit
anyway and userspace shouldn't break from them being ignored.

This is being done in preference to teaching the code how to deal with BOs
that exist at different virtual addresses within separate VMs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Greatly simplifies a number of things, particularly once per-client GPU
address spaces are involved.

May add this back later once I know what things'll look like.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Was previously assuming a page size of 4KiB unless a VMA was present to
override it.  Eventually, a buffer won't necessarily have a VMA at all at
some stages of its life, so we need to store this info elsewhere.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Abuses existing gpuobj_new() chan argument for this, which in turn forces
all NVOBJ_FLAG_VM allocations to be done from the global heap, not
suballocated from the channel's private heap.  Not a problem though in
practise.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

gpuobj really needs splitting into channel/gpuobj code instead...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Userspace hasn't passed us a channel_hint for a long long time now, and
there isn't actually a need to do so anymore anyway.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On chipsets using nouveau_vm, the virtual address stays constant, so
the value set at bo creation time is fine.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Removes the need to disable IRQs to lookup channel struct on every pushbuf
ioctl, among others.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's lots of boards (all recent ones) that don't have this anymore, so
punt the message to debug loglevel.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported-by: NChristoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not a clue what it is yet, but we get the same numbers as NVIDIA now.

My 465 didn't seem to care to greatly *what* I bashed into these registers..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The ability to use NVIDIA's fuc has been retained *temporarily* in order
to better debug any issues that may be lingering in our initial attempt
at writing this ucode.  Once I'm fairly confident we're okay, it'll be
removed.

There's a number of things not implemented by this fuc currently, but
most of it is sets of state that our context setup would not have used
anyway.  No doubt we'll find out what they're for at some point, and
implement it if required.

This has been tested on 0xc0/0xc4 thus far, and from what I could tell
it worked as well as NVIDIA's.  It's also been tested on 0xc1, but even
with NVIDIA's fuc that chipset doesn't work correctly with nouveau yet.

0xc3/0xc8/0xce should in theory be supported too, but I don't have the
hardware to check that.

There's no doubt numerous bugs to squash yet, please report any!
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We need the physical VRAM address in vinst, even for objects mapped into
a vm, as the gpuobj suspend/resume code uses PMEM to access the object.

Previously, vinst was overloaded to mean "VRAM address" for !VM objects,
and "VM address" for VM objects, causing the wrong data to be accessed
during suspend/resume.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Until we know these should work properly, would much rather default to
noaccel than risk giving people corruption/hangs out of the box..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's issues with certain 3D apps still, unknown whether this is a kernel
issue or not.. It does appear that it may be in the 3D driver however.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes DMAR faults during accel, more than likely a similar problem to what
was solved on nv50 previously.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

this printk isn't really useful, just drop it for now.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The DDX modifies DMA_SEMAPHORE on nv50 in order to implement sync-to-vblank,
things will go very wrong for cross-channel sync after this.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>