The code for programming voltage swing and emphasis was duplicated
between DP and HDMI code. Move that to a new file, intel_dpio_phy.c.

v2: Keep the "Use 800mV-0dB" comment in the HDMI code. (Ville)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NJim Bride <jim.bride@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1461761065-21195-3-git-send-email-ander.conselvan.de.oliveira@intel.com

Add new edp_dpcd variable to intel_dp.
Read and save eDP Display control capability registers to edp_dpcd.
Signed-off-by: NYetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459865452-9138-3-git-send-email-yetundex.adebisi@intel.com

Since commit 30d9aa42 ("drm/i915: Read sink_count dpcd always"),
the status of a DP connector depends on its sink count value.
However, some eDP panels don't set that value appropriately,
causing them to be reported as disconnected.
Fix this by ignoring sink count for eDP.

v2: Rephrased commit message. (Ander)
    In case of eDP, returning status as connected if DPCD
    read succeeds to avoid any further operations.

Fixes: 30d9aa42 ("drm/i915: Read sink_count dpcd always")
Cc: Ander Conselvan De Oliveira <conselvan2@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reported-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NShubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Tested-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460444034-22320-1-git-send-email-shubhangi.shrivastava@intel.com

In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some
much needed clean-up was done, but unfortunately part of the change
broke DP MST.  The real issue was setting the connector state to
disconnected in the MST case, which is good, but the code then (after
a goto) checks if the connector state is not connected and shuts down
MST if this is the case, which is bad.  With this change both SST and
MST seem to be happy.

v2: Add removed check further up in the function to be sure that MST
    is shut down when we lose the link. (Ander)

Fixes: commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse")
cc: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>
cc: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
cc: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: NJim Bride <jim.bride@linux.intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Reviewed-by: NLyude <cpaul@redhat.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460394684-7036-1-git-send-email-jim.bride@linux.intel.com

The driver's VDD on/off logic assumes that whenever the VDD is on we
also hold an AUX power domain reference. Since BIOS can leave the VDD on
during booting and resuming and on DDI platforms we won't take a
corresponding power reference, the above assumption won't hold on those
platforms and an eventual delayed VDD off work will do an extraneous AUX
power domain put resulting in a refcount underflow. Fix this the same
way we did this for non-DDI DP encoders:

commit 6d93c0c4 ("drm/i915: fix VDD state tracking after system
resume")

At the same time call the DP encoder suspend handler the same way as the
non-DDI DP encoders do to flush any pending VDD off work. Leaving the
work running may cause a HW access where we don't expect this (at a point
where power domains are suspended already).

While at it remove an unnecessary function call indirection.

This fixed for me AUX refcount underflow problems on BXT during
suspend/resume.

CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
CC: stable@vger.kernel.org
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460963062-13211-4-git-send-email-imre.deak@intel.com

We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI,
and just trying to frob the display timings to include borders results
in a corrupted picture. So reject the 'Center' scaling mode on GMCH
platforms for eDP and DSI.

TODO: Should really filter out the unsupported modes from the prop,
but that would be fairly invasive since the prop is now created and
stored by drm core. So leave it for a rainy day.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-6-git-send-email-ville.syrjala@linux.intel.comTested-by: NJani Nikula <jani.nikula@intel.com>

The underruns we were seeing when enabling eDP port A on ILK seem to
have been caused by prematurely clearing the LP1+ watermark values when
disabling LP1+ watermarks. Now that the watermarks are handled
properly, we can rip out the underrun suppression around the port A
enable.

We still need to worry about the underruns on FDI when enabling
the eDP PLL. But as Bspec tells us, we can avoid that by a vblank
wait on the pipe driving FDI just prior to enabling the eDP PLL.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459536799-18109-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>

Take a bigger hammer to the underrun suppression on ILK. Instead of
trying to suppress them at specific points in the modeset sequence just
silence them across the entire sequence. This gets rid of some underruns
at least on my ILK. Note that this changes SNB and IVB to follow the
same approach just to keep the code less convoluted. The difference is
that on those platforms we won't suppress CPU underruns for port A since
it doesn't seem to be necessary.

My ILK has port A eDP and two PCH HDMI ports, so I can't be sure this is
as effective on other PCH port types. Perhaps we still need some of
Daniel's extra vblank waits [2]?

I've still been able to trigger an underrun on the other pipe, but
fixing that perhaps needs the LP1+ disable trick I implemented here [1]
which never got merged.

