Disabled for the moment until some performance issues are sorted out, code
committed as a reference point.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Been tested on each major revision that's relevant here, but I'm sure there
are still bugs waiting to be ironed out.
This is a *very* invasive change.
There's a couple of pieces left that I don't like much (eg. other engines
using fifo_priv for the channel count), but that's an artefact of there
being a master channel list still. This is changing, slowly.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
All the places this stuff is actually needed tends to be chipset-specific
anyway, so we're able to just inline the register bashing instead.
The parts of the common code that still directly touch PFIFO temporarily
have conditionals, these will be removed in subsequent commits that will
refactor the fifo modules into engine modules like graph/mpeg etc.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Now have a somewhat simpler semaphore sync implementation for nv17:nv84,
and a switched to using semaphores as fences on nv84+ and making use of
the hardware's >= acquire operation.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Just a cleanup more or less, and to remove the need for special handling of
software objects.
This removes a heap of documentation on dma/graph object formats. The info
is very out of date with our current understanding, and is far better
documented in rnndb in envytools git.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This shouldn't be necessary, I believe this is just a bit of missed debug
code that got left over somehow.
Causes flips to be always synced to vblank, regardless of swap interval,
which we don't want..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Wait loop can be interrupted by signal, so if signals are raised
periodically (e.g. SIGALRM) this loop may never finish. Use
emission time as a base for fence timeout.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The conditional definition of the generation helper functions apparently
confuses some IDEs....
Reported-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Depending on exact point of failure, not cleaning would lead to
BUG_ONs/oopses in various distant places.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Port change from "drm/nouveau: Keep RAMIN heap within the channel"
to kernel channel, which has its own ramin heap initialisation.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Younes Manton <younes.m@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Kepler GRAPH has (well, sorta) fixed subchannel<->class assignments, make
this match up to keep it happy without trapping.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This may, perhaps, get re-merged with nvc0_graph.c at some point. It's
still unclear as to how great an idea that'd be. Stay tuned...
Completely dependent on firmware blobs from NVIDIA binary driver currently.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not entirely convinced 0x004018 transitions are correct yet, but, it's
an improvement.
The 750MHz value comes from fiddling with the binary driver + coolbits on
two different DDR3 NVA8 chipsets (T510 NVS3100M, and NVS300), not a clue
where this number comes from.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Probably not quite right, but this is enough now to make NVS300 reclock
between all 3 of its perflvls correctly.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This probably wants a cleanup, but I'm holding off until I know for sure
how the rest of the things that need doing fit together.
Tested on NVS300 by hacking up perflvl 1 to require PLL mode, and switching
between perflvl 3 and 1.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Marcin Slusarz