[go: nahoru, domu]

History log of /drivers/gpu/drm/i915/intel_ddi.c
Revision Date Author Comments
2789339044fb6dfbee0c8cd77e26438b80e333ee 04-Sep-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Rewrite ABS_DIFF() in a safer manner

The new version of the macro does a few things better:
- protect the arguments,
- only evaluate the arguments once,
- check that the arguments are of the same type,

Change LC_FREQ_2K to be a unsigned 64bit constant and removed the '()'
from the caller as a result.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
1012205182fb9470a1bd1620872103a09f566225 27-Aug-2014 Jani Nikula <jani.nikula@intel.com> drm/i915/ddi: use struct for ddi buf translation tables

Try to avoid confusion with ARRAY_SIZE()/2 and hdmi_level*2.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Resolve silent patch conflict (didn't even fail to build)
with with Sonika's preceding patch to use the
hsw_ddi_translations_fdi table to driver the fdi link training
iteration loop. Also drop the double-write loop Damien spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
c5fe6a0637e8a9f407a87b78be6955067f01a4cd 11-Aug-2014 Sonika Jindal <sonika.jindal@intel.com> drm/i915: Rename defines for selection of ddi buffer translation slot

Renaming the HSW-specific macros for ddi buffer translation slot to denote the
slot and not the vswing/pre-emph values as they are platform-dependent.

This patch is based on top of the patch series for renaming the DP training
vswing/pre-emph defines:
http://lists.freedesktop.org/archives/intel-gfx/2014-August/050407.html

v2: Creating single macro with argument for slot number (Damien)
v3: Adding macro for num of translation entries (Damien)

Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
d6699dd3a7f696a80a5f8e5bb6ecf6ff6dd7c998 09-Aug-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Fix wrong number of HDMI translation entries

I keep telling myself that those tables aren't great because their size
is the number of dwords we need to program and not the number of entries
(number of dwords = number of entries * 2).

And... I got it wrong when I refactored the code. Fortunately, it was
only wrong when the VBT table (or the code parsing it) is itself
erroneous. Long story short, it shouldn't matter, but still, there's a
potential array overflow and random programming of the DDI translation
tables.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ac921bdde92a354e8c59ea185dff26dc2611ee81 01-Aug-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Remove now useless comments about the translation values

We used to carry a default HDMI value in entry 9, but this entry got
removed for both HSW and BDW.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
156ae28c9f327d2c026e91cfacb5e224bb760d66 01-Aug-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915/bdw: Remove the HDMI/DVI entry from the DP/eDP/FDI tables

We always write entries 0 to 8 from the DDI translation tables and then
entry 9 for HDMI/DVI with the help of the VBT. We then don't need the
failsafe HDMI entry in the DP/eDP/FDI tables.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
a26aa8baee6c274fc23efccf46e891e63c8d0a30 01-Aug-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915/bdw: Provide the BDW specific HDMI buffer translation table

Among the changes, the tables has only 10 entries instead of 12 on HSW
and the index the the 800mV/0dB entry has changed.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ce4dd49e97813740bd2b03ecdc51521be10f3bf1 01-Aug-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Gather the HDMI level shifter logic into one place

The knowledge about the HDMI/DVI DDI translation table was scattered
around.
- info->hdmi_level_shift was initialized with 6, the index of the 800
mV, 0dB translation
- A check on the VBT value was done to ensure it wasn't overflowing
the translation table (< 0xC)
- The actual programming was done in intel_ddi.c

As we need to change that knowledge for Broadwell, let's gather
everything into one place.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
3d51278af91f8e96077dad3a4c1cc0b19fa8ca25 29-Jul-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Make ddi_clock_gate() HSW/BDW specific

Turns out we were again way too naive and optimistic, of course things
will change.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ad13d6048f5002f1c5ab21c71a5ee136a2d8e889 29-Jul-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Split the CDCLK retrieval per-platform

This is only going to get worse, so split it now to avoid adding more
cases to the if/else ladder.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
d664c0cece2dd410d8134aa820112e471e3592dd 29-Jul-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Make intel_ddi_calculate_wrpll() HSW/BDW specific

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0220ab6e00785da008bb3736737b877d45858608 29-Jul-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Split the BDW/HSW specific shared pll selection

We'll need a different algorithm to select the shared DPLL.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
bf9584bd0e99bd284e115ea8eba9b02a5a2d7b4d 29-Jul-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Fix stale comment for intel_ddi_pll_select()

Since the run-time PM on DPMS series, this function has an outdated
comment. Refresh it a bit.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
143b307c43dcfeae41a3b6c24a29fae4c70884f4 29-Jul-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Extract the HSW/BDW shared dpll init code

So we can easily provide an alternate implementation in the future.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
f68d697eaf3278200a7fc3c8b1d95d72837b84d8 04-Aug-2014 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: only hook up hpd pulse for DP outputs

On HSW+, the digital encoders are shared between HDMI and DP outputs,
with one encoder masquerading as both. The VBT should tell us if we need
to have DP or HDMI support on a particular port, but if we don't have DP
support and we enable the DP hpd pulse handler then we cause an oops.

Don't hook up the DP hpd handling if we don't have a DP port.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81856
Reported-by: Intel QA Team.
Signed-off-by: Dave Airlie <airlied@redhat.com> # v1
[ickle: Fix the error handling after a malloc failure]
Reviewed-by: Dave Airlie <airlied@redhat.com>
Cc: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
ca1381b55b715ae3435a0d600a345bad90233a9b 15-Jul-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Make the WRPLL names const

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0e32b39ceed665bfa4a77a4bc307b6652b991632 02-May-2014 Dave Airlie <airlied@redhat.com> drm/i915: add DP 1.2 MST support (v0.7)

This adds DP 1.2 MST support on Haswell systems.

Notes:
a) this reworks irq handling for DP MST ports, so that we can
avoid the mode config locking in the current hpd handlers, as
we need to process up/down msgs at a better time.

Changes since v0.1:
use PORT_PCH_HOTPLUG to detect short vs long pulses
add a workqueue to deal with digital events as they can get blocked on the
main workqueue beyong mode_config mutex
fix a bunch of modeset checker warnings
acks irqs in the driver
cleanup the MST encoders

Changes since v0.2:
check irq status again in work handler
move around bring up and tear down to fix DPMS on/off
use path properties.

Changes since v0.3:
updates for mst apis
more state checker fixes
irq handling improvements
fbcon handling support
improved reference counting of link - fixes redocking.

Changes since v0.4:
handle gpu reset hpd reinit without oopsing
check link status on HPD irqs
fix suspend/resume

Changes since v0.5:
use proper functions to get max link/lane counts
fix another checker backtrace - due to connectors disappearing.
set output type in more places fro, unknown->displayport
don't talk to devices if no HPD asserted
check mst on short irqs only
check link status properly
rebase onto prepping irq changes.
drop unsued force_act

Changes since v0.6:
cleanup unused struct entry.

[airlied: fix some sparse warnings].

Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
44905a27dd01f2bddd96664d0ab7da43a07f4d5a 02-May-2014 Dave Airlie <airlied@redhat.com> i915: split some DP modesetting code into a separate function

this is just prep work for mst support.

Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
df8ad70ca34f9bdf7e070d1a430bbdcac6acee12 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Only touch WRPLL hw state in enable/disable hooks

To be able to do this we need to separately keep track of how many
crtcs need a given WRPLL and how many actually actively use it. The
common shared dpll framework already has all this, including massive
state readout and cross checking. Which allows us to do this switch in
a fairly small patch.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
716c2e55100ff5588bd2bbca14951ef11624cba2 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Switch to common shared dpll framework for WRPLLs

Mostly this patch is one big excersize in deleting code and asserts
which are no longer needed. Note that we still abuse the shared dpll
framework a bit since we call the enable/disable functions from the
crtc mode_set and off hooks. But changing the actual hardware sequence
will be done in the next step.

Note that besides the massive amount of changes in this patch the
places and order in which the low-level WRPLL code is called is
absolutely unchanged.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
e0b01be41dcdfd28c6855f605983a61b29f65692 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: ->enable hook for WRPLLs

This time around another cute hack to pre-fill the pll->hw_state with
the right values. And also remove a bunch of checks which will be
replaced by lots more checks in the common framework.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
12030431e9ba407b8c35b3c3bf70b67d609447f3 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: ->disable hook for WRPLLs

Currently still with a redudant WARN_ON in there, the common shared
dpll code will take care of this in the future.

Also we need to flip the switch for the transitional hack now to make
sure that we disable the right pll.

Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
d452c5b67a6e2ae9f94df223919c107a8950910a 04-Jul-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: State readout support for WRPLLs

Still tacked onto the side, but slowly getting there.

v2: Don't forget the debugfs file.

v3 (from Paulo): Don't forget to check the power domains.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
9cd86933fe250fd3e698b62505dfe2d43326baaa 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Basic shared dpll support for WRPLLs

Just filing in names and ids, but not yet officially registering them
so that the hw state cross checker doesn't completely freak out about
them. Still since we do already read out and cross check
config->shared_dpll the basics are now there to flesh out the wrpll
shared dpll implementation.

The idea is now to roll out all the callbacks step-by-step and then at
the end switch to the shared dpll framework. This way hw and sw
changes are clearly separated.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[imre: added const to hsw_ddi_pll_names (Damien)]
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0e50338cf0f0009a5c9bc847a4c86a1d4438af66 04-Jul-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Precompute static ddi_pll_sel values in encoders

This way only the dynamic WRPLL selection for hdmi ddi mode is
done in intel_ddi_pll_select.

v2: Don't clobber the precomputed values when selecting clocks fro
hdmi encoders.
v3 (from Paulo): Rebase on top of the s/IS_HASWELL/HAS_DDI/ patch.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
26804afd4b3c7a1ff577db4d70df8055c7901ff4 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: State readout and cross-checking for ddi_pll_sel

To make things a bit more manageable extract a new function for
reading out common ddi port state. This means a bit of duplication
between encoders and the core since both look at the same registers,
but doesn't seem worth to make a fuzz about.

We can also remove the state readout code in intel_ddi_setup_hw_pll_state.
That code is only called from the hardware take over and not the cross
check code, and only after the crtc state is reconstructed. So we can
rely on an accurate value of crtc->config.ddi_pll_sel already.

