HSW no longer has the PIPECONF bit for limited range RGB output.
Instead the pipe CSC unit must be used to perform that task.

The CSC pre offset are set to 0, since the incoming data is full
[0:255] range RGB, the coefficients are programmed to compress the
data into [0:219] range, and then we use either the CSC_MODE black
screen offset bit, or the CSC post offsets to shift the data to
the correct [16:235] range.

Also have to change the confiuration of all planes so that the
data is sent through the pipe CSC unit. For simplicity send the
plane data through the pipe CSC unit always, and in case full
range output is requested, the pipe CSC unit is set up with an
identity transform to pass the plane data through unchanged.

I've been told by some hardware people that the use of the pipe
CSC unit shouldn't result in any measurable increase in power
consumption numbers.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881
Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: NJani Monoses <jani@ubuntu.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Print out the HW context object information per ring. Even though the
existing code only utilizes the render ring, it's simple enough to
support future expansion.

I had this in a patch somewhere in a rev of the original implementation,
but I must have lost it.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: s/context/default context/ bikeshed applied.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Yet another remnant ... this might explain why l3 remapping didn't
really work on HSW.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441Spotted-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The bit controlling whether PIPE_CONTROL DW/QW write targets
the global GTT or PPGTT moved moved from DW 2 bit 2 to
DW 1 bit 24 on IVB.

I verified on IVB that the fix is in fact effective. Without the fix
none of the scratch writes actually landed in the pipe control page.
With the fix the writes show up correctly.

v2: move PIPE_CONTROL_GLOBAL_GTT_IVB setup to where other flags are set
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56359
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9.
Since we do all calculations based on them being register values (which are
subtracted by 2) we need to specify them accordingly.
Signed-off-by: NPatrik Jakobsson <patrik.r.jakobsson@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Similarly to:

  commit 6a0d1df3d3a0d2370541164eb0595fe35dcd6de3
  Author: Damien Lespiau <damien.lespiau@intel.com>
  Date:   Tue Dec 11 15:18:28 2012 +0000

      drm/i915: Preserve the FDI line reversal override bit on CPT

DDI port support lane reversal to easy the PCB layouting work. Let's
preserve the bit configured by the BIOS (until we find how to correctly
retrieve the information from the VBT, but this does sound more fragile
then just relying on the BIOS that has, hopefully, been validated
already.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The FDI link has supported link reversal to make the PCB layout
engineer's life easier for quite a while and we have always presered
this bit as we programmed FDI_RX_CTL with a read/modify/write sequence.

We're trying to take a bit more control over what the BIOS leaves in
various register and with the introduction of DDI, started to program
FDI_RX_CTL fully.

There's a fused bit to indicate DMI link reversal and FDI defaults to
mirroring that configuration. We have a bit to override that behaviour
that we need to preserve from the BIOS.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Amending
commit 4518f611
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jan 23 16:16:35 2013 +0100

    drm/i915: dump UTS_RELEASE into the error_state

CC: stable@vger.kernel.org
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As explained by Chris Wilson gem objects in stolen memory are always
coherent with the GPU so we don't need to ever flush the CPU caches for
these.

This fixes a breakage - at least with the compact sg patches applied -
during the resume/restore gtt mappings path, when we tried to clflush an
FB object in stolen memory, but since stolen objects don't have backing
pages we passed an invalid page pointer to drm_clflush_page().
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If a GPU reset occurs while a page flip has been submitted to the ring,
the flip will never complete once the ring has been reset.

The GPU reset can be detected by sampling the reset_counter before the
flip is submitted, and then while waiting for the flip, the sampled
counter is compared with the current reset_counter value.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: Move the reset_counter assignment to an earlier place in
common code as discussed on the mailing list.]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=60140Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The pending flip mask no longer set anywhere, so trying to wait for
while it's non-zero is a no-op. Remove it completely.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This has been lost in the locking rework for intel_alloc_context_page:

commit 2c34b850
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Sat Mar 19 18:14:26 2011 -0700

    drm/i915: fix ilk rc6 teardown locking

Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already print the HWS addresses during init, so do the same for the
pipe control page. Reduces guesswork when looking at hex addresses
later.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the previous patch "drm/i915: disable shared panel fitter for
pipe" we now disable the panel fitter at the right spot in the modeset
sequence in the crtc functions on all platforms. Hence the disabling
in intel_disable_lvds is no longer required and potentially harmful
(since the plane is still enabled at this point).

Similarly on the enabling side we enable the panel fitter in the lvds
callback only once the plane is enabled. Which is too late. Hence move
this into a new intel_pre_enable_lvds callback.