A few details which hamper stress testing on my ILK are that sometimes
the PCH transcoder gets messed up and refuses to shut down, and sometimes
even the panel power sequencer apparently gets stuck on the always on
position.

[1] https://lists.freedesktop.org/archives/intel-gfx/2014-March/041317.html
[2] https://lists.freedesktop.org/archives/intel-gfx/2016-January/086397.html

v2: Add a note that we also get underruns when enabling PCH ports

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
Link: http://patchwork.freedesktop.org/patch/msgid/1459536799-18109-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com>

This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.

This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.

v2: changed variable type from u8 to bool (Jani)
    return immediately if perform_full_detect is set(Siva)

v3: changed method of determining full detection from using
    pointer to return code (Siva)

v4: changed comments to indicate meaning of return value of
    intel_dp_short_pulse and explain the use of return value
    from intel_dp_get_dpcd in intel_dp_short_pulse (Ander)
Tested-by: NNathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NShubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-5-git-send-email-shubhangi.shrivastava@intel.com

Sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.

This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.

SINK_COUNT dpcd is not dependent on DOWNSTREAM_PORT_PRESENT dpcd.
SINK_COUNT denotes if a display is attached, while
DOWNSTREAM_PORT_PRESET indicates how many ports are available
in the dongle where display can be attached. so it is possible
for sink count to change irrespective of value in downstream
port dpcd.

Here is a table of possible values and scenarios

sink_count      downstream_port
                present
0               0               no display is attached
0               1               dongle is connected without display
1               0               display connected directly
1               1               display connected through dongle

v2: Storing value of intel_dp->sink_count that is ready
    for consumption. (Ander)
    Squashing two commits into one. (Ander)

v3: Added comment to explain the need of early return when
    sink count is 0. (Ander)
Tested-by: NNathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NShubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-4-git-send-email-shubhangi.shrivastava@intel.com

When created originally intel_dp_check_link_status()
was supposed to handle only link training for short
pulse but has grown into handler for short pulse itself.
This patch cleans up this function by splitting it into
two halves. First intel_dp_short_pulse() is called,
which will be entry point and handle all logic for
short pulse handling while intel_dp_check_link_status()
will retain its original purpose of only doing link
status related work.

intel_dp_short_pulse: All existing code other than
link status read and link training upon error status.

intel_dp_check_link_status:
The link status should be read on short pulse
irrespective of panel being enabled or not so
intel_dp_get_link_status() performs dpcd read first
then based on crtc active / enabled it will
perform the link training.

This is because short pulse is a generic interrupt
which should always be handled, because it may mean:
	1. Hotplug/unplug of MST panel
	2. Hotplug/unplug of dongle
	3. Link status change for other DP panels

v2: Added WARN_ON to intel_dp_check_link_status()
    Removed a call to intel_dp_get_link_status() (Ander)

v3: Changed commit message to explain need of link status
    being read before performing encoder checks (Daniel)

v4: Changed commit message to explain need of reading
    link status on short pulse (Ander)
Tested-by: NNathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NShubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
[anderco: fix parenthesis alignment]
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-3-git-send-email-shubhangi.shrivastava@intel.com

Current DP detection has DPCD operations split across
intel_dp_hpd_pulse and intel_dp_detect which contains
duplicates as well. Also intel_dp_detect is called
during modes enumeration as well which will result
in multiple dpcd operations. So this patch tries
to solve both these by bringing all DPCD operations
in one single function and make intel_dp_detect
use existing values instead of repeating same steps.

v2: Pulled in a hunk from last patch of the series to
    this patch. (Ander)

v3: Added MST hotplug handling. (Ander)

v4: Added a flag to check if detect is performed to
    prevent multiple detects on hotplug. (Ander)
Tested-by: NNathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NShubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
[anderco: fix parenthesis aligment]
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-2-git-send-email-shubhangi.shrivastava@intel.com

intel_dp_detect() is called for not just detection but
during modes enumeration as well. Repeating the whole
sequence during each of these calls is wasteful and
time consuming.
This patch moves probing for panel, DPCD read etc done in
intel_dp_detect() to a new function intel_dp_long_pulse().
Note that the behavior of intel_dp_detect() is changed to
report connected or disconnected depending on whether the
EDID is available or not.
This change will be required by further patches in the series
to avoid performing duplicated DPCD operations on hotplug.

v2: Moved a hunk to next patch of the series.
    Moved intel_dp_unset_edid to out. (Ander)

