Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not even remotely ready for the vast majority of the world.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

User control of this has been hard-coded as disabled for now.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

Internal use only at this point.  Userspace later.
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>

These will diverge further in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is what NVIDIA do on these chipsets, let's hope it works around
the reported MSI failures for us on NV86.

v2: updated to include G92, as per information provided by NVIDIA.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

v2. updated to cover GF104, as per information provided by NVIDIA.
Reported-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The nv31/nv40 impls are actually fairly nv44-specific, since they assume
the presence of the instance register/context switching. Create a copy
before nv31/nv40 get fixed.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Generated context verified to be the same for all supported chipsets.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not really "core" per-se.  About to merge Ilia's work adding another
similar class for the VP2 xtensa engines, so, seems like a good time to
move all these to engine/.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

These are pretty much useless for reclocking purposes.  Lets make it
clearer what they're for and move them to DEVINIT to signify they're
for the very simple PLL setting requirements of running the init
tables.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

We need to be able to process interrupts before the DRM code is able to
actually enable them, set it up ourselves.  Also, it's less convoluted
to *not* use the DRM wrappers it appears...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It'd be pretty awesome if someone would care enough to port this all
properly to a class interface, perhaps submitting a command stream to
the core via a sw object on PFIFO (emulating how EVO works basically,
and also what nvidia have done forever..)..

But, this seems unlikely given how old this hardware is now, so, lets
just hide it away.

There's a heap of other bits and pieces laying around that are still
tangled.  I'll (re)move them in pieces.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is needed because temperature management on nv50 can be enabled and it
looks about the same as nv40.
Signed-off-by: NMartin Peres <martin.peres@labri.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>

If I build nouveau on ia64, Kconfig warns:

warning: (DRM_NOUVEAU) selects ACPI_WMI which has unmet direct dependencies (X86 && X86_PLATFORM_DEVICES && ACPI)
warning: (DRM_NOUVEAU) selects MXM_WMI which has unmet direct dependencies (X86 && X86_PLATFORM_DEVICES && ACPI_WMI)

Make all the ACPI support depend on X86 and select
X86_PLATFORM_DEVICES.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

We need to be able to do link training for PIOR-connected ANX9805 from
the third supervisor handler (due to script ordering in the bios, can't
have the "user" call train because some settings are overwritten from
the modesetting bios scripts).

This moves link training for SOR-connected DP encoders to the second
supervisor interrupt, *before* we call the modesetting scripts (yes,
different ordering from PIOR is necessary).  This is useful since we
should now be able to remove some hacks to workaround races between
the supervisor and link training paths.
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>

This removes the nastiness with the interactions between display and
software engines when handling vblank semaphore release interrupts.

Now, all the semantics are handled in one place (sw) \o/.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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