A bunch of functions are now exclusively used for HDMI, so naming the
variables with hdmi prefix/suffix is redundant. Also use int rather
than u32 for the translation level consistently.

v2: Rebase due to hdmi_level=-1 avoidance

Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171018181958.4423-1-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>

Handle missing buf trans tables, or out of bounds buf trans levels
the same way everywhere. These should never be hit under normal
conditions, but let's play it safe for now.

v2: Avoid the hdmi_level=-1 case (James)

Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171018181934.4229-1-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>

SKL DDI B/C/D only have 9 usable buf trans registers for DP/eDP. That
matches the normal DP buf trans tables, but the low vswing eDP tables
have 10 entries. Thus the eDP tables can only be used safely with DDI A
and E.

We try to catch cases where DDI B/C/D gets used with the wrong number of
entires in some parts of the code, but not everywhere. Let's move the
code to deal with that deeper into intel_ddi_get_buf_trans_edp(). And
for sake of symmetry do the same in intel_ddi_get_buf_trans_dp(). That
would also avoid explosions in the rather unlikely case that the DP
tables would get revised to 10 entries as well.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-9-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>

default_index contained in the BXT buf_trans tables is actually useless.
For DP we should always have a valid level selected (otherwise the link
training logic would be buggy), and for HDMI we can just do what the
other platforms do and pick the correct entry in intel_ddi_hdmi_level().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-8-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>

encoder->type is unreliable for DP/HDMI, so pass it in explicity into
cnl_ddi_vswing_sequence(). This matches what we do for BXT.

v2: Pass intel_encoder down to cnl_ddi_vswing_program(), and
    clean up the argument types while at it
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-7-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>

Make BXT less special by following the CNL approach and handling
it in intel_ddi_dp_voltage_max() alognside every other DDI platform.

v2: Clean up the argument types to bxt_ddi_vswing_sequence() while at it
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-6-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>

The caller of intel_prepare_hdmi_ddi_buffers() alreday figured out the
level, so let's just pass it in instead if figuring it out again.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-5-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>

encoder->type isn't reliable for DP/HDMI encoders, so pass the type
explicity to skl_set_iboost(). Also take the opportunity to streamline
the code.

v2: Clean up the argument types to skl_ddi_set_iboost() while at it
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-4-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>

Introduce intel_ddi_get_buf_trans_hdmi() and start using it where we
can.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-3-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>

We'll want to use the intel_ddi_get_buf_trans_*() functions a bit
earlier in the file, so move them up. While at it start using them
in the iboost setup to get rid of the platform checks there.

v2: Rebase due to BDW FDI buf trans fix
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171016145705.11780-2-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>

On PLL Enable sequence we need to "Configure DPCLKA_CFGCR0 to turn on
the clock for the DDI and map the DPLL to the DDI"

So we first do the map and then we unset DDI_CLK_OFF to turn the clock
on. We do this in 2 separated steps.

However, on this second step where we should only unset the off bit we are
also unmapping the ddi from the pll. So we end up using the pll 0
for almost everything. Consequently breaking cases with more than one
display.

Fixes: 555e38d2 ("drm/i915/cnl: DDI - PLL mapping")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Kahola, Mika <mika.kahola@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003220859.21352-2-rodrigo.vivi@intel.com

The compiler warns:

	drivers/gpu/drm/i915/intel_ddi.c:118:35: warning: ‘bdw_ddi_translations_fdi’ defined but not used

Lo and behold, if we look at intel_ddi_get_buf_trans_fdi(), it uses
hsw_ddi_translations_fdi[] for both Haswell and *Broadwell*

Fixes: 7d1c42e6 ("drm/i915: Refactor code to select the DDI buf translation table")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.12+
Link: https://patchwork.freedesktop.org/patch/msgid/20171013154735.27163-1-chris@chris-wilson.co.ukReviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Untangle intel_enable_ddi() by splitting it into DP and HDMI specific
variants.

v2: Keep using intel_ddi_get_encoder_port() for now
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-10-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Rather that plumb the link parameters separately to
intel_ddi_pre_enable_dp() let's just pass the entire crtc state.

intel_ddi_pre_enable_hdmi() already took the crtc state, but for some
reason intel_ddi_pre_enable() still wanted to extract has_infoframe
from therein and pass it in separately. Let's not do that since it's
pointless.

v2: Rebase due to more code getting pulled into the DDI hooks

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-9-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

Untangle intel_disable_ddi() by splitting it into DP and HDMI specific
variants.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-8-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

