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

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

This is a HUGE commit, but it's not nearly as bad as it looks - any problems
can be isolated to a particular chipset and engine combination.  It was
simply too difficult to port each one at a time, the compat layers are
*already* ridiculous.

Most of the changes here are simply to the glue, the process for each of the
engine modules was to start with a standard skeleton and copy+paste the old
code into the appropriate places, fixing up variable names etc as needed.

v2: Marcin Slusarz <marcin.slusarz@gmail.com>
- fix find/replace bug in license header

v3: Ben Skeggs <bskeggs@redhat.com>
- bump indirect pushbuf size to 8KiB, 4KiB barely enough for userspace and
  left no space for kernel's requirements during GEM pushbuf submission.
- fix duplicate assignments noticed by clang

v4: Marcin Slusarz <marcin.slusarz@gmail.com>
- add sparse annotations to nv04_fifo_pause/nv04_fifo_start
- use ioread32_native/iowrite32_native for fifo control registers

v5: Ben Skeggs <bskeggs@redhat.com>
- rebase on v3.6-rc4, modified to keep copy engine fix intact
- nv10/fence: unmap fence bo before destroying
- fixed fermi regression when using nvidia gr fuc
- fixed typo in supported dma_mask checking
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Still the same code, but not an "engine" anymore.  The fence code is more of
a policy decision rather than exposing mechanisms, so it's not appropriate
to port it to the new engine subsystem.
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>

v2 (Ben Skeggs):
- some fixes for 64KiB PAGE_SIZE
- fix porting issues in (currently unused) nv41/nv44 pciegart code
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Having GPUOBJ and VM intertwined like this makes it *really* hard to
continue porting to the new driver architecture, split it out in
favour of requiring explit maps be the caller.

It's more flexible and obvious this way anyway...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

These type of fake objects will not be supported for much longer.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

A ton of duplication for the moment, will go away when they become subdevs.
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>

v2:
- make sure not to execute display scripts unless resuming
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Still missing the main bits we use to change performance levels, I'll get
to it after all the hard yakka has been finished.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

v2: Ben Skeggs <bskeggs@redhat.com>
- rebase on top of v3.6-rc6 with gpio reset patch integrated already
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Adds an extra layer of indirection to each register access, but it's not
too bad, and will also go away as pieces are ported.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These currently just call the existing ones in nouveau_drv.c, but will be
extended in upcoming commits.  This needed to be separated from the current
code as there will be some header clashes until things are ported.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Future work will be headed in the way of separating the policy supplied by
the nouveau drm module from the mechanisms provided by the driver core.

There will be a couple of major classes (subdev, engine) of driver modules
that have clearly defined tasks, and the further directory structure change
is to reflect this.

No code changes here whatsoever, aside from fixing up a couple of include
file pathnames.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fixes kernel panic when vblank interrupt triggers before first sync to
vblank request.

(Besides init, remove some relevant leftovers from vblank rework)
Reported-by: NOrtwin Glück <odi@odi.ch>
Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@vger.kernel.org [3.5]
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

These will be replaced in the near future, the code isn't yet stable enough
for this merge window however.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I want this file for the new interfaces...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Tested sharing to udl.
Signed-off-by: NDave Airlie <airlied@redhat.com>

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

Been tested on each major revision that's relevant here, but I'm sure there
are still bugs waiting to be ironed out.

This is a *very* invasive change.

There's a couple of pieces left that I don't like much (eg. other engines
using fifo_priv for the channel count), but that's an artefact of there
being a master channel list still.  This is changing, slowly.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

All the places this stuff is actually needed tends to be chipset-specific
anyway, so we're able to just inline the register bashing instead.

The parts of the common code that still directly touch PFIFO temporarily
have conditionals, these will be removed in subsequent commits that will
refactor the fifo modules into engine modules like graph/mpeg etc.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now have a somewhat simpler semaphore sync implementation for nv17:nv84,
and a switched to using semaphores as fences on nv84+ and making use of
the hardware's >= acquire operation.
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>

Just a cleanup more or less, and to remove the need for special handling of
software objects.

This removes a heap of documentation on dma/graph object formats.  The info
is very out of date with our current understanding, and is far better
documented in rnndb in envytools git.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The conditional definition of the generation helper functions apparently
confuses some IDEs....
Reported-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This may, perhaps, get re-merged with nvc0_graph.c at some point.  It's
still unclear as to how great an idea that'd be.  Stay tuned...

Completely dependent on firmware blobs from NVIDIA binary driver currently.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>