drm/i915: use GMBUS to manage i2c links

Use the GMBUS interface rather than direct bit banging to grab the EDID
over DDC (and for other forms of auxiliary communication with external
display controllers). The hope is that this method will be much faster
and more reliable than bit banging for fetching EDIDs from buggy monitors
or through switches, though we still preserve the bit banging as a
fallback in case GMBUS fails.

Based on an original patch by Jesse Barnes.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: call drm_encoder_init first

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>

drm/i915/sdvo: Mark the status as unknown if attached with EDID

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>

drm/i915/sdvo: Only create the analog encoder as required

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>

agp/intel: Fix resume regression from 2d2430cf

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>

agp/intel: Remove redundant setting of gtt_mappable_entries

Two calls enter, only one will leave.

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

drm/i915/sdvo: Propagate i2c error from switching DDC control bus.

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

drm/i915/sdvo: Tidy intel_sdvo_hdmi_sink_detect

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

drm/i915: Remove unused intel_ringbuffer->ring_flag

This can always be re-added should somebody find a use...

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

drm/i915/i2c: Track the parent encoder rather than just the dev

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>

drm/i915: Allow get_fence_reg() to be uninterruptible

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>

drm/i915: Push pipelining of display plane flushes to the caller

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>

agp/intel: Use macro to set the count of the size array

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>

drm/i915: Fix regression in ba3d8d749b

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>

drm/i915: Consolidate flushing the display plane

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

drm/i915: Reduce hangcheck frequency

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>

drm/i915: Remove redundant initialisation of crtc->pipe

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

drm/i915: Initialize intel_crtc->active

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>

drm/i915: Fix an overlay regression from 7e7d76c

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>

drm/i915: Share crtc setup and teardown between dpms and disable/enable

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>

drm/i915/lvds: Move private data to the connector from the device.

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

drm/i915/lvds: Remove incorrect mode locking

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>

drm/i915/lvds: Ensure panel is unlocked for Ironlake or the panel fitter

Commit 77d07fd9d73ef28689737c0952dbd5d6a5017743 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>

drm/i915/bios: Prevent NULL dereference after allocation failure

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

drm/i915/sdvo: Poll command status 5 times without delay on read

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>

drm/i915: Use msleep instead of mdelay during wait_vblank_off

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>

drm/i915/lvds: Remove busy wait for powering up the panel.

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>

drm/i915/lvds: Remove busy wait for powering down the panel

Just assume that it will turn off...

Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/i2c: The bit-banging interface controls the delay, drop ours

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>

drm/i915/dp: Convert a udelay(17000) to a sleep during link-off

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

drm/i915: Use macros to switch between equivalent pipe registers

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>

drm/i915: Tidy Ironlake watermark computation

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>

drm/i915: Fix updating FBC

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>

drm/i915: enable thermal reporting for IPS

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>

Merge branch 'drm-intel-fixes' into drm-intel-next

drm/i915: Use the real FDI frequency for determining b/w

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

drm/i915: Only call udelay() when waiting for clocks to stabilise

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

drm/i915: Ensure all PLL registers are flushed before a udelay()

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

drm/i915: set FDI RX TU size to match transmit size

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>

drm/i915: don't write TU size to N1 reg

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>

drm/i915: split Ironlake FDI enable function

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>

drm/i915: enable PCH PLL, FDI training and transcoder even for eDP

eDP panels require these to be set up prior to panel power sequencing,
or they'll fail to power on due to an "asset not ready" check.  And of
course, eDP panels attached to anything other than DP_A need them
enabled regardless, since they'll be driven from the CPU through FDI out
to the PCH.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: use i915 and Ironlake CRTC enable/disable functions in prepare/commit

This will allow us to optimize our prepare/commit paths a bit better.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: minor tweak to handle the cursor across pipe resizing]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: don't unlock panel regs

This was just a workaround for some broken Ironlake CRTC code.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: split i9xx CRTC enable/disable code

So we can use it for CRTC prepare/commit.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: split Ironlake CRTC enable/disable code

This way we can also use it in CRTC prepare/commit.  Also makes it
easier to split out FDI and other code.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Adapt workqueue to new alloc_workqueue interface

create_singlethreaded_workqueue() is being phased out for a new
concurrency managed task infrastructure.

Adapt our workqueue constructor to explicitly create a domain that only
allows the execution of a single task at any time. All the tasks are
expected to require the dev->struct_mutex, so would block concurrency of
other tasks if we allow more than a single i915 task to be run at once.

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

