drm_pci_alloc and drm_pci_free are just very thin wrappers around
dma_alloc_coherent, with a note that we should be removing them.
Furthermore since

commit de09d31d
Author: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Date:   Fri Jan 15 16:51:42 2016 -0800

    page-flags: define PG_reserved behavior on compound pages

    As far as I can see there's no users of PG_reserved on compound pages.
    Let's use PF_NO_COMPOUND here.

drm_pci_alloc has been declared broken since it mixes GFP_COMP and
SetPageReserved. Avoid this conflict by weaning ourselves off using the
abstraction and using the dma functions directly.

Reported-by: Taketo Kabe
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1027
Fixes: de09d31d ("page-flags: define PG_reserved behavior on compound pages")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: <stable@vger.kernel.org> # v4.5+
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20200202153934.3899472-1-chris@chris-wilson.co.uk

Let's add a copy of the active_pipes bitmask into the cdclk_state.
While this is duplicating a bit of information we may already
have elsewhere, I think it's worth it to decopule the cdclk stuff
from whatever else wants to use that bitmask. Also we want to get
rid of all the old ad-hoc global state which is what the current
bitmask is, so this removes one obstacle.

The one extra thing we have to remember is write locking the cdclk
state whenever the bitmask changes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-19-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Let's convert cdclk_state to be a proper global state. That allows
us to use the regular atomic old vs. new state accessor, hopefully
making the code less confusing.

We do have to deal with a few more error cases in case the cdclk
state duplication fails. But so be it.

v2: Fix new plane min_cdclk vs. old crtc min_cdclk check
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121140353.25997-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Extract a small helper to compute the active pipes bitmask
based on the old bitmask + the crtcs in the atomic state.
I want to decouple the cdclk state entirely from the current
global state so I want to track the active pipes also inside
the (to be introduced) full cdclk state.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-17-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Now that we have the more formal global state thing let's
use if for memory bandwidth tracking. No real difference
to the current private object usage since we already
tried to avoid taking the single serializing lock needlessly.
But since we're going to roll the global state out to more
things probably a good idea to unify the approaches a bit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-16-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Our current global state handling is pretty ad-hoc. Let's try to
make it better by imitating the standard drm core private object
approach.

The reason why we don't want to directly use the private objects
is locking; Each private object has its own lock so if we
introduce any global private objects we get serialized by that
single lock across all pipes. The global state apporoach instead
uses a read/write lock type of approach where each individual
crtc lock counts as a read lock, and grabbing all the crtc locks
allows one write access.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-15-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Move intel_atomic_state_free() next to its counterpart.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-13-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Use the same structure to store the cdclk state in both
intel_atomic_state and dev_priv. First step towards proper
old vs. new cdclk states.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-10-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Move all the old vs. new state shenanigans
into intel_set_cdclk_{pre,post}_plane_update() so that the caller
doesn't need to know any of it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-9-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

I want to have a higher level cdclk state object so let's rename
the current lower level thing to cdclk_config (because I lack
imagination).
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-8-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Move the min_cdclk[] and min_voltage_level[] arrays under the
rest of the cdclk state. And while at it provide a simple
helper (intel_cdclk_clear_state()) to clear the state during
the ww_mutex backoff dance.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-6-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Move the initial setup of state->{cdclk,min_cdclk[],min_voltage_level[]}
into intel_modeset_calc_cdclk(), and we'll move the counterparts into
intel_cdclk_swap_state(). This encapsulates the cdclk state much better.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-5-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

The linetime watermarks really have very little in common with the
plane watermarks. It looks to be cleaner to simply track them in
the crtc_state and program them from the normal modeset/fastset
paths.

The only dark cloud comes from the fact that the register is
still supposedly single buffered. So in theory it might still
need some form of two stage programming. Note that even though
HSW/BDWhave two stage programming we never computed any special
intermediate values for the linetime watermarks, and on SKL+
we don't even have the two stage stuff plugged in since everything
else is double buffered. So let's assume it's all fine and
continue doing what we've been doing.

Actually on HSW/BDW the value should not even change without
a full modeset since it doesn't account for pfit downscaling.
Thus only fastboot might be affected. But on SKL+ the pfit
scaling factor is take into consideration so the value may
change during any fastset.

As a bonus we'll plug this thing into the state
checker/dump now.

v2: Rebase due to bigjoiner prep
v2: Only compute ips linetime for IPS capable pipes.
    Bspec says the register values is ignored for other
    pipes, but in fact it can't even be written so the
    state checker becomes unhappy if we don't compute
    it as zero.

Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200120174728.21095-3-ville.syrjala@linux.intel.comReviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>

