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>
The binary driver appears to do various bits and pieces of the memory
clock frequency change at different times, depending on the particular
transition that's occuring. I've attempted to replicate this here
for div->pll, pll->div and div->div transitions.
With some additional (patches upcoming) magic regs being bashed, this
allows me to correctly transition between all 3 perflvls on NVS300.
pll->pll transitions will *not* work correctly at the moment, pending
me tricking the binary driver into doing one and seeing how to correctly
handle it.
This patch also handles (hopefully) 0x1110e0, which appears to need
changing depending on whether in PLL or divider mode.. Maybe. We'll
see.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The reg calculation may get moved elsewhere at some point, but lets
figure out what exactly we need to do first.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This adds prime->fd and fd->prime support to nouveau,
it passes the SG object to TTM, and then populates the
GART entries using it.
v2: add stubbed kmap + use new function to fill out pages array
for faulting + add reimport test.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This adds the ability for ttm common code to take an SG table
and use it as the backing for a slave TTM object.
The drivers can then populate their GTT tables using the SG object.
v2: make sure to setup VM for sg bos as well.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The DRM mode config functions structure declared by drivers and pointed
to by the drm_mode_config funcs field is never modified. Make it a const
pointer.
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Rob Clark <rob.clark@linaro.org>
Reviwed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This seems to be wrong to me, spotted while thinking about dma-buf.
Reviewed-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
This changes the API as a clean-up. Instead of passing multiple
function pointers at each time, introduce a new struct holding the
whole callback functions and pass it to the registration.
The same struct will be used for the upcoming audio client
registration, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Previous issues with i2c-algo-bit have now been resolved.
This is a revert of f553b79c03f0dbd52f6f03abe8233a2bef8cbd0d mostly,
due to fixes in the i2c core repairing the original issue, this code
isn't required and was causing regressions.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reported-by: Nick Bowler <nbowler@elliptictech.com>
Tested-by: Nick Bowler <nbowler@elliptictech.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
