- Tegra K1 voltage support, and coherency improvements
- GM204 support (modesetting, still waiting on NVIDIA for signed fw to
proceed further), and a lot of bios/i2c/devinit adjustments needed to
support it
- GT21x memory reclocking work
- Various other bits and pieces, most of which are prep-work for a
couple of bigger projects I didn't get finished in time
* 'linux-3.19' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (73 commits)
drm/nv50/kms: drop requirement that framebuffer bos be contig up-front
drm/nv50/kms: directly use cursor image from userspace buffer
drm/nouveau/kms: when pinning display-related buffers, force contig vram
drm/nouveau: teach nouveau_bo_pin() how to force a contig vram allocation
drm/nouveau/volt: add support for GK20A
drm/nouveau/platform: add GPU speedo information to nouveau platform
drm/nouveau/volt: allow non-bios voltage scaling
drm/gf100-/gr: return non-fatal error code when fw not present
drm/nouveau/devinit: bump priv ring timeouts before executing scripts
drm/nouveau/bios: translate ramcfg strap through M0203
drm/nouveau/fb: make use of M0203 routines for ram type determination
drm/nouveau/bios: add parsing of BIT M(v2) +0x03 table
drm/nouveau/core: allow vbios parsing without knowing chipset type
drm/nouveau/lib: add null backend
drm/nouveau/device: store revision
drm/nouveau/core: add some forgotten subdevs to disable mask
drm/gk20a/clk: fix max VCO value
drm/nouveau: we need pin_refcnt for nouveau_bo_placement_set()
drm/nv50-/kms: add some evo tracing ability for debugging
drm/nv50/kms: use sclass() instead of trial-and-error
...
The voltage value are calculated by the hardware characterized
result.
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Move the vbios parsing out of init() and call it conditionally if the
platform has a vbios. Non-vbios platforms can use the ctor() to init the
data structures.
Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A machine has been spotted where the ramcfg strap is "8", and the ramcfg
xlat table goes 0-7,0-7, resulting in us selecting config 0 for memory
items. On this particular system, config "8" is available and supposed
to be used. It appears that starting from GT21x (where Mv2 appears),
we're supposed to use the value in this table instead.
One concern here is that not all the places we currently use ramcfg xlat
are supposed to be treated the same now. The strap xlat table wasn't
removed from the vbios either, presumably for some kind of good reason.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We only support one kind of matching here (ramcfg strap), but it appears
alternate methods are possible. I wrote a tool to scan our vbios repo
for other types, but did not see any used. Hopefully this means there
aren't any in the wild that will now break.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
For some reason max_vco was set to a lower value that it can support,
which prevented some clock states to be applied. Fix this by setting it
to the same value as downstream.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Add a function allowing us to know whether a device is CPU-coherent,
i.e. accesses performed by the CPU on GPU-mapped buffers will
be immediately visible on the GPU side and vice-versa.
For now, a device is considered to be coherent if it uses the PCI bus on
a non-ARM architecture.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Probably missing something here, doesn't make a lot of sense to write
or+link data into a register whose offset is calculated by the same
or+link info..
This is the all I've witnessed the binary driver and vbios doing so
far, so it'll do.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The binary driver has been doing this since GF119, and we've somehow
gotten away with it. But, TMDS that hasn't been initialised already
by the x86 vbios code is distorted without it on GM204.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Logging at trace level, rather than as en error, as it seems conceivable
that failure could be normal under certain circumstances (new bios,
older sink that doesn't support a particular DPCD address)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Starting from GM204, certain registers are no longer accessible by the host
(or unsigned PMU firmware).
This commit implements devinit on PMU, using a signed microcode image, and
devinit data, from the VBIOS.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
