Later initialisation of the encoder often requires that
drm_encoder_init() has already been called, for instance, initialiasing
the DDC buses.

Yet another recent regression, as 819f3fb7 depended upon these fixes
which I missed when cherry-picking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

One problem with devices that share the DDC bus between the VGA and
DVI-I connectors is that with two devices attached we cannot know if
there is truly a monitor attached to the DVI connector. In this case, it
is preferrrable to mark the status as unknown, so that the user can
supply the known set of modes and continue to use the output.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

We only need to use the analog encoder for rare devices which share the
DDC between the DVI-I and VGA connectors, so only create as needed.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

On i915 [EeePCs] something scribles over the registers during suspend
and resume so we must save a copy of the PGETBL_CTL register programmed
by the BIOS and restore that upon resume.
Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Two calls enter, only one will leave.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

This can always be re-added should somebody find a use...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

The SDVO proxy i2c adapter wants to be able to use information stored in
the encoder, so pass that through intel_i2c rather than iterate over all
known encoders every time.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

As we currently may need to acquire a fence register during a modeset,
we need to be able to do so in an uninterruptible manner. So expose that
parameter to the callers of the fence management code.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

This ensures that we do wait upon the flushes to complete if necessary
and avoid the visual tears, whilst enabling pipelined page-flips.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

It's a fixed size array so let the compiler do the hard work of updating
all the call sites.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

I pulled the wrong version of the patch from Daniel Vetter which was
missing the read barriers -- and the one that was causing all the trouble
was from i915_gem_object_put_fence_reg(), leading to GPU hangs on gen3.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

By reducing the hangcheck frequency we check less often, conserving
resources, and still detect a lock up quickly. On a fast machine with a
slow GPU (like a Core2 paired with a 945G) it is easy for the hangcheck to
misfire as we check too fast.

Also once hung and if we fail to completely reset the chip, we have a
nasty habit of proclaming a hang many times a second and generating a
strobe-like display.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Fix a regression in the previous regression fix...

In order to turn off the pipes entirely upon the first modeset, we
pretend that BIOS (or earlier module incarnation) left them active.
The first task performed by setup_initial_configuration() is to disable
all pipes and so to avoid skipping that step and so to ensure a known
configuration we need to mark all the crtcs as active.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

When separating out the prepare/commit into its own separate functions
we overlooked that the intel_crtc->dpms_mode was being used elsewhere to
check on the actual status of the pipe.

Track that bit of logic separately from the actual dpms mode, so there
is no confusion should we be able to handle multiple dpms modes, nor
any semantic conflict between prepare/commit and dpms.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

This closes a couple of corner cases where we introduced and forgot
about a couple of routines that need to be called when disabling the
crtc and then re-enabling it. The code needs to be moved again so that
the common bits are shared across generations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

One doesn't need to hold the mode lock in order to duplicate a mode.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Commit 77d07fd9 introduced a regression
where by not waiting for the panel to be turned off, left the panel and
PLL registers locked across the modeset. Thus the panel remaining blank.

As pointed out by Daniel Vetter, when testing LVDS it helps to open the
laptop and look at the actual panel you are purporting to test.

A second issue with the patch was that in order to modify the panel
fitter before gen5, the pipe and the panel must have be completely
powered down. So we wait.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

The documentation says that an SDVO command takes a maximum of 15us to be
processed by the device, and that it is sufficient to read the status byte
3 times (whilst the command is still in the PENDING state) for the driver
to be confident that sufficient time has elapsed.

We err on the safe side and try 5 times before giving up.

The only question that remains: was the old behaviour derived by
experiments with real hardware?

A look into the murky history of UMS, implies that the behaviour was
accidental and the current retry mechanism was solely designed to catch
the status byte indicating PENDING with no reference to hardware
behaviour. (commit ac9181c014638dbeb334b40b4029d0ccb2b7a0fc in
xf86-video-intel)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Avoid a potentially long busy-wait if we not in the process of
atomically switching to the kdb console.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

We just assume that it will happen in a timely manner. A variant of this
patch was first written and tested by Arjan van de Van.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Just assume that it will turn off...
Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Remove our redundant udelay() as the timings are already handled by the
i2c-algo-bit controller.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

The purpose is to make the code much easier to read and therefore reduce
the possibility for bugs.

A side effect is that it also makes it much easier for the compiler,
reducing the object size by 4k -- from just a few functions!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Refactor the common code into seperate functions and use the MIN(large,
small) buffer calculation for self-refresh watermarks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

We need to track different state on each generation in order to detect
when we need to refresh the FBC registers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Thermal reporting may not be enabled by default on some machines, so
enable the appropriate bits to allow IPS to get the data it needs from
the CPU thermal device.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

This allows FDI error checking to work.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

TU size is only part of the M1 and M2 regs, not the N regs.  This keeps
us from overwriting a reserved field.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Easier to read, and will pair up with a disable function.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>