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>

This way other subdevs can notify the clk subdev about temperature changes
without the need of clk to poll that value.

Also make this function safe to be called from an interrupt handler.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

It is better to read out the id out of the cstate struct directly instead
of iterating over the list of cstates over and over again. Especially when
we start saving pointers to a nvkm_cstate struct, it makes things easier.

v5: Rename field to id.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Each pstate has its own voltage map entry like each cstate has.

The voltages of those entries act as a floor value for the currently
selected pstate and nvidia never sets a voltage below them.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There are at least three "max" entries, which specify the max voltage.
Because they are actually normal voltage map entries, they can also be
affected by the temperature.

Nvidia respects those entries and if they get changed, nvidia uses the
lower voltage from all three.

We shouldn't exceed those voltages at any given time.

v2: State what those entries do in the source.
v3: Add the third max entry.
v5: Better describe the entries.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nvkm_volt_map_min is a copy of nvkm_volt_map, which always returns the
lowest possible voltage for a cstate.

nvkm_volt_map will get a temperature parameter there later and also fix
the voltage calculation, so that this functions will be completly
different later.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There is a field in the voltage table which tells us if the VIDs are taken
from the entries or calculated through the header.

v2: Don't break older versions.
v5: Reverse flag name.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Some Fermi+ GPUs specify VID information via voltage table entries, rather
than describing them as a range in the header.

The mask may be bigger than 0x1fffff, but this value is already >2V, so it
will be fine for now.

This patch fixes volting issues on those cards enabling them to switch
cstates.

v6: rework message
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Tested-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Tested-by: NAidan Epstein <aidan@jmad.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Previously we parsed that table a bit wrong:
1. The entry layout depends on the sensor type used.
2. We have all resitors in one entry for the INA3221.
3. The config is already included in the vbios.

This commit addresses that issue and with that we should be able to read
out the right power consumption for every GPU with a INA209, INA219 and
INA3221.
Signed-off-by: NKarol Herbst <karolherbst@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This can show up on SPARC or other architectures that don't handle
unaligned accesses. The kernel normally fixes these up, but it shouldn't
have to.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96836Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

gk20a_ibus_init_ibus_ring() can be called from gk20a_ibus_intr(), in
non-interruptible context. Replace use of usleep_range() with udelay().
Reported-by: NThierry Reding <treding@nvidia.com>
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Just flushing out my -misc queue. Slightly important are the prime
refcount/unload fixes from Chris.

There's also the reservation stuff from Chris still pending, and Sumits
hasn't landed that yet. Might get another pull for that, but pls don't
hold up the main pull for it ;-)

* tag 'topic/drm-misc-2016-10-11' of git://anongit.freedesktop.org/drm-intel:
  drm/crtc: constify drm_crtc_index parameter
  drm: use the right function name in documentation
  drm: Release resources with a safer function
  drm: Fix up kerneldoc for new drm_gem_dmabuf_export()
  drm/bridge: Drop drm_connector_unregister and call drm_connector_cleanup directly
  drm/fb-helper: fix sphinx markup for DRM_FB_HELPER_DEFAULT_OPS
  drm/bridge: Add RGB to VGA bridge support
  drm/prime: Take a ref on the drm_dev when exporting a dma_buf
  drm/prime: Pass the right module owner through to dma_buf_export()
  drm/bridge: Call drm_connector_cleanup directly
  drm: simple_kms_helper: Add prepare_fb and cleanup_fb hooks
  drm: Release resources with a safer function

Merge tag 'drm-intel-next-fixes-2016-10-11' of git://anongit.freedesktop.org/drm-intel into drm-next

A big bunch of i915 fixes for drm-next / v4.9 merge window, with more
than half of them also cc: stable. We also continue to have more Fixes:
annotations for our fixes, which should help the backporters and
archeologists.

* tag 'drm-intel-next-fixes-2016-10-11' of git://anongit.freedesktop.org/drm-intel: (27 commits)
  drm/i915: Fix conflict resolution from backmerge of v4.8-rc8 to drm-next
  drm/i915/guc: Unwind GuC workqueue reservation if request construction fails
  drm/i915: Reset the breadcrumbs IRQ more carefully
  drm/i915: Force relocations via cpu if we run out of idle aperture
  drm/i915: Distinguish last emitted request from last submitted request
  drm/i915: Allow DP to work w/o EDID
  drm/i915: Move long hpd handling into the hotplug work
  drm/i915/execlists: Reinitialise context image after GPU hang
  drm/i915: Use correct index for backtracking HUNG semaphores
  drm/i915: Unalias obj->phys_handle and obj->userptr
  drm/i915: Just clear the mmiodebug before a register access
  drm/i915/gen9: only add the planes actually affected by ddb changes
  drm/i915: Allow PCH DPLL sharing regardless of DPLL_SDVO_HIGH_SPEED
  drm/i915/bxt: Fix HDMI DPLL configuration
  drm/i915/gen9: fix the watermark res_blocks value
  drm/i915/gen9: fix plane_blocks_per_line on watermarks calculations
  drm/i915/gen9: minimum scanlines for Y tile is not always 4
  drm/i915/gen9: fix the WaWmMemoryReadLatency implementation
  drm/i915/kbl: KBL also needs to run the SAGV code
  drm/i915: introduce intel_has_sagv()
  ...

Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1476113170-13816-1-git-send-email-jani.nikula@intel.com

