drm_i915_private is getting bigger and bigger when adding new vbt stuff.
So, the better way of getting drm_i915_private organized is to create
a special structure for vbt stuff.

v2: Basically conflicts fixes
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to track this correctly. While at it shovel the boolean
to track whether the sdvo is in tv mode or not into pipe_config.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=36997Tested-by: NPierre Assal <pierre.assal@verint.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63609Tested-by: Ncancan,feng <cancan.feng@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

More ugly stuff gone for good! The big special case left now is
lvds (which is indeed really special).
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This seems to be an impressive piece of copy&pasta lore. I've
checked all docs and on most platforms these bits are all MBZ, with
the exception of the SDVO pixel multiplier on gen3. On gen4 that
moved to a special DPLL_MD registers.

No indication whatsoever that we actually need this for native
TV-out support. I suspect this started as a hack when we didn't
yet have proper pixel multiplier support in place for SDVO TV, but
then got stuck in a life of its own.

Just rip it out.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

TV-out uses the same reference clock as everyone else. The only
difference seems to be in the slightly different CB tuning limit.

Note that PLL_REF_INPUT_TVCLKINBC is a reserved value on ilk+. Also
strictly speaking we don't support native TV-out on ilk+, hence all
that code is dead. But Bspec still contains some residual mentions of
native TV-out on some pch-split platforms, so I've figured it doesn't
hurt to keep the code around a bit longer (e.g. in the cb tune
function).

v2: Improve the commit message as Jani suggested in his review.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have a very nice infrastructure for this now!

Note that the multifunction sdvo support is pretty neatly broken: We
completely ignore userspace's request for which connector to wire up
with the encoder and just use whatever the last detect callback has
seen.

Not something I'll fix in this patch, but unfortunately something
which is also broken in the DDI code ...

v2: Don't call sdvo_tv_clock twice.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On ILK-IVB the CPU side eDP is always on port-A.

Also reduce somewhat the debug verbosity.

v2:
- reduce debug verbosity
Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

On HSW the CPU side eDP is always on port-A, the PCH side eDP is always
on port-D.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For the device to enter D3 we should enable PCH clock gating.

v2:
- use HAS_PCH_LPT instead of IS_HASWELL (Ville, Paolo)
- rename lpt_allow_clock_gating to lpt_suspend_hw (Paolo)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We did not mention the workaround name when implementing those. This
should help us track what we already implement.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already have the same check on intel_enable_ddi. This patch
prevents "unclaimed register" messages when the power well is
disabled.

V2: Reset intel_crtc->eld_vld to false after the mode_set function.
V3: Add both "type != INTEL_OUTPUT_EDP" requested.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In the error state function we read the registers without checking if
the power well is on, so after doing this we have to clear the
FPGA_DBG_RM_NOCLAIM bit to prevent the next I915_WRITE from detecting
it and printing an error message.

The first version of this patch was checking for the power well state
and then avoiding reading registers that were off, but the reviewers
requested to just read the registers any way and then later clear the
FPGA_DBG_RM_NOCLAIM bit.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to dump these registers if we want to properly interpret the
others.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This should replace intel_using_power_well. The idea is that we're
adding the requested power domain as an argument, so this might enable
the code to look less platform-specific and also allows us to easily
add new domains in case we need.

v2: Add more domains to enum intel_display_power_domain
v3: Even more domains requested
Requested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Supposedly we should use the DAC divider for <300MHz pixel clocks, but as
that doesn't actually work as well as the high freq divider here in
practice, just use the high freq divider all the time.

v2: remove unconditional write (Jesse)
    check for pixel rate properly (Jesse)
v3: give up, the DAC divider apparently doesn't work, and low res modes
    work ok (Jesse)
    remove debug msg (Jesse)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This regression was introduced in:

commit b074cec8
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Apr 25 12:55:02 2013 -0700

    drm/i915: move PCH pfit controls into pipe_config

In refactoring this, it was only applied to eDP, which is incorrect.  In
fact, if we ever use the panel fitter to deal with overscan on HDMI,
we'll need to extend it again, so just drop the conditional altogether.