v3: Rephrased commit message and intel_dp_unset_dp() is called
    within intel_dp_set_dp() to free the previous EDID. (Ander)

v4: Added overriding of status to disconnected for MST. (Ander)
Tested-by: NNathan D Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com>
Signed-off-by: NShubhangi Shrivastava <shubhangi.shrivastava@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
[anderco: fix parenthesis alignment]
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459341326-13142-1-git-send-email-shubhangi.shrivastava@intel.com

Move all data initialized from VBT under dev_priv->vbt. No functional
changes.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-3-git-send-email-jani.nikula@intel.com

Housekeeping, similar to psr, backlight, and dsi. No functional changes.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458834623-8734-2-git-send-email-jani.nikula@intel.com

Hide knowledge about VBT child devices in intel_bios.c.
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1458125015-7931-3-git-send-email-jani.nikula@intel.com

Adds an (unsafe; auto-kernel-tainting) boolean module parameter to the i915
drm driver: "enable_dp_mst", which is enabled by default.  Disabling the
parameter forces newly connected DisplayPort sinks to report as not
supporting multi-stream transport (MST), thus "forcing" the use of
single-stream transport (SST).

v2: rename parameter to conform to style
v3: add signoff
Signed-off-by: NNathan Schulte <nmschulte@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1458054845-5837-1-git-send-email-nmschulte@gmail.com

Include DPLL0 in the managed dplls for SKL/KBL. While it has to be kept
enabled because of it driving CDCLK, it is better to special case that
inside the DPLL code than in the higher level.

v2: Use INTEL_DPLL_ALWAYS_ON flag. (Ander)

v3: Remove extremely paranoid WARN_ONs. (Maarten)
    Handle DPLL0 in skylake_get_ddi_pll() properly. (Ander)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-14-git-send-email-ander.conselvan.de.oliveira@intel.com

Manage the LCPLLs used with DisplayPort, so that all the HSW/BDW DPLLs
are managed by the shared dpll code.

v2: Introduce INTEL_DPLL_ALWAYS_ON flag to please state checker. (Ander)

v3: Initialize pll->flags in intel_shared_dpll_init(). (Ander)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-13-git-send-email-ander.conselvan.de.oliveira@intel.com

The recent commit [0bdf5a05: drm/i915: Add reverse mapping between
port and intel_encoder] introduced a reverse mapping to retrieve
intel_dig_port object from the port number.  The code assumed that the
port vs intel_dig_port are 1:1 mapping.  But in reality, this was a
too naive assumption.

As Martin reported about the missing HDMI audio on his SNB machine,
pre-HSW chips may have multiple intel_dig_port objects corresponding
to the same port.  Since we assign the mapping statically at the init
time and the multiple objects override the map, it may not match with
the actually enabled output.

This patch tries to address the regression above.  The reverse mapping
is provided basically only for the audio callbacks, so now we set /
clear the mapping dynamically at enabling and disabling HDMI/DP audio,
so that we can always track the latest and correct object
corresponding to the given port.

Fixes: 0bdf5a05 ('drm/i915: Add reverse mapping between port and intel_encoder')
Reported-and-tested-by: NMartin Kepplinger <martink@posteo.de>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NMartin Kepplinger <martink@posteo.de>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456324522-21591-1-git-send-email-tiwai@suse.de
(cherry picked from commit 9dfbffcf)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The recent commit [0bdf5a05: drm/i915: Add reverse mapping between
port and intel_encoder] introduced a reverse mapping to retrieve
intel_dig_port object from the port number.  The code assumed that the
port vs intel_dig_port are 1:1 mapping.  But in reality, this was a
too naive assumption.

As Martin reported about the missing HDMI audio on his SNB machine,
pre-HSW chips may have multiple intel_dig_port objects corresponding
to the same port.  Since we assign the mapping statically at the init
time and the multiple objects override the map, it may not match with
the actually enabled output.

This patch tries to address the regression above.  The reverse mapping
is provided basically only for the audio callbacks, so now we set /
clear the mapping dynamically at enabling and disabling HDMI/DP audio,
so that we can always track the latest and correct object
corresponding to the given port.

Fixes: 0bdf5a05 ('drm/i915: Add reverse mapping between port and intel_encoder')
Reported-and-tested-by: NMartin Kepplinger <martink@posteo.de>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456324522-21591-1-git-send-email-tiwai@suse.de

Now that the mess with AUX clock divder rounding is sorted out and
we have both cdclk and rawclk cached in dev_priv, we can clean up
the .get_aux_clock_divider() functions a bit.

