This enables possible 36bit address mask on 965G that use physical
address for hw status page.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

eDP could be on pipe A or B.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Original DP mode_valid check didn't take pixel color depth into account,
which made one 1600x900 eDP panel's mode check invalid because of overclock,
but actually this 6bpc panel does can work with x1 lane at 2.7G. This one
trys to take bpp value properly both in mode validation and mode setting.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Many platform support this feature, and it can provide significant
power savings when the reduced refresh rate is low.  However, on some
platforms a secondary (reduced) timing is provided but not actually
supported by the hardware.  This results in undesirable flicker at
runtime.

So disable the feature by default, but allow users to opt-in to the
reduced clock behavior with a new module parameter, lvds_downclock,
that can be set to 1 to enable the feature.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NEric Anholt <eric@anholt.net>

Suggested-by: NChris Wilson <chris@chris-wilson.co.uk&gt;>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> (in principle)
Signed-off-by: NEric Anholt <eric@anholt.net>

On Ironlake, there is an interrupt master control bit. With the bit
disabled before clearing IIR, we do not need to handle extra interrupt
in a loop. This patch removes the loop in Ironlake interrupt handler.
It fixed irq lost issue on some Ironlake platforms.

Cc: Stable Team <stable@kernel.org>
Signed-off-by: NZou Nan hai <Nanhai.zou@intel.com>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Following drm info repeat 207 times during one hour, it's quite annoying
[ 1266.286747] [drm] TV-19: set mode NTSC 480i 0

Change from DRM_INFO to DRM_DEBUG
Signed-off-by: NDave Young <hidave.darkstar@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Toralf Förster pointed out the typo, the fact I forget the if
statement is purely personal fail.
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are two copies of list_sort() in the tree already, one in the DRM
code, another in ubifs.  Now XFS needs this as well.  Create a generic
list_sort() function from the ubifs version and convert existing users
to it so we don't end up with yet another copy in the tree.
Signed-off-by: NDave Chinner <david@fromorbit.com>
Acked-by: NDave Airlie <airlied@redhat.com>
Acked-by: NArtem Bityutskiy <dedekind@infradead.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Testing GTT ready might be more correct but cp.ready
works fine and has been tested on irc by 2-3 ppl.

fixes bug k.org 15035 and fd.o 25733
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Due to heat issues.  Fixes fdo bug 25992

v2: fix typo noticed by Maarten Maathuis
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Unhandled vectors can be safely ignored, no need
to spam the kernel log by default.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Based on radeonfb code and recent ddx fix.

v2: minor formatting fix from Michel Dänzer
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NMichel Dänzer <michel@daenzer.net>
Tested-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When we setup buffer for display plane, we'll check any pending
required GPU flush and possible make interruptible wait for flush
complete. But that wait would be most possibly to fail in case of
signals received for X process, which will then fail modeset process
and put display engine in unconsistent state. The result could be
blank screen or CPU hang, and DDX driver would always turn on outputs
DPMS after whatever modeset fails or not.

So this one creates new helper for setup display plane buffer, and
when needing flush using uninterruptible wait for that.

This one should fix bug like https://bugs.freedesktop.org/show_bug.cgi?id=24009.
Also fixing mode switch stress test on Ironlake.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

There exist multiple DDC buses for the SDVO cards with multiple outputs.
When we can't get the EDID by using the select DDC bus, we can try the other
possible DDC bus to see whether the EDID can be obtained.

https://bugs.freedesktop.org/show_bug.cgi?id=23842Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: NEric Anholt <eric@anholt.net>

For some SDVO cards based on conexant chip, we can't read the EDID if
we don't read the response after issuing SDVO DDC bus switch
command.

From the SDVO spec once when another I2C transaction is finished after
completing the I2C transaction of issuing the bus switch command, it
will be switched back to the SDVO internal state again. So we can't
initiate a new I2C transaction to read the response after issuing the
DDC bus switch command. Instead we should issue DDC bus switch command
and read the response in the same I2C transaction.

