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

Follow the convention of corresponding .h for .c.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122111504.223248-4-jani.nikula@intel.com

Follow the convention of corresponding .h for .c.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122111504.223248-3-jani.nikula@intel.com

Follow the convention of corresponding .h for .c.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122111504.223248-2-jani.nikula@intel.com

Follow the convention of corresponding .h for .c.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122111504.223248-1-jani.nikula@intel.com

TileF(Tile4 in bspec) format is 4K tile organized into
64B subtiles with same basic shape as for legacy TileY
which will be supported by Display13.

v2: - Fixed wrong case condition(Jani Nikula)
    - Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak)

v3: - s/I915_TILING_F/TILING_4/g
    - s/I915_FORMAT_MOD_F_TILED/I915_FORMAT_MOD_4_TILED/g
    - Removed unneeded fencing code

v4: - Rebased, fixed merge conflict with new table-oriented
      format modifier checking(Stan)
    - Replaced the rest of "Tile F" mentions to "Tile 4"(Stan)

v5: - Still had to remove some Tile F mentionings
    - Moved has_4tile from adlp to DG2(Ramalingam C)
    - Check specifically for DG2, but not the Display13(Imre)

v6: - Moved Tile4 associating struct for modifier/display to
      the beginning(Imre Deak)
    - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier
      checks(Imre Deak)
    - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12
      (Imre Deak)

v7: - Fixed display_ver to { 13, 13 }(Imre Deak)
    - Removed redundant newline(Imre Deak)
Reviewed-by: NImre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJuha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211122211420.31584-1-stanislav.lisovskiy@intel.com

Use forward declarations instead.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-5-jani.nikula@intel.com

Anything internal to the implementation should be hidden away. Move the
intel_display_power structs to the .c file.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-4-jani.nikula@intel.com

The debugfs should have no special privileges to look into the
implementation guts. Move the actual debug printing of power domains to
intel_display_power.c.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-3-jani.nikula@intel.com

Use forward declarations instead.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-2-jani.nikula@intel.com

Use forward declarations instead.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116171434.20516-1-jani.nikula@intel.com

Since I originally wrote these comments we decided to change our
definition of framestart_delay from 0-3 to 1-4. Adjust the comments
to match that new convention. The actual code was adjusted already.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211117183103.27418-3-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

Let's adjust the vblank evasion to account for the case where
a push has already been sent. In that case the vblank exit will start
at vmin vblank start (as opposed to vmax vblank start when no push
has been sent).

This should minimize the effects of the tiny race between sampling
the frame counter vs. intel_vrr_send_push() during the previous frame.
This will also be required if we want to do mailbox style updates with
vrr since then we'd definitely do multiple commits per frame. Currently
mailbox updates are only used by the legacy cursor, but we don't do
vrr push for those.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211117183103.27418-2-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

Moving the vrr push to happen before sampling the frame counter
was wrong. If we are already in vblank when the push is sent
the vblank exit will start immediately which causes the sampled
frame counter to correspond to the next frame instead of the current
frame.

So put things back into the original order (except we should
keep the vrr push within the irq disable section to avoid
pointless irq related delays here).

We'll just have to accept the tiny race that exists between
sampling the frame counter vs. vrr push. And let's at least
document said race properly in a comment.

I suppose we could try to minimize the race by sampling the frame
counter just before sending the push, but that would require
changing drm_crtc_arm_vblank_event() to accept a caller provided
vblank counter value, so leave it be for now. Another thing we
could do is change the vblank evasion to account for the case
where a push was already sent. That would anyway be required
for mailbox style updates. Currently mailbox updates are only
used by the legacy cursor, but we don't do a vrr push for those.

Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: 6f9976bd ("drm/i915: Do vrr push before sampling the frame counter")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211117183103.27418-1-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

In intel_dsi_get_config() double the pclk returned by foo_dsi_get_pclk()
for dual-link panels. This fixes the following WARN triggering:

 i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in pixel_rate (expected 235710, found 118056)
 i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.pipe_mode.crtc_clock (expected 235710, found 118056)
 i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in hw.adjusted_mode.crtc_clock (expected 235710, found 118056)
 i915 0000:00:02.0: [drm] *ERROR* [CRTC:51:pipe A] mismatch in port_clock (expected 235710, found 118056)
 ------------[ cut here ]------------
 pipe state doesn't match!
 WARNING: CPU: 3 PID: 136 at drivers/gpu/drm/i915/display/intel_display.c:9125 intel_display_finish_reset+0x1bd3/0x2050 [i915]
 ...