The conflict resolution of v4.8-rc8 backmerge to drm-next pulled back in
a few lines of dead code due to the code movement around
i915_gem_reset(), fix that up.

Fixes: ca09fb9f ("Merge tag 'v4.8-rc8' into drm-next")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161010125017.23911-1-chris@chris-wilson.co.uk

We reserve space in the GuC workqueue for submitting the request in the
future. However, if we fail to construct the request, we need to give
that reserved space back to the system.

Fixes: dadd481b ("drm/i915/guc: Prepare for nonblocking execbuf submission")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97978Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-4-chris@chris-wilson.co.uk
(cherry picked from commit 5ba89908)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Along with the interrupt, we want to restore the fake-irq and
wait-timeout detection. If we use the breadcrumbs interface to setup the
interrupt as it wants, the auxiliary timers will also be restored.

v2: Cancel both timers as well, sanitize the IMR.

Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-3-chris@chris-wilson.co.uk
(cherry picked from commit ad07dfcd)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

If we run out of enough aperture space to fit the entire object, we
fallback to trying to insert a single page. However, if that also fails,
we currently fail to userspace with an unexpected ENOSPC. (ENOSPC means
to userspace that their batch could not be fitted within the GTT.) Prior
to commit e8cb909a ("drm/i915: Fallback to single page GTT
mmappings for relocations") the approach is to fallback to using the
slow CPU relocation path in case of iomapping failure, and that is the
behaviour we need to restore.

Fixes: e8cb909a ("drm/i915: Fallback to single page GTT mmappings...")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98101Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-2-chris@chris-wilson.co.uk
(cherry picked from commit d7f76335)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

In order not to trigger hangcheck on a idle-but-waiting engine, we need
to distinguish between the pending request queue and the actual
execution queue. This is done later in "drm/i915: Enable multiple
timelines" but for now we need a temporary fix to prevent blaming the
wrong engine for a GPU hang.

(Note that this causes a temporary subtle change in how we decide when
to allow a waitboost to be re-awarded back to the waiter, the temporary
effect is that if the wait is upon the most current execution the wait
is given for free, instead of checking to see if the client stalled
itself. This will be repaired in "drm/i915: Enable multiple timelines".)

Fixes: 0a046a0e ("drm/i915: Nonblocking request submission")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98104Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161007065327.24515-1-chris@chris-wilson.co.uk
(cherry picked from commit 8687b3ec)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Allow returning "connected" or "unknown" connector status for DP branch
devices that don't have an EDID. Currently we'd claim the thing as
"disconnected" if there is no EDID.

This stuff used to broken already, I think, but it got more broken by
commit f21a2198 ("drm/i915: Splitting intel_dp_detect")

Cc: Damien Cassou <damien@cassou.me>
Cc: freedesktop.org@gp.mailgun.org
Cc: Arno <blouin.arno@gmail.com>
Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: stable@vger.kernel.org
Tested-by: NArno <blouin.arno@gmail.com>
Fixes: f21a2198 ("drm/i915: Splitting intel_dp_detect")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
(cherry picked from commit 5cb651a7)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

We can't rely on connector->status in the detect() hook if the long hpd
was already handled by the dig_port_work as that won't update
connector->status. Thus we have to defer the long hpd handling entirely
until the hotplug work runs to avoid the double long hpd handling
the "detect_done" flag is trying to prevent.

We'll start to depend on connector->status being up to date in a
following patch.

Cc: Damien Cassou <damien@cassou.me>
Cc: freedesktop.org@gp.mailgun.org
Cc: Arno <blouin.arno@gmail.com>
Cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Cc: stable@vger.kernel.org
Tested-by: NArno <blouin.arno@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83348Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1475481316-8194-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
(cherry picked from commit 27d4efc5)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

On Braswell, at least, we observe that the context image is written in
multiple phases. The first phase is to clear the register state, and
subsequently rewrite it. A GPU reset at the right moment can interrupt
the context update leaving it corrupt, and our update of the RING_HEAD
is not sufficient to restart the engine afterwards. To recover, we need
to reset the registers back to their original values. The context state
is lost. What we need is a better mechanism to serialise the reset with
pending flushes from the GPU.

Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161004201132.21801-2-chris@chris-wilson.co.uk
(cherry picked from commit a3aabe86)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>