Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In preparation of changing FBVDDQ, as observed on at least one GDDR3 card.
While at it, adhere to func.log[1] properly for consistency.
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

If the hardware supports extended tag field (8-bit ones), then enable it.

This is usually done by the VBIOS, but not on some MBPs (see fdo#86537).

In case extended tag field is not supported, 5-bit tag field is used which
limits the possible number of requests to 32. Apparently bits 7:0 of
0x08841c stores some number of outstanding requests, so cap it to 32 if
extended tag is unsupported.

Fixes: fdo#86537

v2: Restrict changes to chipsets >= 0x84
v3:
  * Add nvkm_pci_mask to pci.h
  * Mask bit 8 before setting it
v4:
  * Rename `add` argument of nvkm_pci_mask to `value`
  * Move code from nvkm_pci_init to g84_pci_init and remove PCIe and chipset
    checks
v5:
  * Rebase code on latest PCI structure
  * Restore PCIe check
  * Fix namings in nvkm_pci_mask
  * Rephrase part of the commit message
Signed-off-by: NPierre Moreau <pierre.morrow@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These nvkm_object_func structures are never modified.  All other
nvkm_object_func structures are declared as const.

Done with the help of Coccinelle.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GF110+ supports both the A and B compute classes, make sure to accept
both.
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

NVIDIA provided the documentation for mp error 0x10, INVALID_ADDR_SPACE,
which apparently happens when trying to use an atomic operation on
local or shared memory (instead of global memory).
Signed-off-by: NIlia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

If pm_runtime_get_sync() we were going to "out" but we missed freeing
vma.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

coverity.com reported that memset was using a buffer of size 0, on
checking the code it turned out that the function was not being used. So
remove it.
Signed-off-by: NSudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: NSamuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reported to be needed as per fdo#70354 comment #61.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not 100% confirmed, but seems to match from the few boards I've looked
at so far.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Was not able to obtain a trace of NVRM due to kernel version annoyances,
however, experimentally confirmed that the WAR we use on NV50/G8x boards
works here too.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

An upcoming patch will implement functionality that we don't use on any
NV40 chipset.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

An upcoming patch will implement functionality that we don't use on the
original NV50.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Increase clock timeout of some unknown engines in order to avoid failure
at high gpcclk rate.

This fixes IBUS read faults on my GF119 when reclocking is manually
enabled. Note that memory reclocking is completely broken and NvMemExec
has to be disabled to allow core clock reclocking only.
Signed-off-by: NSamuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I got confirmation that we can read and change the voltage with the same code.
The divider is also computed correctly on the gm204 we got our hands on.

Thanks to Yoshimo on IRC for executing the tests on his gm204!
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Let's ignore the other desktop Maxwells until I get my hands on one and confirm
that we still can change the voltage.
Signed-off-by: NMartin Peres <martin.peres@free.fr>

Most Keplers actually use the GPIO-based voltage management instead of the new
PWM-based one. Use the GPIO mode as a fallback as it already gracefully handles
the case where no GPIOs exist.

All the Maxwells seem to use the PWM method though.

v2:
 - Do not forget to commit the PWM configuration change!
Signed-off-by: NMartin Peres <martin.peres@free.fr>

This patch is not ideal but it definitely beats a rewrite of the current
interface and is very self-contained.
Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

So far the DMA mask was not set for platform devices, which limited them
to a 32-bit physical space. Allow dma_set_mask() to be called for
non-PCI devices, and also take the IOMMU bit into account since it could
restrict the physically addressable space.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The pci_dma_* functions are now superseeded in the kernel by the DMA
API. Make the conversion to this more generic API.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Use the IOMMU bit specified in platform data instead of hardcoding it to
the bit used by current Tegra GPUs.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Current Tegra code taking advantage of the IOMMU assumes a hardcoded
value for the IOMMU bit. Make it a platform property instead for
flexibility.

v2 (Ben Skeggs): remove nvkm dependence on drm structures
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The Great Nouveau Refactoring Take II brought us a lot of goodness,
including acquire/release methods that are called before and after an
instobj is modified. These functions can be used as synchronization
points to manage CPU/GPU coherency if we modify an instobj using the
CPU.

This patch replaces the legacy and slow PRAMIN access for gk20a instmem
with CPU mappings and writes. A LRU list is used to unmap unused
mappings after a certain threshold (currently 1MB) of mapped instobjs is
reached. This allows mappings to be reused most of the time.

Accessing instobjs using the CPU requires to maintain the GPU L2 cache,
which we do in the acquire/release functions. This triggers a lot of L2
flushes/invalidates, but most of them are performed on an empty cache
(and thus return immediately), and overall context setup performance
greatly benefits from this (from 250ms to 160ms on Jetson TK1 for a
simple libdrm program).

Making L2 management more explicit should allow us to grab some more
performance in the future.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

No longer required in a lot of cases, as objects are identified over NVIF
via an alternate mechanism since the rework.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Allow clients to manually flush and invalidate L2. This will be useful
for Tegra systems for which we want to write instmem using the CPU.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These are useful for systems without a coherent CPU/GPU bus. For such
systems we may need to maintain the L2 ourselves.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reintroduce macros allowing us to test a register against a certain
mask, since this is the most common usage pattern for the more generic
nvkm_xsec macros and makes the code more concise and readable.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Some devices may not have a PMU. Avoid a NULL pointer dereference in
such cases by checking whether the pointer given to nvkm_pmu_pgob() is
valid.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

On nv50+, we restrict the valid domains to just the one where the buffer
was originally created. However after the buffer is evicted to system
memory, we might move it back to a different domain that was not
originally valid. When sharing the buffer and retrieving its GEM_INFO
data, we still want the domain that will be valid for this buffer in a
pushbuf, not the one where it currently happens to be.

This resolves fdo#92504 and several others. These are due to suspend
evicting all buffers, making it more likely that they temporarily end up
in the wrong place.

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

Few more drm-misc stragglers for 4.4. Big thing is the generic probe for
imx/rockchip/armada (but the variant for msm/rpi/exynos is still missing).

Also the hdmi clocking fixes from Ville which was a lot of confusion about
which tree it should be applied to ;-)

