Turns out the DSB has trouble correctly loading the gamma LUT.
From a cursory look maybe like some entries do not load
properly, or they get loaded with some gibberish. Unfortunately
our current kms_color/etc. tests do not seem to catch this.

I had a brief look at the generated DSB batch and it looked
correct. Tried a few quick tricks like writing the index
register twice/etc. but didn't see any improvement.
Also tried switching to the 10bit gamma mode in case
there is yet another issue with the multi-segment mode, but
even the 10bit mode was showing issues.

Switching to mmio fixes all of it. I suppose one theory is that
maybe the DSB bangs on the LUT too quickly and it can't keep up
and instead some data either gets dropped or corrupted. To confirm
that someone should try to slow down the DSB's progress a bit.
Another thought was that maybe the LUT has crappy dual porting
and you get contention if you try to load it during active
scanout. But why then would the mmio path work, unless it's
just sufficiently slow?

Whatever the case, this is currently busted so let's disable
it until we get to the root of the problem.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3916Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211014181856.17581-2-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@intel.com>

All interpolated gamma modes including the icl+ multi segment
mode require non-decreasing entries for the interpolation to
work correctly. For some reason we're forgetting to declare
that for icl+. Let us do so.

References: https://gitlab.freedesktop.org/drm/intel/-/issues/3916Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211014181856.17581-1-ville.syrjala@linux.intel.comReviewed-by: NUma Shankar <uma.shankar@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

The intel_engine_create_virtual() function does not return NULL.  It
returns error pointers.

Fixes: e5e32171 ("drm/i915/guc: Connect UAPI to GuC multi-lrc interface")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211116114916.GB11936@kili

Add the i915_driver_ prefix to the switcheroo functions in
i915_driver.[ch].
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20211111101304.13094-3-jani.nikula@intel.com

As a name, "driver" is too generic and short to be easily located in a
file this size. Rename it to i915_drm_driver.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20211111101304.13094-2-jani.nikula@intel.com

This is more about trimming i915_drv.h than the renamed
i915_driver.[ch]. Split out i915_driver.[ch] out of i915_drv.h as a
feasible thing to do.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20211111101304.13094-1-jani.nikula@intel.com

s2idle and runtime pm puts the pci gfx device in D3Hot, ACPI runtime
monitors the pci tree,if it sees complete tree as D3Hot,it transitions
the device to D3Cold.But i915 do not have D3Cold support in S2idle or in
runtime pm. so disabling D3cold in above flows and its FIXME.

Added pci D3Cold enable/disable in s2idle and runtime suspend/resume
flows.
Signed-off-by: NTilak Tangudu <tilak.tangudu@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211115154054.3220476-1-tilak.tangudu@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

Don't include stuff on behalf of users if they're not strictly necessary
for the header.

Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7bcaa1684587b9b008d3c41468fb40e63c54fbc7.1636977089.git.jani.nikula@intel.com

When kernel.h is used in the headers it adds a lot into dependency hell,
especially when there are circular dependencies are involved.

Replace kernel.h inclusion with the list of what is really being used.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4d6a976459547407979f4b4c05a52785523e6bd8.1636977089.git.jani.nikula@intel.com

Only intel_gt.c and intel_ggtt.c need the interface.

Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/034f57db24d6936ac2e4e6830261d791240cdd79.1636977089.git.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

Update ADL_P device info to support DSI0, DSI1

v2: Re-define cpu_transcoder_mask only (Jani)
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-3-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>

In the case of FBC_LLC_READ_CTRL the "FBC" stands for
frame buffer _caching_, not frame buffer compression.
Move the register definition out from the middle of the
frame buffer compression register definitions. Let's
just stick it somewhere with similar looking register
offsets.

And while at it switch it over to REG_BIT().
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211104144520.22605-15-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

Currently we reset the whole PCON linkConfig DPCD to set the TMDS mode.
This also resets the Source control bit and HDMI link enable bit and
goes to autonomous mode of operation, which is seen to spoil the PCONs
internal state.

This patch avoids resetting the PCON link config register and sets only
the source control bit, with FRL Enable bit set to 0 (TMDS mode) in the
configuration DPCD. It then enables the HDMI Link Enable bit.

v2: Removed the redundant resetting of the bits as the buffer is already
initialized to 0. (Uma)
Updated comments and commit message.

v3: Rebase
Signed-off-by: NAnkit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: NUma Shankar <uma.shankar@intel.com>
Signed-off-by: NUma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211110072947.171659-3-ankit.k.nautiyal@intel.com