Compared to the old code also trust the hw state more and don't
special-case port A - we want to cross-check the actual-state, not
bake in our own assumptions about how this is supposed to all be
linked up.

v2: Make use of the read-out ddi_pll_sel in intel_ddi_clock_get.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
de7cfc635e4ce20ded5ca4e40328386d9ba81922 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Move ddi_pll_sel into the pipe config

Just boring sed job for preparation.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
abfdc1e375aefb3945cdd9b408059b35f4f4f4ec 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Move SPLL disabling into hsw_crt_post_disable

Similar to how the ->crtc_mode_set hook should touch the hardware to
enable anything the ->crtc_off hook should disable anything in the
hardware. Otherwise runtime pm for dpms will not work.

Currently the only things left int the haswell_crtc_off hook is
disabling the ddi plls. We can't move the WRPLL enabling out yet
because the current ddi pll sharing code used by the haswell code
doesn't separately track active users and overall users. This must be
fixed by porting it to the generic shared display pll framework, which
is powerful enough.

But the SPLL source is only used by the crt encoder and so can be
moved already. We only need to make sure that the ddi port E is
already off, which hsw_fdi_disable does by calling
intel_ddi_post_disable.

With this the code reorg to shuffle hsw fdi/lpt specific code into a
new hsw-specific crt encoder type is now finally complete.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
082717ead9f5836fac1b2757aad38f652cc63636 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Move the SPLL enabling into hsw_crt_pre_enable

The call to intel_ddi_pll_enable in haswell_crtc_mode_set is the only
function that still touches the hardware state from the crtc mode_set
callback on hsw. Since the SPLL isn't ever shared we can easily take
it out into the hsw crt encoder functions.

Temporarily we'll loose a bit of WARN_ON coverage with this, but once
the WRPLLs are switched over that will be restored. For the SPLL
selection add a WARN in the hsw fdi link training code.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[imre: rebased on patchset version w/o pch/crt/fdi refactoring]
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
114fe4885721d985907fbfb0d1a0c1c6676b4543 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Clean up WRPLL/SPLL #defines

Luckily the bit definitions match, but it's still confusing
to use one when handling the other. So sprinkle some OCD over
the #defines to make them match and use the right version in
each place.

Maybe we should unify these definitions completely, but that
can always be done sometime in the future.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
7ca1ac135bc4d566e460230133ff959bb1bfcf88 25-Jun-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Remove spll_refcount for hsw

SPLL would be a reference clock we could potentially share,
especially if we want to use the SSC mode. But currently we
don't, so let's rip out this complexity for a simpler conversion
to the new display pll framework.

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fabf6e513f640dac89645e1a98376eb8064394ee 29-May-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Support pf CRC source on haswell transcoder edp

The always-on power well pixel path on haswell is routed such that it
bypasses the panel fitter when we use is. Which means the pfit CRC
source won't work in that configuration.

Add a new disallow-bypass flags to the pfit pipe config state and set
it when we want to use the pf CRC. Results in a bit of flicker, but
should get the job done. We'll also undo do it afterwards to make sure
other tests arent' negatively affected.

Totally untested due to lack of hsw laptops around here.

v2: s/disallow_bypass/force_power_well_on/ to avoid a double negative
(Damien).

v3: force_thru because roadsigns.

v4: Don't forget the power wells! Also note that until the runtime pm
for DPMS series is fully merged the simple disable/enable trick won't
work since the ->crtc_mode_set callback is still required to do nasty
things. This stuff is tricky, but I think by both fixing up
get_crtc_power_domains and the debugfs wa code we should always
grab/drop the additional power well correctly.

v5: Wrap in () as suggested by Damien to avoid setting reserved values
for the edp transcoder path on bdw+

References: https://bugs.freedesktop.org/show_bug.cgi?id=72864
Cc: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Tested-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
13cf550448b58abf8f44f5d6a560f2d20871c965 18-Jun-2014 Dave Airlie <airlied@redhat.com> drm/i915: rework digital port IRQ handling (v2)

The digital ports from Ironlake and up have the ability to distinguish
between long and short HPD pulses. Displayport 1.1 only uses the short
form to request link retraining usually, so we haven't really needed
support for it until now.

However with DP 1.2 MST we need to handle the short irqs on their
own outside the modesetting locking the long hpd's involve. This
patch adds the framework to distinguish between short/long to the
current code base, to lay the basis for future DP 1.2 MST work.

This should mean we get better bisectability in case of regression
due to the new irq handling.

v2: add GM45 support (untested, due to lack of hw)

Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
[danvet: Fix conflicts in i915_irq.c with Oscar Mateo's irq handling
race fixes and a trivial one in intel_drv.h with the psr code.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
9576c27f5287f873505583350049100896a48299 13-Jun-2014 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: update BDW DDI buffer translations

Two BSpec updates changed the recommended values for BDW eDP and DP
DDI buffer translations. Now the signal levels also match the HSW signal
levels, which simplify things a little bit.

It seems some DP sinks don't work properly without voltage level 0 and
pre-emphasis level 3, so this patch may fix some bugs on
panels/monitors that happen on BDW but not on HSW.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
d45a0bf549cda7ab77f3ffce6db1b27b7b435316 21-May-2014 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: grab the audio power domain when enabling audio on HSW+

With the current code, we unconditionally touch
HSW_AUD_PIN_ELD_CP_VLD, which means we can touch it when the power
well is off, and that will trigger an "Unclaimed register" message.

Just adding the intel_crtc->config.has_audio should already avoid the
unclaimed register messsages, but since we actually need the power
well to make the Audio code work, it makes sense to also grab the
audio power domain reference, and release it when it's not needed
anymore.

I used IGT's pm_rpm to reproduce this bug, but it can probably be
reproduced on other tests that do modesets. I'm using a machine with
eDP+HDMI connected.

Regression introduced by:

commit acfa75b02e72bad7c93564ac379712e29c001432
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Apr 24 23:54:51 2014 +0200
drm/i915: Simplify audio handling on DDI ports

Credits to Daniel for suggesting this implementation.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
a60551b1c9478dc2aaef9e87d6dc7e54e76714b5 21-May-2014 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: don't read HSW_AUD_PIN_ELD_CP_VLD when the power well is off

Because this will trigger "Unclaimed register" messages. All I need to
reproduce this problem is to boot my HSW machine with eDP+HDMI
connected.

Regression introduced by:

commit 9ed109a7b445e3f073d8ea72f888ec80c0532465
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Apr 24 23:54:52 2014 +0200
drm/i915: Track has_audio in the pipe config

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
30cf6db8b242e6bc7a660403471d2d78445f4860 24-Apr-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915/ddi: Remove ->mode_set callback

A bit more care required here since there are some very few things
between the call to encoder->mode_set and encoder->pre_enable. But
they're either book-keeping or only matter for the vga port on the
pch. So of no concern.

Note that with the new sequence we write the infoframes after
selecting the clock source, but that shouldn't matter. I've simply
opted for this to have simpler code.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
9ed109a7b445e3f073d8ea72f888ec80c0532465 24-Apr-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Track has_audio in the pipe config

Including state readout and cross-checking. This allows us to get rid
of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy
if the BIOS hasn't set up the audio routing like we want it too.

Wrt fastboot and external screens I see a few options:
- Don't.
- Try to fix up eld, infoframes and audio settings after the fact. But
that means some pretty extensive reworking of our code which
currently does all this while the pipe/port is still off.

I won't bother with converting SDVO over to this because the audio
support for SDVO is very lacking:
- We don't update the eld.
- We don't update the audio state on the sdvo encoder.
- We don't check whether the platform can even feed audio to the sdvo
encoder.

I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi
and dp converted and so doing it step-by-step would have required a
few intermediate hacks.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
acfa75b02e72bad7c93564ac379712e29c001432 24-Apr-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Simplify audio handling on DDI ports

There's no need to check whether audio is enabled (which for ddi ports
is done through the crtc->eld_vld flag) since at the cost of a
potentially unecessary register rmw cycle we can unconditionally do
this.

Note that the edp check is just paranoia since we won't ever call the
write_eld function for an edp panel.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
6897b4b5d3336a0a02d94225de971985c7ad42fe 24-Apr-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Track hdmi mode in the pipe config

Also add state readout and cross-check support. The only invasive change
is wiring up the new flag to the ->set_infoframes callbacks.

Reviewed-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
882244a3404088113f1add19d2d029f83e69efeb 01-Apr-2014 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: fix WARNs when reading DDI state while suspended

If runtime PM is enabled and we unset all modes, we will runtime
suspend after __intel_set_mode() , then function
intel_modeset_check_state() will try to read the HW state while it is
suspended and trigger lots of WARNs because it shouldn't be reading
registers.

So on this patch we make intel_ddi_connector_get_hw_state() return
false in case the power domain is disabled, and we also make
intel_display_power_enabled() return false in case the device is
suspended. Notice that we can't just use
intel_display_power_enabled_sw() because while the driver is being
initialized the power domain refcounts are not reflecting the real
state of the hardware.

Just for reference, I have previously published an alternate patch for
this problem, called "drm/i915: get runtime PM at intel_set_mode".

Testcase: igt/pm_pc8
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
825938307f812c7cbfe064c7884bd8bdb27c2144 17-Mar-2014 Jani Nikula <jani.nikula@intel.com> Revert "drm/i915: don't touch the VDD when disabling the panel"

This reverts
commit dff392dbd258381a6c3164f38420593f2d291e3b
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Dec 6 17:32:41 2013 -0200

drm/i915: don't touch the VDD when disabling the panel

which didn't take into account

commit 6cb49835da0426f69a2931bc2a0a8156344b0e41
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun May 20 17:14:50 2012 +0200

drm/i915: enable vdd when switching off the eDP panel

and

commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Aug 12 22:17:14 2012 +0200

drm/i915: reorder edp disabling to fix ivb MacBook Air

Unsurprisingly, various MacBooks failed.

Effectively the same has already been done in drm-intel-next-queued.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628
Tested-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
24f3e092b8e2939365e2105c2eed3e3db2813aa6 17-Mar-2014 Jani Nikula <jani.nikula@intel.com> drm/i915: finish off reverting eDP VDD changes

This is a small follow-up fix to the series of eDP VDD back and forth
we've had recently. This is effectively a combined revert of three
commits:

