Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since they're all the same register, leave all the #defines at the
same place, organized by Gen and also specify which bits are used by
only a specific port or encoding.

Also remove a few unused duplicates and adjust indentation.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some HDMI registers can be used for SDVO, so saying "HDMIB" should be
the same as saying "SDVOB" for a given HW generation. This was not
true and led to confusions and even a regression.

Previously we had:
  - SDVO{B,C} defined as the Gen3+ registers
  - HDMI{B,C,D} and PCH_SDVOB defined as the PCH registers

But now:
  - SDVO{B,C} became GEN3_SDVO{B,C} on SDVO code
  - SDVO{B,C} became GEN4_HDMI{B,C} on HDMI code
  - HDMI{B,C,D} became PCH_HDMI{B,C,D}
  - PCH_SDVOB is still the same thing

v2: Rebase (v1 was sent in May 2012).
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While old platforms had 3 transcoders and 3 pipes (1:1), HSW has
4 transcoders and 3 pipes.
These regs were being used only by HDMI code where pipe is always the same
thing as cpu_transcoder.
This patch allow us to use them for DP, specially for TRANSCODER_EDP.

v2: Adding HSW_TVIDEO_DIP_VSC_DATA to transmit vsc to eDP.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The indentation is getting way too deep. Pull the vblank interupt
handling out to separate functions.

v2: Keep flip_mask handling in the main irq handler and
    flatten {i8xx,i915}_handle_vblank() even further.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We plan to treat GEN7_ERR_INT as an interrupt, so use this register
for the checks inside I915_WRITE. This way we can have the best of
both worlds: the error message with a register address and the

V2: Split in 2 patches: one for the macro, one for changing the
register, as requested by Ben.
V3: Rebase.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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>

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>

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>

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>

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>

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 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>

The shift changed, hurray.
Reported-by: NKenneth Graunke <kenneth@whitecape.org>
Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Implements WaVSRefCountFullforceMissDisable as documented in the BSpec
3D workarounds chapter.

Cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The current code was wrong in many different ways, so this is a full
rewrite. We don't have "different power wells for different parts of
the GPU", we have a single power well, but we have multiple registers
that can be used to request enabling/disabling the power well. So
let's be a good citizen and only use the register we're suppose to
use, except when we're loading the driver, where we clear the request
made by the BIOS.

If any of the registers is requesting the power well to be enabled, it
will be enabled. If none of the registers is requesting the power well
to be enabled, it will be disabled.

For now we're just forcing the power well to be enabled, but in the
next commits we'll change this.

V2:
  - Remove debug messages that could be misleading due to possible
    race conditions with KVMr, Debug and BIOS.
  - Don't wait on disabling: after a conversaion with a hardware
    engineer we discovered that the "restriction" on bit 31 is just
    for the "enable" case, and we don't even need to wait on the
    "disable" case.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

SR01 needs to be touched to disable VGA on non-UMS setups too.
So the sequencer registers need to include the appripriate offset
on VLV.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Dropped the clock gating registers
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of 0x18xxxx use (VLV_DISPLAY_BASE + xxxx).
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Instead of 0x18xxxx use (VLV_DISPLAY_BASE + xxxx).
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

CURSIZE is not present on VLV, so it was left out, as were the IVB
specific cursor B registers.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is a required workarounds for all products, especially on gen6+
where it causes the command streamer to fail to parse instructions
following a WAIT_FOR_EVENT. We use WAIT_FOR_EVENT for synchronising
between the GPU and the display engines, and so this bit being unset may
cause hangs.

References: https://bugzilla.kernel.org/show_bug.cgi?id=52311Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The RGB color range select bit on the DP/SDVO/HDMI registers
disappeared when PCH was introduced, and instead a new PIPECONF bit
was added that performs the same function.

Add a new INTEL_MODE_LIMITED_COLOR_RANGE private mode flag, and set
it in the encoder mode_fixup if limited color range is requested.
Set the the PIPECONF bit 13 based on the flag.

Experimentation showed that simply toggling the bit while the pipe is
active doesn't work. We need to restart the pipe, which luckily already
happens.

The DP/SDVO/HDMI bit 8 is marked MBZ in the docs, so avoid setting it,
although it doesn't seem to do any harm in practice.

TODO:
- the PIPECONF bit too seems to have disappeared from HSW. Need a
  volunteer to test if it's just a documentation issue or if it's really
  gone. If the bit is gone and no easy replacement is found, then I suppose
  we may need to use the pipe CSC unit to perform the range compression.

v2: Use mode private_flags instead of intel_encoder virtual functions
v3: Moved the intel_dp color_range handling after bpc check to help
    later patches

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46800Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>