GitLab

This register is read-only, so we have never actually set
OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code
comment about this. I filed a specification update request to clarify
this there.

CC: Arthur J Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: David Weinehall <david.weinehall@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-4-git-send-email-imre.deak@intel.com

Silences

	src/drivers/gpu/drm/i915/intel_ddi.c: warning: 'port' may be used uninitialized in this function [-Wuninitialized]
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1459717154-27607-1-git-send-email-chris@chris-wilson.co.uk

Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists
FDI RX disable both as step 13 and step 18 in the sequence. But I dug
up an old BUN mail from Art that moved the FDI RX disable to happen
before DDI_BUF_CTL disable. That BUN did not renumber the steps and just
added a note:
"Workaround: Disable PCH FDI Receiver before disabling DDI_BUF_CTL."

The BUN described the symptoms of the fixed issue as:
"PCH display underflow and a black screen on the analog CRT port that
happened after a FDI re-train"

I suppose later someone tried to renumber the steps to match, but forgot
to remove the FDI RX disable from its old position in the sequence.

They also forgot to update the note describing what should be done in
case of an FDI training failure. Currently it says:
"To retry FDI training, follow the Disable Sequence steps to Disable FDI,
but skip the steps related to clocks and PLLs (16, 19, and 20), ..."

It should really say "17, 20, and 21" with the current sequence because
those are the steps that deal with PLLs and whatnot, after step 13 became
FDI RX disable. And had the step 18 FDI RX disable been removed, as I
suspect it should have, the note should actually say "17, 19, and 20".

So, let's move the FDI RX disable to happen before DDI_BUF_CTL disable,
as that would appear to be the correct order based on the BUN.

Note that Art has since unconfused the spec, and so this patch should
now match the steps listed in the spec.

v2: Add a note that the spec is now correct

Cc: Paulo Zanoni <przanoni@gmail.com>
Cc: Art Runyan <arthur.j.runyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456841783-4779-1-git-send-email-ville.syrjala@linux.intel.com

Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

Make it easier to see which ports are configured for each phy. No
functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459496681-398-1-git-send-email-jani.nikula@intel.com

According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register needs to be
checked to ensure that the register is in accessible state.
Also, based on a BSpec update, changing the timeout value to
check iphypwrgood, from 10ms to wait for up to 100us.

v2: [Ville] use wait_for_us instead of the atomic call.
v3: [Jani/Imre] read register only once
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reported-by: Philippe Lecluse <Philippe.Lecluse@intel.com>
Cc: Deak, Imre <imre.deak@intel.com>
Cc: Nikula, Jani <jani.nikula@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1459446354-19012-1-git-send-email-vandana.kannan@intel.com

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

The BXT display connections have DSI transcoders A and C that can be
muxed to any pipe, not unlike the eDP transcoder. Add the notion of DSI
transcoders.

The "normal" transcoders A, B and C are not used with BXT DSI, so care
must be taken to avoid accessing those registers with DSI transcoders in
the hardware state readout, modeset, and generally everywhere.

v2: addressing comments by Ville:
 - rename the dsi get config function to hsw_get_dsi_transcoder_state
 - rebase onto the higher level split of pipe/transcoder functions
 - use more has_dsi_encoder as we can now because of the above,
   with no need to look at the transcoder so much
 - rename IS_DSI_TRANSCODER to transcoder_is_dsi
 - use the above a bit more instead of comparing to < TRANSCODER_EDP
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/299740536b7941e31b2744f3ce34f7afe936a771.1458313400.git.jani.nikula@intel.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: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten 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: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten 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

Move the code for configurating BXT plls into the shared dpll code, so
that the platform specific details are hidden behind that interface.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-12-git-send-email-ander.conselvan.de.oliveira@intel.com

Move the code for selecting plls for SKL/KLB into the shared dpll code,
so that the platform specific details are hidden behind that interface.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-11-git-send-email-ander.conselvan.de.oliveira@intel.com