drm/i915: don't enable self-refresh on Ironlake

We don't know how to enable it safely, especially as outputs turn on and
off.  When disabling LP1 we also need to make sure LP2 and 3 are already
disabled.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29173
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29082
Reported-by: Chris Lord <chris@linux.intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/debug: Include Ironlake in self-refresh status

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

drm/i915: Make the connector->encoder relationship explicit

Currently we have a exact mapping of a connector onto an encoder for its
whole lifetime. Make this an explicit property of the structure and so
simplify the code.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

drm/i915: Use the direct mapping of pipe->crtc

Why iterate all the crtcs to find the pipe, when we already know which
crtc is attached to which pipe?

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

drm/i915: Rename intel_encoder->enc to base for consistency

[Patch is slightly larger than is strictly necessary to fixup
surrounding checkpatch.pl errors.]

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

drm/i915: Double check that the wait_request is not pending before warning

If we are busy, then we may have woken up the wait_request handler but
not yet serviced it before the hang check fires. So in hang check,
double check that the i915_gem_do_wait_request() is still pending the
wake-up before declaring all hope lost.

Fixes regression with e78d73b16bcde921c9cf458d2e4de8e4fc2518f3.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30073
Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/dp: Flush the PLL register write before sleeping

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

drm/i915: make sure panel is sequenced off when starting a mode set

Otherwise we may not be able to train the DP link.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: make sure VDD AUX power has time to settle

When turning on or off the VDD AUX bit, we need to give the panel time
to start or stop or AUX transactions may fail.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: don't change VDD AUX status in panel power functions

Mode set sequence outlines when the AUX VDD bit should be set and
cleared, and it's separate from the panel power sequence.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: split DP link training across panel power sequencing

Mode set sequence requires that we start training, then enable the
panel, then complete training.  So split the DP training function into
two parts; the first enables the DP port and sets training pattern 1 and
the second completes the training.

As part of this, remove some redundant function args from the various DP
handling functions and use the intel_dp fields everywhere we can.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: removed first ironlake_edp_backlight_on() on advice of jbarnes]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: use VDD AUX for panel power around detection and in prepare

Mode setting sequence specifies that we use VDD AUX for configuration
and detection, and early in the mode set sequence.  Only later (after
DP_A has started training) should we actually enable panel power.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: checkpatch.pl complaining about whitespace]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: use 125MHz reference clock for PCH attached eDP

Fix the test so we don't try to use the 450MHz refclk on PCH attached
eDP.

References:
  https://bugs.freedesktop.org/show_bug.cgi?id=29141

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: fix eDP detection

Panel needs to be powered up.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

i915: snprintf returns large values

snprintf() returns the number of bytes which would have been used if
there was enough space.  It can be larger than the size of the buffer.
Obviously in this case the buffer is large enough but everyone just
copy and pastes this code so it's better to limit it and set a good
example.

Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: die, i915_probe_agp, die

Use the detection from intel-gtt.ko instead. Hooray!

Also move the stolen mem allocator to the other gtt stuff in dev_prv->mem.

v2: Chris Wilson noted that my error handling was crap. Fix it. He also
said that this fixes a problem on his i845. Indeed, i915_probe_agp
misses a special case for i830/i845 stolen mem detection.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=25476
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: drop prealloc_start from i915_dma gtt init

Not used and simply confusing.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: use chipset generation number some more

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: call init_gtt_init in probe function

This way create_gatt_table become dummy glue functions for the fake
agp driver - rename them accordingly (and kill the now unnecessary
i9xx copy).

With this change, the gtt initialization code is almost independant
from the agp stuff. Two things are still missing:
- the scratch page is created by the generic agp code.
- filling the whole gtt with scratch_page ptes is not yet consolidated -
  this needs abstracted pte handling, first.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: consolidate i9xx setup

The only difference between i915 and i965 was the calculation of the
gtt address. So merge these two paths into one. Otherwise the same
changes as in the i830 setup consolidation.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: consolidate i830 setup

Slighlty reordered sequence was necessary. Also don't set
agp_bridge->gatt_bus_addr anymore. Only used by generic agp helper
functions, hence unnecessary for the intel fake agp driver.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: consolidate the gtt ioremap calls

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: i830: adjust ioremap of regs and gtt to i9xx