The main thing here is just calling ilk_get_aux_clock_divider()
from hsw_get_aux_clock_divider() except for the LPT:H special
case.

We could go further and call g4x_get_aux_clock_divider() from
ilk_get_aux_clock_divider() for the PCH ports, but I'm sure Jani
would object, so leave that be.

While at it repeat the comment where the AUX clock comes from
in ilk_get_aux_clock_divider().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456932138-14004-6-git-send-email-ville.syrjala@linux.intel.com

With the hrawclk frequency cached in dev_priv, we can simply use
g4x_get_aux_clock_divider() for VLV/CHV.

v2: Rebase due to IS_VALLYVIEW vs. IS_CHERRYVIEW split
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456932138-14004-4-git-send-email-ville.syrjala@linux.intel.com

g4x is the first platform with DP support, so let's name the relevant
functions as g4x_ instead i9xx_ to avoid confusion.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456932138-14004-3-git-send-email-ville.syrjala@linux.intel.com

Generalize rawclk handling by storing it in dev_priv.

Presumably our hrawclk readout works at least for CTG and ELK
since we've been using it for DP AUX on those platforms. There
are no real docs anymore after configdb vanished, so the only
reference is the public CTG GMCH spec. What bits are listed in
that doc match our code. The ELK GMCH spec have no relevant
details unfortunately.

The PNV situation is less clear. Starting from
commit aa17cdb4 ("drm/i915: initialize backlight max from VBT")
we assume that the CTG/ELK hrawclk readout works for PNV as well.
At least the results *seem* reasonable for one PNV machine (Lenovo
Ideapad S10-3t). Sadly the PNV GMCH spec doesn't have the goods on
the relevant register either.

So let's keep assuming it works for PNV,ELK,CTG and read it out on
those platforms. G33 also has hrawclk according to some notes
in BSpec, but we don't actually need it for anything, so let's not
even try to read it out there.

v2: Rebase due to IS_VALLYVIEW vs. IS_CHERRYVIEW split
    Use KHz() all over, and kill off a few useless temp variables
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456932138-14004-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

This is for callers who want micro-second precision but are not
waiting from the atomic context.

v2:
  * Fix atomic waits. (Dave Gordon)
  * Use USEC_PER_SEC and USEC_PER_MSEC. (Chris Wilson)
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Dave Gordon <david.s.gordon@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Currently we check if the encoder's idea of dotclock agrees with what
we calculated based on the FDI parameters. We do this in the encoder
.get_config() hooks, which isn't so nice in case the BIOS (or some other
outside party) made a mess of the state and we're just trying to take
over.

So as a prep step to being able sanitize such a bogus state, move the
the sanity check to just after we've read out the entire state. If
we then need to sanitize a bad state, it should be easier to move the
sanity check to occur after sanitation instead of before it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455738073-14502-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-10-git-send-email-imre.deak@intel.com
(cherry picked from commit 6fa9a5ec)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

The assumption when adding the intel_display_power_is_enabled() checks
was that if it returns success the power can't be turned off afterwards
during the HW access, which is guaranteed by modeset locks. This isn't
always true, so make sure we hold a dedicated reference for the time of
the access.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-10-git-send-email-imre.deak@intel.com

Looks like g4x hpd live status bits actually agree with the spec. At
least they do on the machine I have, and apparently on Nick Bowler's
g4x as well.

So gm45 may be the only platform where they don't agree. At least
that seems to be the case based on the (somewhat incomplete)
logs/dumps in [1], and Daniel has also tested this on his gm45
sometime in the past.

So let's change the bits to match the spec on g4x. That actually makes
the g4x bits identical to vlv/chv so we can just share the code
between those platforms, leaving gm45 as the special case.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=52361

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Nick Bowler <nbowler@draconx.ca>
References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.htmlReported-by: NNick Bowler <nbowler@draconx.ca>
Cc: stable@vger.kernel.org
Fixes: 237ed86c ("drm/i915: Check live status before reading edid")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455127145-20087-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 0780cd36)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

intel_digital_port_connected() lacks one 'else'. There's no
actual harm in not having it since each branch has an unconditional
return, so it can't accidentally end up in taking two branches instead
of just the one. But let's be consistent and add the 'else' anyway.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455201868-31527-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Looks like g4x hpd live status bits actually agree with the spec. At
least they do on the machine I have, and apparently on Nick Bowler's
g4x as well.

