FBC and double wide pipe are mutually exclusive. Disable FBC when
we have to resort to double wide.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-20-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Rename the 'params' to just fbc state.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-19-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Currently we track the FBC plane as a pointer under intel_fbc
and also as a i9xx_plane_id under intel_fbc_state. Just store
the pointer once in the fbc state.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-18-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

fbc->state_cache has now become useless. We can simply update
the reg params directly from the plane/crtc states during
__intel_fbc_enable().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-17-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Currently a FIFO underrun just causes FBC to be deactivated,
and later checks then prevent it from being reactivated. We
can simpify our lives a bit by logically disabling FBC on
FIFO underruns. This avoids the funny intermediate state where
FBC is logically enabled but can't actually be activated.

v2: intel_wait_for_vblank() is no more
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-16-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Don't really see a good reason why we can't just do the vgpu and
modparam checks already in intel_fbc_check_plane().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-15-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

In the future we may have more than one FBC instance on some
platforms. So let's just allocate it dynamically. This also
lets us fully hide the implementation from prying eyes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-14-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

In order to better encapsulate the FBC implementation
introduce a small helper to do the plane<->FBC instance
association.

We'll also try to structure the plane init code such
that introducing multiple FBC instances will be easier
down the line.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-13-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

In order to encapsulate FBC harder let's just move the debugfs
stuff into intel_fbc.c.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-12-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>

The underrun code doesn't need to know any details about FBC, so
just pass in the whole device rather than a specific FBC instance.
We could make this a bit more fine grained by also passing in the
pipe to intel_fbc_handle_fifo_underrun_irq() and letting the FBC
code figure which FBC instance (if any) is active on said pipe.
But that seems a bit overkill for this so don't bother.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-11-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Use an early return to flatten most of __intel_fbc_pre_update().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-10-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

In the future we may have multiple planes on the same pipe
capable of using FBC. Prepare for that by tracking FBC usage
per-plane rather than per-crtc.

v2: s/intel_get_crtc_for_pipe/intel_crtc_for_pipe/
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-9-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Pass the FBC instance instead of the crtc to a bunch of places.

We also adjust intel_fbc_post_update() to do the
intel_fbc_get_reg_params() things instead of doing it from the lower
level function (which also gets called for front buffer tracking).
Nothing in there will change during front buffer updates.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-8-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

The FBC state cache and params are now nearly identical. Just
use the same structure for both.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-7-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

There isn't a good reason why we'd have to cache all this
plane state stuff in the FBC state. Instead we can just
pre-calculate what FBC will really need.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-6-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Move intel_fbc_override_cfb_stride() next to its cousins.
Helps with later patches.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-5-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

There's no need to store all this stuff in intel_fbc_state_cache.
Just check it all against the plane/crtc states and store only
what we need. Probably more should get nuked still, but this
is a start.

So what we'll do is:
- each plane will check its own state and update its local
  no_fbc_reason
- the per-plane no_fbc_reason (if any) then gets propagated
  to the cache->no_fbc_reason while doing the actual update
- fbc->no_fbc_reason gets updated in the end with either
  the value from the cache or directly from frontbuffer
  tracking

It's still a bit messy, but should hopefuly get cleaned up
more in the future. At least now we can observe each plane's
reasons for rejecting FBC now more consistently, and we don't
have so mcuh redundant state store all over the place.

v2: store no_fbc_reason per-plane instead of per-pipe
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-4-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

No reason to burden the caller with the details on how the minimum
compression limit is calculated, so just pass in the whole plane
state instead of just the cpp value.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-3-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

The ilk fbc watermark computation uses intel_fbc_is_active() which
is racy since we don't know whether FBC will be enabled or not at
some point. So let's just assume it will be if both HAS_FBC()
and the modparam agree.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-2-ville.syrjala@linux.intel.comReviewed-by: NMika Kahola <mika.kahola@intel.com>

Rename the PLANE_CUS_CTL Y plane selection bits to actually
say "Y plane".
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-6-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Rename the YUV byte order bits to be a bit more consistent.

v2: Deal with gvt
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-3-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Let's just stick to 32bit mmio accesses so we can get rid
of the bare "uncore" reg access in display code. The register
are defined as 32bit in the spec anyway.

We could define a 64bit "de" variant I suppose, but doesn't
really make much sense just for this one case, and when we
start to use the DSB for this stuff we'd also need another
64bit variant for that. Just easier to do 32bit always.

While at it we can reorder stuff a bit so that we write the
registers in order of increasing offset (more or less).
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-2-ville.syrjala@linux.intel.comReviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>

Break the dependency on i915_drv.h.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ee740f494e416d875e057c2eda585f4e66d65500.1638366969.git.jani.nikula@intel.com

Avoid looking into the guts of struct drm_i915_private in
headers. Again, converting an inline function to a macro is less than
ideal, but avoids having to pull in i915_drv.h just for the to_i915()
part.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ed6c43455d13c90ebfed442b196625af5e6ede88.1638366969.git.jani.nikula@intel.com

It's not the ideal location, but a better alternative than
i915_drv.h. The goal is to break the intel_display_types.h to i915_drv.h
dependency.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9f882eff78cdc6b28c18e73f5e53f57e413240dc.1638366969.git.jani.nikula@intel.com

This is far from ideal, but it reduces the i915_drv.h dependency from
intel_display_types.h. Maybe in the future we'll need a better split.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c6c60d9a8f6dcd1fa2f4b187000c5bb6843a1371.1638366969.git.jani.nikula@intel.com

