drm/nouveau/disp: switch to instanced constructor

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

drm/nouveau/device: pass instance id when looking up a subdev/engine

This switches to using the subdev list for lookup, and otherwise should
be a no-op aside from switching the function signatures.

drm/nouveau/device: pass instance id when looking up a subdev/engine

This switches to using the subdev list for lookup, and otherwise should
be a no-op aside from switching the function signatures.

Callers will be transitioned to split type+inst individually.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reviewed-by: Lyude Paul <lyude@redhat.com>

show more ...

drm/nouveau/fb/gf100-: declare constants as unsigned long long.

Explicitly declare constants as unsigned long long to address the
following sparse warnings:
warning: constant is so big it is long

v

drm/nouveau/fb/gf100-: declare constants as unsigned long long.

Explicitly declare constants as unsigned long long to address the
following sparse warnings:
warning: constant is so big it is long

v2: convert to unsigned long long for compatibility with 32-bit
architectures.

Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Suggested by: lia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

show more ...

drm/nouveau/fb/ramgk104: fix spelling mistake "sucessfully" -> "successfully"

There is a spelling mistake in a nvkm_debug message. Fix it.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
R

drm/nouveau/fb/ramgk104: fix spelling mistake "sucessfully" -> "successfully"

There is a spelling mistake in a nvkm_debug message. Fix it.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

show more ...

drm/nouveau/fb/ram: remove old allocators

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

drm/nouveau/fb/ram/nv40-: use new devinit script interpreter entry-point

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

drm/nouveau/fb/gf100-: rework ram detection

This commit reworks the RAM detection algorithm, using RAM-per-LTC to
determine whether a board has a mixed-memory configuration instead of
using RAM-per-

drm/nouveau/fb/gf100-: rework ram detection

This commit reworks the RAM detection algorithm, using RAM-per-LTC to
determine whether a board has a mixed-memory configuration instead of
using RAM-per-FBPA. I'm not certain the algorithm is perfect, but it
should handle all currently known configurations in the very least.

This should fix GTX 970 boards with 4GiB of RAM where the last 512MiB
isn't fully accessible, as well as only detecting half the VRAM on
GF108 boards.

As a nice side-effect, GP10x memory detection now reuses the majority
of the code from earlier chipsets.

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

show more ...

drm/nouveau/fb/gf100-: modify constructors to allow more customisation

GF108/GM107 implementations will want slightly different functions for
the upcoming RAM detection improvements.

Signed-off-by:

drm/nouveau/fb/gf100-: modify constructors to allow more customisation

GF108/GM107 implementations will want slightly different functions for
the upcoming RAM detection improvements.

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

show more ...

drm/nouveau/fb/ram/gk104: remove unused best_clk variable

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

drm/nouveau/fb/ram: Use Kepler implementation on Maxwell

This enables memory reclocking on Maxwell. Sadly without a PMU firmware it
is useless for gm20x gpus.

Signed-off-by: Karol Herbst <karolherb

drm/nouveau/fb/ram: Use Kepler implementation on Maxwell

This enables memory reclocking on Maxwell. Sadly without a PMU firmware it
is useless for gm20x gpus.

Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

show more ...

drm/nouveau/fb/ramgk104: Touch 0x62c000 only when there is a display engine

Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Tested-by: Aidan Epstein <aidan@jmad.org>
Signed-off-by: Ben Skeggs <b

drm/nouveau/fb/ramgk104: Touch 0x62c000 only when there is a display engine

Signed-off-by: Karol Herbst <karolherbst@gmail.com>
Tested-by: Aidan Epstein <aidan@jmad.org>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

show more ...

drm/nouveau/nvkm: add/remove 0's to make 7 (or 9)-nibble constants use 8 nibbles

Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/pll/gk104: fix PLL instability due to bad configuration with gddr5

This patch uses an approach closer to the nvidia driver to configure
both PLLs for high gddr5 memory clocks (usually ab

drm/nouveau/pll/gk104: fix PLL instability due to bad configuration with gddr5

This patch uses an approach closer to the nvidia driver to configure
both PLLs for high gddr5 memory clocks (usually above 2400MHz)

Previously nouveau used the one PLL as it was used for the lower clocks
and just adjusted the second PLL to get as close as possible to the
requested clock. This means for my card, that I got a 4050 MHz clock
although 4008 MHz was requested.

Now the driver iterates over a list of PLL configuration also used by
the nvidia driver and then adjust the second PLL to get near the
requested clock. Also it hold to some restriction I found while
analyzing the PLL configurations

This won't fix all gddr5 high clock issues itself, but it should be
fine on hybrid gpu systems as found on many laptops these days. Also
switching while normal desktop usage should be a lot more stable than
before.

v2: move the pll code into ramgk104

Signed-off-by: Karol Herbst <nouveau@karolherbst.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

show more ...

drm/nouveau/bios/rammap: Identify DLLoff for >= GF100

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

drm/nouveau/gpio: convert to new-style nvkm_subdev

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

drm/nouveau/fb: convert to new-style nvkm_subdev

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

drm/nouveau/clk: convert to new-style nvkm_subdev

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

drm/nouveau/fb: transition nvkm_ram away from being based on nvkm_object

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

drm/nouveau/bios: remove object accessor functions

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

drm/nouveau/fb: switch to subdev printk macros

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

drm/nouveau/fb: switch to device pri macros

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

drm/nouveau/fb: cosmetic changes

This is purely preparation for upcoming commits, there should be no
code changes here.

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

drm/nouveau/device: include core/device.h automatically for subdevs/engines

Pretty much every subdev/engine is going to need access to nvkm_device
shortly to touch registers and/or output messages.

drm/nouveau/device: include core/device.h automatically for subdevs/engines

Pretty much every subdev/engine is going to need access to nvkm_device
shortly to touch registers and/or output messages.

The odd placement of the includes is necessary to work around some
inter-dependencies that currently exist. This will be fixed later.

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

show more ...

drm/nouveau/pmu: namespace + nvidia gpu names (no binary change)

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver. This is bein

drm/nouveau/pmu: namespace + nvidia gpu names (no binary change)

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver. This is being
done in order to make it very clear as to what part of the driver a
given symbol belongs to, and as a minor step towards splitting the
DRM driver out to be able to stand on its own (for virt).

Because there's already a large amount of churn here anyway, this is
as good a time as any to also switch to NVIDIA's device and chipset
naming to ease collaboration with them.

A comparison of objdump disassemblies proves no code changes.

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

show more ...

drm/nouveau/fb: namespace + nvidia gpu names (no binary change)

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver. This is being

drm/nouveau/fb: namespace + nvidia gpu names (no binary change)

The namespace of NVKM is being changed to nvkm_ instead of nouveau_,
which will be used for the DRM part of the driver. This is being
done in order to make it very clear as to what part of the driver a
given symbol belongs to, and as a minor step towards splitting the
DRM driver out to be able to stand on its own (for virt).

Because there's already a large amount of churn here anyway, this is
as good a time as any to also switch to NVIDIA's device and chipset
naming to ease collaboration with them.

A comparison of objdump disassemblies proves no code changes.

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

show more ...