intel_dp_set_m_n() has a clear place in the DDI DP specific pre-enable
hook.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128162850.8660-3-jani.nikula@intel.com

To allow better flexibility for encoder specific code, push
intel_enable_pipe(), lpt_pch_enable() and intel_crtc_vblank_on() down to
the encoders from hsw_crtc_enable().

There's slight duplication, but also more clarity with the reduced
conditional statements.

Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128162850.8660-1-jani.nikula@intel.com

The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().

Replace them with the corresponding new display engine register
accessors intel_de_read(), intel_de_write(), intel_de_posting_read(),
intel_de_read_fw(), and intel_de_write_fw().

No functional changes.

Generated using the following semantic patch:

@@
expression REG, OFFSET;
@@
- I915_READ(REG)
+ intel_de_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- POSTING_READ(REG)
+ intel_de_posting_read(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE(REG, OFFSET)
+ intel_de_write(dev_priv, REG, OFFSET)

@@
expression REG;
@@
- I915_READ_FW(REG)
+ intel_de_read_fw(dev_priv, REG)

@@
expression REG, OFFSET;
@@
- I915_WRITE_FW(REG, OFFSET)
+ intel_de_write_fw(dev_priv, REG, OFFSET)
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/41b937d632edb59ca2ddecefd9ac613c2f998d58.1580149467.git.jani.nikula@intel.com

We've added more internal things that use modeset locks and
thus we need to be prepared for intel_atomic_check() grabbing
more locks than what our initial drm_modeset_lock_all_ctx()
took. So we're missing the backoff handling here.

Also drm_atomic_helper_duplicate_state() works against us
by clearing state->acquire_ctx in anticipation of
drm_atomic_helper_commit_duplicated_state() being used to
commit the state.

We could probably just reset acquire_ctx back, but instead
let's just rewrite the whole thing without using either of
those "helpers". There's also no need to add any connectors
to the state here since we just want the new watermarks
which don't depend on connectors.

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/20200122204329.2477-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Despite that during hw readout we seem to have scalers assigned
to pipes, then call atomic_setup_scalers, at the commit stage in
skl_update_scaler there is a check, that if we have fb src and
dest of same size, we stage freeing of that scaler.

However we don't update pfit.enabled flag then, which makes
the state inconsistent, which in turn triggers a WARN_ON
in skl_pfit_enable, because we have pfit enabled,
but no assigned scaler.

To me this looks weird that we kind of do the decision
to use or not use the scaler at skl_update_scaler stage
but not in intel_atomic_setup_scalers, moreover
not updating the whole state consistently.

This fix is to not free the scaler if we have pfit.enabled
flag set, so that the state is now consistent
and the warnings are gone.

v2: - Put pfit.enable check into crtc specific place
      (Ville Syrjälä)

Bugzilla: https://gitlab.freedesktop.org/drm/intel/issues/577Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: NTomi Sarvela <tomi.p.sarvela@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200124172301.16484-1-stanislav.lisovskiy@intel.com

drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'state' not described in 'intel_connector_needs_modeset'
drivers/gpu/drm/i915/display/intel_atomic.c:185: warning: Function parameter or member 'connector' not described in 'intel_connector_needs_modeset'

drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Function parameter or member 'state' not described in 'intel_fbc_enable'
drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'crtc_state' description in 'intel_fbc_enable'
drivers/gpu/drm/i915/display/intel_fbc.c:1124: warning: Excess function parameter 'plane_state' description in 'intel_fbc_enable'
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200126195654.2172937-1-chris@chris-wilson.co.uk

This patch converts various instances of the printk based logging macros
in drm/i915/display/intel_display.c to the new struct drm_device based
logging macros.
In some instances, this involves extracting the struct drm_i915_private
device from various intel types and using it in the macros.

v2: use correct variable name in assignment over variable type.
Signed-off-by: NWambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121214641.7262-1-wambui.karugax@gmail.com

A recent change in BSpec allow us to change EXTLINE while transcoder
is enabled so this allow us to change it even when doing the first
fastset after taking over previous hardware state set by BIOS.
BIOS don't enable PSR, so if sink supports PSR it will be enabled on
the first fastset, so moving the EXTLINE compute and set to PSR flows
allow us to simplfy a bunch of code.

This will save a lot of time in all the IGT tests that uses CRC, as
when PSR2 is enabled CRCs are not generated, so we switch to PSR1, so
the previous code would compute dc3co_exitline=0 causing a full
modeset that would shutdown pipe, enable and train link.

v2: only programming EXTLINE when DC3CO is enabled

BSpec: 49196
Cc: Imre Deak <imre.deak@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200122182617.18597-2-jose.souza@intel.com

In the port sync mode, for the master crtc, the master_transcoder is INVALID.
In that case since its value is -1, do not set the bit in the bitmask.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: d0eed154 ("drm/i915: Fix post-fastset modeset check for port sync")
Signed-off-by: NManasi Navare <manasi.d.navare@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200123002415.31478-1-manasi.d.navare@intel.com

We've already pinned the vma and fence by the time we try to
deal with implicit fencing. Properly unpin the vma and fence
if the fence setup fails instead of just bailing straight out
from .prepare_fb(). As can be expected
drm_atomic_helper_prepare_planes() will not call .cleanup_fb()
for the plane whose .prepare_fb() failed so we must do the
cleanup ourself.

v2: Rebase
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-6-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

intel_prepare_plane_fb() bails early if there is no fb (or rather
no obj, which is the same thing). intel_cleanup_plane_fb() does not.
This means the steps performed by intel_cleanup_plane_fb() aren't
balanced with with what was done intel_prepare_plane_fb() if there
is no fb for the plane. These hooks get called for every plane in
the state regardless of whether they have an fb or not.

Add a matching null obj check to intel_cleanup_plane_fb() to restore
the balance.

Note that intel_cleanup_plane_fb() has sufficient protections
already in place that the imbalance doesn't cause any real problems.
But having things be in balance seems nicer anyway, and might help
avoid some surprises in the future.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-5-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Drop the redundant intel_ prefix from our atomic state variable.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-4-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Switch over to using explicit old/new planes states instead of
digging the old state out via plane->state. The main issue is that
plane->state will point to the uapi state which we generally don't
even want to look at.

Also it sets a bad example as using plane->state during commit_tail()
would be a bug. Here we're still holding the modeset locks so it's
actually safe, but best not give people bad ideas.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-3-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Let's do the intel_plane_copy_uapi_to_hw_state() before we bail out
due to both old and new uapi.crtc being NULL. This will drop the
reference to the old hw.fb for planes that are transitioning from
being a slave plane to simply being disabled.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-2-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.

Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where intel_encoder struct pointer is available.

The conversion was done automatically with below coccinelle semantic
patch.

@@
identifier func, T;
@@
func(...) {
...
struct intel_encoder *T = ...;
<...
(
-WARN(
+drm_WARN(T->base.dev,
...)
|
-WARN_ON(
+drm_WARN_ON(T->base.dev,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T->base.dev,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T->base.dev,
...)
)
...>

}

@@
identifier func, T;
@@
func(struct intel_encoder *T,...) {
<...
(
-WARN(
+drm_WARN(T->base.dev,
...)
|
-WARN_ON(
+drm_WARN_ON(T->base.dev,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T->base.dev,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T->base.dev,
...)
)
...>

}

command: spatch --sp-file <script> --dir drivers/gpu/drm/i915/display \
					--linux-spacing --in-place
Signed-off-by: NPankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-5-pankaj.laxminarayan.bharadiya@intel.com

Replace the hand rolled intel_attached_dp() with the real thing.

@@
identifier F !~ "^intel_attached_dp$";
expression C;
@@
F(...)
{
<...
- enc_to_intel_dp(intel_attached_encoder(C))
+ intel_attached_dp(C)
...>
}

v2: Regenerated
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-8-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

It's easy to confuse the drm_connector->encoder (legacy state
adjusted during modeset) and intel_connector->encoder (the statically
(sans. MST) attached encoder of the connector). For the latter
let's use intel_attached_encoder() consistently.

@@
identifier F !~ "^intel_attached_encoder$";
struct intel_connector *C;
expression E;
@@
F(...)
{
<...
(
  C->encoder = E
|
- C->encoder
+ intel_attached_encoder(C)
)
...>
}

@@
identifier F !~ "^intel_attached_encoder$";
struct drm_connector *C;
expression E;
@@
F(...)
{
<...
(
  to_intel_connector(C)->encoder = E
|
- to_intel_connector(C)->encoder
+ intel_attached_encoder(to_intel_connector(C))
)
...>
}

v2: Regenerated
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-6-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

Let's not pollute the function scope with variables when they're
only needed inside some loops.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-5-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

sync_mode_slaves_mask is a bitmask so use PIPE_CONF_CHECK_X() for it
so we get the mismatch printed in hex instead of decimal.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-4-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Tested-by: NManasi Navare <manasi.d.navare@intel.com>

Let's use the pipe rather than the silly 'i' iterator from
for_each_oldnew_intel_crtc_in_state() for indexing the ddb
entries array. Maybe one day we can assume c99 and hide the
'i' entirely from sight.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-3-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Currently we don't call intel_crtc_prepare_cleared_state() for crtcs
that are going to be entirely disabled (uapi.enable==false). That
means such crtcs will leave stale junk lying around in their states
and we have to sprinkle hw.enable checks all over before we can
look at the states. Let's change that a bit so that we aways do
the state clearing, even for fully disabled crtcs.

Note that we still keep some parts of the old state (see
intel_crtc_prepare_cleared_state() for the details) so probably
can't trust things 100% when hw.enable==false. But at least there's
less chance now that we end up looking at stale junk.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-2-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

The post-fastset "does anyone still need a full modeset?" for
port sync looks busted. The outer loop bails out of a full modeset
is still needed by the current crtc, and then we skip forcing
a full modeset on the related crtcs. That's totally the opposite
of what we want.

The MST path has the logic mostly the other way around so it
looks correct. To fix the port sync case let's follow the MST
logic for both. So, if the current crtc already needs a modeset
we do nothing. otherwise we check if any of the related crtcs
needs a modeset, and if so we force a full modeset for the
current crtc.

And while at let's change the else if to a plain if to so
we don't have needless coupling between the MST and port sync
checks.

Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: 05a8e451 ("drm/i915/display: Use external dependency loop for port sync")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200115190813.17971-1-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Instead of dealing with the presence/absence of the primary
plane in the higher level pre/post plane update code let's
move all that into the fbc code itself. Now the higher level
code doesn't have to think about FBC details anymore.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-3-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever
it is present. We copy that from the master plane to the slave plane,
but we fail to copy the corresponding ggtt view. Thus when it comes time
to pin the slave plane's fb we use some stale ggtt view left over from
the last time the plane was used as a non-slave plane. If that previous
use involved 90/270 degree rotation or remapping we'll try to shuffle
the pages of the new fb around accordingingly. However the new
fb may be backed by a bo with less pages than what the ggtt view
rotation/remapped info requires, and so we we trip a GEM_BUG().

Steps to reproduce on icl:
1. plane 1: whatever
   plane 6: largish !NV12 fb + 90 degree rotation
2. plane 1: smallish NV12 fb
   plane 6: make invisible so it gets slaved to plane 1
3. GEM_BUG()

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/issues/951
Fixes: 1f594b20 ("drm/i915: Remove special case slave handling during hw programming, v3.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200110183228.8199-1-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Lots of enc_to_foo(&encoder->base) around. Simplify by passing
in the intel_encoder instead.

@find@
identifier F =~ "^enc_to_.*";
identifier E;
@@
F(struct drm_encoder *E)
{
...
}

@@
identifier find.F;
identifier find.E;
@@
F(
- struct drm_encoder *E
+ struct intel_encoder *encoder
  )
{
<...
- E
+ &encoder->base
...>
}

@@
identifier find.F;
expression E;
@@
- F(E)
+ F(to_intel_encoder(E))

@@
expression E;
@@
- to_intel_encoder(&E->base)
+ E
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-4-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>

Life is usually easier when we pass around intel_ types instead
of drm_ types. In this case it might not be, but I think being
consistent is a good thing anyway. Also some of this might get
cleaned up a bit more later as we keep propagating the intel_
types further.

@find@
identifier F =~ "^intel_attached_.*";
identifier C;
@@
F(struct drm_connector *C)
{
...
}

@@
identifier find.F;
identifier find.C;
@@
F(
- struct drm_connector *C
+ struct intel_connector *connector
  )
{
<...
- C
+ &connector->base
...>
}

@@
identifier find.F;
expression C;
@@
- F(C)
+ F(to_intel_connector(C))

@@
expression C;
@@
- to_intel_connector(&C->base)
+ C
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-3-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

This loop was added directly to intel_atomic_check() to be used by
all other features that have external pipe dependencies, so using it
and removing intel_atomic_check_synced_crtcs().

After this changes is_trans_port_sync_master() it not used anywhere,
so removing it.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200106142823.145260-1-jose.souza@intel.com