Appears to more closely match what RM does.

For GM20B, now also copying bit 12 from NV_PFB_MMU_CTRL as upcoming
changes will require it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

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

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

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

These are specified by PTOP on Maxwell GPUs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

It appears these don't map to PBDMAs (at least on Kepler, it may or may
be valid for Fermi - this hasn't been checked), but to runlists.

This drops the NVKM_ENGINE_FIFO data from the entries too, as resetting
all of PFIFO is *not* the way to handle such faults.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

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

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

These are now specified directly in the MC subdev.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

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

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

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

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

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

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

Engine fields have been removed, as they're specified by PTOP.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

With the addition of PTOP-specified reset bits, it makes more sense to
move the definitions here rather than in individual subdev
implementations.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This will be later extended to handle PTOP-specified reset masks as well
as the hardcoded ones.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

This will also be used to define NV_PMC_ENABLE <-> subdev mappings in an
upcoming commit.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Ported from the code currently in engine/fifo/gk104.c.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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

v2: rename ina209/ina219 read function
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

v2: add list_del call, reword error message
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

v2: add list_del calls
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Reviewed-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

When we start communicating with the pmu a bit more, the current code is
a real issue. I encountered a dead lock here, while testing my dynamic
reclocking code
Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

In case of successful suspend, devinit will have to be run and this is
the behavior currently hardcoded. However, as FD bug 94725 suggests,
there might be cases where runtime suspend leaves the GPU powered, and
in such cases devinit should not be run on resume.

On GF100+ we have a reliable way to know whether we need to run devinit.
Use it instead of blindly trusting the flag set by nvkm_devinit_fini().

The code around the NvForcePost also needs to be slightly reworked in
order to keep working.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Suggested-by: Dave Airlie <airlied@redhat.com>
Suggested-by: Karol Herbst <nouveau@karolherbst.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Fixes out-of-tree build issue where uapi/drm/nouveau_drm.h gets picked
up instead.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Not the biggest fan of doing it this way, but what the hell.

* 'drm-uapi-extern-c-fixes' of https://github.com/evelikov/linux: (22 commits)
  drm/vmwgfx: add extern C guard for the UAPI header
  drm/virgl: add extern C guard for the UAPI header
  drm/via: add extern C guard for the UAPI header
  drm/vc4: add extern C guard for the UAPI header
  drm/tegra: add extern C guard for the UAPI header
  drm/sis: add extern C guard for the UAPI header
  drm/savage: add extern C guard for the UAPI header
  drm/radeon: add extern C guard for the UAPI header
  drm/r128: add extern C guard for the UAPI header
  drm/qxl: add extern C guard for the UAPI header
  drm/omap: add extern C guard for the UAPI header
  drm/nouveau: drop drm/ prefix from include
  drm/nouveau: add extern C guard for the UAPI header
  drm/msm: add extern C guard for the UAPI header
  drm/mga: add extern C guard for the UAPI header
  drm/i915: add extern C guard for the UAPI header
  drm/i810: add extern C guard for the UAPI header
  drm/exynos: add extern C guard for the UAPI header
  drm/etnaviv: add extern C guard for the UAPI header
  drm: add extern C guard for the UAPI headers
  ...

I kinda hoped that I could still sneak in Noralf's
drm_simple_display_pipe, since there's intereset by others now (for tilcdc
at least). But it wasn't ready by a hair. Oh well.

Otherwise random stuff plus prep patches from Noralf.

* tag 'topic/drm-misc-2016-05-13' of git://anongit.freedesktop.org/drm-intel:
  drm/atomic: Add drm_atomic_helper_best_encoder()
  drm/atomic: Don't skip drm_bridge_*() calls if !drm_encoder_helper_funcs
  drm/fb-cma-helper: Hook up to DocBook and fix some docs
  drm/fb-helper: Remove mention of CONFIG_FB_DEFERRED_IO in docs
  drm/sti: include linux/seq_file.h where needed
  drm/tegra: Use lockless gem BO free callback
  drm/exynos: Use lockless gem BO free callback
  drm: Make drm_encoder_helper_funcs optional

Merge branch 'topic-arcpgu-updates' of https://github.com/foss-for-synopsys-dwc-arc-processors/linux into drm-next

Please pull this mini-series that allows ARC PGU to use
dedicated memory location as framebuffer backing storage.

* 'topic-arcpgu-updates' of https://github.com/foss-for-synopsys-dwc-arc-processors/linux:
  ARC: [axs10x] Specify reserved memory for frame buffer
  drm/arcpgu: use dedicated memory area for frame buffer