Finally we can ditch lvds_encoder->pfit_dirty - this was required to
work around the crtc helper semantics, but with the new i915 modeset
infrastructure we should enable/disable the pfit only when enabling or
disabling the entire output pipeline. So separate state tracking for
the pfit is no longer required.
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
[danvet: Bikeshed the commit message a bit to stress that now we
enable/disable the pfit on i9xx platforms at the right point of time
compared to the old code.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If encoder is switched off by BIOS, but the panel fitter is left on,
we never try to turn off the panel fitter and leave it still attached
to the pipe - which can cause blurry output elsewhere.

Based on work by Chris Wilson <chris@chris-wilson.co.uk>

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867
Cc: stable@vger.kernel.org
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Tested-by: NAndreas Sturmlechner <andreas.sturmlechner@gmail.com>
[danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny
comment.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some early bios versions seem to ship with the wrong tuning values for
the MCH, possible resulting in pipe underruns under load. Especially
on DP outputs this can lead to black screen, since DP really doesn't
like an occasional whack from an underrun.

Unfortunately the registers seem to be locked after boot, so the only
thing we can do is politely point out issues and suggest a BIOS
upgrade.

Arthur Runyan pointed us at this issue while discussion DP bugs - thus
far no confirmation from a bug report yet that it helps. But at least
some of my machines here have wrong values, so this might be useful in
understanding bug reports.

v2: After a bit more discussion with Art and Ben we've decided to only
the check the watermark values, since the OREF ones could be be a
notch more aggressive on certain machines.

Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Runyan, Arthur J <arthur.j.runyan@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's not that the assertion is incorrect, but rather that we can call
do_destroy early in loading, and we will falsely BUG().

Since contexts have been in for a while now, and in the internal APIs
are pretty stable, it should be fairly safe to remove this.

v2: Remove unused dev_priv, and dev
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The ring initialization will differ a bit in upcoming generations, and
this split will prepare the code for what's needed.

This patch also fixes a bug introduced in:
commit 99433931
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Tue Jan 22 14:12:17 2013 +0200

    drm/i915: use gem_set_seqno() on hardware init

After doing the extraction, the bad error handling became obvious.  I
acknowledge that this should be two patches, but it's a pretty
small/trivial patch. If requested, I can certainly do the fix as a
distinct patch.

v2: Should be cleanup blt, not init blt on failure (Chris)

v3: Forgot to git add on v2

Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When I refactored the code initially, I forgot that gen2 uses a
different bar for the CPU mappable aperture. The agp-less code knows
nothing of generations less than 5, so we have to expand the gtt_probe
function to include the mappable base and end.

It was originally broken by me:
commit baa09f5f
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Thu Jan 24 13:49:57 2013 -0800

    drm/i915: Add probe and remove to the gtt ops
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So we can remove duplicated code. Note that this function is used not
only on IBX, but also CPT and LPT.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Also bikeshed s/ironlake_enable_pch_hotplug/ibx_enable_hotplug
to keep consistent with our ibx for pch naming scheme.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have more than one sprite, so a boolean simply won't cut it.
Turn sprite_scaling_enabled into a bitmask and track the state
of sprite scaler for each sprite independently.

Also don't re-enable LP watermarks until the sprite registers
have actually been written, and thus sprite scaling has really
been disabled.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

They're physically the same pins and also the same bits, duplicating
only confuses the reader. This also makes it a bit obvious that we
have quite some code duplication going on here. Squashing that is for
a larger rework in our hpd handling though.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This was a rebase error from when the patches originally landed. Since
the context size is unsigned, there is also no use in checking if it's
less than 0.

The existing code is not really wrong, but it's not simple as it should
be.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

770c1231 is the first bad commit
commit 770c1231
Author: Takashi Iwai <tiwai@suse.de>
Date:   Sat Aug 11 08:56:42 2012 +0200

    drm/i915: Fix blank panel at reopening lid

changed the register write sequence for restoring the backlight, which
helped prevent non-working backlights on some machines. Turns out that
the original sequence was the right thing to do for a different set of
machines. Worse, setting the backlight level _after_ enabling it seems
to reset it somehow. So we need to make that one conditional upon the
backlight having been reset to zero, and add the old one back.

Cargo-culting at it's best, but it seems to work.

Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

i915 driver needs to do modeset when
1. system resumes from sleep
2. lid is opened

In PM_SUSPEND_MEM state, all the GPEs are cleared when system resumes,
thus it is the i915_resume code does the modeset rather than intel_lid_notify().

But in PM_SUSPEND_FREEZE state, this will be broken because
system is still responsive to the lid events.
1. When we close the lid in Freeze state, intel_lid_notify() sets modeset_on_lid.
2. When we reopen the lid, intel_lid_notify() will do a modeset,
   before the system is resumed.
here is the error log,

[92146.548074] WARNING: at drivers/gpu/drm/i915/intel_display.c:1028 intel_wait_for_pipe_off+0x184/0x190 [i915]()
[92146.548076] Hardware name: VGN-Z540N
[92146.548078] pipe_off wait timed out
[92146.548167] Modules linked in: hid_generic usbhid hid snd_hda_codec_realtek snd_hda_intel snd_hda_codec parport_pc snd_hwdep ppdev snd_pcm_oss i915 snd_mixer_oss snd_pcm arc4 iwldvm snd_seq_dummy mac80211 snd_seq_oss snd_seq_midi fbcon tileblit font bitblit softcursor drm_kms_helper snd_rawmidi snd_seq_midi_event coretemp drm snd_seq kvm btusb bluetooth snd_timer iwlwifi pcmcia tpm_infineon i2c_algo_bit joydev snd_seq_device intel_agp cfg80211 snd intel_gtt yenta_socket pcmcia_rsrc sony_laptop agpgart microcode psmouse tpm_tis serio_raw mxm_wmi soundcore snd_page_alloc tpm acpi_cpufreq lpc_ich pcmcia_core tpm_bios mperf processor lp parport firewire_ohci firewire_core crc_itu_t sdhci_pci sdhci thermal e1000e
[92146.548173] Pid: 4304, comm: kworker/0:0 Tainted: G        W    3.8.0-rc3-s0i3-v3-test+ #9
[92146.548175] Call Trace:
[92146.548189]  [<c10378e2>] warn_slowpath_common+0x72/0xa0
[92146.548227]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548263]  [<f86398b4>] ? intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548270]  [<c10379b3>] warn_slowpath_fmt+0x33/0x40
[92146.548307]  [<f86398b4>] intel_wait_for_pipe_off+0x184/0x190 [i915]
[92146.548344]  [<f86399c2>] intel_disable_pipe+0x102/0x190 [i915]
[92146.548380]  [<f8639ea4>] ? intel_disable_plane+0x64/0x80 [i915]
[92146.548417]  [<f8639f7c>] i9xx_crtc_disable+0xbc/0x150 [i915]
[92146.548456]  [<f863ebee>] intel_crtc_update_dpms+0x5e/0x90 [i915]
[92146.548493]  [<f86437cf>] intel_modeset_setup_hw_state+0x42f/0x8f0 [i915]
[92146.548535]  [<f8645b0b>] intel_lid_notify+0x9b/0xc0 [i915]
[92146.548543]  [<c15610d3>] notifier_call_chain+0x43/0x60
[92146.548550]  [<c105d1e1>] __blocking_notifier_call_chain+0x41/0x80
[92146.548556]  [<c105d23f>] blocking_notifier_call_chain+0x1f/0x30
[92146.548563]  [<c131a684>] acpi_lid_send_state+0x78/0xa4
[92146.548569]  [<c131aa9e>] acpi_button_notify+0x3b/0xf1
[92146.548577]  [<c12df56a>] ? acpi_os_execute+0x17/0x19
[92146.548582]  [<c12e591a>] ? acpi_ec_sync_query+0xa5/0xbc
[92146.548589]  [<c12e2b82>] acpi_device_notify+0x16/0x18
[92146.548595]  [<c12f4904>] acpi_ev_notify_dispatch+0x38/0x4f
[92146.548600]  [<c12df0e8>] acpi_os_execute_deferred+0x20/0x2b
[92146.548607]  [<c1051208>] process_one_work+0x128/0x3f0
[92146.548613]  [<c1564f73>] ? common_interrupt+0x33/0x38
[92146.548618]  [<c104f8c0>] ? wake_up_worker+0x30/0x30
[92146.548624]  [<c12df0c8>] ? acpi_os_wait_events_complete+0x1e/0x1e
[92146.548629]  [<c10524f9>] worker_thread+0x119/0x3b0
[92146.548634]  [<c10523e0>] ? manage_workers+0x240/0x240
[92146.548640]  [<c1056e84>] kthread+0x94/0xa0
[92146.548647]  [<c1060000>] ? ftrace_raw_output_sched_stat_runtime+0x70/0xf0
[92146.548652]  [<c15649b7>] ret_from_kernel_thread+0x1b/0x28
[92146.548658]  [<c1056df0>] ? kthread_create_on_node+0xc0/0xc0

