Previously I was under the impression that the scanline counter
reads 0 when the pipe is off. Turns out that's not correct, and
instead the scanline counter simply stops when the pipe stops, and
it retains it's last value until the pipe starts up again, at which
point the scanline counter jumps to vblank start.

These jumps can cause the timestamp to jump backwards by one frame.
Since we use the timestamps to guesstimage also the frame counter
value on gen2, that would cause the frame counter to also jump
backwards, which leads to a massice difference from the previous value.
The end result is that flips/vblank events don't appear to complete as
they're stuck waiting for the frame counter to catch up to that massive
difference.

Fix the problem properly by actually making sure the scanline counter
has started to move before we assume that it's safe to enable vblank
processing.

v2: Less pointless duplication in the code (Chris)

Cc: stable@vger.kernel.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Fixes: b7792d8b ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129153732.3612-1-ville.syrjala@linux.intel.com

i830_disable_pipe() gets called from the power well code, and thus
we're already holding the power domain mutex. That means we can't
call plane->get_hw_state() as it will also try to grab the
same mutex and will thus deadlock.

Replace the assert_plane() calls (which calls ->get_hw_state()) with
just raw register reads in i830_disable_pipe(). As a bonus we can
now get a warning if plane C is enabled even though we don't even
expose it as a drm plane.