* tag 'topic/drm-misc-2015-10-22' of git://anongit.freedesktop.org/drm-intel:
  drm: correctly check failed allocation
  vga_switcheroo: Constify vga_switcheroo_handler
  drm/armada: Convert the probe function to the generic drm_of_component_probe()
  drm/rockchip: Convert the probe function to the generic drm_of_component_probe()
  drm/imx: Convert the probe function to the generic drm_of_component_probe()
  drm: Introduce generic probe function for component based masters.
  drm/edid: Round to closest when computing the CEA/HDMI alternate clock
  drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings

More amdgpu and radeon stuff for drm-next.  Stoney support is the big change.
The rest is just bug fixes and code cleanups.  The Stoney stuff is pretty
low impact with respect to existing chips.

* 'drm-next-4.4' of git://people.freedesktop.org/~agd5f/linux:
  drm/amdgpu: change VM size default to 64GB
  drm/amdgpu: add Stoney pci ids
  drm/amdgpu: update the core VI support for Stoney
  drm/amdgpu: add VCE support for Stoney (v2)
  drm/amdgpu: add UVD support for Stoney
  drm/amdgpu: add GFX support for Stoney (v2)
  drm/amdgpu: add SDMA support for Stoney (v2)
  drm/amdgpu: add DCE support for Stoney
  drm/amdgpu: Update SMC/DPM for Stoney
  drm/amdgpu: add GMC support for Stoney
  drm/amdgpu: add Stoney chip family
  drm/amdgpu: fix the broken vm->mutex V2
  drm/amdgpu: remove the unnecessary parameter adev for amdgpu_fence_wait_any()
  drm/amdgpu: remove the exclusive lock
  drm/amdgpu: remove old lockup detection infrastructure
  drm: fix trivial typos
  drm/amdgpu/dce: simplify suspend/resume
  drm/amdgpu/gfx8: set TC_WB_ACTION_EN in RELEASE_MEM packet
  drm/radeon: Use rdev->gem.mutex to protect hyperz/cmask owners

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

Bunch of -fixes for 4.4. Well not just, I've left the mmio/register work
from Ville in here since it's low-risk but lots of churn all over.