This has been tested on a Xiaomi Mi Pad 2 (with CHT x5-Z8500 SoC) tablet,
with a 1536x2048 dual-link DSI panel.

Note this fix was taken from icl_dsi.c which does the same in
its get_config().

Cc: Tsuchiya Yuto <kitakar@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211024155020.126328-1-hdegoede@redhat.com

After a non-blocking modeset on a TypeC port's CRTC - possibly blocked
later in drm_atomic_helper_wait_for_dependencies() - a fastset on the
same CRTC may copy the state of CRTC before this gets updated to reflect
the up-to-date DP-alt vs. TBT-alt TypeC mode DPLL used for the CRTC. In
this case after the first (non-blocking) commit completes enabling the
DPLL required for the up-to-date TypeC mode the following fastset will
update the CRTC state pointing to the wrong DPLL. A subsequent disabling
modeset will try to disable the wrong PLL, triggering a state checker
WARN (and leaving the DPLL which is actually used active for good).

Fix the above race by copying the DPLL state for fastset CRTCs from the
old CRTC state at the point where it's guaranteed to be up-to-date
already. This could be handled in the encoder's update_prepare() hook as
well, but that's a bigger change, which is better done as a follow-up.

v2: Copy dpll_hw_state as well. (Ville)

Testcase: igt/kms_busy/extended-modeset-hang-newfb-with-reset
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4308
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211115181121.156197-1-imre.deak@intel.com

v2: Fix the typo, move out the hardcoding from
    macro(Jani, Ville)

Fixes: f87c46c4 ("drm/i915/dsi/xelpd: Add WA to program LP to HS wakeup guardband")
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211019151435.20477-2-vandita.kulkarni@intel.com
(cherry picked from commit 6f07707f)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

