gm20b's FB has the same capabilities as gm200, minus the ability to
allocate RAM. Create a device that reflects this instead of re-using the
gk20a device which may be incorrect.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-By: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

gk20a's FB is not special compared to other Kepler chips, besides the
fact it does not have VRAM. Use the regular gf100 hooks instead of the
incomplete versions we rewrote.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-By: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The gf100 constructor should be called, otherwise we will allocate a
smaller object than expected. This was without effect so far because
gk20a did not allocate a page, but with gf100's page allocation moved
to the oneinit() hook this problem has become apparent.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The reset hook of pmu_func is never called, and gt215 was the only chip
to implement. Remove this dead code.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There is no reason to not free the notify data if the NTFY_DEL ioctl
failed. As nvif_notify_fini() is also called from the cleanup path of
nvif_notify_init(), the notifier may not have been successfully created
at that point. But it should also be the right thing to just free the
data in the regular fini calls, as there is nothing much we can do if
the ioctl fails, so better not leak memory.
Signed-off-by: NLucas Stach <dev@lynxeye.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

uevent based fences hold a reference to the fence context,
just like the legacy ones. So they need to drop this reference
in the same way.
Signed-off-by: NLucas Stach <dev@lynxeye.de>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

gcc-4.9 notices that the validate_init() function returns unintialized
data when called with a zero 'nr_buffers' argument, when called with the
-Wmaybe-uninitialized flag:

drivers/gpu/drm/nouveau/nouveau_gem.c: In function ‘validate_init.isra.6’:
drivers/gpu/drm/nouveau/nouveau_gem.c:457:5: error: ‘ret’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

However, the only caller of this function always passes a nonzero
argument, and gcc-6 is clever enough to take this into account and
not warn about it any more.

Adding an explicit initialization to -EINVAL here is correct even if
the caller changed, and it avoids the warning on gcc-4.9 as well.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-By: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous prototype for 'nvbios_fan_table' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:56:1: warning: no previous prototype for 'nvbios_fan_entry' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous prototype for 'gt215_clk_info' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:99:1: warning: no previous prototype for 'gt215_link_train_calc' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no previous prototype for 'gt215_link_train' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:271:1: warning: no previous prototype for 'gt215_link_train_init' [-Wmissing-prototypes]
....

In fact, both functions are only used in the file in which they are
declared and don't need a declaration, but can be made static.
So this patch marks these functions with 'static'.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous prototype for 'nvkm_sddr3_calc' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr2.c:60:1: warning: no previous prototype for 'nvkm_sddr2_calc' [-Wmissing-prototypes]
....

In fact, these functions are declared in
drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ram.h
drivers/gpu/drm/nouveau/nvkm/subdev/volt/priv.h
drivers/gpu/drm/nouveau/nvkm/engine/gr/nv50.h
drivers/gpu/drm/nouveau/dispnv04/disp.h.
So this patch adds missing header dependencies.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

DPAUX registers moved on Kepler, these chipsets were still using the
Fermi implementation for some reason.

This fixes detection of hotplug/sink IRQs on DP connectors.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

This fixes (works around?) link training failures seen on (at least)
the Lenovo P50's internal panel.

It's also an important fix on the same system for MST support on the
dock.  Sometimes, right after receiving an IRQ from the sink, there's
an error bit (SINKSTAT_ERR) set in the DPAUX registers before we've
even attempted a transaction.

v2. Fixed regression on passive DP->DVI adapters.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

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

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

Check whether the kernel really supports power resources for a device,
otherwise the power might not be removed when the device is runtime
suspended (DSM should still work in these cases where PR does not).

This is a workaround for a problem where ACPICA and Windows 10 differ in
behavior. ACPICA does not correctly enumerate power resources within a
conditional block (due to delayed execution of such blocks) and as a
result power_resources is set to false even if _PR3 exists.

Fixes: 692a17dc ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")
Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398Reported-and-tested-by: NRick Kerkhof <rick.2889@gmail.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: NPeter Wu <peter@lekensteyn.nl>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes a regression in all these drivers since the cache
mode tracking was fixed for mixed mappings. It uses the new
arch API to add the VRAM range to the PAT mapping tracking
tables.

Fixes: 87744ab3 (mm: fix cache mode tracking in vm_insert_mixed())
Reviewed-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This way the driver can decide if it is valuable to evict a BO or not.