* tag 'drm-intel-next-fixes-2015-10-22' of git://anongit.freedesktop.org/drm-intel: (23 commits)
  drm/i915: Use round to closest when computing the CEA 1.001 pixel clocks
  drm/i915: Kill the leftover RMW from ivb_sprite_disable()
  drm/i915: restore ggtt double-bind avoidance
  drm/i915/skl: Enable pipe gamma for sprite planes.
  drm/i915/skl+: Enable pipe CSC on cursor planes. (v2)
  MAINTAINERS: add link to the Intel Graphics for Linux web site
  drm/i915: Move skl/bxt gt specific workarounds to ring init
  drm/i915: Drop i915_gem_obj_is_pinned() from set-cache-level
  drm/i915: revert a few more watermark commits
  drm/i915: Remove dev_priv argument from NEEDS_FORCE_WAKE
  drm/i915: Clean up LVDS register handling
  drm/i915: Throw out some useless variables
  drm/i915: Parametrize and fix SWF registers
  drm/i915: s/PIPE_FRMCOUNT_GM45/PIPE_FRMCOUNT_G4X/ etc.
  drm/i915: Turn GEN5_ASSERT_IIR_IS_ZERO() into a function
  drm/i915: Fix a few bad hex numbers in register defines
  drm/i915: Protect register macro arguments
  drm/i915: Include gpio_mmio_base in GMBUS reg defines
  drm/i915: Parametrize HSW video DIP data registers
  drm/i915: Eliminate weird parameter inversion from BXT PPS registers
  ...

A bit smaller pull this time.  Few minor things, plus initial support
for msm8996 (snapdragon 820)..  Sorry, a bit latish, was hoping to get
some 8960/8064 DSI stuff included.  But still waiting on the v2 of the
patchset (just pending some minor review comments).  It would be nice
to get the DSI patches merged since it would help some folks trying to
get upstream kernel running on n4/n7 and xperia z and wanting to write
some more panel drivers.  Also, waiting for OCMEM driver to get merged
via other trees and then I have a small bit to go along with that to
make the gpu actually work on devices w/ OCMEM (snapdragon 800, 805,
etc).  So maybe a second later pull req, time permitting.

* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
  drm/msm: Remove local fbdev emulation Kconfig option
  drm/msm/mdp5: Basic support for MDP5 v1.7 (MSM8996)
  drm/msm/mdp: Add Software Pixel Extension support
  drm/msm/mdp5: Use the newly introduced enum mdp_component_type
  drm/msm/hdmi: Add basic HDMI support for msm8996
  drm/msm/mdp5: Avoid printing error messages for optional clocks
  drm/msm: Fix IOMMU clean up path in case msm_iommu_new() fails
  drm/msm/mdp5: remove the cfg pointer from SMP struct
  drm/msm/dsi: Updata LNn_CFG4 register settings for 28nm PHY
  drm: msm: dsi: Don't attempt changing voltage of switches
  drm/msm: update generated headers

DRM_MSM_FBDEV config is used to enable/disable fbdev emulation for the
msm kms driver.

Replace this with the top level DRM_FBDEV_EMULATION config option where
applicable. This also prevents build breaks caused by undefined
drm_fb_helper_* functions when legacy fbdev support was disabled.
Signed-off-by: NArchit Taneja <architt@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

This change adds the basic MDP5 support for MSM8996.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

In order to produce an image, the scalar needs to be fed extra
pixels. These top/bottom/left/right values depend on a various of
factors, including resolution, scaling type, phase step and
initial phase.

Pixel Extension are programmed by hardware in most targets - and
can be overwritten by software. For some targets (e.g.: msm8996),
software *must* program those registers.

In order to ease this computation, let's always use bilinear
filters, which are easier to program from kernel. Eventually,
all of these values will come down from user space for better
quality.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>

When calculating phase steps, let's use the same enum
mdp_component_type in order to ease the readability; 0/1 indexes
are a bit confusing and we now have explicit values to index
this type of arrays.
Signed-off-by: NStephane Viau <sviau@codeaurora.org>
Signed-off-by: NRob Clark <robdclark@gmail.com>