It appears that, for whatever reason, both link A and B use the same
register to control the training pattern. It's a little odd, as the
GPUs before this (Tesla/Fermi1) have per-link registers, as do newer
GPUs (Maxwell).
Fixes the third DP output on NVS 510 (GK107).
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
This is a simplied version of the fix by Roy in fdo#93629. While this
doesn't appear to fix the issues for the users in that report, it's a
real issue that deserves to be resolved.
Reported-by: Roy Spliet <rspliet@eclipso.eu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Also removes an XXX; according to nvgpu headers the field is called
NV_PGRAPH_GPCS_SWDX_TC_BETA_CB_SIZE_DIV3, so, apparently not some
magic we need to figure out :)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This was really inconsistent, some implementations could touch PPCs
that didn't exist, others neglected to touch ones that did.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
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>
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>
Just a single fix to prevent GM20B systems hanging at boot.
* 'linux-4.6' of git://github.com/skeggsb/linux:
drm/nouveau/tegra: acquire and enable reference clock if needed
GM20B requires an extra clock compared to GK20A. Add that information
into the platform data and acquire and enable this clock if necessary.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
gcc-6 warns about code in the nouveau driver that is obviously silly:
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c: In function 'nv40_perfctr_next':
drivers/gpu/drm/nouveau/nvkm/engine/pm/nv40.c:62:19: warning: self-comparison always evaluats to false [-Wtautological-compare]
if (pm->sequence != pm->sequence) {
The behavior was accidentally introduced in a patch described as "This is
purely preparation for upcoming commits, there should be no code changes here.".
As far as I can tell, that was true for the rest of that patch except for
this one function, which has been changed to a NOP.
This patch restores the original behavior.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 8c1aeaa139 ("drm/nouveau/pm: cosmetic changes")
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Add a basic clock driver that reuses the GK20A logic.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add basic GM20B volt driver that reuses the GK20A logic.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This class supports a WFI method (0x0078) that's not present on the
KeplerChannelGpfifoA class.
The binary driver exposes both classes on these GPUs for some reason,
though there doesn't appear to be any difference in the setup that's
done for each (ie. even if you allocate GpfifoA, the WFI method will
still work).
We shall just expose GpfifoB, as I don't see a good reason to report
the presence of both.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
