| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
MMU will need to know this during its constructor, so we can't delay
deciding this until init-time.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
In a future commit, this will be constructed by common code.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Before: "imem: init completed in 299277us"
After: "imem: init completed in 11574us"
Suspend from Fedora 26 gnome desktop on GP102.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Before: "imem: suspend completed in 5540487us"
After: "imem: suspend completed in 1871526us"
Suspend from Fedora 26 gnome desktop on GP102.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
These will require slow-path access during suspend/resume.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
functions
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
A good deal of the structures we map into here aren't accessed very often
at all, and Fedora 26 has exposed an issue where after creating a heap of
channels, BAR2 space would run out, and we'd need to make use of the slow
path while accessing important structures like page tables.
This implements an LRU on BAR2 space, which allows eviction of mappings
that aren't currently needed, to make space for other objects.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Another piece of solving the "GP100 BAR2 VMM bootstrap" puzzle.
Without doing this, we'd attempt to write PDEs for the lower page table
levels through BAR2 before BAR2 access has been fully initialised.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This is not as simple as it was for earlier GPUs, due to the need to swap
accessor functions depending on whether BAR2 is usable or not.
We were previously protected by nvkm_instobj's accessor functions keeping
an object mapped permanently, with some unclear magic that managed to hit
the slow-path where needed even if an object was marked as mapped.
That's been replaced here by reference counting maps (some objects, like
page tables can be accessed concurrently), and swapping the functions as
necessary.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This is to simplify upcoming changes. The slow-path is something that
currently occurs during bootstrap of the BAR2 VMM, while backing up an
object during suspend/resume, or when BAR2 address space runs out.
The latter is a real problem that can happen at runtime, and occurs in
Fedora 26 already (due to some change that causes a lot of channels to
be created at login), so ideally we'd prefer not to make it any slower.
We'd also like suspend/resume speed to not suffer.
Upcoming commits will solve those problems in a better way, making the
extra overhead of moving the locking here a non-issue.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
acquire()/boot() will need different logic in addition to performing
the actual mapping.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This will eliminate a step through the call chain, and give backends
more flexibility.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
The accessor functions can change as a result of acquire()/release() calls,
and are protected by any refcounting done there.
Other functions must remain constant, as they can be called any time.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Discovered by accident while working to use BAR2 access to instmem objects
on more paths.
We've apparently been relying on luck up until now!
Signed-off-by: Ben Skeggs <[email protected]>
|
|
If we initialise BAR2 earlier, we're able to complete BAR1 setup using
the instmem fast-path.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
GP100's page table nests a lot more deeply than the GF100-compatible
layout we're currently using, which means our hackish-but-simple way
of dealing with BAR2 VMM teardown won't work anymore.
In order to sanely handle the chicken-and-egg (BAR2's PTs get mapped
into themselves) problem, we need prevent page tables getting mapped
back into BAR2 during the destruction of its VMM.
To do this, we simply key off the state that's now maintained by the
BAR2 init/fini functions.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Match API with the BAR1 version.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Upcoming changes will remove the nvkm_vmm pointer from nvkm_vma, instead
requiring it to be explicitly specified on each operation.
It's not currently possible to get this information for BAR1 mappings,
so let's fix that ahead of time.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Will prevent spurious MMU fault interrupts if something decides to touch
BAR1 after we've unloaded the driver.
Exposed external to BAR so that INSTMEM can use it to better control the
suspend/resume fast-path access.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
If we want to be able to hit the instmem fast-path in a few trickier cases,
we need to be more flexible with when we can initialise BAR2 access.
There's probably a decent case to be made for merging BAR/INSTMEM into BUS,
but that's something to ponder another day.
Flushes have been added after the write to bind the instance block,
as later commits will reveal the need for them.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Will prevent spurious MMU fault interrupts if something decides to touch
BAR1 after we've unloaded the driver.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
BAR2 being done for practical reasons, this is just for consistency.
Flushes have been added after the write to bind the instance block,
as later commits will reveal the need for them.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
NVIDIA call it BAR2, Linux APIs treat it as BAR3 due to BAR1 being a
64-bit BAR, which I presume take two slots or something.
No actual code changes here, just to make future commits less messy.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
It's handled by FIFO preinit() now.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Will already be done by MMU as a result of the PT writes that occur
during BAR2 bootstrapping.
This is likely just a left-over from the days when it was hardcoded.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
RM appears to do this really early in its initialisation, before DEVINIT.
We currently do this before BAR2 initialisation for some reason.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
nvkm_device hasn't subclassed nvkm_object in a long time.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
nvkm_gpuobj hasn't subclassed nvkm_object in a long time.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
MMU will be using this for BAR mappings.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
MMU will be needing this to specify kind info on BAR mappings.
We have no userspace currently using these interfaces, so break the ABI
instead of supporting both. NVIF version bump so any future use can be
guarded.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Want to be able to include this from core/device.h without pulling in
core/object.h.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
The correct thing to do on OOM is to return 0 and set mm_node to NULL,
otherwise TTM will assume some other kind of error, and not attempt to
evict other buffers to make space.
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Signed-off-by: Ben Skeggs <[email protected]>
|
|
This was already done in dcb.c inside nvkm, but the other parser did not
get the update.
Signed-off-by: Ilia Mirkin <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Using the ARRAY_SIZE macro improves the readability of the code. Also,
it is useless to re-invent it.
Found with Coccinelle with the following semantic patch:
@r depends on (org || report)@
type T;
T[] E;
position p;
@@
(
(sizeof(E)@p /sizeof(*E))
|
(sizeof(E)@p /sizeof(E[...]))
|
(sizeof(E)@p /sizeof(T))
)
Reviewed-by: Thierry Reding <[email protected]>
Signed-off-by: Jérémy Lefaure <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
Reported-by: Dave Airlie <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
nouveau supports the Tegra K1 and higher after the SoC-based GPUs converged
with the main GeForce GPU families.
v2:
- Qualify that support is Tegra K1+ (Martin Peres)
Signed-off-by: Rhys Kidd <[email protected]>
Reviewed-by: Martin Peres <[email protected]>
Acked-by: Pierre Moreau <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
v2:
- add nv138 and drop nv13b chipsets (Ilia Mirkin)
- refactor out status variable and instead mask tsensor (Ilia Mirkin)
- switch SHADOWed state message away from nvkm_error() (Ilia Mirkin)
- rename internal temperature variable (Karol Herbst)
v3:
- use nvkm_trace() for SHADOWed state message (Ben Skeggs)
Signed-off-by: Rhys Kidd <[email protected]>
Signed-off-by: Ben Skeggs <[email protected]>
|
|
The fan control mode can either be FDO_PWM_MODE_STATIC or FDO_PWM_MODE_STATIC_RPM.
Setting it as AMD_FAN_CTRL_AUTO will cause the fan spin faster wrongly.
This can be reproduced by:
'# cat /sys/class/hwmon/hwmon0/pwm1
38
'# cat /sys/class/hwmon/hwmon0/pwm1_enable
2
'# echo "2" > /sys/class/hwmon/hwmon0/pwm1_enable
'# cat /sys/class/hwmon/hwmon0/pwm1
122
The fan speed get faster wrongly even with its original mode echo back.
Signed-off-by: Evan Quan <[email protected]>
Reviewed-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|