commit 2c2894f698fffd8ff53e1e1d3834f9e1035b1f39
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Mar 7 20:05:20 2014 -0300

drm/i915: properly disable the VDD when disabling the panel

commit b3064154dfd37deb386b1e459c54e1ca2460b3d5
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date: Tue Mar 4 00:42:44 2014 +0100

drm/i915: Don't just say it, actually force edp vdd

commit dff392dbd258381a6c3164f38420593f2d291e3b
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Dec 6 17:32:41 2013 -0200

drm/i915: don't touch the VDD when disabling the panel

which shows that we're pretty close back to where we started
already. The first two were basically reverting the last, but missing
the WARN. Add that back. We also OCD the intel_ prefix back to
intel_edp_panel_vdd_on() which was lost somewhere in between. The circle
closes.

For future reference, "drm/i915: don't touch the VDD when disabling the
panel" failed to take into account

commit 6cb49835da0426f69a2931bc2a0a8156344b0e41
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun May 20 17:14:50 2012 +0200

drm/i915: enable vdd when switching off the eDP panel

and

commit 35a38556d900b9cb5dfa2529c93944b847f8a8a4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Aug 12 22:17:14 2012 +0200

drm/i915: reorder edp disabling to fix ivb MacBook Air

Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
849e39f5d7e52eb44d37bbd5ce695f7cdcbe923c 08-Mar-2014 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: properly disable the VDD when disabling the panel

Commit b3064154dfd37deb386b1e459c54e1ca2460b3d5 tried to revert commit
dff392dbd258381a6c3164f38420593f2d291e3b, but wasn't complete, which
resulted in regressions on Haswell. So this commit should fix
b3064154dfd37deb386b1e459c54e1ca2460b3d5 by undoing what it did and
providing an actual complete revert of
dff392dbd258381a6c3164f38420593f2d291e3b.

Fixes regression introduced by:
commit b3064154dfd37deb386b1e459c54e1ca2460b3d5
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date: Tue Mar 4 00:42:44 2014 +0100
drm/i915: Don't just say it, actually force edp vdd

Testcase: igt/pm_pc8
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
bc079e8b1684e1de505ec06f8c2339ae60a329e8 03-Mar-2014 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Make encoder cloning more flexible

Currently we allow encoders to indicate whether they can be part of a
cloned set with just one flag. That's not flexible enough to describe
the actual hardware capabilities. Instead make it a bitmask of encoder
types with which the current encoder can be cloned.

For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should
match what the old boolean flag allowed. We will add some more cloning
options in the future.

Note that this patch also removes the encoder.possible_clones setting
from encoder setup code - we compute this dynamically.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add Ville's explanation why removing the encoder
possible_clones is save.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
6d129beac7099bddad368b6a02e8e0a67f59e9b8 05-Mar-2014 Imre Deak <imre.deak@intel.com> drm/i915: check port power domain when reading the encoder hw state

Since the encoder is tied to its port, we need to make sure the power
domain for that port is on before reading out the encoder HW state.

Note that this also covers also all connector get_hw_state handlers,
since all those just call the corresponding encoder get_hw_state
handler, which checks - after this change - for all power domains
the connector needs.

v2:
- no change
v3:
- push down the power domain checks into the specific encoder
get_hw_state handlers (Daniel)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
e3589908592cae966fa00dd9ef48a208705d3365 07-Feb-2014 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Consolidate FUSE_STRAP in one set of defines

We had 2 set of defines for the same register, so make it one.

Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
20f0ec16ca5c51accdb9a7631411b39aa6b4256e 22-Jan-2014 Jesse Barnes <jbarnes@virtuousgeek.org> drm/i915: fix WRPLL clock calculation

Forgot to convert to using the refclk variable when I added refclk
readout support, and Paulo noticed the resulting calculation was off due
to the way p & r are stored.

Reported-by: Paulo Zanoni <przanoni@gmail.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
11578553d354f3408e5eff5ca87c44a0296a5e80 21-Jan-2014 Jesse Barnes <jbarnes@virtuousgeek.org> drm/i915: clock readout support for DDI v3

Read out and calculate the port and pixel clocks on DDI configs as well.
This means we have to grab the DP divider values and look at the port
mapping to figure out which clock select reg to read out.

v2: do the work from ddi_get_config (Ville)
v3: check WRPLL reference clock (Ville)
add additional SPLL freqs (Ville)
clean up port/crtc clock calc (Ville)
fix up crtc_clock conditionals (Ville)
drop superfluous dp_get_m_n from get_config (Ville)

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
4be7378004a0bfb75adfacd0a943547e18bfa688 17-Jan-2014 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: drop ironlake_ prefix from edp panel/backlight functions

They now also work on vlv, which has the regs somewhere else. And
daring a glance into the looking glass it seems like this
functionality will continue to work the same for the next few hardware
platforms.

So it's better to just remove that misleading prefix and have a bit
shorter code for better readability.

The only exceptions are the panel/backlight functions shared with
intel_ddi.c, those get an intel_ prefix.

While at it make the vdd_on/off functions static.

And one straggler was missing the edp_ in the name, so make everything
neatly OCD.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0882dae983707455e97479e5e904e37673517ebc 08-Jan-2014 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: fix DDI PLLs HW state readout code

Properly zero the refcounts and crtc->ddi_pll_set so the previous HW
state doesn't affect the result of reading the current HW state.

This fixes WARNs about WRPLL refcount if we have an HDMI monitor on
HSW and then suspend/resume.

Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64379
Tested-by: Qingshuai Tian <qingshuai.tian@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
566b734a190766f25f21c8c44633c14a122e61fa 25-Nov-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: split intel_ddi_pll_mode_set in 2 pieces

The first piece, intel_ddi_pll_select, finds a PLL and assigns it to
the CRTC, but doesn't write any register. It can also fail in case it
doesn't find a PLL.

The second piece, intel_ddi_pll_enable, uses the information stored by
intel_ddi_pll_select to actually enable the PLL by writing to its
register. This function can't fail. We also have some refcount sanity
checks here.

The idea is that one day we'll remove all the functions that touch
registers from haswell_crtc_mode_set to haswell_crtc_enable, so we'll
call intel_ddi_pll_select at haswell_crtc_mode_set and then call
intel_ddi_pll_enable at haswell_crtc_enable. Since I'm already
touching this code, let's take care of this particular split today.