Move fb functions where they belong, and un-inline to avoid looking into
struct drm_i915_private guts in header files.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4aa89f113ce6d840d62f50c989e2a1415483557c.1638366969.git.jani.nikula@intel.com

Move a number of crtc/pipe related functions to intel_crtc.[ch], and
un-inline to avoid looking into struct drm_i915_private guts in header
files.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c0be2adc4a7f7e72a47e12a57f742aaa42b813e6.1638366969.git.jani.nikula@intel.com

gt_pm selftest calculates engine ticks cycles and wall time
cycles by delta of respective engine elapsed TIMESTAMP and ktime
for period of 1000us.
It compares the engine ticks cycles with wall time cycles.

Disable local cpu interrupt so that interrupt handler does not
switch out the thread during measure_clocks() and prevent
miscalculation of engine tick cycles.

v2:
- nuke preempt_{disable,enable}, as disable_local_irq()
  disable the preemption. (Chris)

Cc: Chris P Wilson <chris.p.wilson@intel.com>
Cc: Badal Nilawar <badal.nilawar@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Signed-off-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: NAshutosh Dixit <ashutosh.dixit@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211130132005.6305-1-anshuman.gupta@intel.com

Extend existing workaround 1409120013 to DG2.

Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NMatt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116174818.2128062-6-matthew.d.roper@intel.com

This workaround is documented a bit strangely in the bspec; it's listed
as an A0 workaround, but the description clarifies that the workaround
is implicitly handled by the hardware and what the driver really needs
to do is program a chicken bit to reenable some internal behavior.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116174818.2128062-3-matthew.d.roper@intel.com

Commit cd0fcf5a ("drm/i915: rename DISP_STEPPING->DISPLAY_STEP and
GT_STEPPING->GT_STEP") renamed all platforms' display stepping tests,
but the DG2 patches were still in-flight at that time and did not
incorporate the new naming scheme.  Rename DG2's macro now for
consistency with other platforms.

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116174818.2128062-2-matthew.d.roper@intel.com

PLANE_CUS_CTL has a restriction of 4096 width even though
PLANE_SIZE and scaler size registers supports max 5120.
Take care of this restriction in max_width.

Without this patch, when 5k content is sent on HDR plane
with NV12 content, FIFO underrun is seen and screen blanks
out.

v2: Addressed review comments from Ville. Added separate
functions for max_width - for HDR and SDR

v3: Addressed review comments from Ville. Changed names of
HDR and SDR max_width functions to icl_hdr_plane_max_width
and icl_sdr_plane_max_width

v4: Fixed paranthesis alignment. No code change
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NVidya Srinivas <vidya.srinivas@intel.com>
[vsyrjala: Fix alignment]
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211202110836.17536-1-vidya.srinivas@intel.com

There are only three call sites remaining for
intel_wait_for_vblank(). Remove the function, and open code it to avoid
new users from showing up.

v2:
- Use intel_crtc_wait_for_next_vblank() (Ville)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/aabcda1208072a732d7796e6dacce37dca9bb843.1638366969.git.jani.nikula@intel.com

The "get" in the name implies reference counting, remove it. This also
makes the function conform to naming style.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/50359b38c0eabe262ff31c9ec35c97aa5dfb7fef.1638366969.git.jani.nikula@intel.com

The "get" in the name implies reference counting, remove it. This also
makes the function conform to naming style.
Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6105d0ff44efac3c999af6382e4b0729e251f1e1.1638366969.git.jani.nikula@intel.com

intel_wait_for_vblank() goes through a pipe to crtc lookup, while in
most cases we already have the crtc available. Avoid the extra lookups
by adding an intel_crtc based helper.

v2:
- Add intel_crtc_wait_for_next_vblank() helper (Ville)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/90cfbd8c3e79a742b0ee9e3ae75493acb0785dbb.1638366969.git.jani.nikula@intel.com

While working on supporting the Intel HDR backlight interface, I noticed
that there's a couple of laptops that will very rarely manage to boot up
without detecting Intel HDR backlight support - even though it's supported
on the system. One example of such a laptop is the Lenovo P17 1st
generation.

Following some investigation Ville Syrjälä did through the docs they have
available to them, they discovered that there's actually supposed to be a
30ms wait after writing the source OUI before we begin setting up the rest
of the backlight interface.

This seems to be correct, as adding this 30ms delay seems to have
completely fixed the probing issues I was previously seeing. So - let's
start performing a 30ms wait after writing the OUI, which we do in a manner
similar to how we keep track of PPS delays (e.g. record the timestamp of
the OUI write, and then wait for however many ms are left since that
timestamp right before we interact with the backlight) in order to avoid
waiting any longer then we need to. As well, this also avoids us performing
this delay on systems where we don't end up using the HDR backlight
interface.

V3:
* Move last_oui_write into intel_dp
V2:
* Move panel delays into intel_pps
Signed-off-by: NLyude Paul <lyude@redhat.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Fixes: 4a8d7990 ("drm/i915/dp: Enable Intel's HDR backlight interface (only SDR for now)")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org> # v5.12+
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211130212912.212044-1-lyude@redhat.com

The drm.mode_config state is not initialized in case of !HAS_DISPLAY
so taking the fb_lock and iterating the fb list won't work on those
platforms. Skip the suspend/resume with an explicit check for this.

Fixes: 9755f055 ("drm/i915: Restore memory mapping for DPT FBs across system suspend/resume")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211125171603.1775179-1-imre.deak@intel.com

Tile4 patch still needs an ack from userspace,
IGT tests and some essential fixes, related to
new .plane_caps attribute being added.

This reverts commit 3c542cfa.
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Acked-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124092355.16668-1-stanislav.lisovskiy@intel.com