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: NKarol Herbst <nouveau@karolherbst.de>
Reviewed-by: NMartin Peres <martin.peres@free.fr>

Signed-off-by: NKarol Herbst <nouveau@karolherbst.de>
Reviewed-by: NMartin Peres <martin.peres@free.fr>

v2: expose only if the sensor reading is valid
Signed-off-by: NKarol Herbst <nouveau@karolherbst.de>
Reviewed-by: NMartin Peres <martin.peres@free.fr>

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: NKarol Herbst <nouveau@karolherbst.de>
Reviewed-by: NMartin Peres <martin.peres@free.fr>

Karol Herbst:
v4: don't kmalloc(0)
v5: stricter validation
Signed-off-by: NKarol Herbst <nouveau@karolherbst.de>
Reviewed-by: NMartin Peres <martin.peres@free.fr>

Signed-off-by: NKarol Herbst <nouveau@karolherbst.de>
Reviewed-by: NMartin Peres <martin.peres@free.fr>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Secure falcons' firmware is managed by secboot. Do not load it in GR for
them.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Start securely-managed falcons using secboot functions since the process
for them is different from just writing CPUCTL.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Load firmware and bundles in GM200's constructor. The previously called
GF100 function did not care about the bundles.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There functions are going to be used by other chips that rely on
NVIDIA-provided firmware. Export them.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Make these functions easier to use by handling memory management from
within.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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

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

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

We never use any nv50-specific member in this nv50_devinit_preinit().
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.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>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Use the nvkm_firmware_* functions when loading external firmware to
avoid duplicate code.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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.

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

Nouveau wanted this to avoid some worse conflicts when I merge that.

The commit d931589c ("drm/exynos: remove DRM_EXYNOS_GEM_MAP_OFFSET
ioctl") removed it same with the ioctl that this patch adds. The reason
that removed DRM_EXYNOS_GEM_MAP_OFFSET was we could use
DRM_IOCTL_MODE_MAP_DUMB. Both did exactly same thing.

Now we again will revive it as DRM_EXYNOS_GEM_MAP because of render
node. DRM_IOCTL_MODE_MAP_DUMB isn't permitted in render node.
Signed-off-by: NJoonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

Two i915 regression fixes.

* tag 'drm-intel-fixes-2016-03-11' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Actually retry with bit-banging after GMBUS timeout
  drm/i915: Fix bogus dig_port_map[] assignment for pre-HSW