v2: - Clock on the debug message is in KHz
- Add missing POSTING_READ

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
[danvet: Bikeshed comments.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
dff392dbd258381a6c3164f38420593f2d291e3b 06-Dec-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: don't touch the VDD when disabling the panel

I don't see a reason to touch VDD when we're disabling the panel:
since the panel is enabled, we don't need VDD. This saves a few sleep
calls from the vdd_on and vdd_off functions at every modeset.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69693
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Fix the patch mangle wiggle has done ... Spotted by Paulo.
Also drop the runtime_pm_put call which now has to go due to different
patch ordering. Also from Paul.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
9b33600d52fab54df1aa82ea0d70c113060c293a 06-Dec-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: don't enable VDD just to enable the panel

We just don't need this. This saves 250ms from every modeset on my
machine.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
e1b22732485396dda9b8eab90cdd1c636efc0a3e 03-Dec-2013 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Fix copy/paste DP vs eDP error in comment

It's all about tiny details.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
5d8a77529bd6864361005117c3a611b6d810aa77 01-Nov-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Check VBT for eDP ports on VLV

VLV can have eDP on either port B or C, or even both. Based on the
VBT spec, intel_dpd_is_edp() should work on VLV too, assuming we
check the correct ports.

So instead of hardcoding port D, rename the function to
intel_dp_is_edp() and pass the port as a parameter, and use it
on VLV ports B and C.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71051
Tested-by: Robert Hooker <robert.hooker@canonical.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Wrestle the patch to apply and compile properly.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
76bb80ed3027fc51af24a378a5986672dc01398f 15-Nov-2013 Jani Nikula <jani.nikula@intel.com> drm/i915/ddi: set sink to power down mode on dp disable

Similar to
commit fdbc3b1f639bb2cbfb32c612b2699e0ba373317d
Author: Jani Nikula <jani.nikula@intel.com>
Date: Tue Nov 12 17:10:13 2013 +0200

drm/i915/dp: set sink to power down mode on dp disable

but for DDI, where we've never done this.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
1021442098ee9328fdd4d113d63a3a7f2f40c37b 18-Nov-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: Replicate BIOS eDP bpp clamping hack for hsw

Haswell's DDI encoders have their own ->get_config callback and in

commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
Author: Jani Nikula <jani.nikula@intel.com>
Date: Mon Oct 21 10:52:07 2013 +0300

drm/i915/dp: workaround BIOS eDP bpp clamping issue

we've forgotten to replicate this hack. So let's do it that.

Note for backporters: The above commit and all it's depencies need to
be backported first.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049
Cc: stable@vger.kernel.org
Tested-by: Gökçen Eraslan <gokcen.eraslan@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0694001b27efe5878ba5bd273e39b384821d865e 30-Oct-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: reuse WRPLL when possible

It seems we do have machines with 3 HDMI/DVI outputs, so sharing
WRPLLs is the only way to get 3 pipes working.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68485
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
77d8d00944dd5a0a2f4f67809819df927ee23030 03-Nov-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915/bdw: check DPD on port D when setting the DDI buffers

Use the eDP values on platforms where port D is eDP. This doesn't
affect Haswell since it uses the same DDI buffer values for eDP and
DP.

Reviewed-by: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
300644c7dc4699fe9afb61b280aa5ed7109a4d93 03-Nov-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915/bdw: add BDW DDI buf translations for eDP

Broadwell has different DDI buffer translations for eDP and DP, so add
support for the missing eDP and keep Haswell the same.

A future patch addresses the suggestion from Art to check for eDP on
port D and use the eDP values there, too.

v2: Make checkpatch happy.

Reviewed-by: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
e58623cb65dfa40f0ed9f6f9ddbca91aee3c9bd2 03-Nov-2013 Art Runyan <arthur.j.runyan@intel.com> drm/i915/bdw: Add BDW DDI buffer translation values

Many of the DDI buffer translation values have changed for BDW.
Add new translation tables and selection between HSW and BDW.

v2: s/BUG/WARN/ to avoid breaking future GENs.

v3: Rebase on top of the hdmi translation table changes.

v4: Fix up the multiline comment while at it.

Signed-off-by: Art Runyan <arthur.j.runyan@intel.com> (v2)
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
e39bf98a91abd5c8fb290f139521dddc3db3c37d 03-Nov-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915/bdw: get the correct LCPLL frequency on Broadwell

v2: Rebased onto Paulo's MHz->kHz change.

v3: Rebased on top of the Haswell pc8+ adjustements.

v4: Use the exact 337.5MHz clock, should have been done as part of v2.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
c7670b1098b1a05c5266a7d3d2f07165621e7de9 03-Nov-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915/bdw: on Broadwell, the panel fitter is on the pipe

So you can use the panel fitter while the power well is disabled and
you also don't need to set the "pipe" bit.

v2: Rebased on top of Jesse's pfit refactor, which moved pfit state
into the pipe_config.

v3: Rebase on top of the latest Haswell/panel fitter rework, which
neatly resolves a FIXME we have in this patch here:

v4: Rebase on top of the new power domain framework.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
7195a50b5c7e00cc3312934fd022c3006b533d12 24-Sep-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Add HSW CRT output readout support

Call intel_ddi_get_config() to get the pipe_bpp settings from
DDI.

The sync polarity settings from DDI are irrelevant for CRT
output, so override them with data from the ADPA register.

Note: This is already merged in drm-intel-next-queued as

commit 6801c18c0a43386bb44712cbc028a7e05adb9f0d
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Tue Sep 24 14:24:05 2013 +0300

drm/i915: Add HSW CRT output readout support

but is required for the following edp bpp bugfix.

v2: Extract intel_crt_get_flags()

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691
Tested-by: Qingshuai Tian <qingshuai.tian@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
4f56d12ebb28fceac4c6e60c8993fbfc122e1399 21-Oct-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Add support for pipe_bpp readout

On CTG+ read out the pipe bpp setting from hardware and fill it into
pipe config. Also check it appropriately.

v2: Don't do the pipe_bpp extraction inside the PCH only code block on
ILK+.
Avoid the PIPECONF read as we already have read it for the
PIPECONF_EANBLE check.

Note: This is already in drm-intel-next-queued as
commit 42571aefafb1d330ef84eb29418832f72e7dfb4c
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Sep 6 23:29:00 2013 +0300

drm/i915: Add support for pipe_bpp readout

but is needed for the following bugfix.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
4a28ae58c0abad2d45a45db21e86c7166b2b4462 09-Oct-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: don't leak dp_connector at intel_ddi_init

Regression introduced by:
commit 311a20949f047a70935d6591010f42336f5402e7
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
drm/i915: don't init DP or HDMI when not supported by DDI port

Since the commit above it is possible to have a DDI encoder that has
the HDMI connector but not the DP connector (in case the port doesn't
support DP). In this case, we must properly free the DP connector.

We just leak this once, so it's not a big deal.

Reported by kmemleak.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
6aba5b6cf098ba305fc31b23cc14114a16768d22 04-Oct-2013 Jani Nikula <jani.nikula@intel.com> drm/i915/dp: get rid of intel_dp->link_configuration

It's not really needed, rather just adds another place to hold
intermediate values that could go wrong, and it's not clear that the
training pattern set or training lane set should be written at this
point at all.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
6801c18c0a43386bb44712cbc028a7e05adb9f0d 24-Sep-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Add HSW CRT output readout support

Call intel_ddi_get_config() to get the pipe_bpp settings from
DDI.

The sync polarity settings from DDI are irrelevant for CRT
output, so override them with data from the ADPA register.

v2: Extract intel_crt_get_flags()

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691
Tested-by: Qingshuai Tian <qingshuai.tian@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
311a20949f047a70935d6591010f42336f5402e7 12-Sep-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: don't init DP or HDMI when not supported by DDI port

There's no reason to init a DP connector if the encoder just supports
HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
AUX transactions to detect if there's something there. Same goes for a
DP connector that doesn't support HDMI, but I'm not sure these
actually exist.

v2: - Use bit fields
- Remove useless identation level
- Replace DRM_ERROR with DRM_DEBUG_KMS

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
6acab15a7b0d2722924c5d671cb29974791beece 12-Sep-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: use the HDMI DDI buffer translations from VBT

We currently use the recommended values from BSpec, but the VBT
specifies the correct value to use for the hardware we have, so use
it. We also fall back to the recommended value in case we can't find
the VBT.

In addition, this code also provides some infrastructure to parse more
information about the DDI ports. There's a lot more information we
could extract and use in the future.

v2: - Move some code to init_vbt_defaults.
v3: - Rebase
- Clarify the "DVO Port" matching code
v4: - Use I915_MAX_PORTS
- Change the HAS_DDI checks
- Replace DRM_ERROR with DRM_DEBUG_KMS

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
b14c5679dd2c87b5bd14c49c5bdd1962be2ab209 19-Sep-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) pattern

Done while reviewing all our allocations for fubar. Also a few errant
cases of lacking () for the sizeof operator - just a bit of OCD.

I've left out all the conversions that also should use kcalloc from
this patch (it's only 2).

Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
eb14cb747bc53465cbc93e54d9f19f49eed2c0c7 10-Sep-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Add state readout and checking for has_dp_encoder and dp_m_n

Add functions to read out the CPU and PCH transcoder M/N values,
and use them to fill out the pipe config dp_m_n information. And
while at it populate has_dp_encoder too.

Also refactor ironlake_get_fdi_m_n_config() to simply call the new
intel_cpu_transcoder_get_m_n() function.

v2: Remember the DDI

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
42571aefafb1d330ef84eb29418832f72e7dfb4c 06-Sep-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Add support for pipe_bpp readout

On CTG+ read out the pipe bpp setting from hardware and fill it into
pipe config. Also check it appropriately.

v2: Don't do the pipe_bpp extraction inside the PCH only code block on
ILK+.
Avoid the PIPECONF read as we already have read it for the
PIPECONF_EANBLE check.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
a666283e9061c58fc888ddf1d9fc552123f1f014 10-Sep-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Fix HSW sync flags to use pipe config adjusted_mode

intel_ddi_enable_transcoder_func() picked the sync flags from crtc->mode
instead of the pipe config adjusted_mode. Fix the problem and hopefully
rid my HSW machine of the remaining pipe config warnings.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fd4daa9cea025ddf8623db289e79d264e9fa66f6 27-Aug-2013 Chris Wilson <chris@chris-wilson.co.uk> drm/i915: Track pfit enable state separately from size

Detangle the additional state of whether or not the hw has the pfit
enabled from whether it has zero size. This allows us to cleanly
distinguish in the code when we expect the pfit to be enabled (for
Haswell pc8), and when the BIOS is confused and needs sanitizing.

Reported-by: shui yanwei <yangweix.shui@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68251
Tested-by: shui yanwei <yangweix.shui@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
20f4dbe45950e462aa7c3243f95c0d8bcc369ca0 30-Aug-2013 Jani Nikula <jani.nikula@intel.com> drm/i915: expose intel_ddi_get_encoder_port()

In preparation for followup work.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
a40066412cc2ace1c1299e7a4d7a81dc33395b6f 06-Aug-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add the FCLK case to intel_ddi_get_cdclk_freq

We already have code to disable LCPLL and switch to FCLK, so we need this too.
We still don't call the code to disable LCPLL, but we'll call it when we add
support for Package C8+.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ad8d270c21aa2f57f0cd578b1737f65c44c34b80 05-Aug-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: remove use_fdi_mode argument from intel_prepare_ddi_buffers

We set the mode based on the port, and we already pass the port as an
argument.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
f72d19f069f8efaa535aacc719d23d469b0d9f18 05-Aug-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: silence useless messages about DDI buffer translation

These messages are not really useful since it's very easy to check
which mode is used for each port: The values programmed are based on
the port type, then assigned to the ddi_translations variable.
Currently we use DP mode for ports A-D and FDI mode for port E.

Also, when we add the code to enable/disable PC8+,
intel_prepare_ddi_buffers will be called more often and will eat your
dmesg buffers.

While at it, fix the coding style of the "for" statement above.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Pimp commit message with Paulo's more detailed explanation of
how the ddi translation buffer settings are computed, to answer a
question from Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
c7d8be305aa28dd809dedd401adcd4da8e4f9144 21-Jul-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915/ddi: use the native encoder ->mode_set callback

Same conversion as for hdmi/dp.

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
4906557eb37b7fef84fad4304acef6dedf919880 11-Jul-2013 Rodrigo Vivi <rodrigo.vivi@gmail.com> drm/i915: Hook PSR functionality

PSR must be enabled after transcoder and port are running.
And it is only available for HSW.

v2: move enable/disable to intel_ddi
v3: The spec suggests PSR should be disabled even before backlight (by pzanoni)
v4: also disabling and enabling whenever panel is disabled/enabled.
v5: make it last patch to avoid breaking whenever bisecting. So calling for
update and force exit came to this patch along with enable/disable calls.
v6: Remove unused and unecessary psr_enable/disable calls, as notice by Paulo.

CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Drop the psr exit code in the busy ioctl since I didn't merge
that part of the infrastructure yet - it needs more thought.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
bcf53de4e60d9000b82f541d654529e2902a4c2c 12-Jul-2013 Stéphane Marchesin <marcheu@chromium.org> drm/i915: Preserve the DDI_A_4_LANES bit from the bios

Otherwise the DDI_A_4_LANES bit gets lost and we can't use > 2 lanes
on eDP. This fixes eDP on hsw with > 2 lanes.

Also s/port_reversal/saved_port_bits/ since the current name is
confusing.

Signed-off-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
15b1d171d87e86366266255462e6b11d21b61c1c 12-Jun-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: fix the "ghost eDP" encoder unwind path

Because calling intel_dp_encoder_destroy inside
intel_edp_init_connector is just wrong. This is the initialization
path, so we should properly unwind all the initialization through the
whole caller stack.

On the intel_dp_encoder_destroy function we do the following:
1 - Call i2c_del_adapter
2 - Call drm_encoder_cleanup
3 - If edp:
3.1 - Cancel panel_vdd_work
3.2 - Call ironlake_panel_vdd_of_sync
4 - Free the encoder

And here is how we unwind each specific step:
1 - We have intel_dp_init_connector -> intel_dp_i2c_init ->
i2c_dp_aux_add_bus -> i2c_add_adapter, so we call
i2c_del_dapter at intel_dp_init_connector
2 - Call it in the same function that called drm_encoder_init
3 - Call it in the same function that called INIT_DELAYED_WORK
4 - Free it in the same function that allocated it

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
b2f246a8998ccf9e00477c8829a62139804e9857 12-Jun-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: fix the "ghost eDP" connector unwind path

Because calling intel_dp_destroy inside intel_edp_init_connector is
just wrong. This is the initialization path, so we should properly
unwind all the initialization through the whole caller stack.

On the intel_dp_destroy function we do the following:
1 - Free edid if it exists
2 - Call intel_panel_fini in case it's eDP
3 - Call drm_sysfs_connector_remove
4 - Call drm_connector_cleanup
5 - Free the connector

And here is how we unwind each specific step:
1 - No need as we still didn't assign anything
2 - No need as we still didn't call intel_panel_init
3 - Call it in the same function that called drm_sysfs_connector_add
4 - Call it in the same function that called drm_connector_init
5 - Free it in the same function that allocated it

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
16c255335b0ec39b4e5e976f4b260978aeed5a68 12-Jun-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: propagate errors from intel_dp_init_connector

In case we detect a "ghost eDP", intel_edp_init_connector frees both
the connector and encoder and then returns. On Haswell, intel_ddi_init
then tries to use the freed encoder on the HDMI initialization path
since the following commit:

commit 21a8e6a4853b2ed39fa4c5188a710f2cf1b92026
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Apr 10 23:28:35 2013 +0200
drm/i915: don't setup hdmi for port D edp in ddi_init

So now on intel_ddi_init we check for the "ghost eDP" case and return
without trying to initialize HDMI. This way we won't try to read the
freed "intel_encoder" struct in the next "if" statement.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Zoltan Nyul <zoltan.nyul@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ef1b460d1bab7e5b04c34f88c3dfa042528e7c27 01-Jun-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: set default value for config->pixel_multiplier

This way we can simplify the code quite a bit.

Also add a WARN in the sdvo code to complain about a bogus value
and kill the readout code in intel_ddi.c that Jesse sneaked in.
HW state readout for the pixel multiplier will work a bit differently
in the end.

v2: Rebase on top of the fdi pixel mutliplier handling fix.

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ff9a6750aca3553c78385a9aa89b678b2b9be7df 01-Jun-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: store adjusted dotclock in adjusted_mode->clock

... not the port clock. This allows us to kill the funny semantics
around pixel_target_clock.

Since the dpll code still needs the real port clock, add a new
port_clock field to the pipe configuration. Handling the default case
for that one is a bit tricky, since encoders might not consistently
overwrite it when retrying the crtc/encoder bw arbitrage step in the
compute config stage. Hence we need to always clear port_clock and
update it again if the encoder hasn't put in something more specific.
This can't be done in one step since the encoder might want to adjust
the mode first.

I was a bit on the fence whether I should subsume the pixel multiplier
handling into the port_clock, too. But then I decided against this
since it's on an abstract level still the dotclock of the adjusted
mode, and only our hw makes it a bit special due to the separate pixel
mulitplier setting (which requires that the dpll runs at the
non-multiplied dotclock).

So after this patch the adjusted_mode accurately describes the mode we
feed into the port, after the panel fitter and pixel multiplier (or
line doubling, if we ever bother with that) have done their job.
Since the fdi link is between the pfit and the pixel multiplier steps
we need to be careful with calculating the fdi link config.

v2: Fix up ilk cpu pll handling.

v3: Introduce an fdi_dotclock variable in ironlake_fdi_compute_config
to make it clearer that we transmit the adjusted_mode without the
pixel multiplier taken into account. The old code multiplied the the
available link bw with the pixel multiplier, which results in the same
fdi configuration, but is much more confusing.

v4: Rebase on top of Imre's is_cpu_edp removal.

v5: Rebase on top of Paulo's haswell watermark fixes, which introduce
a new place which looked at the pixel_clock and so needed conversion.

v6: Split out prep patches as requested by Paulo Zanoni. Also rebase
on top of the fdi dotclock handling fix in the fdi lanes/bw
computation code.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v3)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v6)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
eccb140bca6727f2ef849e8811d5fe4c9fbfd5dd 22-May-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: hw state readout&check support for cpu_transcoder