The current implementation is added as default to all existing drivers.

v2: fix some typos found during internal testing
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>

I plan to usurp the short name of struct fence for a core kernel struct,
and so I need to rename the specialised fence/timeline for DMA
operations to make room.

A consensus was reached in
https://lists.freedesktop.org/archives/dri-devel/2016-July/113083.html
that making clear this fence applies to DMA operations was a good thing.
Since then the patch has grown a bit as usage increases, so hopefully it
remains a good thing!

(v2...: rebase, rerun spatch)
v3: Compile on msm, spotted a manual fixup that I broke.
v4: Try again for msm, sorry Daniel

coccinelle script:
@@

@@
- struct fence
+ struct dma_fence
@@

@@
- struct fence_ops
+ struct dma_fence_ops
@@

@@
- struct fence_cb
+ struct dma_fence_cb
@@

@@
- struct fence_array
+ struct dma_fence_array
@@

@@
- enum fence_flag_bits
+ enum dma_fence_flag_bits
@@

@@
(
- fence_init
+ dma_fence_init
|
- fence_release
+ dma_fence_release
|
- fence_free
+ dma_fence_free
|
- fence_get
+ dma_fence_get
|
- fence_get_rcu
+ dma_fence_get_rcu
|
- fence_put
+ dma_fence_put
|
- fence_signal
+ dma_fence_signal
|
- fence_signal_locked
+ dma_fence_signal_locked
|
- fence_default_wait
+ dma_fence_default_wait
|
- fence_add_callback
+ dma_fence_add_callback
|
- fence_remove_callback
+ dma_fence_remove_callback
|
- fence_enable_sw_signaling
+ dma_fence_enable_sw_signaling
|
- fence_is_signaled_locked
+ dma_fence_is_signaled_locked
|
- fence_is_signaled
+ dma_fence_is_signaled
|
- fence_is_later
+ dma_fence_is_later
|
- fence_later
+ dma_fence_later
|
- fence_wait_timeout
+ dma_fence_wait_timeout
|
- fence_wait_any_timeout
+ dma_fence_wait_any_timeout
|
- fence_wait
+ dma_fence_wait
|
- fence_context_alloc
+ dma_fence_context_alloc
|
- fence_array_create
+ dma_fence_array_create
|
- to_fence_array
+ to_dma_fence_array
|
- fence_is_array
+ dma_fence_is_array
|
- trace_fence_emit
+ trace_dma_fence_emit
|
- FENCE_TRACE
+ DMA_FENCE_TRACE
|
- FENCE_WARN
+ DMA_FENCE_WARN
|
- FENCE_ERR
+ DMA_FENCE_ERR
)
 (
 ...
 )
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Acked-by: NChristian König <christian.koenig@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161025120045.28839-1-chris@chris-wilson.co.uk

Since fence_wait_timeout_reservation_object_wait_timeout_rcu() with a
timeout of 0 becomes reservation_object_test_signaled_rcu(), we do not
need to handle such conversion in the caller. The only challenge are
those callers that wish to differentiate the error code between the
nonblocking busy check and potentially blocking wait.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20160829070834.22296-4-chris@chris-wilson.co.uk

The 100c08 scratch page is mapped using dma_map_page() before the TTM
layer has had a chance to set the DMA mask. This means we are still
running with the default of 32 when this code executes, and this causes
problems for platforms with no memory below 4 GB (such as AMD Seattle)

So move the dma_map_page() to the .oneinit hook, which executes after the
DMA mask has been set.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The 100c10 scratch page is mapped using dma_map_page() before the TTM
layer has had a chance to set the DMA mask. This means we are still
running with the default of 32 when this code executes, and this causes
problems for platforms with no memory below 4 GB (such as AMD Seattle)

So move the dma_map_page() to the .oneinit hook, which executes after the
DMA mask has been set.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Some subdevices (i.e., fb/nv50.c and fb/gf100.c) map a scratch page using
dma_map_page() way before the TTM layer has had a chance to set the DMA
mask. This may prevent the driver from loading at all on platforms whose
system memory is not covered by the default DMA mask of 32-bit (i.e., when
all RAM is above 4 GB).