v2: drop check for eDP since we can use the fitter in any config (Daniel)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only one caller. Also drop the intel_ prefix as is now customary for
platform specific and static functions.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

- PCH_ prefix for pch registers on ibx/cpt/ppt.
- Drop the DP_ from the link defines, redundant.
- Drop the GMCH from the data defines and instead give the special g4x
  registers a consistent _G4X postfix.

v2:
- Realign #defines and use tabs (Paulo).
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is possible thanks to moving the m/n stuff into pipe_config.

Unfortunately we need to move them a bit to avoid forward
declarations.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While at it, also extract a common helper to copy the timings from the
cpu transcoder to the pch transcoder. That way it's really explicit
how the lpt transcoder is hardcoded.

v2:
- Re-align #defines properly (Paulo).
- Use cpu_transcoder when copying pipe timings (Paulo).
- s/intel_pch_transcoder_enable/intel_pch_transcoder_set_timings/
  since we already have a pch transcoder enable function, and this is
  clearer, too.
- Fixup 80 char line overflow in intel_display.c. I've opted to ignore
  this in i915_reg.h and i915_ums.c since meh.

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

Every time I read hsw code I get completely confused about this. So
call it what it is more explicitly.

Also, add an LPT_TRANSCONF for the pch transcoder A and use it in
lpt-only code, to really unconfuse me.

v2: s/plane/pipe/ in the TRANSCONF #define (Paulo).
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the hw state readout&check code it's important that the values we
keep around are the canonical ones. Unfortunately when adding the pipe
timings readout support I've missed that the write side adjusts the
timings in the pipe config.

Fix this up and so prevent the unsightly WARN noise in dmesg. This
regression has been introduced in

commit 1bd1bd80
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Mon Apr 29 21:56:12 2013 +0200

    drm/i915: hw state readout support for pipe timings
Reported-by: NPaulo Zanoni <przanoni@gmail.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can't read the pfit regs if the power well is off, so use the cached
value.

v2: re-add lost comment (Jesse)
    make sure the crtc using the fitter is actually enabled (Jesse)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Drop now unused dev_priv, as spotted by Mika.]
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Writing hw registers from compute_config?
Just say no!

In this case not too horrible since we write a constant 0, and only
debugging would put something else in there. But while checking that
code I've noticed that this register disappeared on pch platforms, so
fix that up, too.

And adjust the comment a bit, it's outdated.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This does duplicate the logic in intel_crtc_mode_get a bit, but the
issue is that we also should handle interlace modes and other insanity
correctly.

Hence I've opted for a sligthly more elaborate route where we first
read out the crtc timings for the adjusted mode, and then optionally
(not sure if we really need it) compute the modeline from that.

v2: Also read out the pipe source dimensions into the requested mode.

v3: Rebase on top of the moved cpu_transcoder.