This allows us to drop a bunch of ugly hacks and finally implement
what

commit cc464b2a17c59adedbdc02cc54341d630354edc3
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Jan 25 16:59:16 2013 -0200

drm/i915: set TRANSCODER_EDP even earlier

tried to achieve, but that was reverted again in

commit bba2181c49f1dddf8b592804a1b53cc1a3cf408a
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Mar 22 10:53:40 2013 +0100

Revert "drm/i915: set TRANSCODER_EDP even earlier"

Now we should always have a consistent cpu_transcoder in the
pipe_config.

v2: Fix up the code as spotted by Paulo:
- read the register for real
- assign the right pipes
- break out if the hw state doesn't make sense

v3: Shut up gcc.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
b2b877ffe37d699f77f45e993590b66010491c52 03-May-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: make intel_ddi_get_cdclk_freq return values in KHz

With this, that 338 can finally become the correct 337500.

Due to the change we need to adjust the intel_dp_aux_ch function to
set the correct value, so adjust the division and also use
DIV_ROUND_CLOSEST instead of the old "round down" behavior because the
spec says the value "should be programmed to get as close as possible
to the ideal rate of 2MHz".

Quoting Paulo's follow-up to a question from Chris Wilson to explain
what exactly will change:

I use the 337500 value on the next patch, when setting the
ips_linetime value. The correct frequency is 337500, not 338000.

ips_linetime = DIV_ROUND_CLOSEST(mode->htotal * 1000 * 8,
intel_ddi_get_cdclk_freq);
For a mode with htotal of 2640 [0] we'll have: (i) (2640 * 1000 * 8) /
338000 = 62.48, resulting in 62 and (ii) (2640 * 1000 * 8) / 337500 =
62.57 resulting in 63.

For the case inside intel_dp.c:
Previously we were using 338. So with the old formula we were writing
338/2 = 169 to the register. And 337500 / 169 = 1997.04 (we use 337500
here because it's the real clock value). With the new value of
337500/2000 we'll have 168.75, which is 168 on the round-down case and
169 on the round-closest case. If we write 168 to the register, 337500
/ 168 = 2008.92, and 2008.92 is more distant from 2000 than 1997.04.
So with this patch we're changing the formula but still writing the
same correct value to the DP AUX register.

[0]: That's 1920x1080@50Hz on my DP monitor.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Pimp the commit message with Paulo's follow-up.]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
045ac3b5629d9711531a408e92f9074db6afe7ce 15-May-2013 Jesse Barnes <jbarnes@virtuousgeek.org> drm/i915: add encoder get_config function v5

We can use this for fetching encoder specific pipe_config state, like
mode flags, adjusted clock, etc.

Just used for mode flags atm, so we can check the pipe config state at
mode set time.

v2: get_config when checking hw state too
v3: fix DVO and LVDS mode flags (Ville)
get SDVO DTD for flag fetch (Ville)
v4: use input timings (Ville)
correct command used (Ville)
remove gen4 check (Ville)
v5: get DDI flag config too

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v4)
Tested-by: Paulo Zanoni <przanoni@gmail.com> (the new hsw ddi stuff)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
1c0b85c566b7a5a5cdabb767a39b445ce271a4fa 10-May-2013 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Compute WR PLL dividers dynamically

Up to now, we were using a static table to match the clock frequency
with a (r2,n2,p) triplet. Despite this table being big, it's by no mean
comprehensive and we had to fall back to the closest frequency when the
requested TMDS clock wasn't in the table.

This patch computes (r2,n2,p) dynamically and get rid of The Big Table.

v2: Replace the floating point constant 1e6 by 1000000

Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58497
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1)
[danvet: s/ /^T/]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
8693a824873a0a97be77c1d5f1e98777f06f7305 03-May-2013 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Add references to some workaround we implement

We did not mention the workaround name when implementing those. This
should help us track what we already implement.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
c77bf5659deb9405ef61080c148e47d2c8ee31e5 03-May-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: only disable DDI sound if intel_crtc->eld_vld

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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
21a8e6a4853b2ed39fa4c5188a710f2cf1b92026 10-Apr-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: don't setup hdmi for port D edp in ddi_init

dp_init_connector adjusts the encoder type if it is a eDP panel. Use
that to decide whether we should set up a hdmi connector or not.

To do so reorder the hdmi connector setup sequence in ddi_init a bit.

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
3ab9c63705cb7b1b9f83ddce725d8bd9ef7c66a9 02-May-2013 Imre Deak <imre.deak@intel.com> drm/i915: hsw: fix link training for eDP on port-A

According to BSpec the link training sequence for eDP on HSW port-A
should be as follows:

1. link training: clock recovery
2. link training: equalization
3. link training: set idle transmission mode
4. display pipe enable
5. link training: disable (set normal mode)

Contrary to this at the moment we don't do step 3. and we do step 5.
before step 4. Fix this by setting idle transmission mode for eDP at
the end of intel_dp_complete_link_train and adding a new
intel_dp_stop_link_training function to disable link training. With
these changes we'll end up with the following functions corresponding
to the above steps:

intel_dp_start_link_train -> step 1.
intel_dp_complete_link_train -> step 2., step 3.
intel_dp_stop_link_train -> step 5.

For port-A we'll call intel_dp_stop_link_train only after enabling the
pipe, for everything else we'll call it right after
intel_dp_complete_link_train to preserve the current behavior.

Tested on HSW/HSW-ULT.

In v2:
- Due to a HW issue we must set idle transmission mode for port-A too
before enabling the pipe. Thanks for Arthur Runyan for explaining
this.
- Update the patch subject to make it clear that it's an eDP fix, DP is
not affected.

v3:
- rename intel_dp_link_train() to intel_dp_set_link_train(), use 'val'
instead 'l' as var name. (Paulo)

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
17aa6be9579eb204b426eeae146a43bf3dd05078 30-Apr-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: simplify DP/DDI port width macros

If we ever leak a non-DP compliant port width through here, we have a
pretty serious issue. So just rip out all these WARNs - if we need
them it's probably better to have them at a central place where we
compute the dp lane count.