Move the code for selecting and configuring HSW/BDW DDI PLLs into the
shared dpll infrastructure. With this most of the PLL selection logic
for those platforms is in one place. DisplayPort is handled separately,
but that should be fixed on a follow up patch. It also allows a small
clean up of the SPLL logic.

v2: Rebase.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-10-git-send-email-ander.conselvan.de.oliveira@intel.com

Change the type of intel_crtc_state->shared_dpll to be a pointer to a
shared dpll. With this there is no need to first convert the id stored
in the crtc state to a pointer in order to use it. It does introduce a
bit of hassle on doing the opposite.

The long term objective is to hide details about dpll ids behind the
shared dpll interface.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-5-git-send-email-ander.conselvan.de.oliveira@intel.com

No functional changes.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1457451987-17466-3-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: Martin Kepplinger <martink@posteo.de>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Martin Kepplinger <martink@posteo.de>
Signed-off-by: Jani 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: Jani 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: Martin Kepplinger <martink@posteo.de>
Cc: drm-intel-fixes@lists.freedesktop.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1456324522-21591-1-git-send-email-tiwai@suse.de

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.

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com
(cherry picked from commit e27daab4

)
Signed-off-by: Jani 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.

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com

We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a
result we skip assigning a DPLL to any DP MST ports, which makes link
training fail:

[ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well
[ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well
[ 1442.933957] [drm:intel_mst_pre_enable_dp] 0
[ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000
[ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0
[ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0
[ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000
[ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1
[ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1
[ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000
[ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2
…
[ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
[ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting

After which the pipe state goes completely out of sync:

[   70.075596] [drm:check_crtc_state] [CRTC:25]
[   70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001)
[   70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0)
[   70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021)
[   70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173)
[   70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5)
[   70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256)
[   70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500)

And if you're especially lucky, it keeps going downhill:

[   83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
[   83.309265]
[   83.309265] =================================
[   83.309266] [ INFO: inconsistent lock state ]
[   83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted
[   83.309267] ---------------------------------
[   83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[   83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes:
[   83.309293]  (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915]
[   83.309293] {IN-HARDIRQ-W} state was registered at:
[   83.309297]   [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00
[   83.309299]   [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0
[   83.309302]   [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90
[   83.309321]   [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915]
[   83.309332]   [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915]
[   83.309337]   [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300
[   83.309339]   [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60
[   83.309341]   [<ffffffff811010b4>] handle_edge_irq+0x74/0x130
[   83.309344]   [<ffffffff81009073>] handle_irq+0x73/0x120
[   83.309346]   [<ffffffff817805f1>] do_IRQ+0x61/0x120
[   83.309348]   [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20
[   83.309351]   [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330
[   83.309353]   [<ffffffff815f5367>] cpuidle_enter+0x17/0x20
[   83.309356]   [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50
[   83.309358]   [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0
[   83.309360]   [<ffffffff817701da>] rest_init+0x13a/0x140
[   83.309363]   [<ffffffff81f2af8e>] start_kernel+0x475/0x482
[   83.309365]   [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c
[   83.309367]   [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a

Fixes: 82d35437

 ("drm/i915/skl: Implementation of SKL DPLL programming")
Signed-off-by: Lyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454428183-994-1-git-send-email-cpaul@redhat.com
(cherry picked from commit 78385cb3

)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Assuming any connector that isn't DP, MST, or HDMI is eDP definitely
seems likely to cover up other bugs in the future.
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454423709-21882-2-git-send-email-cpaul@redhat.com

We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a
result we skip assigning a DPLL to any DP MST ports, which makes link
training fail:

[ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well
[ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well
[ 1442.933957] [drm:intel_mst_pre_enable_dp] 0
[ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000
[ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0
[ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0
[ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000
[ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1
[ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1
[ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000
[ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2
…
[ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
[ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting

After which the pipe state goes completely out of sync:

[   70.075596] [drm:check_crtc_state] [CRTC:25]
[   70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001)
[   70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0)
[   70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021)
[   70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173)
[   70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5)
[   70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256)
[   70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500)

And if you're especially lucky, it keeps going downhill:

[   83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
[   83.309265]
[   83.309265] =================================
[   83.309266] [ INFO: inconsistent lock state ]
[   83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted
[   83.309267] ---------------------------------
[   83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[   83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes:
[   83.309293]  (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915]
[   83.309293] {IN-HARDIRQ-W} state was registered at:
[   83.309297]   [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00
[   83.309299]   [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0
[   83.309302]   [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90
[   83.309321]   [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915]
[   83.309332]   [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915]
[   83.309337]   [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300
[   83.309339]   [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60
[   83.309341]   [<ffffffff811010b4>] handle_edge_irq+0x74/0x130
[   83.309344]   [<ffffffff81009073>] handle_irq+0x73/0x120
[   83.309346]   [<ffffffff817805f1>] do_IRQ+0x61/0x120
[   83.309348]   [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20
[   83.309351]   [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330
[   83.309353]   [<ffffffff815f5367>] cpuidle_enter+0x17/0x20
[   83.309356]   [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50
[   83.309358]   [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0
[   83.309360]   [<ffffffff817701da>] rest_init+0x13a/0x140
[   83.309363]   [<ffffffff81f2af8e>] start_kernel+0x475/0x482
[   83.309365]   [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c
[   83.309367]   [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a

Fixes: 82d35437

 ("drm/i915/skl: Implementation of SKL DPLL programming")
Signed-off-by: Lyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454428183-994-1-git-send-email-cpaul@redhat.com

In commit bfb9faab8 we added a workaround for some BXT BIOS that fail to
properly initialize the DDI_A_4_LANES bit of the control register (4
lanes is the only valid configuration on BXT since there is no DDI E to
share with).  A recent patch added some additional checks on this
register bit before the workaround gets applied; this breaks eDP on BXT
in some settings.  Some minor code shuffling is all we need to restore
the workaround.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 7cd87cb80 ("drm/i915: Check max number of lanes when registering DDI ports")
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1454022577-834-1-git-send-email-matthew.d.roper@intel.com

Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

commit 10afa0b6 ("drm/i915: Reject >9 ddi translation entried if port != A/E on SKL")
added sanity checks to make sure we don't end up with too many ddi translation
values for eDP ports, but it actually failed to check if the port is eDP.
We still look up the edp translations for non-eDP ports, but don't use
them, so we shouldn't be complaining about them either.

Fixes: 10afa0b6

 ("drm/i915: Reject >9 ddi translation entried if port != A/E on SKL")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452612496-9201-1-git-send-email-ville.syrjala@linux.intel.com

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Move the ddi buffer translation programming to occur from the encoder
.pre_enable() hook, for just the ddi port we are enabling. Previously
we used to reprogram the translations for all ddi ports during
init and during power well enabling.

v2: s/intel_prepare_ddi_buffers/intel_prepare_ddi_buffer/ (Daniel)
    Resolve conflicts due to  dev_priv->atomic_cdclk_freq
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Only DDI A and E support 10 translation entries in DP mode. For the
other ports the tenth entry is reserved for HDMI.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449597590-6971-9-git-send-email-ville.syrjala@linux.intel.com

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

Make the ddi buffer programming code a bit more neat by passing
around dev_priv instead of dev.

v2: Resolve conflicts due to KBL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)

skl_get_buf_trans_edp() effectively contains another copy of
skl_get_buf_trans_dp(). Remove the duplication and just call
skl_get_buf_trans_dp() from  skl_get_buf_trans_edp().

v2: Resolve conflicts due to KBL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)

skl_get_buf_trans_*() don't need the 'ddi_translations' local variable
since all they with is assign and return. Just return the right thing
directly and get rid of the local variable.

v2: Resolve conflicts due to KBL
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)

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: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

DDI A and E share some of the lanes, so check that we have enough
lanes for the purpose we need before registering the encoders.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449597590-6971-3-git-send-email-ville.syrjala@linux.intel.com

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

No functional changes.

That state the obvious and just duplicate the place we
need to change whenever the table is updated. So let's clean it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452021535-22641-1-git-send-email-rodrigo.vivi@intel.com

When reviewing DDI translation table I noticed few changes we
haven't incorporated yet and it is always good to follow latest
spec.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452009511-15064-1-git-send-email-rodrigo.vivi@intel.com

When debuging an intermittent corrupted screen I suspected on DDI
translation table and checked we are out of date with the spec.

I'm not sure this will fix my bug yet, but it is always good to follow
the spec.

v2: Ville caught a switched i-boost value. Thanks!

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452021087-21673-1-git-send-email-rodrigo.vivi@intel.com

Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.

@@
identifier dev, encoder, funcs;
@@
 int drm_encoder_init(struct drm_device *dev,
                      struct drm_encoder *encoder,
                      const struct drm_encoder_funcs *funcs,
                      int encoder_type
+                     ,const char *name, int DOTDOTDOT
                      )
{ ... }

@@
identifier dev, encoder, funcs;
@@
 int drm_encoder_init(struct drm_device *dev,
                      struct drm_encoder *encoder,
                      const struct drm_encoder_funcs *funcs,
                      int encoder_type
+                     ,const char *name, int DOTDOTDOT
                      );

@@
expression E1, E2, E3, E4;
@@
 drm_encoder_init(E1, E2, E3, E4
+                 ,NULL
                  )

v2: Add ', or NULL...' to @name kernel doc (Jani)
    Annotate the function with __printf() attribute (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449670818-2966-1-git-send-email-ville.syrjala@linux.intel.com

This patch adds a reverse mapping from a digital port number to
intel_encoder object containing the corresponding intel_digital_port.
It simplifies the query of the encoder a lot.

Note that, even if it's a valid digital port, the dig_port_map[] might
point still to NULL -- usually it implies a DP MST port.  Due to this
fact, the NULL check in each place has no WARN_ON() and just skips the
port.  Once when the situation changes in future, we might introduce
WARN_ON() for a more strict check.
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This patch adds support for DP MST audio in i915.

Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.

Another separated patches to support DP MST audio will be implemented
in audio driver.
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Libin Yang <libin.yang@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449036584-105393-2-git-send-email-libin.yang@linux.intel.com

Let's introduce ULT and ULX Kabylake definitions and start
using it for a propper DDI buffer translation.

v2: Remove extra white space. (Paulo)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

Currently we disable some parts of FDI setup after a failed link
training. But despite that we continue with the modeset as if everything
is fine. This results in tons of noise from the state checker, and
it means we're not following the proper modeset sequence for the rest of
crtc enabling, nor for crtc disabling.

Ideally we should abort the modeset and follow the proper disable
sequence to shut off everything we enabled so far, but that would
require a big rework of the modeset code. So instead just leave FDI
up and running in its untrained state, and log an error. This is
what we do on older platforms too.

v2: Fix a typo in the commit message
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449260570-14670-1-git-send-email-ville.syrjala@linux.intel.com

The .get_config() hooks should not reference anything in crtc->config,
everything should be based on the passed in pipe_config instead. So
don't dig out the cpu_transcoder from crtc->config on ddi platfforms,
and also avoid using the encoder->crtc link and instead look up the
pipe via pipe_config->base.crtc.

I don't think this will actually fix anything since during the initial
state readout we set up the encoder->crtc link prior to calling
.get_config(), and during the modeset state check the encoder->crtc
ought to be correct anyway since it's that state we just programmed.
But this seems the right thing to do anyway.

While at it, do some house cleaning on the local variables in the
.infoframe_enabled() hooks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1448555227-31403-1-git-send-email-ville.syrjala@linux.intel.com

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>