https://bugs.freedesktop.org/show_bug.cgi?id=23842
https://bugs.freedesktop.org/show_bug.cgi?id=24458
https://bugs.freedesktop.org/show_bug.cgi?id=24522
https://bugs.freedesktop.org/show_bug.cgi?id=24282Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NSebastien Caty <sebastien.caty@mrnf.gouv.qc.ca>
Signed-off-by: NEric Anholt <eric@anholt.net>

On some boxes the BIOS will report different child device arrays when
the system is booted with/without the dock. In such case the HDMI/DP
port can't be setup correctly.  So revert two commits
(fc816655/
6e36595a) that use the child device
parsed from VBT to setup HDMI/DP.

http://bugzilla.kernel.org/show_bug.cgi?id=14854
http://bugzilla.kernel.org/show_bug.cgi?id=14860Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Tested-by: NSean Young <sean@mess.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Commit cbda12d7 (drm/i915: implement
new pm ops for i915), among other things, removed the .suspend and
.resume pointers from the struct drm_driver object in i915_drv.c,
which broke resume without KMS on my MSI Wind U100.

Fix this by reverting that part of commit cbda12d7.
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[anholt: added comment explaining when .suspend/.resume matter]
Signed-off-by: NEric Anholt <eric@anholt.net>

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

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

Some upcoming G80 DMA changes will depend on this, but it's split out for
bisectibility just in case it causes some unexpected issues.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

Currently Nouveau will unvalidate all buffers if it is forced to wait on
one, and then start revalidating from the beginning.  While doing so, it
destroys the operation fence, causing nouveau_fence_emit to crash.

This patch fixes this bug by taking the fence object out of validate_op
and creating it just before emit.  The fence pointer is initialized to 0
and unref'ed unconditionally.

In addition to fixing the bug, this prevents its reintroduction and
simplifies the code.
Signed-off-by: NLuca Barbieri <luca@luca-barbieri.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The below is mainly an educated guess at what's going on, docs would
sure be handy...  NVIDIA? :P

It appears it's possible for a ctxprog to run even while a GPU exception
is pending.  The GF8 and up ctxprogs appear to have a small snippet of
code which detects this, and stalls the ctxprog until it's been handled,
which essentially looks like:

	if (r2 & 0x00008000) {
		r0 |= 0x80000000;
		while (r0 & 0x80000000) {}
	}

I don't know of any way that flag would get cleared unless the driver
intervenes (and indeed, in the cases I've seen the hang, nothing steps
in to automagically clear it for us).  This patch causes the driver to
clear the flag during the PGRAPH IRQ handler.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There's no good reason for us to have our own anymore, this is left over
from an early port to these TTM interfaces.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

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

It's mostly a cleanup, but in nv50_fbcon_accel_init gpu lockup
message was printed, but HWACCEL_DISBALED flag was not set.
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>

Depending on the visual, the colours handed to us in fillrect() can either be
an actual colour, or an index into the pseudo-palette.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

This should avoid a race condition on nv0x, if we're doing it with
actual PGRAPH objects and a there's a fence within the FIFO DMA fetch
area when a context switch kicks in.

In that case we get an ILLEGAL_MTHD interrupt as expected, but the
values in PGRAPH_TRAPPED_ADDR aren't calculated correctly and they're
almost useless (e.g. you can see ILLEGAL_MTHDs for the now inactive
channel, with a wrong offset/data pair).
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

It will be useful for various synchronization purposes, mostly stolen
from "[PATCH] drm/nv50: synchronize user channel after buffer object
move on kernel channel" by Maarten Maathuis.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

- This should be better than what we have now.
- I'm less sure about the non power of two path.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>

- Aligning to block size should ensure that the extra size is enough.
- Using roundup, because not all sizes are powers of two.
Signed-off-by: NMaarten Maathuis <madman2003@gmail.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>