Also use the new DDI width macro for FDI mode.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: fixup the embarrassing s/intel_dp->DP/temp/ mistake Paulo
spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
627eb5a318a6caca2145d3c7195b084c59b291d9 29-Apr-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: hw state readout support for pipe_config->fdi_lanes

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: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
33d29b145305641f2c693b759cac468e0c87ab4d 13-Feb-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: move intel_crtc->fdi_lanes to pipe_config

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: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
b074cec8c652f2d273907a4b35239b4766c894ac 25-Apr-2013 Jesse Barnes <jbarnes@virtuousgeek.org> drm/i915: move PCH pfit controls into pipe_config

And put the pfit stuff into substructs while we're at it.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
bf98a72650c9272e70e7f0e904f85c025c0bb421 19-Apr-2013 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Remove mention of Haswell in DDI code

We are trying to have more platform-orthogonal pieces of code. The DDI
code shouldn't mention Haswell.

v2: Fix the email address

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
84f44ce795b3da9a08dc2041ecd60550d34c123e 17-Apr-2013 Ville Syrjälä <ville.syrjala@linux.intel.com> drm/i915: Print plane, pipe, port names as alphabetical insted of decimal

Alway use the alphabetical names in debug/error messages for planes,
pipes and ports, instead of using decimal numbers occasionally.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
3b117c8f2815bc4dd36b0b2c4b6490ad7d10b758 17-Apr-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: move cpu_transcoder to the pipe configuration

For a bunch of reason we need to more accurately track this:
- hw pipe state readout for Haswell needs the cpu transcoder.
- We need to know the right cpu transcoder in a bunch of places in
->disable and other modeset callbacks.

In the future we need to add hw state readout&check support, too. But
to avoid ugly merge conflicts do the rote sed job now without any
functional changes.

v2: Preserve the cpu_transcoder value when overwriting crtc->config.
Reported by Paulo.