So set a preliminary DMA mask right after constructing the PCI device, and
base it on the .dma_bits member of the MMU subdevice, which is what the TTM
layer will base the DMA mask on as well.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NFaris Alsalama <farisbenbrahem@gmail.com>
Acked-by: NAcked-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The BAR2 page table was being made WAY too big - oops.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We get 1 warning when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/engine/disp/sorg94.c:49:1: warning: no previous prototype for 'g94_sor_output_new' [-Wmissing-prototypes]

In fact, this function is called by no one and not exported,
so this patch removes it.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Doing direct 64 bit divisions in kernel code leads to references to
undefined symbols on 32 bit architectures. Replace such divisions with
calls to div64_s64 to make the module usable on 32 bit archs.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Reviewed-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]

In fact, both functions are declared in
drivers/gpu/drm/nouveau/include/nvkm/core/firmware.h,
so this patch adds missing header dependencies.
Signed-off-by: NBaoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Tested on a NV34. There are reports of this also working on the other
nv3x chips. Largely useful for testing software written for NV2x without
having the actual hardware available.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We received a donation of a Titan which has this useless feature
allowing users to control the brightness of the LED behind the
logo of NVIDIA. In the true spirit of open source, let's expose
that to the users of very expensive cards!

This patch hooks up this LED/PWM to the LED subsystem which allows
blinking it in sync with cpu/disk/network/whatever activity (heartbeat
is quite nice!). Users may also implement some breathing effect or
morse code support in the userspace if they feel like it.

v2:
 - surround the use of the LED framework with ifdef CONFIG_LEDS_CLASS

v3:
 - avoid using ifdefs everywhere, follow the recommendations of
   /doc/Documentation/CodingStyle. Suggested by Emil Velikov.

v4 (Ben):
 - squashed series of fixes from ml
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This enables memory reclocking on Maxwell. Sadly without a PMU firmware it
is useless for gm20x gpus.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I'm quite sure that those coefficients are real close, because while
testing the biggest error compared to nvidia was around -1.5% (biggest
error with right coefficients is 12.5mV / 600mV = 2%).

These coefficients were REed by modifing the voltage map entries and by
calculating the set voltage back until I was able to forecast which voltage
nvidia sets for a given voltage map entry.

With these formulars I am able to precisely predict at which exact
temperature Nvidia down- or upvolts due to a changed therm reading.

That's why I am quite sure these are right, or at least really really
close.

v4: Use better coefficients and speedo.
v5: Add error message when speedo is missing.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

v5: Squashed speedo related commits.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Since gf100 we need a speedo value for calculating the voltage. The readout
will be added in a later patch.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Depending on the value a different formular is used to calculated the
voltage for this entry.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

If we calculate the voltage in the table right, we get all kinds of values,
which never fit the hardware steps, so we use the closest higher value the
hardware can do.

v3: Simplify the implementation.
v5: Initialize best_err with volt->max_uv.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

0: base clock from the vbios is max clock (default)
1: boost only to boost clock from the vbios
2: boost to max clock available

v2: Moved into nvkm_cstate_valid.
v4: Check the existence of the clocks before limiting.
v5: Default to boost level 0.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This table contains three important clocks:

base  clock: This is the non boosted max clock.
tdp   clock: The clock at wich the vbios guarentees the TDP won't ever be
             exceeded at max load (seems to be always the same as the base
             clock, but behaves differently).
boost clock: The avg clock the gpu will stay boosted to. It doesn't seem to
             affect the behaviour of the nvidia driver at all though.

v2: Make clear that base/boost/tdp fields are ids.
v5: Rename Base clock to vpstate.
    Make vbios pointers 32bit.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We should never allow to select a cstate which current voltage (depending
on the temperature) is higher than

1. the max volt entries in the voltage map table.
2. what tha gpu actually can volt to.

v3: Use find_best for all cstates before actually trying.
    Add nvkm_cstate_get function to get cstate by index.
v5: Cstates with voltages lower then min_uv are valid.
    Move nvkm_cstate_get into the previous commit.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Now the cstatei parameter can be used of the nvkm_cstate_prog function to
select a specific cstate.

v5: Make a constant for the magic value.
    Use list_last_entry.
    Add nvkm_cstate_get here instead of in the next commit.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The voltage entries actually may map to a different voltage depending on
the current temperature.

v2: Only read the temperature when actually needed.
v5: Be smarter about using max().
    Don't read the temperature anymore.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>