Commit Graph

576985 Commits

Author SHA1 Message Date
Alexandre Courbot f2a0adadeb drm/nouveau: silence unimportant HDMI status message
On non-PCI devices, nobody should really care if the device does not
provide HDMI...

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:32 +10:00
Alexandre Courbot 9bcd38de5b drm/nouveau/bo: consider DMA buffers on x86 only
The DMA API has different semantics on different architectures.
Currently on arm64, it can only provide memory from a small pool which
dries up quickly if we attempt to allocate big buffers from it.

Do not consider that option when running on non-x86, since regular TTM
buffers are the (current) best-fit for ARM platforms.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:32 +10:00
Alexandre Courbot ab08f38cac drm/nouveau/ltc/gf100: use more reasonable timeout value
LTC operations timeout was set to 2ms, which may be too low for devices
that run at very low clocks (e.g. GM20B) and trigger timeout messages.

Set the timeout to the default 2s. Also remove the redundant error
messages since nvkm_wait_msec() will already display a warning.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:31 +10:00
Alexandre Courbot a2e435a1b0 drm/nouveau/fifo/gk104: take runlist target into account
Bits 28:29 of RUNLIST_BASE specify the memory target of the runlist. Set
it to 0x3 (SYS_MEM_NONCOHERENT) if the runlist object resides in system
memory.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:31 +10:00
Alexandre Courbot c694ecad9d drm/nouveau/fifo/gf100: take runlist target into account
Bits 28:29 of RUNLIST_BASE specify the memory target of the runlist. Set
it to 0x3 (SYS_MEM_NONCOHERENT) if the runlist object resides in system
memory.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:30 +10:00
Xia Yang 0689aad70d drm/nouveau/fifo/gk104: fix chid bit mask
Fix the channel id bit mask in FIFO schedule timeout error handling.

FIFO_ENGINE_STATUS_NEXT_ID is bit 27:16 thus 0x0fff0000.
FIFO_ENGINE_STATUS_ID      is bit 11:0  thus 0x00000fff.

Signed-off-by: Xia Yang <xiay@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:30 +10:00
Alexandre Courbot 9d0394c6be drm/nouveau/instmem/gk20a: set DMA mask early
DMA mask is typically set in nouveau_ttm_init(), but this function is
called late during initialization and GK20A's instmem will have called
DMA functions before this happens.

Having a wrongly set DMA mask can result in the use of unneeded bounce
buffers. Set it early to avoid this.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:29 +10:00
Ben Skeggs 7d31cb7ca4 drm/nouveau/gr/gm206: remove implementation, it's now identical to gm200
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:29 +10:00
Ben Skeggs 5f7e8028c7 drm/nouveau/gr/gm200: switch over to using sw_nonctx from firmware
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:28 +10:00
Ben Skeggs d4a43a612a drm/nouveau/gr/gm200: switch over to using sw_method_init from firmware
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:28 +10:00
Ben Skeggs c0e8550dbf drm/nouveau/gr/gm200: switch over to using sw_bundle_init from firmware
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:27 +10:00
Ben Skeggs 43bc83b9b0 drm/nouveau/gr/gm200: switch over to using sw_ctx from firmware
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:27 +10:00
Karol Herbst b774c40b1c drm/nouveau/bios/extdev: also parse v4.1 table
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
2016-03-14 10:13:26 +10:00
Karol Herbst eb72ed5dc8 drm/nouveau/hwmon: don't require therm to be valid to get any data
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
2016-03-14 10:13:26 +10:00
Karol Herbst 353b983440 drm/nouveau/hwmon: add power consumption
v2: expose only if the sensor reading is valid

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
2016-03-14 10:13:26 +10:00
Karol Herbst b71c089263 drm/nouveau/iccsense: implement for ina209, ina219 and ina3221
based on Martins initial work

v3: fix ina2x9 calculations
v4: don't kmalloc(0), fix the lsb/pga stuff
v5: add a field to tell if the power reading may be invalid
    add nkvm_iccsense_read_all function
    check for the device on the i2c bus

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
2016-03-14 10:13:25 +10:00
Martin Peres 39b7e6e547 drm/nouveau/nvbios/iccsense: add parsing of the SENSE table
Karol Herbst:
v4: don't kmalloc(0)
v5: stricter validation

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
2016-03-14 10:13:25 +10:00
Martin Peres dc06e366fe drm/nouveau/subdev/iccsense: add new subdev for power sensors
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
2016-03-14 10:13:24 +10:00
Alexandre Courbot 923f1bd27b drm/nouveau/secboot/gm20b: add secure boot support
Add secure boot support for the GM20B chip found in Tegra X1. Secure
boot on Tegra works slightly differently from desktop, notably in the
way the WPR region is set up.

In addition, the firmware bootloaders use a slightly different header
format.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:24 +10:00
Alexandre Courbot 9cc4552149 drm/nouveau/secboot/gm200: add secure-boot support
Add secure-boot for the dGPU set of GM20X chips, using the PMU as the
high-secure falcon.

This work is based on Deepak Goyal's initial port of Secure Boot to
Nouveau.