v2: Do a separate WARN_ON() for each plane (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Fixes: 51f5a096 ("drm/i915: Add .get_hw_state() method for planes")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129125411.29055-1-ville.syrjala@linux.intel.com

This comment predates atomic, and I think with the way we currently
track IPS, it's safe to enable this for the case we switch too.

Changes since v1:
- Keep IPS enabled when switching planes.
Changes since v2:
- Enable IPS when at least one plane is enabled. (Ville)
Changes since v3:
- Actually do what was advertised in v3, sigh! (Ville, CI)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171122183906.47767-1-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

ips_enabled was used as a variable of whether IPS can be enabled or not,
but should be used to test whether IPS is actually enabled.

Changes since v1:
- Call needs_modeset on new crtc state. (Ville)
- IPS can be enabled with sprite plane enabled too. (Ville)
- Fix CDCLK vs IPS workaround. (Ville)
Changes since v2:
- Only re-enable fastset when inheriting mode. (Ville)
- Put the conditions for enabling and disabling IPS in a helper.
Changes since v3:
- Keep the max_cdclk workaround working. (Ville)
- Also check logical cdclk out of paranoia.
- Remove planes check from IPS disable function for initial disable.
- Remove assert_plane_enabled/disabled checks and use
  crtc_state->active_planes for hsw_enable_ips only, always allow
  calling hsw_disable_ips to disable it initially in hw.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171122183901.47720-1-maarten.lankhorst@linux.intel.com
[mlankhorst: pipe_config -> crtc_state (Ville)]
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Previously we would enable hotplug polling on the outputs immediately
upon construction. This would allow a very early hotplug event to
trigger before we had finishing setting up the driver to handle it.
Instead, move the output polling to the last step of registration, after
we have set up all handlers, including the fbdev configuration.

v2: Symmetrically turnoff the hotplug helper in unregister after the
fbdev is first synchronised then finalized. This stops a late hotplug
event being processed after the interrupts are disabled.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20171128110147.28654-1-chris@chris-wilson.co.uk

This goes back to pre-atomic, where due to intermediate dpms states
connectors and encoder states might indeed not have matched.

With atomic that's all smashed together (and hopefully no bios ever
enables a vga output in dpms standby/suspedn state or we're toast).
In

commit 873ffe69
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Wed Aug 5 12:37:07 2015 +0200

    drm/i915: Remove connectors_active from sanitization, v2.

sanitize_encoders was changed to disable the encoder in all cases,
which made the comment obsolete.

Remove the misleading comment.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171121094241.9129-1-daniel.vetter@ffwll.ch

Check that the planes are in the state we expect them to be. For
now we can only check whether each plane is correctly enabled or
disabled. In the future we may want to expand the plane state
readout to support a more thorough verification.

v2: Verify all planes part of the state as long as at least
    one crtc is doing a modeset (Daniel)
v3: Fix typoes (James)

Cc: James Ausmus <james.ausmus@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-11-ville.syrjala@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Since we now have a ->get_hw_state() method for planes, let's use
that during the initial plane fb readout.

v2: s/plane/i9xx_plane/ etc. (James)

Cc: James Ausmus <james.ausmus@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NJames Ausmus <james.ausmus@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-10-ville.syrjala@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Eliminate crtc->plane since it's pretty much a layering violation.
We can always get the plane via crtc->primary if we actually need it.

The only ugly thing left is plane_to_crtc_mapping[], but that's
still needed by the pre-g4x watermark code.

v2: Removed a misplaced comment change (Daniel)
v3: Rebase due to fbc crtc->y usage removal
v4: s/plane/i9xx_plane/ etc. (James)

Cc: James Ausmus <james.ausmus@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-9-ville.syrjala@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Stop using the old for_each_intel_plane_in_state() type iteration
macro and replace it with for_each_new_intel_plane_in_state().
And similarly replace drm_atomic_get_existing_crtc_state() with
intel_atomic_get_new_crtc_state(). Switch over to intel_ types
as well to make the code less cluttered.

v2: s/plane/i9xx_plane/ etc. (James)

Cc: James Ausmus <james.ausmus@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-8-ville.syrjala@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

The only relevant difference between i9xx_get_initial_plane_config() and
ironlake_get_initial_plane_config() is the HSW/BDW TILEOFF handling.
Add that to i9xx_get_initial_plane_config() and nuke
ironlake_get_initial_plane_config().

v2: s/plane/i9xx_plane/ etc. (James)

Cc: James Ausmus <james.ausmus@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-7-ville.syrjala@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Use enum pipe, enum plane_id, and enum i9xx_plane_id consistently in the
initial framebuffe readout.

v2: Use old_plane_id in the ilk code
v3: s/old_plane_id/i9xx_plane_id/ (Daniel)
v4: Rebase due to GLK/CNL PLANE_COLOR_CTL alpha stuff
v5: s/plane/i9xx_plane/ etc. (James)

Cc: James Ausmus <james.ausmus@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-6-ville.syrjala@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Rename enum plane to enum i9xx_plane_id to make it clear that it only
applies to pre-SKL platforms.

enum i9xx_plane_id is a global identifier, whereas enum plane_id is
per-pipe. We need the old global identifier to index the primary plane
(and the pre-g4x sprite C if we ever expose it) registers on pre-SKL
platforms.

v2: Reorder patches
v3: s/old_plane_id/i9xx_plane_id/ (Daniel)
    Pimp the commit message a bit
    Note that i9xx_plane_id doesn't apply to SKL+
v4: Rebase due to power domain handling in plane readout
v5: Rebase due to crtc->dspaddr_offset removal
v6: s/plane/i9xx_plane/ etc. (James)

Cc: James Ausmus <james.ausmus@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-4-ville.syrjala@linux.intel.comReviewed-by: NJames Ausmus <james.ausmus@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Unify the plane disabling during state readout by pulling the code into
a new helper intel_plane_disable_noatomic(). We'll also read out the
state of all planes, so that we know which planes really need to be
diabled.

Additonally we change the plane<->pipe mapping sanitation to work by
simply disabling the offending planes instead of entire pipes. And
we do it before we otherwise sanitize the crtcs, which means we don't
have to worry about misassigned planes during crtc sanitation anymore.

v2: Reoder patches to not depend on enum old_plane_id
v3: s/for_each_pipe/for_each_intel_crtc/

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alex Villacís Lasso <alexvillacislasso@hotmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103223Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NThierry Reding <thierry.reding@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-3-ville.syrjala@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Add a .get_hw_state() method for planes, returning true or false
depending on whether the plane is enabled. Use it to rewrite the
plane enabled/disabled asserts in platform agnostic fashion.

We do lose the pre-gen4 plane<->pipe mapping checks, but since we're
supposed sanitize that anyway it doesn't really matter.

v2: Reoder patches to not depend on enum old_plane_id
    Just call assert_plane_disabled() from assert_planes_disabled()
v3: Deal with disabled power wells in .get_hw_state()
v4: Rebase due skl primary plane code removal

Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alex Villacís Lasso <alexvillacislasso@hotmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v2
Tested-by: Thierry Reding <thierry.reding@gmail.com> #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20171117191917.11506-2-ville.syrjala@linux.intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Changes since v1:
- Only pass crtc_state, not crtc.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-8-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

The firmware may have set up the pipe correctly, but the FIFO
underrun and CRC interrupts are likely not enabled.

This resulted in debugfs_test.read_all_entries failing on haswell,
because of a timeout when reading the crc debugfs entry.

Solve this by enabling FIFO underrun reporting after the initial
fastset, which lets interrupts be generated as expected.

Changes since v1:
- Always enable CPU FIFO underrun reporting for >GEN2,
  and handle GEN2 correctly.
Changes since v2:
- Remove unneeded HAS_DDI, simplify GEN2 case.
Changes since v3:
- Use intel_crtc_pch_transcoder to determine pch transcoder for underruns. (Ville)
- Remove crtc->config dereference in intel_crtc_pch_transcoder. (Ville)

Testcase: debugfs_test.read_all_entries
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113144043.58658-1-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Avoid touching PIPECONF in intel_sanitize_crtc() unless the pipe is
actually on. Should cure some unclaimed register accesses during reset,
as we are rather cavalier in our approach to powerdomain management.

We don't have to sanitize this if the pipe is off since we will
overwrite the frame start delay anyway when turning the pipe on.

v2: Amended commit message to implicate the reset path (Chris)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102249Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171115200442.15051-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Display is not sending a PMRsp when a PMReq is received
at the same time that all planes are turned off.
State machine in the dcprunit is stuck in the WAIT4DONE
state which means that there is no fill_done.

WA: disable arbiter clock gating, set bit [27] of 0x46530

v2: As Ville pointed out, based on the description the issue
    can happen when disabling the planes, similar to
    WaRsPkgCStateDisplayPMReq:hsw
    Also description of the issue was updated on commit
    message to make it more clear that we need this
    earlier.
v3: Restore comment about possibility to system hang
    to where we are sure about it, without speculation. (Ville).
v4: Remove doubled sob. Actually do v3 changes :/

Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
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/20171111000319.5040-1-rodrigo.vivi@intel.com

Since GLK, some plane configuration settings have moved to the
PLANE_COLOR_CTL register. Refactor handling of the register to work like
PLANE_CTL. This also allows us to fix the set/read of the plane Alpha
Mode for GLK+.

v2: Adjust ordering of platform checks to be newest->oldest, drop
redundant comment about alpha blending. (Ville)

v3: Move Alpha Mode bits out of skl_plane_ctl_format into
skl_plane_ctl_alpha, and drop glk_plane_ctl_format, drop initialization
of state->color_ctl on platforms that don't use it, and drop color_ctl
local var. (Ville)

v4: Consolidate skl_plane_ctl_format switch statement on formats that
return the same settings. (Ville)
Signed-off-by: NJames Ausmus <james.ausmus@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171113181128.2926-1-james.ausmus@intel.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Some parameters use CHECK_BOOL, but should really use
CHECK_BOOL_INCOMPLETE. We cannot currently check whether
the inherited infoframes and audio are set up correctly.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-4-maarten.lankhorst@linux.intel.com
[mlankhorst: Add danvet's comment about why this is needed.]
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add PIPE_CONF_CHECK_BOOL for boolean options, which are printed with yesno.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-3-maarten.lankhorst@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The flag just tells us IPS can be enabled, if the primary plane
is not enabled it means IPS might not be. This never triggered
in CI because we don't have a haswell ULT there, but can be
reproduced easily with kms_atomic_transitions.plane-all-modeset-transition
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-2-maarten.lankhorst@linux.intel.com
[mlankhorst: Remove from haswell_get_pipe_config too. (danvet)]
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We no longer use intel_crtc->wm.active for watermarks any more,
which was incorrect. But this uncovered a bug in sanitize_watermarks(),
which meant that we wrote the correct watermarks, but the next
update would still use the wrong hw watermarks for calculating.
This caused all further updates to fail with -EINVAL and the
log would reveal an error like the one below:

[   10.043902] [drm:ilk_validate_wm_level.part.8 [i915]] Sprite WM0 too large 56 (max 0)
[   10.043960] [drm:ilk_validate_pipe_wm [i915]] LP0 watermark invalid
[   10.044030] [drm:intel_crtc_atomic_check [i915]] No valid intermediate pipe watermarks are possible
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: b6b178a7 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.")
Cc: stable@vger.kernel.org #v4.8+
Link: https://patchwork.freedesktop.org/patch/msgid/20171110113503.16253-1-maarten.lankhorst@linux.intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

intel_modeset_gem_init() now only sets up the legacy overlay, so let's
remove the function and call the setup directly during driver load. This
should help us find a better point in the initialisation sequence for it
later.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-5-chris@chris-wilson.co.uk

Despite its name intel_init_clock_gating applies both display clock gating
workarounds; GT mmio workarounds and the occasional GT power context
workaround. Worse, sometimes it includes a context register workaround
which we need to apply before we record the default HW state for all
contexts.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-4-chris@chris-wilson.co.uk

GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110142634.10551-3-chris@chris-wilson.co.uk

Remove intel_digital_port->port and replace its users with
intel_encoder->port. intel_encoder->port is a superset of
intel_digital_port->port, and it works correctly even for
MST encoders.

v2: Eliminate a few dp_to_dig_port()->base.port cases too (DK)

Performed with cocci:
@@
@@
struct intel_digital_port {
       ...
-       enum port port;
       ...
}

@@
struct intel_digital_port *D;
expression E;
@@
- D->port = E;

@@
struct intel_digital_port *D;
@@
- D->port
+ D->base.port

@
expression E;
@@
(
- dp_to_dig_port(E)->port
+ dp_to_dig_port(E)->base.port
|
- enc_to_dig_port(E)->port
+ to_intel_encoder(E)->port
)

@@
expression E;
@@
- to_intel_encoder(&E->base)
+ E

@@
struct intel_digital_port *D;
identifier I, M;
@@
  I = &D->base
<...
(
- D->base.M
+ I->M
|
- &D->base
+ I
)
...>

@@
identifier D;
expression E;
identifier M;
@@
 D = enc_to_dig_port(&E->base)
<...
(
- D->base.M
+ E->M
|
- &D->base
+ E
)
...>

@@
identifier D, DP;
expression E;
identifier M;
@@
 DP = enc_to_intel_dp(&E->base)
<...
(
- dp_to_dig_port(DP)->base.M
+ E->M
|
- &dp_to_dig_port(DP)->base
+ E
)
...>

@@
expression E;
identifier M;
@@
(
- enc_to_dig_port(&E->base)->base.M
+ E->M
|
- enc_to_dig_port(&E->base)->base
+ E
|
- enc_to_mst(&E->base)->primary->base.port
+ E->port
)

@@
expression E;
identifier D;
@@
- struct intel_digital_port *D = E;
... when != D

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: NDhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Acked-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/20171109152434.32074-1-ville.syrjala@linux.intel.com

Apparently setting up a bunch of GT registers before we've properly
initialized the rest of the GT hardware leads to these setting being
lost. So looks like I broke HSW with commit b7048ea1 ("drm/i915:
Do .init_clock_gating() earlier to avoid it clobbering watermarks")
by doing init_clock_gating() too early. This should actually affect
other platforms as well, but apparently not to such a great degree.

What I was ultimately after in that commit was to move the
ilk_init_lp_watermarks() call earlier. So let's undo the damage and
move init_clock_gating() back to where it was, and call
ilk_init_lp_watermarks() just before the watermark state readout.

This highlights how fragile and messed up our init order really is.
I wonder why we even initialize the display before gem. The opposite
order would make much more sense to me...

v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must
    be done before all planes might get disabled.

Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reported-by: NMark Janes <mark.a.janes@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549
Fixes: b7048ea1 ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks")
References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.htmlSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.syrjala@linux.intel.comTested-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit f72b84c6)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Apparently setting up a bunch of GT registers before we've properly
initialized the rest of the GT hardware leads to these setting being
lost. So looks like I broke HSW with commit b7048ea1 ("drm/i915:
Do .init_clock_gating() earlier to avoid it clobbering watermarks")
by doing init_clock_gating() too early. This should actually affect
other platforms as well, but apparently not to such a great degree.

What I was ultimately after in that commit was to move the
ilk_init_lp_watermarks() call earlier. So let's undo the damage and
move init_clock_gating() back to where it was, and call
ilk_init_lp_watermarks() just before the watermark state readout.

This highlights how fragile and messed up our init order really is.
I wonder why we even initialize the display before gem. The opposite
order would make much more sense to me...

v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must
    be done before all planes might get disabled.

Cc: stable@vger.kernel.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mark Janes <mark.a.janes@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reported-by: NMark Janes <mark.a.janes@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549
Fixes: b7048ea1 ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks")
References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.htmlSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.syrjala@linux.intel.comTested-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

During intel_atomic_check(), we do not take the intel_runtime_pm_get()
wakeref and so should do the atomic modeset precalculations without
referring to the HW. However, on Ironlake we see

<7>[   23.487557] [drm:intel_atomic_check [i915]] [CONNECTOR:47:VGA-1] checking for sink bpp constrains
<7>[   23.487615] [drm:intel_atomic_check [i915]] clamping display bpp (was 36) to default limit of 24
<4>[   23.487621] RPM wakelock ref not held during HW access
<4>[   23.487652] ------------[ cut here ]------------
<4>[   23.487697] WARNING: CPU: 0 PID: 1343 at drivers/gpu/drm/i915/intel_drv.h:1813 gen5_read32+0x183/0x200 [i915]
<4>[   23.487701] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich e1000e mei_me ptp mei pps_core prime_numbers
<4>[   23.487784] CPU: 0 PID: 1343 Comm: debugfs_test Tainted: G        W       4.14.0-rc7-CI-Trybot_1378+ #1
<4>[   23.487788] Hardware name: Hewlett-Packard HP Compaq 8100 Elite SFF PC/304Ah, BIOS 786H1 v01.13 07/14/2011
<4>[   23.487793] task: ffff8801f90aa6c0 task.stack: ffffc900013ec000
<4>[   23.487838] RIP: 0010:gen5_read32+0x183/0x200 [i915]
<4>[   23.487842] RSP: 0018:ffffc900013efb58 EFLAGS: 00010292
<4>[   23.487849] RAX: 000000000000002a RBX: ffff880205c00000 RCX: 0000000000000006
<4>[   23.487854] RDX: 000000000000140a RSI: ffffffff81d0eb14 RDI: ffffffff81cc26f6
<4>[   23.487857] RBP: ffffc900013efb80 R08: ffff8801f90aaff8 R09: 0000000000000000
<4>[   23.487861] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
<4>[   23.487865] R13: 0000000000046000 R14: ffff88020ffaba78 R15: ffff88020b109bf8
<4>[   23.487870] FS:  00007f53b5e40a40(0000) GS:ffff88021bc00000(0000) knlGS:0000000000000000
<4>[   23.487874] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[   23.487878] CR2: 000055e41900c0e8 CR3: 00000001fa0d6005 CR4: 00000000000206f0
<4>[   23.487882] Call Trace:
<4>[   23.487931]  intel_atomic_check+0x745/0x1290 [i915]
<4>[   23.487948]  drm_atomic_check_only+0x459/0x560
<4>[   23.487956]  ? drm_atomic_set_crtc_for_connector+0xc9/0x100
<4>[   23.488025]  drm_atomic_commit+0x18/0x50
<4>[   23.488035]  restore_fbdev_mode_atomic+0x190/0x1f0
<4>[   23.488059]  restore_fbdev_mode+0x32/0x120
<4>[   23.488072]  drm_fb_helper_restore_fbdev_mode_unlocked+0x50/0xa0
<4>[   23.488139]  intel_fbdev_restore_mode+0x34/0x90 [i915]
<4>[   23.488194]  i915_driver_lastclose+0xe/0x10 [i915]
<4>[   23.488208]  drm_lastclose+0x39/0xf0
<4>[   23.488219]  drm_release+0x30c/0x3c0
<4>[   23.488236]  __fput+0xb9/0x200
<4>[   23.488252]  ____fput+0xe/0x10
<4>[   23.488264]  task_work_run+0x89/0xc0
<4>[   23.488278]  exit_to_usermode_loop+0x83/0x90
<4>[   23.488290]  syscall_return_slowpath+0xd0/0x110
<4>[   23.488304]  entry_SYSCALL_64_fastpath+0xaf/0xb1
<4>[   23.488312] RIP: 0033:0x7f53b4317560
<4>[   23.488320] RSP: 002b:00007ffca7e70748 EFLAGS: 00000246 ORIG_RAX: 0000000000000003
<4>[   23.488333] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00007f53b4317560
<4>[   23.488340] RDX: 0000000000000005 RSI: 00007ffca7e70640 RDI: 0000000000000004
<4>[   23.488347] RBP: 000055e417783900 R08: 000055e418f9e290 R09: 0000000000000000
<4>[   23.488356] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
<4>[   23.488363] R13: 00007f53b4302c40 R14: 0000000000000000 R15: 0000000000000000
<4>[   23.488384] Code: b5 f2 f2 e0 0f ff e9 c5 fe ff ff 80 3d 0e 4b 10 00 00 0f 85 c6 fe ff ff 48 c7 c7 30 73 29 a0 c6 05 fa 4a 10 00 01 e8 8e f2 f2 e0 <0f> ff e9 ac fe ff ff e8 51 9d f3 e0 85 c0 0f 85 01 ff ff ff 48
<4>[   23.488780] ---[ end trace 6bc72ce7f1596190 ]---
<7>[   23.488844] [drm:intel_atomic_check [i915]] checking fdi config on pipe A, lanes 1
<7>[   23.488911] [drm:intel_atomic_check [i915]] hw max bpp: 36, pipe bpp: 24, dithering: 0

due to intel_fdi_link_freq() poking at FDI_PLL_BIOS_0. Avoid this by
recording the fdi pll frequency during device initiailisation.

v2: Also extract the static FDI PLL frequencies for Sandybridge and
Ivybridge.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171107214713.18704-1-chris@chris-wilson.co.ukReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Currently the DDI encoder->type will change at runtime depending on
what kind of hotplugs we've processed. That's quite bad since we can't
really trust that that current value of encoder->type actually matches
the type of signal we're trying to drive through it.

Let's eliminate that problem by declaring that non-eDP DDI port will
always have the encoder type as INTEL_OUTPUT_DDI. This means the code
can no longer try to distinguish DP vs. HDMI based on encoder->type.
We'll leave eDP as INTEL_OUTPUT_EDP, since it'll never change and
there's a bunch of code that relies on that value to identify eDP
encoders.

We'll introduce a new encoder .compute_output_type() hook. This allows
us to compute the full output_types before any encoder .compute_config()
hooks get called, thus those hooks can rely on output_types being
correct, which is useful for cloning on oldr platforms. For now we'll
just look at the connector type and pick the correct mode based on that.
In the future the new hook could be used to implement dynamic switching
between LS and PCON modes for LSPCON.

v2: Fix BXT/GLK PPS explosion with DSI/MST encoders
v3: Avoid the PPS warn on pure HDMI/DVI DDI encoders by checking dp.output_reg
v4: Rebase
v5: Populate output_types in .get_config() rather than in the caller
v5: Split out populating output_types in .get_config() (Maarten)

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-3-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Rather than having the caller of .get_config() set output_types based on
encoder->type, let's just have .get_config() itself populate
output_types. This way we are isolated from encoder->type, which won't
be useable for this purpose anyway soon (at least for DDI encoders).

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171027193128.14483-2-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

During modeset cleanup on driver unload we may have a pending
hotplug work. This needs to be canceled early during the teardown
so that it does not fire after we have freed the connector.
We do this after drm_kms_helper_poll_fini(dev) since this might
trigger modeset retry work due to link retrain and before
intel_fbdev_fini() since this work requires the lock from fbdev.

If this is not done we may see something like:
DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock))
 ------------[ cut here ]------------
 WARNING: CPU: 4 PID: 5010 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x4e/0x60
 Modules linked in: i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem ax88179_178
+a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core prime_numbers i2c_hid
+[last unloaded: snd_hda_intel]
 CPU: 4 PID: 5010 Comm: drv_module_relo Tainted: G     U          4.14.0-rc3-CI-CI_DRM_3186+ #1
 Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWX1.R00.X104.A03.1709140524 09/14/2017
 task: ffff8803c827aa40 task.stack: ffffc90000520000
 RIP: 0010:mutex_destroy+0x4e/0x60
 RSP: 0018:ffffc90000523d58 EFLAGS: 00010292
 RAX: 000000000000002a RBX: ffff88044fbef648 RCX: 0000000000000000
 RDX: 0000000080000001 RSI: 0000000000000001 RDI: ffffffff810f0cf0
 RBP: ffffc90000523d60 R08: 0000000000000001 R09: 0000000000000001
 R10: 000000000f21cb81 R11: 0000000000000000 R12: ffff88044f71efc8
 R13: ffffffffa02b3d20 R14: ffffffffa02b3d90 R15: ffff880459b29308
 FS:  00007f5df4d6e8c0(0000) GS:ffff88045d300000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000055ec51f00a18 CR3: 0000000451782006 CR4: 00000000003606e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  drm_fb_helper_fini+0xd9/0x130
  intel_fbdev_destroy+0x12/0x60 [i915]
  intel_fbdev_fini+0x28/0x30 [i915]
  intel_modeset_cleanup+0x45/0xa0 [i915]
  i915_driver_unload+0x92/0x180 [i915]
  i915_pci_remove+0x19/0x30 [i915]
  i915_driver_unload+0x92/0x180 [i915]
  i915_pci_remove+0x19/0x30 [i915]
  pci_device_remove+0x39/0xb0
  device_release_driver_internal+0x15d/0x220
  driver_detach+0x40/0x80
  bus_remove_driver+0x58/0xd0
  driver_unregister+0x2c/0x40
  pci_unregister_driver+0x36/0xb0
  i915_exit+0x1a/0x8b [i915]
  SyS_delete_module+0x18c/0x1e0
  entry_SYSCALL_64_fastpath+0x1c/0xb1
 RIP: 0033:0x7f5df3286287
 RSP: 002b:00007fff8e107cc8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
 RAX: ffffffffffffffda RBX: ffffffff81493a03 RCX: 00007f5df3286287
 RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000564c7be02e48
 RBP: ffffc90000523f88 R08: 0000000000000000 R09: 0000000000000080
 R10: 00007f5df4d6e8c0 R11: 0000000000000246 R12: 0000000000000000
 R13: 00007fff8e107eb0 R14: 0000000000000000 R15: 0000000000000000
Or a GPF like:

 general protection fault: 0000 [#1] PREEMPT SMP
 Modules linked in: i915(-) snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem ax88179_178
+a usbnet mii x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core prime_numbers i2c_hid
+[last unloaded: snd_hda_intel]
 CPU: 0 PID: 82 Comm: kworker/0:1 Tainted: G     U  W       4.14.0-rc3-CI-CI_DRM_3186+ #1
 Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWX1.R00.X104.A03.1709140524 09/14/2017
 Workqueue: events intel_dp_modeset_retry_work_fn [i915]
 task: ffff88045a5caa40 task.stack: ffffc90000378000
 RIP: 0010:drm_setup_crtcs+0x143/0xbf0
 RSP: 0018:ffffc9000037bd20 EFLAGS: 00010202
 RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000002 RCX: 0000000000000001
 RDX: 0000000000000001 RSI: 0000000000000780 RDI: 00000000ffffffff
 RBP: ffffc9000037bdb8 R08: 0000000000000001 R09: 0000000000000001
 R10: 0000000000000780 R11: 0000000000000000 R12: 0000000000000002
 R13: ffff88044fbef4e8 R14: 0000000000000780 R15: 0000000000000438
 FS:  0000000000000000(0000) GS:ffff88045d200000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000055ec51ee5168 CR3: 000000044c89d003 CR4: 00000000003606f0
 Call Trace:
  drm_fb_helper_hotplug_event.part.18+0x7e/0xc0
  drm_fb_helper_hotplug_event+0x1a/0x20
  intel_fbdev_output_poll_changed+0x1a/0x20 [i915]
  drm_kms_helper_hotplug_event+0x27/0x30
  intel_dp_modeset_retry_work_fn+0x77/0x80 [i915]
  process_one_work+0x233/0x660
  worker_thread+0x206/0x3b0
  kthread+0x152/0x190
  ? process_one_work+0x660/0x660
  ? kthread_create_on_node+0x40/0x40
  ret_from_fork+0x27/0x40
 Code: 06 00 00 45 8b 45 20 31 db 45 31 e4 45 85 c0 0f 8e 91 06 00 00 44 8b 75 94 44 8b 7d 90 49 8b 45 28 49 63 d4 44 89 f6 41 83 c4 01 <48> 8b 04 d0 44
+89 fa 48 8b 38 48 8b 87 a8 01 00 00 ff 50 20 01
 RIP: drm_setup_crtcs+0x143/0xbf0 RSP: ffffc9000037bd20
 ---[ end trace 08901ff1a77d30c7 ]---

v2:
* Rename it to intel_hpd_poll_fini() and call drm_kms_helper_fini() inside it
as the first step before cancel work (Chris Wilson)
* Add GPF trace in commit message and make the function static (Maarten Lankhorst)
Suggested-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Fixes: 9301397a ("drm/i915: Implement Link Rate fallback on Link training failure")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tony Cheng <tony.cheng@amd.com>
Cc: Harry Wentland <Harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1509054720-25325-1-git-send-email-manasi.d.navare@intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

This is heavily based on a initial patch provided by Ville
plus all changes provided later by Ander.

As Geminilake, Cannonlake also supports 2 pixels per clock.

Different from Geminilake we are not implementing the 99% Wa.
But we can revisit that decision later if we find out
any limitation on later CNL SKUs.

v2: Rebase on top of commit 'd305e061 ("drm/i915: Track
minimum acceptable cdclk instead of "minimum dotclock")'

v3: When fixing HDMI on CNL I noticed that I missed to convert
    back the doubled pixel rate to cdclk.

Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003223142.26264-1-rodrigo.vivi@intel.com

WARN if the cdclk state doesn't match what we expect after programming.
And let's remove the WARN from bdw_set_cdclk() that's trying to achieve
the same thing in a more limite fashion.

Also take the opportunity to refactor the code to use a common function
for dumping out a cdclk state.

Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-11-ville.syrjala@linux.intel.comReviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

On CNL we may need to bump up the system agent voltage not only due
to CDCLK but also when driving DDI port with a sufficiently high clock.
To that end start tracking the minimum acceptable voltage for each crtc.
We do the tracking via crtcs because we don't have any kind of encoder
state. Also there's no downside to doing it this way, and it matches how
we track cdclk requirements on account of pixel rate.

v2: Allow disabled crtcs to use the min voltage
    Add IS_CNL check to intel_ddi_compute_min_voltage() since
    we're using CNL specific values there
    s/intel_compute_min_voltage/cnl_compute_min_voltage/ since
    the function makes hw specific assumptions about the voltage
    values
v3: Drop the test hack leftovers from skl_modeset_calc_cdclk()
v4: s/voltage/voltage_level/ (Rodrigo)
    Replace DPLL DVFS FIXMEs with an explanation why we don't
    do anything there (Rodrigo)

Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-9-ville.syrjala@linux.intel.com

For CNL we'll need to start considering the port clocks when we select
the voltage level for the system agent. To that end start tracking the
voltage in the cdclk state (since that already has to adjust it).

v2: s/voltage/voltage_level/ (Rodrigo)

Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171024095216.1638-3-ville.syrjala@linux.intel.com

They're unused and unsupported. Leave the reduced_clock pointers in
place still, should they prove useful later on.

v2: go from nuking DDI lowfreq_avail to nuking it entirely (Ville)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171017140234.20677-1-jani.nikula@intel.com

Don't handle skylake primary plane separately as it is similar
plane as the others.
Signed-off-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1508270891-22186-5-git-send-email-juhapekka.heikkila@gmail.com