A variety of tweaks to the NVIF library interfaces, mostly ripping out
things that turned out to be not so useful.

- Removed refcounting from nvif_object, callers are expected to not be
  stupid instead.
- nvif_client is directly reachable from anything derived from nvif_object,
  removing the need for heuristics to locate it
- _new() versions of interfaces, that allocate memory for the object
  they construct, have been removed.  The vast majority of callers used
  the embedded _init() interfaces.
- No longer storing constructor arguments (and the data returned from
  nvkm) inside nvif_object, it's more or less unused and just wastes
  memory.
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>

Userspace has started doing this, which upsets the display class hw
error checking in various unpleasant ways.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver.  This is being
done in order to make it very clear as to what part of the driver a
given symbol belongs to, and as a minor step towards splitting the
DRM driver out to be able to stand on its own (for virt).

Because there's already a large amount of churn here anyway, this is
as good a time as any to also switch to NVIDIA's device and chipset
naming to ease collaboration with them.

A comparison of objdump disassemblies proves no code changes.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

NVKM is having it's namespace switched to nvkm_, which will conflict
with these functions (which are workarounds for the fact that as of
yet, we still aren't able to split DRM and NVKM completely).

A comparison of objdump disassemblies proves no code changes.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Restore the nv50 cursor bo on resume, and load the lut in
nv50_display_display_init so it gets set on resume too.

Tested on a fermi and a curie.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@ubuntu.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Looks like a userspace bug can trigger this somehow during a mode
switch, causing: EVO complaint -> semaphores get out of sync ->
entire display stalled.

We likely want to be even stricter than this (or at least deal
better if EVO rejects our request), but I'll save that for the
drm_plane/atomic conversion and just fix the bug that I already
know can be triggered.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The hilarious part is that, under X, this won't work anyway because the
server decides to construct its own modes for some reason.

Tested with modetest, which isn't quite as insane.  I'd hope that
wayland is more sensible.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

We'll move them at pin() time if necessary.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Preparation for transition to planes, which use framebuffers for the
cursor image.  We've always done copies from the userspace buffer up
until now for legacy reasons, there's no good reason to do so on the
chipsets this code covers.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

We have the ability to move buffers around in the kernel if necessary,
and should probably use it rather than failing if userspace passes us
a non-contig buffer for a plane.

The NOUVEAU_GEM_TILE_NONCONTIG flag from userspace will become a mere
initial placement hint once all the relevant paths have been updated.
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>

The Baseline_ELD_Len field does not include ELD Header Block size.

From High Definition Audio Specification, Revision 1.0a:

	The header block is a fixed size of 4 bytes. The baseline block
	is variable size in multiple of 4 bytes, and its size is defined
	in the header block Baseline_ELD_Len field (in number of
	DWords).

Do not include the header size in Baseline_ELD_Len field. Fix all known
users of eld[2].

While at it, switch to DIV_ROUND_UP instead of open coding it.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NDave Airlie <airlied@linux.ie>
[danvet: Fix compile fail in nouveau.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Commit 1dce6264 introduced a regression
spotted on several G94 (FDObz #85160). This device seems to expect the
vblank period to be set after setting scale instead of before.

V2: shove this in a separate function

This is a candidate bug-fix for 3.18
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Tested-by: NZlatko Calusic <zcalusic@bitsync.net>
Tested-by: NMichael Riesch <michael@riesch.at>
Tested-by: N"poma" <pomidorabelisima@gmail.com>
Tested-by: NAdam Williamson <adamw@happyassassin.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Just a bit of OCD cleanup on headers - this function isn't the core
interface any more but just a helper for drivers who haven't yet
transitioned to universal planes. Put the declaration at the right
spot and sprinkle necessary #includes over all drivers.

Maybe this helps to encourage driver maintainers to do the switch.

v2: Fix #include ordering for tegra, reported by 0-day builder.

v3: Include required headers, reported by Thierry.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Adds an extra argument to nouveau_bo_new, which is only used in nouveau_prime.c.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.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>

Solves blinking on reclocking memory. The value set is an underestimate, but
with non-reduced vblanking this should give us plenty of time
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

One of the next commits will remove some of the class IDs, leaving only
the ones used by NVIDIA which, presumably, mark where functionality
changes actually happened.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The full object interfaces are about to be exposed to userspace, so we
need to check for any security-related issues and version the structs
to make it easier to handle any changes we may need in the future.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>