v2. use proper memory target function

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:23 +10:00
Alexandre Courbot 82babeaf75 drm/nouveau/gr/gm200: do not load firmware for secure falcons
Secure falcons' firmware is managed by secboot. Do not load it in GR for
them.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:23 +10:00
Alexandre Courbot c9469aae5e drm/nouveau/gr/gf100: add support for securely-managed falcons
Start securely-managed falcons using secboot functions since the process
for them is different from just writing CPUCTL.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:22 +10:00
Alexandre Courbot 7d12388a1f drm/nouveau/core: add support for secure boot
On GM200 and later GPUs, firmware for some essential falcons (notably
GR ones) must be authenticated by a NVIDIA-produced signature and
loaded by a high-secure falcon in order to be able to access privileged
registers, in a process known as Secure Boot.

Secure Boot requires building a binary blob containing the firmwares
and signatures of the falcons to be loaded. This blob is then given to
a high-secure falcon running a signed loader firmware that copies the
blob into a write-protected region, checks that the signatures are
valid, and finally loads the verified firmware into the managed falcons
and switches them to privileged mode.

This patch adds infrastructure code to support this process on chips
that require it.

v2:
- The IRQ mask of the PMU falcon was left - replace it with the proper
  irq_mask variable.
- The falcon reset procedure expecting a falcon in an initialized state,
  which was accidentally provided by the PMU subdev. Make sure that
  secboot can manage the falcon on its own.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:22 +10:00
Alexandre Courbot f008d8c7b2 drm/nouveau/gr/gm200: load external firmware and bundles
Load firmware and bundles in GM200's constructor. The previously called
GF100 function did not care about the bundles.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:21 +10:00
Alexandre Courbot 2e404b0da9 drm/nouveau/gr/gk20a: share external bundles loading functions
There functions are going to be used by other chips that rely on
NVIDIA-provided firmware. Export them.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:21 +10:00
Alexandre Courbot 5986d3e13b drm/nouveau/gr/gk20a: simplify external bundle loading functions
Make these functions easier to use by handling memory management from
within.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:20 +10:00
Alexandre Courbot 18cd5bc8ea drm/nouveau/gr/gf100: load firmware in outer function
The firmwares required by GR may vary from chip to chip, especially with
the introduction of secure boot and NVIDIA-provided firmwares. Move the
firmware loading outside of gf100_gr_ctor so other chips may still call
it while managing their firmwares themselves.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:20 +10:00
Alexandre Courbot 336c46524f drm/nouveau/gr/gk20a: move firmware bundle release to gf100
Some members of gf100_gr were freed by the gk20a driver. That's not
where it should be done - free them in gf100 so other chips that use
NVIDIA-provided firmware free these structures properly.

This also removes the need for a GK20A-specific destructor.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:19 +10:00
Alexandre Courbot 5d2083d2f9 drm/nouveau/core: add gpuobj memcpy helper functions
Add memcpy functions to copy a buffer to a gpuobj and vice-versa. This
will be used by the secure boot code.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:19 +10:00
Ben Skeggs 96fc422c27 drm/nouveau/gm200: enable graphics device
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:18 +10:00
Ben Skeggs 9ec280529a drm/nouveau/gr/gm200: s/gm204/gm200/
Most of the per-chipset differences will go away when we fully switch
to using the register lists provided by the firmware files, which will
leave all the remaining code "belonging" to GM200.

This is a preemptive rename from GM204 to GM200.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:18 +10:00
Ben Skeggs e24c9c44d7 drm/nouveau/bios/devinit: properly handle unknown generic conditions
Upon encountering an unknown condition code, the script interpreter
is supposed to skip 'size' bytes and continue at the next devinit
token.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:17 +10:00
Ben Skeggs 989f578473 drm/nouveau/bios/devinit: rename INIT_DP_CONDITION to INIT_GENERIC_CONDITION
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:17 +10:00
Ben Skeggs 96aedd0ba9 drm/nouveau/ltc/gm107: fix slice intr offset
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:16 +10:00
Alexandre Courbot a6a0f67ca7 drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit
It is not advisable to perform devinit if it has already been done.
VBIOS will very likely have invoked devinit if the GPU is the primary
graphics device, but there is no accurate way to detect this fact yet.

This patch adds such a method for gf100 and later chips, by means of the
NV_PTOP_SCRATCH1_DEVINIT_COMPLETED bit. This bit is set to 1 by devinit,
and reset to 0 when the GPU is powered.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:16 +10:00
Alexandre Courbot 8fb1240a71 drm/nouveau/devinit/nv50: remove unneeded variable
We never use any nv50-specific member in this nv50_devinit_preinit().

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:15 +10:00
Ben Skeggs db1eb52846 drm/nouveau: s/gm204/gm200/ in a number of places
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:12 +10:00
Ben Skeggs 2ed95a4c65 drm/nouveau: recognise GM200 chipset
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:13:06 +10:00
Alexandre Courbot 1b82111fae drm/nouveau/device/tegra: fix uninitialized IRQ number
nvkm_device_tegra_new initializes the irq member of the Tegra device
to -1 in order to signal that it is uninitialized. However,
nvkm_device_tegra_fini tests it against 0 to check whether an IRQ has
been allocated or not. This leads to free_irq being called on -1 during
device initialization.

