A source (or multiplexer) is a tuple addr+mask+shift which allows to
control a block of signals. The maximum number of sources that a signal
can define is arbitrary limited to 8 and this should be large enough.
This patch allows to define multi-level of sources for a signal.

Each different sources are stored to a global list and will be exposed
to the userspace through the nvif interface in order to avoid conflicts.

Signed-off-by: Samuel Pitoiset <samuel.pitoiset at gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NSamuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

16 bits is large enough to store the maximum number of signals available
for one domain (i.e. 256).
Signed-off-by: NSamuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will allow to configure performance counters with hardware signal
indexes instead of user-readable names in an upcoming patch.
Signed-off-by: NSamuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This allows to query the number of available domains, including the
number of hardware counter and the number of signals per domain.
Signed-off-by: NSamuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This commit introduces the NVIF_IOCTL_NEW_V0_PERFMON class which will be
used in order to query domains, signals and sources. This separates the
querying and the counting interface.
Signed-off-by: NSamuel Pitoiset <samuel.pitoiset@gmail.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

PDAEMON signals don't have to be exposed by the perfmon engine.
Signed-off-by: NSamuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: NMartin Peres <martin.peres@free.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Some of the bits in there are similar to the bits in the gt215 rammap.
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Might need some generalisation to < GT200. For those: use at your own risk!
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In preparation of NV50 reclocking, where there is no version
Signed-off-by: NRoy Spliet <rspliet@eclipso.eu>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This was merged with core/device.h in an earlier commit, but somehow
never got removed.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Commit 3740c825 ("drm/nouveau/gr/gf100-: add symbolic names for
classes") introduced a wrong macro definition causing acceleration setup
to fail. Fix it.
Signed-off-by: NLars Seipel <ls@slrz.net>
Fixes: 3740c825 ("drm/nouveau/gr/gf100-: add symbolic names for classes")
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Uncertain whether the GPC pack change is due to a newer driver version,
or a legitimate difference from GM204.  My GM204 has broken vram, so
can't currently try a newer binary driver on it to confirm.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

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

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

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

Turns out the PTHERM part of this dance is bracketed by the same PMU
fiddling that occurs on GK104/6, let's assume it's also PGOB.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

GK20A does not have dedicated RAM, thus having a RAM device for it does
not make sense. Move the contiguous physical memory allocation to
instmem.
Signed-off-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>

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: NBen Skeggs <bskeggs@redhat.com>