three different modeset flags are introduced in this patch
MODESET_ON_LID_OPEN: do modeset on next lid open event
MODESET_DONE:  modeset already done
MODESET_SUSPENDED:  suspended, only do modeset when system is resumed

In this way,
1. when lid is closed, MODESET_ON_LID_OPEN is set so that
   we'll do modeset on next lid open event.
2. when lid is opened, MODESET_DONE is set
   so that duplicate lid open events will be ignored.
3. when system suspends, MODESET_SUSPENDED is set.
   In this case, we will not do modeset on any lid events.

Plus, locking mechanism is also introduced to avoid racing.
Signed-off-by: NZhang Rui <rui.zhang@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The RC6 VIDS has a linear ramp starting at 250mv, which means any values
below 250 are invalid. The old buggy macros tried to adjust for this to
be more flexible, but there is no need. As Dan pointed out the ENCODE
only ever has one value. The only invalid value for decode is an input
of 0 which means something is really wonky, and the cases where DECODE
are used either don't matter (debug values), or would be implicitly
correct (the check for less than 450).

This patch makes simpler, easier to read macros which are actually
correct. Maybe this patch can actually fix some bugs now.

Thanks to Dan for catching this. /me hides

Cc: stable@kernel.org
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The fb helper lost its support for reallocating an fb completely, so
no need to return special success values any more.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While doing the modeset rework for drm/i915 I've noticed that the fb
helper is very liberal with the semantics of the ->set_config
interface:
- It doesn't bother clearing stale modes (e.g. when unplugging a
  screen).