So gm45 may be the only platform where they don't agree. At least
that seems to be the case based on the (somewhat incomplete)
logs/dumps in [1], and Daniel has also tested this on his gm45
sometime in the past.

So let's change the bits to match the spec on g4x. That actually makes
the g4x bits identical to vlv/chv so we can just share the code
between those platforms, leaving gm45 as the special case.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=52361

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Sonika Jindal <sonika.jindal@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Nick Bowler <nbowler@draconx.ca>
References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.htmlReported-by: NNick Bowler <nbowler@draconx.ca>
Cc: stable@vger.kernel.org
Fixes: 237ed86c ("drm/i915: Check live status before reading edid")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455127145-20087-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

So far, the i915 driver and some other drivers set it to the drm_device,
which doesn't allow one to know which DP a given aux channel is related
to. Changing this to be the drm_connector provides proper nesting, still
allowing one to get the drm_device from it. Some drivers already set it
to the drm_connector.

This also removes the need to add a sysfs link for the i2c device under
the connector, as it will already be there.

v9:
 - As a side effect, drm_dp_aux_unregister() must be called before
 intel_connector_unregister(), as both the aux.dev and the i2c adapter
 dev are children of the drm_connector device now. Calling
 drm_dp_aux_unregister() before prevents them from being destroyed
 twice.

v10:
 - move aux_fini() to connector_unregister(), instead of moving
 drm_dp_aux_unregister() outside of connector_register().
Signed-off-by: NRafael Antognolli <rafael.antognolli@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453417821-2811-4-git-send-email-rafael.antognolli@intel.com

Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12)
if this time is already spent in suspend/poweron time.

v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle
    delay calculation(Ville).

v3: Addressed below comments
    1. Tracking time from where last powercycle is initiated.
    2. Used ktime_get_bootime() wrapper for boottime clock.
    3. Used ktime_ms_delta() to get time difference.

v4: Updated v3 change log in detail.

v5: Removed static from panel_power_on_time(Stéphane).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NAbhay Kumar <abhay.kumar@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453513144-14135-1-git-send-email-abhay.kumar@intel.com

It is possible the we request to have a mode that has
higher pixel clock than our HW can support. This patch
checks if requested pixel clock is lower than the one
supported by the HW. The requested mode is discarded
if we cannot support the requested pixel clock.

This patch applies to DisplayPort.

V2:
- removed computation for max DOT clock

V3:
- cleanup by removing unnecessary lines

V4:
- max_pixclk renamed as max_dotclk
Signed-off-by: NMika Kahola <mika.kahola@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454419003-6001-2-git-send-email-mika.kahola@intel.com

While we are calling intel_dp_aux_transfer() with msg->size=0 whenever
msg->buffer is NULL, passing NULL to memcpy() is undefined according to
the ISO C standard. I haven't found any notes about this in the GNU C's
or the kernel's documentation of the function and can't imagine what it
would do with the NULL ptr. To better document this use of the
parameters it still make sense to add an explicit check for this to the
code.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NDavid Weinehall <david.weinehall@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1454071949-24677-1-git-send-email-imre.deak@intel.com

When we stop the sink CRC calculation we wait a while until the counter
is reset to zero and return -ETIMEDOUT. However the sink crc was
calculated already by this point so we just ignore this return at
the main function.

So, let's also ignore the message and put it as a debug message instead
of an error one. The message might still be useful when debuging
test failures so we could be able to know something was not going so
well with sink crc stop.

v2: Improve log message.

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=93694
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1454107499-29678-1-git-send-email-rodrigo.vivi@intel.com

Having this on stack triggers the -Wframe-larger-than=1024 and
is not nice to put such big things on the kernel stack anyway.

This required a little bit of refactoring to handle the new
failure path from vlv_force_pll_on.

v2: Corrected some whitespace.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: John Harrison <john.c.harrison@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1453217117-26125-1-git-send-email-tvrtko.ursulin@linux.intel.com

Add a common function to return "on" or "off" string based on the
argument, and drop the local versions of it.

This is the onoff version of

commit 42a8ca4c
Author: Jani Nikula <jani.nikula@intel.com>
Date:   Thu Aug 27 16:23:30 2015 +0300

    drm/i915: add yesno utility function
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452768814-29787-1-git-send-email-jani.nikula@intel.com

Rather than having open coded checks for the DDI A/E configuration,
just store the max supported lane count in intel_digital_port.

We had an open coded check for DDI A, but not for DDI E. So we may
have been vilating the DDI E max lane count.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>