This way around this can be extracted into common code.

Also use a common cleanup function (and give it a generic name).

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: i965: use detected gtt size for mapping

Also move the Sandybdridge size detection into gtt_total_entries, like
the rest.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: i915: use detected gtt size for mapping

Slight reordering of the init sequence required.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: introduce intel_gtt_driver

Same idea as INTEL_INFO from drm/i915. This
- reduces the dependancy on agp_driver
- stops the what-does-IS_I965G-mean confusion (here it's just gen4, in
  drm/i915 it's gen >=4)
- further prepares the separation of the fake agp driver from the rest.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: fix gtt_total_entries detection

In commit f1befe71 Chris Wilson added some code to clear the full gtt
on g33/pineview instead of just the mappable part. The code looks like
it was copy-pasted from agp/intel-gtt.c, at least an identical piece
of code is still there (in intel_i830_init_gtt_entries). This lead to
a regression in 2.6.35 which was supposedly fixed in commit e7b96f28

Now this commit makes absolutely no sense to me. It seems to be
slightly confused about chipset generations - it references docs for
4th gen but the regression concerns 3rd gen g33. Luckily the the g33
gmch docs are available with the GMCH Graphics Control pci config
register definitions. The other (bigger problem) is that the new
check in there uses the i830 stolen mem bits (.5M, 1M or 8M of stolen
mem). They are different since the i855GM.

The most likely case is that it hits the 512M fallback, which was
probably the right thing for the boxes this was tested on.

So the original approach by Chris Wilson seems to be wrong and the
current code is definitely wrong. There is a third approach by Jesse
Barnes from his RFC patch "Who wants a bigger GTT mapping range?"
where he simply shoves g33 in the same clause like later chipset
generations.

I've asked him and Jesse confirmed that this should work. So implement
it.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16891$
Tested-by: Anisse Astier <anisse@astier.eu>
Cc: stable@kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: s/i8[13]0/fake_agp for generic functions

Start to separate the fake agp driver from the rest of intel-gtt.c

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: adjust overhead entries in intel_gtt_stolen_entries

agp/intel_gtt.c and drm/i915/i915_dma.c don't calculate this the same
way: The intel-gtt code seems to use the actual gtt size, the drm
module just the mappable. Go with the logic from the drm module because
that's the more conservative choice.

But conserve the original code in intel_gtt_total_size for later use.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: drop unnecessary conditions in intel_gtt_stolen_entries

The dedection function in drm/i915/i915_dma.c works without it, so
drop it here, too. All the values are disdinct, anyway.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: sane variable names for intel_gtt_stolen_entries

This somewhat aligns it with the version in drm/i915/i915_dma.c.
Changes:
- s/gtt_entries/stolen_size
- track overhead entries in a seperate var (the effective gtt size
  calculation will be extracted later on).
- subtract the overhead at the end instead of in each clause.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: generic intel_fake_agp_fetch_size

This uses the new mappable gtt size detection from the previous patch.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: new function intel_gtt_mappable_entries

This implementation is stolen from drm/i915, but is equivalent to
the code sprinkled over intel-gtt.c in the various fetch_size functions.
It's not yet used anywhere, though.

Also introduce intel_gtt_init which only calls intel_gtt_stolen_entries.
Over the course of the next patches, this will grow untill it contains
the complete init sequence starting from the call to gtt_mappable_entries.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: s/intel_i830_init_gtt_entries/intel_gtt_stolen_entries

First simple step towards a more generic initialization. This
is needed to disentangle the agp stuff from the stuff that is
actually needed by drm/i915.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: store a local pointer to the bridge pci dev

When the intel-gtt code now longer depends on agp, we cannot rely
on this. So store a local reference in intel-gtt.c.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

intel-gtt: introduce drm/intel-gtt.h

Add a few definitions to it that are already shared and that will
be shared in the future (like the number of stolen entries).
No functional changes in here.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

agp/intel: make intel-gtt.c into a real source file

Now that the disentangling is complete, stop including intel-gtt.c
from intel-agp.c.

The linux build system _really_ doesn't allow .c source files with the
same name as the module. It fails with the following message when trying
to build such a bugger:

make[3]: Circular drivers/char/agp/intel-agp.o <- drivers/char/agp/intel-agp.o dependency dropped.

Instead of renameing intel-agp.c I've simply created a new module out
of intel-gtt.c. Renaming intel-agp.ko to something else is not an option
for it will surely kill someones boot process.

This also paves the way to use the gtt code without loading the agp
driver.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

agp/intel: split out gmch/gtt probe, part 2

This just splits the device list into two and moves the gtt related stuff
to intel-gtt.c. The two new devices lists also lose the not longer needed
fields. There where only about 5 cases anyway with both a gmch and a
possible agp port, so the duplication of entries is rather small.
Additionally kill 2 out of the three Ironlake mobile entries that
only differed in host bridge pci id.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Don't disable panel for modesetting if pfit hasn't changed

It seems to be possible to program a new mode without disabling the panel
if the panel fitter setup doesn't change. Add support for that.

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: set dither bits on eDP panels too

We really need a macro to test whether a given connector has a panel
attached rather than sprinkling HAS_PCH_SPLIT/IS_eDP/has_edp_encoder
etc all over. In the meantime, fix the bug...

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[ickle: tidy up the duplicity in the conditionals]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: fix pipeconf dither bit definitions

Make them match the others and add BPP definitions.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Remove impossible error handling from bit17 swizzling

Our usage of kmap() cannot return NULL here, so remove the unnecessary
error handling.

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

drm/i915: Add ringbuffer wait reset to hangcheck

The GPU records whether it is currently waiting for a completion of a
WAIT_FOR_EVENT in the RB_WAIT bit in the ringbuffer control registers.
On third generation chipsets and later, a write of 1 to this bit breaks
the hang and returns the GPU to arbitration, i.e. the GPU should
continue executing the reminder of the batchbuffer and return to normal
operations.

By adding this to hangcheck we can avoid a full GPU reset under these
conditions.

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

drm/i915: Clear scanline waits after disabling the pipe.

If we disable the pipe and the GPU is currently waiting on a scanline
WAIT_FOR_EVENT, the GPU will hang. Fortunately, there is a magic bit
which we can write on i915+ to break this wait after disabling the
pipe.

References:

  Bug 29252 - [Arrandale] Hung WAIT_FOR_EVENT when running rss-glx-skyrocket
  https://bugs.freedesktop.org/show_bug.cgi?id=29252

  Bug 28964 - [i965gm] GPU infinite MI_WAIT_FOR_EVENT while watching video in Totem
  https://bugs.freedesktop.org/show_bug.cgi?id=28964

and many others.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

drm/i915: Show framebuffer info in debugfs

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

drm/i915: Show device capabilities in debugfs

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

drm/i915/tv: After disabling the pipe, use wait_for_vblank_off()

Hopefully this is a contributing factor to the spurious TV detection
repoted by Ivan Bulatovic and others.

References:

  Bug 16871 - "TV1 connected" with no tv
  https://bugzilla.kernel.org/show_bug.cgi?id=16871

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Ivan Bulatovic <combuster@gmx.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>

drm/i915: Refactor panel backlight controls

There were two instances of code to control the panel backlight and
neither handled the complete set of device variations.

Fixes:

  Bug 29716 - [GM965] Regression: Backlight resets to minimum when changing resolution
  https://bugs.freedesktop.org/show_bug.cgi?id=29716

And a bug on one of my PineView boxes which overflowed the backlight
value.

Incorporates part of a similar patch by Matthew Garrett that exposes a
native Intel backlight controller.

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

drm/i915: Remove redundant initialisation of fb_base

We do it whilst configuring dev->mode_config, so remove the out-of-place
earlier initialisation.

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

drm/i915: Quieten sparse warnings for missing prototypes.

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

drm/i915: Kill the active list spinlock

This spinlock only served debugging purposes in a time when we could not
be sure of the mutex ever being released upon a GPU hang. As we now
should be able rely on hangcheck to do the job for us (and that error
reporting should not itself require the struct mutex) we can kill the
incomplete attempt at protection.

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

drm/i915: Remove the random SyncFlush during initialisation

We have no idea why we request a SyncFlush via INSTPM at that point in
time -- we certainly never check for its completion...

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

drm/i915: Compile out error state without DEBUG_FS

Alexander reported that the compilation of intel_overlay.c was failing
due to an inclusion that was only valid with CONFIG_DEBUG_FS. As the
whole error reporting is only useful with debugfs enabled, remove all
the redundant error state collection code when compiling without
CONFIG_DEBUG_FS.

Reported-by: Alexander Lam <lambchop468@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>