This reverts commit 991d9557 ("drm/i915/tgl/dsi: Gate the ddi clocks
after pll mapping"). The Bspec was updated recently with the pll ungate
sequence similar to that of icl dsi enable sequence. Hence reverting.

Bspec: 49187
Fixes: 991d9557 ("drm/i915/tgl/dsi: Gate the ddi clocks after pll mapping")
Cc: <stable@vger.kernel.org> # v5.4+
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211109120428.15211-1-vandita.kulkarni@intel.com
(cherry picked from commit 4579509e)
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>

Fix the recently introduced 'make htmldocs' warnings:

$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/display/intel_fbc.c:635: warning: Excess function parameter 'i915' description in 'intel_fbc_is_active'
./drivers/gpu/drm/i915/display/intel_fbc.c:1638: warning: Excess function parameter 'i915' description in 'intel_fbc_handle_fifo_underrun_irq'
./drivers/gpu/drm/i915/display/intel_fbc.c:635: warning: Function parameter or member 'fbc' not described in 'intel_fbc_is_active'
./drivers/gpu/drm/i915/display/intel_fbc.c:635: warning: Excess function parameter 'i915' description in 'intel_fbc_is_active'
./drivers/gpu/drm/i915/display/intel_fbc.c:1638: warning: Function parameter or member 'fbc' not described in 'intel_fbc_handle_fifo_underrun_irq'
./drivers/gpu/drm/i915/display/intel_fbc.c:1638: warning: Excess function parameter 'i915' description in 'intel_fbc_handle_fifo_underrun_irq'

Fixes: e49a656b ("drm/i915/fbc: Start passing around intel_fbc")
Cc: Ville 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/20211115140549.27629-1-jani.nikula@intel.com

MIPI DSI transcoder cannot be in video mode to support any of the
display C states.

Bspec: 49195 (For DC*co DSI transcoders cannot be in video mode)
Bspec: 49193 (Hardware does not support DC5 or DC6 with MIPI DSI enabled)
Bspec: 49188 (desc of DSI_DCSTATE_CTL talks about cmd mode PM control

v2: Align to the power domain ordering (Jani)
    Add bspec references (Imre)
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211019151435.20477-4-vandita.kulkarni@intel.com

v2: Fix the typo, move out the hardcoding from
    macro(Jani, Ville)

Fixes: f87c46c4 ("drm/i915/dsi/xelpd: Add WA to program LP to HS wakeup guardband")
Signed-off-by: NVandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211019151435.20477-2-vandita.kulkarni@intel.com

Don't populate the read-only array states on the stack but instead it
static. Also makes the object code smaller.
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210915112702.12783-1-colin.king@canonical.com

When a plane with a multiplanar format is added to the state by
drm_atomic_add_affected_planes(), only the UV plane is
added, so a intel_atomic_get_new_plane_state() call to get the Y
plane state can return a null pointer.
To fix this, intel_atomic_get_plane_state() should be called and
the return needs to be checked for errors, as it could return a EAGAIN
as other atomic state could be holding the lock for the Y plane.

Other issue with the patch being fixed is that the Y plane is not
being committed to hardware because the corresponded plane bit is not
set in update_planes when UV and Y planes are added to the state by
drm_atomic_add_affected_planes().

Cc: Jouni Högander <jouni.hogander@intel.com>
Cc: Mika Kahola <mika.kahola@intel.com>
Fixes: 3809991f ("drm/i915/display: Add initial selective fetch support for biplanar formats")
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NJouni Högander <jouni.hogander@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211108213807.39865-1-jose.souza@intel.com

With multiple fbc instances we need to find the right one for each
plane. Rather than going looking for the right instance every time
let's just replace the has_fbc boolean with a pointer that gets us
there straight away.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-18-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

In preparation for multiple FBC instances start passing around
intel_fbc pointers rather than i915 pointers. And once there are
multiple of these we can't rely on container_of() to get back to
the i915, so we toss in a fbc->i915 pointer already.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-17-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Rename 'dev_priv' to 'i915' to match modern style.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-16-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Switch all the FBC1 registers over to REG_BTT()/etc.
And while at it add a few more registers/bits that
escaped the net previously.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-14-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

The FBC register defines are a mess:
- namespace changes between DPFC_, FBC_, and some platform
  specific prefix at a whim
- ilk+ reuses most g4x bits but still has some separate bit
  defines elsewhere
- it's not clear from the defines that the bit defines are
  shared

So let's clean it up:
- both g4x and ilk register share the same defines now
- only defines which conflict have a _PLATFORM suffix, everyone
  else just gets comments to indicate which platforms do what
- namespace is consistent DPFC_ now
- SNB system agent fence registers also get a consistent namespace
- REG_BIT() & co. for everything
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-13-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Just use a same mask for ivb/hsw as for bdw+. The extra bit
in the bdw mask is mbz on ivb/hsw anyway so this is just
pointless complexity.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-12-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Pull the direct FBC register frobbing out from the debugfs code
into the fbc code. Also add a vfunc for this so we don't need
extra platforms checks.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-11-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Eliminate the last if-ladder by pulling the CFB/LLB programming
into a vfunc as well.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-10-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

"gen7" in display code is not really sensible. We shall call
these things "ivb".
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-9-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Eliminate yet another if-ladder by adding .nuke() vfunc.

We also rename all *_recompress() stuff to *_nuke() since
that's the terminology the spec uses. Also "recompress"
is a bit confusing by perhaps implying that this triggers
an immediate recompression. Depending on the hardware that
may definitely not be the case, and in general we don't
specifically know when the hardware decides to compress.
So all we do is "nuke" the current compressed framebuffer
and leave it up to the hardware to recompress later if it
so chooses.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-8-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Replace the "if-ladders everywhere" approach with vfuncs.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-7-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Declutter the *_fbc_activate() functions by pulling all the
control register value computations into helpers.

I left the enable bit in *_fbc_activate() in the hopes of maybe
using the helpers in the *_fbc_deactivate() paths as well instead
of the current rmw approach. That won't be possible at least
quite yet since we clobber the fbc->params before deactivating
FBC so we could end up changing some of the values live, which
given FBC's lack of/poor double buffering would likely not go
so well.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-6-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Move the direct FBC status register reads from the debugfs code
behind an abstract api.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-5-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

No need to tiptoe around programming DPFC_FENCE_YOFF with
params->fence_y_offset vs. 0. If the fence is not enabled
it doesn't even matter what we program here.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-4-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

Declutter gen7_fbc_activate() by sucking the override
stride programming stuff into helpers.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-3-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

We have two identical copies of the snb+ system agent
CPU fence programming code. Extract into a helper.

Also there's no real point in insisting that we
program 0 into DPFC_CPU_FENCE_OFFSET when the fence is
disabled. So just always stick the computed Y offset there
whether or not the fence is actually used or not.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-2-ville.syrjala@linux.intel.comAcked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>

In Video Mode, if DSI transcoder is set to transmit packets
in LP Escape mode, screen flickering would be obseved when
brightness commands are continuously and quickly transmitted
to a panel.

The problem may be resolved by changing the mode to transmit
packets from Low Power to HS.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Signed-off-by: NWilliam Tseng <william.tseng@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211110010217.26759-1-william.tseng@intel.com