intel_edp_panel_on() will itself do the is_edp() check, so the caller
doesn't have to bother. Pre-DDI code doesn't bother, so let's follow the
same approach for DDI.
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-7-ville.syrjala@linux.intel.com

To clean up the mess in intel_ddi_post_disable() split it into two
clean variants for HDMI and DP.

v2: Rebase due to MST DPMS changes

Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-6-ville.syrjala@linux.intel.com

To untangle the mess that is intel_ddi_post_disable() move the the bits
needed by FDI into intel_ddi_fdi_post_disable(). This way we can stop
worrying about FDI in intel_ddi_post_disable().
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-5-ville.syrjala@linux.intel.com

Extract the code to disable the DDI_BUF_CTL into small helper. This
will allows us to detangle the encoder type mess in
intel_ddi_post_disable().

v2: Keep using intel_ddi_get_encoder_port() for now
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-4-ville.syrjala@linux.intel.com

Pull the code to disable the port clock into a function. We already have
the intel_ddi_clk_select() counterpart.

v2: Keep using intel_ddi_get_encoder_port() for now (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171010121207.570-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>

If for some unexpected reason the registers all read zero it's better
to WARN and return instead of dividing by zero and completely freezing
the machine.

I don't expect this to happen in the wild with the current code, but I
accidentally triggered the division by zero while doing some debugging
in an unusual environment.

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171005213842.11423-2-paulo.r.zanoni@intel.com

Simplify CRTC enable.

v2: Don't forget DSI (Daniel)
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1ad8f3ccaed99a5f03e3d53345221a25ad0be50f.1507200657.git.jani.nikula@intel.com

One of the recent changes introduced a warning about
undefined behavior in the sanity checking:

drivers/gpu/drm/i915/intel_ddi.c: In function 'intel_ddi_hdmi_level':
drivers/gpu/drm/i915/intel_ddi.c:654:6: error: 'n_hdmi_entries' may be used uninitialized in this function [-Werror=maybe-uninitialized]

It seems that the new cnl specific get_buf_trans functions
can return uninitialized data if the voltage level is set
to an unexpected value. This changes the code to always return
'1' in that error case, which seems like the safest choice
as we use one less than the number as an array index later on.

Fixes: cc9cabfd ("drm/i915/cnl: Move voltage check into ddi buf trans functions.")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
[danvet: shut up gcc comment added.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171005120835.437022-1-arnd@arndb.de

Use the POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions to
set power states for downstream sinks. Apart from giving us the ability
to set power state for individual sinks, this fixes the below test for
me.

$ xrandr --display :0 --output DP-2-2-8 --off
$ xrandr --display :0 --output DP-2-2-1 --off
$ xrandr --display :0 --output DP-2-2-8 --auto #Black screen
$ xrandr --display :0 --output DP-2-2-1 --auto

v2: Modify and document the dpms and port disable order (Ville)
    Add comment explaining is_mst = !crtc_state equivalence(Ville, Maarten)

v3 by Jani: rebase

References: https://bugs.freedesktop.org/show_bug.cgi?id=90963
References: https://bugs.freedesktop.org/show_bug.cgi?id=88124
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Lyude <lyude@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NLyude Paul <lyude@redhat.com>
Acked-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003142211.860-1-jani.nikula@intel.com

The common lane power down flag of a DPIO PHY has a funky semantic:
after the initial enabling of the PHY (so from a disabled state) this
flag will be clear. It will be set only after the PHY will be used for
the first time (for instance due to enabling the corresponding pipe) and
then become unused (due to disabling the pipe). During the initial PHY
enablement we don't know which of the above phases we are in, so move
the check for the flag where this is known, the HW readout code. This is
where the rest of lane power down status checks are done anyway.

This fixes at least a problem on GLK where after module reloading, the
common lane power down flag of PHY1 is set, but the PHY is actually
powered-on and properly set up. The GRC readout code for other PHYs will
hence think that PHY1 is not powered initially and disable it after the
GRC readout. This will cause the AUX power well related to PHY1 to get
disabled in a stuck state, timing out when we try to enable it later.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Fixes: e93da0a0 ("drm/i915/bxt: Sanitiy check the PHY lane power down status")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102777Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171002135307.26117-1-imre.deak@intel.com

All the values we put into the CNL buf_trans tables fit into 8 bits.
So switch over to u8 from the u32 we use currently.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170918182604.9519-4-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJani Nikula <jani.nikula@intel.com>

All the values we put into the BXT buf_trans tables fit into 8 bits.
So switch over to u8 from the u32 we use currently.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170918182604.9519-3-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Some comments in intel_ddi.c are indented with spaces instead of tabs.
Fix that up.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170918182604.9519-2-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>

No functional changes. Only change the macro from
"DPLL_CFGCR0_DC0_FRAC_SHIFT to DPLL_CFGCR0_DCO_FRACTION_SHIFT
to be consistent with DPLL_CFGCR0_DCO_FRACTION_MASK
and DPLL_CFGCR0_DCO_FRACTION

Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1505413899-30876-1-git-send-email-manasi.d.navare@intel.com

On clock recovery this function is called to find out
the max voltage swing level that we could go.

However gen 9 functions use the old buffer translation tables
to figure that out. That table is not valid for CNL
causing an invalid number of entries and an invalid selection
on the max voltage swing level.

v2: Let's use same approach that previous platforms.
v3: Actually use n_entries and avoid duplicated -1.
v4: Avoid cnl_max_level and use current style.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170831145356.15932-1-rodrigo.vivi@intel.com

Let's get a proper HDMI DDI entry level for vswing programming
sequences on CNL.

Spec doesn't specify any default for HDMI tables,
so let's pick the last entry as the default for now.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-7-rodrigo.vivi@intel.com

No functional changes. But those functions will be needed
to get max level for HDMI and DP, so let's move those
up closer to other similar functions existent for previous
platforms.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-6-rodrigo.vivi@intel.com

Let's start converging CNL buf translations to same style
used on previous platforms. So first thing is to use the
standard signature so we don't need to propagate the voltage
check into other parts of the code, but only on the parts
that it is really useful.
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-5-rodrigo.vivi@intel.com

Sequences for DisplayPort asks us to
" Configure voltage swing and related IO settings.
Refer to DDI Buffer section."

before "Configure and enable DDI_BUF_CTL"

On BXT and CNL this means to execute the ddi vswing sequences.

At this point these sequences calls are getting duplicated for DP
because they are all called from DP link trainning sequences.

However this patch is not yet removing it before a futher discussion
since spec also allows that during link training without disabling
anything:

"
Notes
Changing voltage swing during link training:
Change the swing setting following the DDI Buffer section.
The port does not need to be disabled.
"

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-4-rodrigo.vivi@intel.com

Vswing sequences on BXT and CNL are equivalent
to the ddi buffer registers setting on other platforms.

For some reason it got aligned with skl_ddi_set_iboost what
is semantically incorrect. This forced us to keep skipping
ddi buffer translation tables on the platforms that has
the vswing sequences.

v2: Don't mess with DP signal levels on this patch.

Cc: Vandana Kannan <vandana.kannan@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-3-rodrigo.vivi@intel.com

Let's decouple bxt, glk and cnl dp signal levels
from other DDIs to avoid confusion.

No functional change. Only a reorg to avoid messing
with currently working DP signal levels when
moving voltage swing sequences around to match spec.

v2: ddi_signal_levels is also called from other ddi
    platforms, so don't remove IS_GEN9_BC check from
    skl_ddi_set_iboos. (Ville).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-2-rodrigo.vivi@intel.com

No functional changes. This only moves the DP level
selection to a separated function that will be later
used to organize better the vswing sequences.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170829232230.23051-1-rodrigo.vivi@intel.com

The enable/disable/etc. encoder hooks aren't supposed to alter the
state(s), so pass them as const. Unfortunately C lacks any kind of deep
const thingy, so this can't catch all abuses. But at least it acts as a
hint to the reader telling them not to mess about with the state(s).

v2: Update intel_tv_mode_find() and ironlake_edp_pll_on() as well
v3: Deal with intel_sdvo_connector_state
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818134958.15502-9-ville.syrjala@linux.intel.com

The PSR enable/disable need to know things about the crtc state, so
plumb it through. This will become even more important when we start
to reuse the generic infoframe code for the VSC DIP programming as the
infoframe code wants the crtc state as well.

v2: Fix kernel docs
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818134958.15502-7-ville.syrjala@linux.intel.com

DP ports may want to use the video DIP for SDP transmission, so let's
initialize the vfuncs for DP encoders as well. The only exception is
port A eDP prior to HSW as that one doesn't have a video DIP instance.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NShashank Sharma <shashank.sharma@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170818134958.15502-6-ville.syrjala@linux.intel.com