Fix this by using 0 as the uninitialized value everywhere.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:11:06 +10:00
Alexandre Courbot 0529a46a7a drm/nouveau/device: call nvkm_device_fini if nvkm_device_init fails
nvkm_device_fini is never called if a failure occurs in
nvkm_device_init, even when unloading the module. This can lead to a
resources leak (one example is the Tegra interrupt which would never be
freed in that case). Fix this by calling nvkm_device_fini in
nvkm_device_init's failure path.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:11:06 +10:00
Alexandre Courbot 33bcb4c340 drm/nouveau/gr/gf100: use the nvkm_firmware functions
Use the nvkm_firmware_* functions when loading external firmware to
avoid duplicate code.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:11:06 +10:00
Alexandre Courbot 046fdb2a59 drm/nouveau/core: add firmware handling functions
Add two functions nvkm_firmware_get() and nvkm_firmware_put() to load a
firmware file and free its resources, respectively. Since firmware files
are becoming a necessity for new GPUs, and their location has been
standardized to nvidia/chip/, this will prevent duplicate and
error-prone name-generation code.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:11:06 +10:00
Alexandre Courbot f0db6e3be9 drm/nouveau/ltc/gm107: wait on relevant bit in gm107_ltc_cbc_wait
Patch "ltc/gm107: use nvkm_mask to set cbc_ctrl1" sets the 3rd bit
of the CTRL1 register instead of writing it entirely in
gm107_ltc_cbc_clear(). As a counterpart, gm107_ltc_cbc_wait() must also
be modified to wait on that single bit only, otherwise a timeout may
occur if some other bit of that register is set. This happened at least
on GM206 when running glmark2-drm.

While we are at it, use the more compact nvkm_wait_msec() to wait for
the bit to clear.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-03-14 10:11:06 +10:00
Dan Carpenter 585cb132a4 drm/vc4: Return -EFAULT on copy_from_user() failure
The copy_from_user() function returns the number of bytes not copied but
we want to return a negative error code.

Fixes: 463873d570 ('drm/vc4: Add an API for creating GPU shaders in GEM BOs.')
Cc: stable@vger.kernel.org
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
2016-03-13 17:09:12 -07:00
Eric Anholt 0b06e0a794 drm/vc4: Respect GPIO_ACTIVE_LOW on HDMI HPD if set in the devicetree.
The original Raspberry Pi had the GPIO active high, but the later
models are active low.  The DT GPIO bindings allow specifying the
active flag, except that it doesn't get propagated to the gpiodesc, so
you have to handle it yourself.

Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Daniel Stone <daniels@collabora.com>
2016-03-13 17:06:57 -07:00
Eric Anholt 0e60eab575 drm/vc4: Let gpiolib know that we're OK with sleeping for HPD.
Fixes an error thrown every few seconds when we poll HPD when it's on
a I2C to GPIO expander.

Signed-off-by: Eric Anholt <eric@anholt.net>
Tested-by: Daniel Stone <daniels@collabora.com>
2016-03-13 17:06:36 -07:00
Varad Gautam ca26d28bba drm/vc4: improve throughput by pipelining binning and rendering jobs
The hardware provides us with separate threads for binning and
rendering, and the existing model waits for them both to complete
before submitting the next job.

Splitting the binning and rendering submissions reduces idle time and
gives us approx 20-30% speedup with some x11perf tests such as -line10
and -tilerect1.  Improves openarena performance by 1.01897% +/-
0.247857% (n=16).

Thanks to anholt for suggesting this.

v2: Rebase on the spurious resets fix (change by anholt).

Signed-off-by: Varad Gautam <varadgautam@gmail.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Eric Anholt <eric@anholt.net>
2016-03-13 17:05:05 -07:00
Dave Airlie 67d1c0a25c Merge tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux into drm-next
This pull request fixes the major VC4 HDMI modesetting bugs found when
the first wave of users showed up in Raspbian.

* tag 'drm-vc4-fixes-2016-03-03' of github.com:anholt/linux:
  drm/vc4: Initialize scaler DISPBKGND on modeset.
  drm/vc4: Fix setting of vertical timings in the CRTC.
  drm/vc4: Fix the name of the VSYNCD_EVEN register.
  drm/vc4: Add another reg to HDMI debug dumping.
  drm/vc4: Bring HDMI up from power off if necessary.
  drm/vc4: Fix a framebuffer reference leak on async flip interrupt.
2016-03-14 09:48:04 +10:00
Dave Airlie c3d7a1d1e6 Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: add DRM_EXYNOS_GEM_MAP ioctl
2016-03-14 09:46:46 +10:00
Dave Airlie 9b61c0fcdf Merge drm-fixes into drm-next.
Nouveau wanted this to avoid some worse conflicts when I merge that.
2016-03-14 09:46:02 +10:00