Cc: Paulo Zanoni <przanoni@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
[danvet: Removed rough whitespace that Chris spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
22f9fe50597094970a9bcdf2464fc3b356fbedb6 02-Apr-2013 Jesse Barnes <jbarnes@virtuousgeek.org> drm/i915: fix DDI get_hw_state return value

If we couldn't find a pipe we shouldn't return true. This might be even
better as a WARN though, since it should be impossible to have the port
enabled without a pipe selected.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
4e53c2e010e531b4a014692199e978482d471c7e 27-Mar-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: precompute pipe bpp before touching the hw

The procedure has now 3 steps:

1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the encoder and crtc functions, according to
whatever constraints there are.
3. Decide whether to use dither by comparing the stored plane bpp with
computed pipe_bpp.

There are a few slight functional changes in this patch:
- LVDS connector are now also going through the EDID clamping. But in
a 2nd change we now unconditionally force the lvds bpc value - this
shouldn't matter in reality when the panel setup is consistent, but
better safe than sorry.
- HDMI now forces the pipe_bpp to the selected value - I think that's
what we actually want, since otherwise at least the pixelclock
computations are wrong (I'm not sure whether the port would accept
e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
the next higher bpc value, since otherwise there's no way to make
use of the 12 bpc mode (since the next patch will remove the 12bpc
plane format, it doesn't exist).

Both of these changes are due to the removal of the

pipe_bpp = min(display_bpp, plane_bpp);

statement.

Another slight change is the reworking of the dp bpc code:
- For the mode_valid callback it's sufficient to only check whether
the mode would fit at the lowest bpc.
- The bandwidth computation code is a bit restructured: It now walks
all available bpp values in an outer loop and the codeblock that
computes derived values (once a good configuration is found) has been
moved out of the for loop maze. This is prep work to allow us to
successively fall back on bpc values, and also correctly support bpc
values != 8 or 6.

v2: Rebased on top of Paulo Zanoni's little refactoring to use more
drm dp helper functions.

v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
range work.

v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.

v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
in a later patch though again.

v6: Fix spelling in a comment.

v7: Debug output improvements for the bpp computation.

v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
things!

v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
was lost in a rebase.

v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
that. Still unsure whether this is the way to go, but at least 6bpc
for a 8bpc hdmi output seems to work.

v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
depth on DP. Adjust the code.

v12: Rebased.

v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
requested from Jesse Barnes.

v14: Split out the special 6BPC handling for DP, as requested by Jesse
Barnes.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
965e0c489f360df1beeb567e4540777a09b8896e 27-Mar-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: introduce pipe_config->dither|pipe_bpp

We want to compute this earlier. To avoid a big complicated patch,
this patch here just does the big search&replace and still calls the
old functions at the same places.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
5bfe2ac00395ca37219b7187299cd9d23ae06682 27-Mar-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: add pipe_config->has_pch_encoder

This is used way too often in the enable/disable paths. And will
be even more useful in the future.

Note that correct semantics of this change highly depend upon
correct updating of intel_crtc->config: Like with all other
modeset state, we need to call ->disable with the old config,
but ->mode_set and ->enable with the new config.

v2: Do not yet use the flag in the ->disable callbacks - atm we don't
yet have support for the information stored in the pipe_config in the
hw state readout code, so this will be wrong at boot-up/resume.

v3: Rebased on top of the hdmi/dp ddi encoder merging.

v4: Fixup stupid rebase error which lead to a NULL vfunc deref.

v5: On haswell the VGA port is on the PCH!

v6: s/IS_HASWELL/HAS_DDI/, spotted by Paulo Zanoni. Also add a missing
parameter name in a function declaration.

v7: Don't forget to git add ...

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
a42f704b71b252705f34fbe60ea6f4a76f891a78 25-Mar-2013 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Warn if a pipe is enabled with a bogus port

If TRANS_DDI_FUNC_CTL has been wrongly programmed with an incorrect
port, we are currently trying to read PORT_CLK_SEL(port) with an
uninitialized value.

Handle that case by returning PORT_CLK_SEL_NONE and warning about it.

v2: Move the warning inside intel_ddi_get_crtc_pll (Paulo Zanoni)

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
8228c251ba5eda4c74aa1c6306f0057a419ec1c7 07-Mar-2013 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Rename intel_ddi_enable_pipe_func() to transcoder_func()

We are really talking about the transcoder function here and the disable
version uses trancoder in its name already, so let's try to be
consistent.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
00037c2e95618c8a598ff41e2fc4d34367b0eb91 07-Mar-2013 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Error out if we are trying to use VGA with SPLL already in use

Our static analysis tool noticed that 'reg' could be used uninitialized if
we are trying to get a PLL to drive VGA and SPLL is already in use
(plls->spll_refcoung != 0).

In the (error) case above, let's return false to the caller and emit an
error.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2831d8427cace563767cb802de05db28c4c6f894 07-Mar-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: disable sound first on intel_disable_ddi

Our mode set sequence documentation says audio must be disabled first.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Resolve conflict since the first patch in this series isn't
applied yet. Also bikeshed commit message as suggested by Ben.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
f3e227df8235fc0bf8ba08304aa135066ec9b9b0 24-Feb-2013 Syam Sidhardhan <syamsidhardh@gmail.com> drm/i915: Fix missing variable initilization

Need to initialize the variable wait to false.

Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
b242b7f745650832f445dca3e19efc3dd2d65a66 18-Feb-2013 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: rename sdvox_reg to hdmi_reg on HDMI context

Some (but not all) of the HDMI registers can be used to control sDVO,
so those registers have two names. IMHO, when we're talking about
HDMI, we really should call the HDMI control register "hdmi_reg"
instead of "sdvox_reg", otherwise we'll just confuse people reading
our code (we now have platforms with HDMI but without SDVO). So now
"struct intel_hdmi" has a member called "hdmi_reg" instead of
"sdvox_reg".

Also, don't worry: "struct intel_sdvo" still has a member called
"sdvo_reg".

v2: Rebase (v1 was sent in May 2012).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
876a8cdf92b23d268275cdce4397df0c37dac3fe 11-Dec-2012 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Preserve the DDI link reversal configuration

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: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
3e68320ef84528604d971afc3cadfbe208bef001 11-Dec-2012 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Preserve the FDI line reversal override bit on CPT

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: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
af5676f1f91585cabe811b8f697e32015e2be826 20-Jan-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: rip out helper->disable noop functions

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: Daniel Vetter <daniel.vetter@ffwll.ch>
d6dd9eb1d96d2b7345fe4664066c2b7ed86da898 29-Jan-2013 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: dynamic Haswell display power well support

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: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
7b9f35a6dd72f89452c58bbdbaf063027bf857ec 22-Jan-2013 Wang Xingchao <xingchao.wang@intel.com> drm/i915: HDMI/DP - ELD info refresh support for Haswell

ELD info should be updated dynamically according to hot plug event.
For haswell chip, clear/set the eld valid bit and output enable bit
from callback intel_disable/eanble_ddi().

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
68d18ad7fbc16288aa230ec0ffb4416fd4363c87 01-Dec-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: set the LPT FDI RX polarity reversal bit when needed

If we fail to set the bit when needed we get some nice FDI link
training failures (AKA "black screen on VGA output").

While we don't really know how to properly choose whether we need to
set the bit or not (VBT?), just read the initial value set by the BIOS
and store it for later usage.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
248138b59880a3cc69e9b7f0e06fb0caedd58305 29-Nov-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: fix hsw_fdi_link_train "retry" code

We were previously doing exactly what the "mode set sequence for CRT"
document mandates, but whenever we failed to train the link in the
first tentative, all the other subsequent retries always failed. In
one of my monitors that has 47 modes, I was usually getting around 3
failures when running "testdisplay -a".

After this patch, even if we fail in the first tentative, we can
succeed in the next ones. So now when running "testdisplay -a" I see
around 3 times the message "FDI link training done on step 1" and no
failures.

Notice that now the "retry" code looks a lot like the DP retry code.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
1a240d4de2ccf40de5796a4d1dbb3a0236051fc9 29-Nov-2012 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: fixup sparse warnings

- __iomem where there is none (I love how we mix these things up).
- Use gfp_t instead of an other plain type.
- Unconfuse one place about enum pipe vs enum transcoder - for the pch
transcoder we actually use the pipe enum. Fixup the other cases
where we assign the pipe to the cpu transcoder with explicit casts.
- Declare the mch_lock properly in a header.

There is still a decent mess in intel_bios.c about __iomem, but heck,
this is x86 and we're allowed to do that.

Makes-sparse-happy: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Use a space after the cast consistently and fix up the
newly-added cast in i915_irq.c to properly use __iomem.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0d536cb4e911c2496073f268e9730a9badaafa55 23-Nov-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: invert the log inside intel_prepare_ddi

Do an early return in case we don't have DDI instead of having the
whole function inside an "if" statement.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
affa935440733a79c5a9eb0e5357e2564ca4b355 23-Nov-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add HAS_DDI check

And use it whenever we call code that uses the DDIs. We already have
intel_ddi.c and prefix every function with intel_ddi_something instead of
haswell_something, so I think replacing the checks with HAS_DDI makes more
sense. Just a cosmetical change, yes I know, but I have this OCD...

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
c1f63f9d688e68088ef743a48a3aa8e0dc01a160 23-Nov-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: intel_prepare_ddi_buffers should be static

It's not even declared on header files.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
d567b07fce8f55f82e2cfe040cd74f7b4997ff38 20-Nov-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: fix intel_ddi_get_cdclk_freq for ULT machines

For now, this code is just used by the eDP AUX channel frequency.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
8fed6193736bf22e0e44c03ee783761e9cc37238 19-Nov-2012 Takashi Iwai <tiwai@suse.de> drm/i915: Enable DP audio for Haswell

This patch adds the missing code to send ELD for Haswell DisplayPort,
based on Xingchao's original patch.

A test was performed with HSW-D machine and NEC EA232Wmi DP monitor.

Cc: Xingchao Wang <xingchao.wang@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
1ad960f25ca419ca337284b369cf78d84b6a439e 02-Nov-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: fix Haswell FDI link disable path

This covers the "Disable FDI" section from the CRT mode set sequence.
This disables the FDI receiver and also the FDI pll.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
049456416f74a4a66d058cf9a46075f0051c6383 02-Nov-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: fix Haswell FDI link training code

This commit makes hsw_fdi_link_train responsible for implementing
everything described in the "Enable and train FDI" section from the
Hawell CRT mode set sequence documentation. We completely rewrite
hsw_fdi_link_train to match the documentation and we also call it in
the right place.

This patch was initially sent as a series of tiny patches fixing every
little problem of the function, but since there were too many patches
fixing the same function it got a little difficult to get the "big
picture" of how the function would be in the end, so here we amended
all the patches into a single big patch fixing the whole function.

Problems we fixed:

1 - Train Haswell FDI at the right time.

We need to train the FDI before enabling the pipes and planes, so
we're moving the call from lpt_pch_enable to haswell_crtc_enable
directly.

We are also removing ironlake_fdi_pll_enable since the PLL
enablement on Haswell is completely different and is also done
during the link training steps.

2 - Use the right FDI_RX_CTL register on Haswell

There is only one PCH transcoder, so it's always _FDI_RXA_CTL.
Using "pipe" here is wrong.

3 - Don't rely on DDI_BUF_CTL previous values

Just set the bits we want, everything else is zero. Also
POSTING_READ the register before sleeping.

4 - Program the FDI RX TUSIZE register on hsw_fdi_link_train

According to the mode set sequence documentation, this is the
right place. According to the FDI_RX_TUSIZE register description,
this is the value we should set.

Also remove the code that sets this register from the old
location: lpt_pch_enable.

5 - Properly program FDI_RX_MISC pwrdn lane values on HSW

6 - Wait only 35us for the FDI link training

First we wait 30us for the FDI receiver lane calibration, then we
wait 5us for the FDI auto training time.

7 - Remove an useless indentation level on hsw_fdi_link_train

We already "break" when the link training succeeds.

8 - Disable FDI_RX_ENABLE, not FDI_RX_PLL_ENABLE

When we fail the training.

9 - Change Haswell FDI link training error messages

We shouldn't call DRM_ERROR when still looping through voltage
levels since this is expected and not really a failure. So in this
commit we adjust the error path to only DRM_ERROR when we really
fail after trying everything.

While at it, replace DRM_DEBUG_DRIVER with DRM_DEBUG_KMS since
it's what we use everywhere.

10 - Try each voltage twice at hsw_fdi_link_train

Now with Daniel Vetter's suggestion to use "/2" instead of ">>1".

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Applied tiny bikesheds:
- mention in comment that we test each voltage/emphasis level twice
- realing arguments of the only untouched reg write, it spilled over
the 80 char limit ...]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
349d7e5d7b27ee7b0b596ef1047e5c63908597fa 01-Nov-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: set the correct number of FDI lanes on Haswell

We had 2 places using X2 and one place using X1.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
00c09d70df6b30c980f20facc1db3def3f5a637e 26-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: create the DDI encoder

Now intel_ddi_init is just like intel_hdmi_init and intel_dp_init: it
inits the encoder and then calls the proper init_connector functions.
Notice that for non-eDP ports we call both HDMI and DP connector init,
so we have 2 connectors attached to each DDI encoder.

After this change, intel_hdmi_init and intel_dp_init are only called
by Ivy Bridge and earlier, while hardware containing DDI outputs
should call intel_ddi_init.

Also added/removed quite a few "static" keywords due to the fact that
some function pointers were moved from intel_dp.c and intel_hdmi.c to
intel_ddi.c.

DP finally works on Haswell now! \o/

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
bcbc889bc44a781577479939490f6b7452d5b808 26-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add intel_ddi_connector_get_hw_state

We need this since now on DDI we will have 2 connectors on each
encoder.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
174edf1f867dc573439675f9b4c2211012d4b563 26-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add port field to intel_digital_port

Both "intel_dp" and "intel_hdmi" structs had a "port" field, which
always had the same value. It makes more sense to move this to
intel_digital_port, so we can know the port independently of the
connector type.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
5de8bbf5536fe79c1353c5476c31409531b5393f 23-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: enable DDI eDP

Now that all the eDP enablement bits are there, we can actually try to
use the eDP.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
82a4d9c0a82a59c1f214ab1f9ce6b34d0736a54a 23-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: turn the eDP DDI panel on/off

It's an important step :)

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
d6c50ff8cae880f20969556698a3246ac401144c 23-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: set/unset the DDI eDP backlight

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
b8fc2f6a18052194c486b407765a4f5e4dca692d 23-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: set the correct eDP aux channel clock divider on DDI

The cdclk frequency is not always the same, so the value here should
be adjusted to match it.

Version 2: call intel_ddi_get_cdclk_freq instead of reading
CDCLK_FREQ, because the register is just for earlier HW steppings.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
e6f0bfc4fb963da9e945ebc6330db9a4d756ba78 23-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: select the correct pipe when using TRANSCODER_EDP

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
c9809791ae0ae3e5792fc6ad3d4a5d9658aadc62 23-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: convert PIPE_MSA_MISC to transcoder

Same as the other registers. This one also appeared on Haswell for the
first time, so that's why we are renaming it.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
ad80a810ec3ffa96450ce3b40128d55fede7a825 24-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: convert DDI_FUNC_CTL to transcoder

Because there's one instance of the register per CPU transcoder and
not per CPU pipe. This is another register that appeared for the first
time on Haswell, and even though its Haswell name is
PIPE_DDI_FUNC_CTL, it will be renamed to TRANS_DDI_FUNC_CTL, so let's
just use the new naming scheme before it confuses more people.

Notice that there's a big improvement on intel_ddi_get_hw_state due to
the new TRANSCODER_EDP.

V2: Also rename the register to TRANS_DDI_FUNC_CTL as suggested by
Damien Lespiau.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
bb523fc08d4a4a726c7555be7800735685888b3c 23-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: convert PIPE_CLK_SEL to transcoder

This register appeared in Haswell. It does not have an EDP version
because the EDP transcoder is always tied to the DDIA clock. Notice
that if we call PIPE_CLK_SEL(pipe) when pipe is PIPE_A and transcoder
is TRANSCODER_EDP we might introduce a bug, that's why this is a
transcoder register even though it does not have an EDP version.

Even though Haswell names this register PIPE_CLK_SEL, it will be
renamed to TRANS_CLK_SEL in the future, so let's just start using the
real name that makes more sense and avoids misusage.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
c19b0669925cb00dc1c7b2362bfa85128afba882 15-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: implement Haswell DP link train sequence

Previous patch "drm/i915: add basic Haswell DP link train bits"
implemented the basic structure to set the voltage levels and training
patterns. This patch adds the higher-level bits that are part of the
mode set sequence and hot plug.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
a836bdf9ae5aa3b100c8cdd04aae5bb9c0340145 15-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add DP support to intel_ddi_disable_port

Just a missing register. There is no problem to run this code when the
output is HDMI.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
247d89f62230f3369aeaab85dca34978f79dcb86 15-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add DP support to intel_ddi_mode_set

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
6547fef887b057ee860f4266fa2923b7bbbf1850 15-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add DP support to intel_enable_ddi

We should only write the DDI_BUF_CTL at this point for HDMI/DVI. For
DP we need to do this earlier, and the values written to the register
are also different.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fe43d3f5a38e5b7db27f79cb8447cb25a884dfc7 15-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add DP support to intel_ddi_get_hw_state

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0bdee30ed351d437cc24bb0ec51dfd02f60273fb 15-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add DP support to intel_ddi_get_encoder_port

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
068759bd6ee26b5c69977d99611cc72b43280ab5 15-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add DP support to intel_ddi_pll_mode_set

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
dae847991a4327b8883a2a4e7b0440a42d528b77 15-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add intel_ddi_set_pipe_settings

In theory, all the DDI pipe settings should be set here, including
timing and M/N registers. For now, let's just set the DP MSA
attributes.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: fixed up the unused typo in a #define, spotted by Jani
Nikula.]
Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
7739c33ba48174204b24c1b867b455318e752787 15-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add DP support to intel_ddi_enable_pipe_func

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
39bc66c9371fa6cdb1029e6c1768824f068be913 11-Oct-2012 Damien Lespiau <damien.lespiau@intel.com> drm/i915: Fix the SCC/SSC typo in the SPLL bits definition

We're talking about Spread Spectrum Clocks here, thus SSC.

Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2886e93f5d28c559b3de9c4f75547af31e14504e 05-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: disable DDI_BUF_CTL at the correct time

And also properly wait for its idle bit.

You may notice that DDI_BUF_CTL is enabled in .enable but disabled in
.post_disable instead of .disable. Yes, the mode set sequence is not
exactly symmetrical, but let's assume the spec is correct unless we
can prove it's wrong.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
1e6210f45d95f1db7831072b7be64f9562280df1 05-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: don't rely on previous values set on DDI_BUF_CTL

Just set the only bit we need, everything else is either ignored on
HDMI or should be set to zero.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
6441ab5f8ffdf7e99eefe0fb747858e0c12b567e 05-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: completely rewrite the Haswell PLL handling code

Problems with the previous code:
- HDMI just uses WRPLL1 for everything, so dual head cases might not
work sometimes.
- At encoder->mode_set we just write the PLL register without doing
any kind of check (e.g., check if the PLL is already being used).
- There is no way to fail and return error codes at
encoder->mode_set.
- We write to PORT_CLK_SEL at mode_set and we never disable it.
- Machines hang due to wrong clock enable/disable sequence.

So here we rewrite the code, making it a little more like the
pre-Haswell PLL mode set code:
- Check PLL availability at ironlake_crtc_mode_set.
- Try to use both WRPLLs.
- Check if PLLs are used before actually trying to use them, and
properly fail with error messages.
- Enable/disable PORT_CLK_SEL at the right place.
- Add some WARNs to check for bugs.

The next improvement will be to try to reuse PLLs if the timings
match, but this is content for another patch and it's already
documented with a TODO comment.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
fc914639b12054c930fe75a2ff4221311699e9c2 05-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: enable and disable PIPE_CLK_SEL at the right time

Previously we were enabling it at mode_set but never disabling. Let's
follow the mode set sequence.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
8d9ddbcbd0e3fc9368a5972346dc726493d31c9c 05-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: enable and disable DDI_FUNC_CTL at the right time

And the right time is exactly after/before changing PIPE_CONF. See the
documentation about the mode set sequence.

This code is not inside any encoder-specific callback because
DDI_FUNC_CTL is part of the pipe, so it is used by all encoders.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
79f689aa6b14e058d4effd734e9920ed9531401d 05-Oct-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: rewrite the LCPLL code

Right now, we're trying to enable LCPLL at every mode set, but we're
never disabling it. Also, we really don't want to be disabling LCPLL
since it requires a very complex disable/enable sequence. This
register should really be set by the BIOS and we shouldn't be touching
it. Still, let's try to check its value and print some errors in case
we find something wrong. We're also adding intel_ddi_get_cdclk_freq
which will be used later in other places.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
85234cdc28f622dc94d8bb0089635113e2aa5609 02-Jul-2012 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915/hdmi: implement get_hw_state

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
5ab432ef4997ce32c9406721b37ef6e97e57dae1 30-Jun-2012 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915/hdmi: convert to encoder->disable/enable

I've picked hdmi as the first encoder to convert because it's rather
simple:
- no cloning possible
- no differences between prepare/commit and dpms off/on switching.

A few changes are required to do so:
- Split up the dpms code into an enable/disable function and wire it
up with the intel encoder.
- Noop out the existing encoder prepare/commit functions used by the
crtc helper - our crtc enable/disable code now calls back into the
encoder enable/disable code at the right spot.
- Create new helper functions to handle dpms changes.
- Add intel_encoder->connectors_active to better track dpms state. Atm
this is unused, but it will be useful to correctly disable the
entire display pipe for cloned configurations. Also note that for
now this is only useful in the dpms code - thanks to the crtc
helper's dpms confusion across a modeset operation we can't (yet)
rely on this having a sensible value in all circumstances.
- Rip out the encoder helper dpms callback, if this is still getting
called somewhere we have a bug. The slight issue with that is that
the crtc helper abuses dpms off to disable unused functions. Hence
we also need to implement a default encoder disable function to do
just that with the new encoder->disable callback.
- Note that we drop the cpt modeset verification in the commit
callback, too. The right place to do this would be in the crtc's
enable function, _after_ all the encoders are set up. But because
not all encoders are converted yet, we can't do that. Hence disable
this check temporarily as a minor concession to bisectability.

v2: Squash the dpms mode to only the supported values -
connector->dpms is for internal tracking only, we can hence avoid
needless state-changes a bit whithout causing harm.

v3: Apply bikeshed to disable|enable_ddi, suggested by Paulo Zanoni.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
4f07854dd7fc197d9ea2bd83c26736baabb0b981 09-Aug-2012 Wang Xingchao <xingchao.wang@intel.com> drm/i915: write eld info for HDMI audio

HDMI audio related registers will be configured in write_eld callback.

Signed-off-by: Wang Xingchao <xingchao.wang@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
126e9be816e7c0322f5dac994f94d65a8fabcc56 10-Aug-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: try harder to find WR PLL clock settings

If we don't find the exact refresh rate, go with the next one. This
makes some modes work for me. They won't have the best settings, but
will at least have something. Just returning from this function when
we don't find the perfect settings does not help us at all.

Version 2:
- Remove duplicate lines on the clock table.
- Add back debug message with refresh, p, n2 and r2.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
602c43d34dcd46b0349b31c9b53b19cd5063ae3f 08-Aug-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: completely reset the value of DDI_FUNC_CTL

Don't rely on previous values already set on the register. Everything
we're not explicitly setting should be zero for now.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
dfcef252e024b4ca6fe5be9e1d656ac1929ce894 08-Aug-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: correctly set the DDI_FUNC_CTL bpc field

Correctly erase the values previously set and also check for 6bpc and
10bpc.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
f63eb7c4528060e54688baafb7a499e9391eefe6 08-Aug-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: set the DDI sync polarity bits

During my tests, everything worked even if the wrong polarity was set.
Still, we should try to set the correct values.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
3f7c447faab3e750b0b2f94edad605ba8eb28a7f 08-Aug-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: fix pipe DDI mode select

Mask the value before changing it and also select DVI when needed.

DVI was working in cases where the BIOS was setting the correct value
because we were not masking the value before changing it.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
08d644add0e5f799a47dbe7849401606c522e59e 12-Jul-2012 Daniel Vetter <daniel.vetter@ffwll.ch> drm/i915: add port parameter to intel_hdmi_init

Instead of having a giant if cascade to figure this out according to
the passed-in register. We could do quite a bit more cleaning up and
all by using the port at more places, but I think this should be part
of a bigger rework to introduce a struct intel_digital_port which
would keep track of all these things. I guess this will be part of
some haswell-DP-induced refactoring.

For now this rips out the big cascade, which is what annoyed me so
much.

v2: Add port variable name back for the func decl (I've tried to trick
myself below the 80 char limit).

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
4acf518626cdad5bbf7aac9869bd4accbbfb4ad3 05-Jul-2012 Eugeni Dodonov <eugeni.dodonov@intel.com> drm/i915: program FDI_RX TP and FDI delays

This is required for a stable FDI connection.

v2: fix and simplify the FDI_RX_MISC bits as noticed by Paulo Zanoni.

CC: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
687f4d06dbb1cf3c8f9f6050cd7aad24dc0ce978 28-May-2012 Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: add set_infoframes to struct intel_hdmi

We need a function that is able to fully 'set' the state of the DIP
registers to a known state.

Currently, we have the write_infoframe function that is called twice:
once for AVI and once for SPD. The problem is that write_infoframe
tries to keep the state of the DIP register as it is, changing only
the minimum necessary bits. The second problem is that
write_infoframe does twice (once for each time it is called) some
work that should be done only once (like waiting for vblank and
setting the port). If we add even more DIPs, it will do even more
repeated work.

This patch only adds the infrastructure keeping the code behavior the
same as before.

v2: add static keywords

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
72662e103c7dd305725dcf4aabcbd8f69483dfbc 09-May-2012 Eugeni Dodonov <eugeni.dodonov@intel.com> drm/i915: prepare HDMI link for Haswell

On Haswell, we need to properly train the DDI buffers prior to enabling
HDMI, and enable the required clocks with correct dividers for the desired
frequency.

Also, we cannot simple reuse HDMI routines from previous generations of
GPU, as most of HDMI-specific stuff is being done via the DDI port
programming instead of HDMI-specific registers.

This commit take advantage of the WR PLL clock table which is in a
separate (previous) commit to select the right divisors for each mode.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
12a13a3389716009db8deb64094656f946e8950d 09-May-2012 Eugeni Dodonov <eugeni.dodonov@intel.com> drm/i915: add WR PLL programming table

This table is used for programming WR PLL clocks, used by HDMI and DVI outputs.
I split it into a separate patch to simplify the HDMI enabling patch which was
getting huge.

Note that this table is a temporary solution for WR PLL programming. It
will be reworked into a more exact algorithm at a later stage. But for
now, it provides the most accurate clock setting solution, so we use it
here.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
0e72a5b55e706dafa3402611f6f9e082a810673d 09-May-2012 Eugeni Dodonov <eugeni.dodonov@intel.com> drm/i915: detect digital outputs on Haswell

Digital port detection on Haswell is indicated by the presence of a bit in
DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
So we check for those bits during the initialization time and let the hdmi
function know about those.

Note that this bit does not indicates whether the output is DP or HDMI.
However, the DDI buffers can be programmed in a way that is shared between
DP/HDMI and FDI/HDMI except for PORT E.

So for now, we detect those digital outputs as being HDMI, but proper DP
support is still pending.

Note that DDI A can only drive eDP, so we do not handle it here for hdmi
initialization.

v2: simplify Haswell handling logic

v3: use generic function for handling digital outputs.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
c82e4d265d98aed94547435605b5e05f8aae9676 09-May-2012 Eugeni Dodonov <eugeni.dodonov@intel.com> drm/i915: support DDI training in FDI mode

Starting with Haswell, DDI ports can work in FDI mode to support
connectivity with the outputs located on the PCH.

This commit adds support for such connections in the intel_ddi module, and
provides Haswell-specific functionality to make it work.

v2: simplify the commit as per Daniel Vetter suggestion.

Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
45244b87943b1173353b48854352bb9f4b065867 09-May-2012 Eugeni Dodonov <eugeni.dodonov@intel.com> drm/i915: initialize DDI buffer translations

DDI is introduced starting with Haswell GPU generation. So to simplify its
management in the future, we also add intel_ddi.c to hold all the
DDI-related items.

Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the connection
parameters. HDMI uses the last pair of values and ignores the first 9
pairs. So we program HDMI values in both cases, which allows HDMI to work
over both FDI and DP-friendly buffers.

Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>