v4: Simplify CHECK_FLAGS logic as suggested by Chris Wilson. Also
properly #undef that macro again.

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3)
[danvet: Use the existing mask for interlaced bits, spotted by Mika.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We want to use the fdi m/n values to easily compute the adjusted mode
dotclock on pch ports. Hence make sure the values stored in the pipe
config are always reliable.

v2: Fixup FDI TU readout.

v3: Rebase on top of moved cpu_transcoder.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This code will get _really_ repetive, and we'll end up with tons more
of this kind. So extract the common patterns.

This should also help when we add a lazy pipe_config compare mode for
fastboot.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Spotted while changing related code.
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.

The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.

But ports compute their state under the assumption that the bpp they
pick will be the one selected, e.g. the display port bw computations
won't work otherwise. Now we could adjust our code to again up-dither
to the computed DP link parameters, but that's pointless.

So instead when the pipe needs to adjust parameters we need to retry
the pipe_config computation at the encoder stage. Furthermore we need
to inform encoders that they should not increase bandwidth
requirements if possible. This is required for the hdmi code, which
prefers the pipe to up-dither to either of the two possible hdmi bpc
values.

LVDS has a similar requirement, although that's probably only
theoretical in nature: It's unlikely that we'll ever see an 8bpc
high-res lvds panel (which is required to hit the 2 fdi lane limit).

eDP is the only thing which could increase the pipe_bpp setting again,
even when in the retry-loop. This could hit the WARN. Two reasons for
not bothering:
- On many eDP panels we'll get a black screen if the bpp settings
  don't match vbt. So failing the modeset is the right thing to do.
  But since that also means it's the only way to light up the panel,
  it should work. So we shouldn't be able to hit this WARN.
- There are still opens around the eDP panel handling, and maybe we
  need additional tricks. Before that happens it's imo no use trying
  to be too clever.
Worst case we just need to kill that WARN or maybe fail the compute
config stage if the eDP connector can't get the bpp setting it wants.
And since this can only happen with an fdi link in between and so for
pch eDP panels it's rather unlikely to blow up, if ever.

v2: Rebased on top of a bikeshed from Paulo.

v3: Improve commit message around eDP handling with the stuff
things with Imre.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This allows us to use all 4 fdi lanes on fdi B when the cpu eDP is
running on pipe C. Yay!

v2: Encapsulate test into a little helper function, as suggested by
Chris Wilson.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This nicely allows us to drop some hacks which have only been used
to work around modeset failures due to lack of fdi lanes.

v2: Implement proper checking for Haswell platforms - the fdi link to
the LPT PCH has only 2 lanes. Note that we already filter out
impossible modes in intel_crt_mode_valid. Unfortunately LPT does not
support 6bpc on the fdi rx, so we can't pull clever tricks to squeeze
in a few more modes.

v2: Rebased on top of Ben Widawsky's num_pipes reorg.

v3: Rebase on top of Ville's pipe debug output ocd rampage.

v4: Fixup rebase fail spotted by Ville.

v5: Fixup rebase fail spotted by Imre Deak. I suck.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Again in preparation to move the configuration checks into the
pipe_config computation stage of the modeset sequence.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that it's split up, we can easily move it around and precompute
the fdi lane configuration.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And also move the computed m_n values into the pipe_config. This is a
prep step to move the fdi state computation completely into the
prepare phase of the modeset sequence. Which will allow us to handle
fdi link bw constraints in a better way.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Introduce some nice #defines for the FDI lane width fields and put
them to good use. Suggested by Ville.

v3: Fixup the mask vs. shift copy&pasta fail Imre Deak spotted, and
use the shift #define also in the mask.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need this for two reasons:
- Correct handling of shared fdi lanes on ivb with fastboot.
- Handling fdi link bw limits when we only have two fdi lanes by
  dithering down a bit.

Just search&replace in this patch, no functional change at all.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The current code is rather ... ugly. The only thing it managed to pull
off is getting 6bpc on DP working on g4x. Then someone added another
custom hack for 6bpc eDP on vlv. Fix up this entire mess by properly
implementing the PIPECONF-based dither/bpc controls on g4x/vlv.

Note that compared to pch based platforms g4x/vlv don't support 12bpc
modes. g4x is already caught, extend the check for vlv.

The other fixup is to restrict the lvds-specific dithering to early
gen4 devices - g4x should use the pipeconf dither controls. Note that
on gen2/3 the dither control is in the panel fitter even.

v2: Don't enable dithering when the pipe is in 10 bpc mode. Quoting
from Bspec "PIPEACONF - Pipe A Configuration Register, bit 4":

"Programming note: Dithering should only be enabled for 8 bpc or 6
bpc."

v3: Actually drop the old ugly dither code.

v4: Explain in a short comment why g4x/vlv shouldn't dither for 30 bpp
pipes (Jesse).

v5: Also clear the dither type correctly as spotted by Ville.

v6: As Ville pointed out we need to indeed set the dithering both in
the pipeconf register (for DP outputs) and in the LVDS port register
(for LVDS ouputs). Otherwise LVDS panel will not get properly
dithered. The old patch got away with this since it forgot to clear
the LVDS dither bit ...

v7: Remove redundant BPC_MASK clearing, spotted by Ville.

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

They can get at the adjusted mode through intel_crtc->config.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This hack is getting a bit messy, but this plugs the leak for now
until we have the cpu_transcoder properly pipe_config'ed.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>