fb: Prevent inlining of ramfuc_reg

When gcc 4.8 inlines this function, it eats up 16 bytes on the stack
every time. Eventually we hit warnings because our stack grew too
much:

ramnve0.c:1383:1: error: the frame size of 1496 bytes is larger than
1024 bytes

We fix this by preventing inlining for this function.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
kms/nv50-: pass a non-zero value for head to sor dpms methods

There's Apple machines out there which (probably completely arbitrarily)
restrict each output path to a particular head.  This causes us to not
be able to locate the output data needed to power on/off the DP output
correctly.

We fix this by passing in a head index we know is valid (as opposed to
"head 0").

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
kms: restore fbcon after display has been resumed

Under some complicated circumstances (boot, suspend, resume, attach
second display, suspend, resume, suspend, detach second display,
resume, suspend, attach second display, resume), the fb_set_suspend()
call can somehow result in a modeset being attempted before we're
ready for it and things blow up in fun ways.

Running display init first fixes the issue.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
kms: take more care when pulling down accelerated fbcon

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
kms: restore acceleration before fb_set_suspend() resumes

This *should* be safe these days.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm: pull in some missing bits from kernel tree

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm: support for probing platform devices

Add a platform driver for Nouveau devices declared using the device tree
or platform data. This driver currently supports GK20A on Tegra
platforms and is only compiled for these platforms if Nouveau is
enabled.

Nouveau will probe the chip type itself using the BOOT0 register, so all
this driver really needs to do is to make sure the module is powered and
its clocks active before calling nouveau_drm_platform_probe().

Heavily based on work done by Thierry Reding.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
disp/dp: fix required link bandwidth calculations

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
perfmon: Add simple hardware events on domain 1 for nva3 chipset

These events use a 8-bits signal and the 0xaaaa logic operation.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Store the signal source (8-bits) in the nouveau_perfsig struct

This will allow us to monitor hardware events using up to 4 signals
(32-bits).

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Remove unused function nouveau_perfsig_wrap()

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Replace nouveau_perfsig in favour of nouveau_specsig

These two data structs are similar.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: s/signal/src in nouveau_specsig struct

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Do not use the signal source as index

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Make use of 32-bits signal

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Store the logical operation of a signal in nouveau_specsig

The logical operation of complex hardware events using up to 4 signals
is not 0xaaaa and have to be specified.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Add more hardware events for nva3 chipset

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Add support for multiplexers

This introduces a new struct nouveau_specmux with a couple (reg, val)
which can be used to define a mux.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Add complex hardware events for nva3 chipsets

All of these signals use multiplexers.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
perfmon: Allow to specify more than one counters per hardware event

This will allow us to configure complex hardware events using the
special counter modes like EVENT_B4 and EVENT_B6.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>