Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJakob Bornecrantz <jakob@vmware.com>
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Used by the vmwgfx driver.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* 'drm-intel-next' of git://people.freedesktop.org/~keithp/linux:
  Drivers: i915: Fix all space related issues.

* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6: (353 commits)
  drm/nouveau: remove allocations from gart populate() hook
  drm/nvc0/fb: slightly improve PMFB intr handling, move out of nvc0_graph.c
  drm/nvc0/fifo: avoid touching missing subfifos
  drm/nvd9/disp: bail out of mode_set_base if no fb bound to crtc
  drm/nvd9/disp: stub some more api hooks so we don't oops on resume
  drm/nouveau: fix printk typo in ioremap failure path
  drm/nvc0/pm: minor clock readback fixes
  drm/nv40/pm: execute memory reset script from vbios
  drm/nv50/gr: refactor initialisation
  drm/nouveau: if requested, try harder at disabling sysmem pushbufs
  drm/nv50/gr: enable ctxprog xfer only when we need it to save power
  drm/nouveau/dp: add support for displayport table 0x30
  drm/nouveau/dp: return master dp table pointer too when looking up encoder
  drm/nouveau/bios: simplify U/d table hash matching func to just match
  drm/nouveau/dp: preserve non-pattern bits in DP_TRAINING_PATTERN_SET
  drm/nvc0/gr: remove MODULE_FIRMWARE() lines
  drm/nouveau/dp: use alternate lane mask for nvaf
  drm/nouveau/dp: link rate scripts are selected with a comparison table
  drm/nv40/pm: write nv40-specific reclocking routines
  drm/nv40/pm: parse geometric delta clock from vbios
  ...

Since some somewhat questionable changes a while back, TTM provides a
completely empty array of struct dma_address that stays around for the
entire lifetime of the TTM object.

Lets use this array, *always*, rather than wasting yet more memory on
another array who's purpose is identical, as well as yet another bool array
of the same size saying *which* of the previous two arrays to use...

This change will also solve the high order allocation failures seen by
some people while using nouveau.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

I'm still not certain how to determine the number of SUBPs are present on
a given board.
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: NMarcin Slusarz <marcin.slusarz@gmail.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>

On >=nv50, userspace would still end up allocating pushbufs in GART.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This patch adds instructions to ctxprog and by doing, impacts context
switching performance.  My testcase showed a 1% performance cost using
glxgears that is a context-switch bound application.

Please test and report bugs/performance/power/other.

Many thanks to Maxim Levitsky for his dedicated work on lowering power
consumption with nouveau.

More patches are coming thanks to his work:

https://bugs.freedesktop.org/show_bug.cgi?id=37922Signed-off-by: NMartin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Written from observations of my NVD9's vbios, completely untested due to
my NVD9 lacking actual DisplayPort connectors..
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Will need to be able to distinguish 2.0/2.1 from 3.0 soon.  Also, move
the vbios parsing to nouveau_dp where it belongs.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The caller is now responsible for parsing its own lists (or whatever) of
possible encoders.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

We don't use these by default anymore, and there's been complaints from a
number of places thinking that the firmware blobs are required still.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Naturally...  Because Macs can't just be the same as everything else
now can they?
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not hardcoded as originally thought.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Not 100% perfect yet, but a good start towards what it'll look like in the
end.

Actually seems stable on a NV44 I have here, as much as running around OA
for a fair amount of time constantly switching between performance levels
can prove..

My NV49 isn't quite so happy, and semaphores mess up somehow (sometimes) as
a result of the memory reclocking.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This changes the meaning of what we reported as "core" clock previously.

The shader/rop units are allegedly supposed to be run at the base clock
listed in the perf table, while the geometric clock can be bumped from
this value on some boards.

So that we can report both, we'll report the base clock as "shader" (since
the shaders *do* run at it), and the geometric clock as "core".
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>

Not used currently, but it will be used in preference to pre-determined
lane/bandwidth numbers at a later point.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Allows us to be lazy elsewhere...
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

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

I'm sure that out there somewhere, someone will need this.  We currently
haven't seen an example of LVDS being on a non-0 SOR so far though.
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>

The HW will only accept the DMA_FROM_MEMORY class for DMA_SEMAPHORE without
asking the driver to intervene.

It appears that semaphores will work correctly even without DMA_IN_MEMORY,
so lets avoid the large amount of interrupts generated by x-chan sync.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>