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>

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>

Reported-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

Useful for debugging different VBIOS versions.
Signed-off-by: Ben Skeggs <bskeggs@redhat.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>

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

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

These numbers from the binary driver's daemon scripts, and fix the transition
to perflvl 3 on my T510.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

Loads of magic missing, this will probably blow up if you try it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

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>

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>

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 gets us a start on memory timings.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

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

Reported-by: wfg@linux.intel.com
Signed-off-by: Dave Airlie <airlied@redhat.com>

these functions and the table can all be static/static const.

Reported-by: wfg@linux.intel.com
Signed-off-by: Dave Airlie <airlied@redhat.com>

New drivers merged after changes were done in prime TTM code.

Fix build.
Signed-off-by: Dave Airlie <airlied@redhat.com>

* 'prime-merge' of ssh://people.freedesktop.org/~airlied/linux:
  drm/radeon: add PRIME support (v2)
  i915: add dmabuf/prime buffer sharing support.
  nouveau: add PRIME support
  ttm: add prime sharing support to TTM (v2)
  udl: add prime fd->handle support.
  drm/prime: add exported buffers to current fprivs imported buffer list (v2)
  drm/prime: introduce sg->pages/addr arrays helper

This adds prime->fd and fd->prime support to radeon.
It passes the sg object to ttm and then populates
the gart entries using it.

Compile tested only.

v2: stub kmap + use new helpers + add reimporting
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

This adds handle->fd and fd->handle support to i915, this is to allow
for offloading of rendering in one direction and outputs in the other.

v2 from Daniel Vetter:
- fixup conflicts with the prepare/finish gtt prep work.
- implement ppgtt binding support.

Note that we have squat i-g-t testcoverage for any of the lifetime and
access rules dma_buf/prime support brings along. And there are quite a
few intricate situations here.

Also note that the integration with the existing code is a bit
hackish, especially around get_gtt_pages and put_gtt_pages. It imo
would be easier with the prep code from Chris Wilson's unbound series,
but that is for 3.6.

Also note that I didn't bother to put the new prepare/finish gtt hooks
to good use by moving the dma_buf_map/unmap_attachment calls in there
(like we've originally planned for).

Last but not least this patch is only compile-tested, but I've changed
very little compared to Dave Airlie's version. So there's a decent
chance v2 on drm-next works as well as v1 on 3.4-rc.

v3: Right when I've hit sent I've noticed that I've screwed up one
obj->sg_list (for dmar support) and obj->sg_table (for prime support)
disdinction. We should be able to merge these 2 paths, but that's
material for another patch.

v4: fix the error reporting bugs pointed out by ickle.

v5: fix another error, and stop non-gtt mmaps on shared objects
stop pread/pwrite on imported objects, add fake kmap
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

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>

udl can only be used as an output offload so doesn't need to support
handle->fd direction.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

If userspace attempts to import a buffer it exported on the same device,
we need to return the same GEM handle for it, not a new handle pointing
at the same GEM object.

v2: move removals into a single fn, no need to set to NULL. (Chris Wilson)
Signed-off-by: Dave Airlie <airlied@redhat.com>

the ttm drivers need this currently, in order to get fault handling
working and efficient.

It also allows addrs to be NULL for devices like udl.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

The omapdrm driver uses this for setting per-overlay rotation.  It
is likely also useful for setting YUV->RGB colorspace conversion
matrix, etc.
Signed-off-by: Rob Clark <rob@ti.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>