- It unconditionally sets the fb, even if no mode will be set on a
  given crtc.
- The initial setup is a bit fun since we need to pick crtcs to decide
  the desired fb size, but also should set the modeset->fb pointer.
  Explain what's going on in the fixup code after the fb is allocated.

The crtc helper didn't really care, but the new i915 modeset
infrastructure did, so I've had to add a bunch of special-cases to
catch this.

Fix this all up and enforce the interface by converting the checks in
drm/i915/intel_display.c to BUG_ONs.

v2: Fix commit message spell fail spotted by Rob Clark.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that the driver is in control of whether it needs to disable
everything at take-over or not, we can rip this all out.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should be done in the drivers for two reasons:
- it gets in the way of fastboot efforts
- it links the fb helpers with the crtc helpers instead of going
  through the real interface vfuncs, forcing i915 to fake all the
  ->disable callbacks used by the crtc helper to avoid ugly Oopsen

v2: Resolve conflicts since drivers still call
drm_fb_helper_single_add_all_connectors.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

acpi_bus_get_device() returns int not acpi_status.

The patch change not to apply ACPI_FAILURE() to the return value of
acpi_bus_get_device().
Signed-off-by: NYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

From BSpec / SR01 - Clocking Mode:
"The following sequence must be used when disabling the VGA plane.
 Write SR01 to set bit 5 = 1 to disable video output.
 Wait for 100us.
 Disable the VGA plane via Bit 31 of the MMIO VGA control."

So simply call i915_disable_vga() from i915_redisable_vga().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All display registers should now include the proper offset on VLV.
That means IS_DISPLAYREG() is now useless, and we can eliminate it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The VGACNTRL register has moved around between different platforms.
To handle the differences add i915_vgacntrl_reg() which returns the
correct offset for the VGACNTRL register.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NChanglong Xie <changlongx.xie@intel.com>
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can disable (almost) all the display hw if we only use pipe A, with
the integrated edp transcoder on port A. Because we don't set the cpu
transcoder that early (yet), we need to help us with a trick to simply
check for any edp encoders.

v2: Paulo Zanoni pointed out that we also need to configure the eDP
cpu transcoder correctly.

v3: Made by Paulo Zanoni
  - Rebase patch to be on top of "fix intel_init_power_wells" patch
  - Fix typos
  - Fix a small bug by adding a "connectors_active" check
  - Restore the initial code that unconditionally enables the power
    well when taking over from the BIOS

v4: Made by Paulo Zanoni
  - One more typo spotted by Jani Nikula

v5: Made by Paulo Zanoni
  - Rebase
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the power well is disabled, we should not try to read its
registers, otherwise we'll get "unclaimed register" messages.

V2: Don't check whether the power well is enabled or not, just check
whether we asked it to be enabled or not: if we asked to disable the
power well, don't use the registers on it, even if it's still enabled.

V3: Fix bug that breaks all non-Haswell machines.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>