Whenever we are not able to get enough timeslots
for required PBN, let's try to allocate those
using DSC, just same way as we do for SST.

v2: Removed intel_dp_mst_dsc_compute_config and refactored
    intel_dp_dsc_compute_config to support timeslots as a
    parameter(Ville Syrjälä)

v3: - Rebased
    - Added a debug to see that we at least try reserving
      VCPI slots using DSC, because currently its not visible
      from the logs, thus making debugging more tricky.
    - Moved timeslots to numerator, where it should be.

v4: - Call drm_dp_mst_atomic_check already during link
      config computation, because we need to know already
      by this moment if uncompressed amount of VCPI slots
      needed can fit, otherwise we need to use DSC.
      (thanks to Vinod Govindapillai for pointing this out)

v5: - Put pipe_config->bigjoiner_pipes back to original
      condition in intel_dp_dsc_compute_config
      (don't remember when I lost it)

v6: - Removed unnecessary drm_dp_mst_atomic_check as it is
      now always called in a newly introduced
      intel_dp_mst_find_vcpi_slots_for_bpp function
      (Vinod Govindapillai)

Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-5-stanislav.lisovskiy@intel.com

We would be using almost same code to loop through bpps while calling
drm_dp_atomic_find_vcpi_slots - lets remove this duplication by
introducing a new function intel_dp_mst_find_vcpi_slots_for_bpp

v2: Fix pbn_div calculation - shouldn't matter if its DSC or not.
v3: FIx rebase conflict, constant_n no longer needed.

Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-4-stanislav.lisovskiy@intel.com

We currently always exit that bpp loop because
drm_dp_atomic_find_vcpi_slots doesn't care if we actually
can fit those or not.
I think that wasn't the initial intention here, especially when
we keep trying with lower bpps, we are supposed to keep trying
until we actually find some _working_ configuration, which isn't the
case here.
So added that drm_dp_mst_check here, so that we can make sure
that try all the bpps before we fail.

Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-3-stanislav.lisovskiy@intel.com

Adding DP DSC register definitions, we might need for further
DSC implementation, supporting MST and DP branch pass-through mode.

v2: - Fixed checkpatch comment warning
v3: - Removed function which is not yet used(Jani Nikula)

Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221101094222.22091-2-stanislav.lisovskiy@intel.com

Add a new sub-directory for things that aren't specifically about the
GPU and don't really belong in the i915 driver top level, but also don't
belong under any of the existing sub-directories either.

Name it "soc", and move the PCH and DRAM code there.

Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208142347.602726-1-jani.nikula@intel.com

We could use the dsb to load the LUT in any gamma mode, not just
when using the multi-segment mode. So replace the direct mmio
on all ilk+ paths with the wrapper.

There are a few functions (ilk_load_lut_10(), ivb_load_lut_10())
that would never be used on a platform with dsb so we could
skip those, but probably better to keep all this 100% consistent
to avoid people getting confused and copy pasting the wrong thing
when adding a new gamma mode.

The gmch stuff I left with direct mmio since those are fairly
distinct and shouldn't cause too much confusion. Although
I've also pondered about converting everything over to dsb
command buffers and just executing it on the CPU when the
real hw is not available. But dunno if that would actually
be a good idea or not...

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-13-ville.syrjala@linux.intel.com


Reviewed-by: Uma Shankar <uma.shankar@intel.com>

This reverts commit 99510e1a

.

DSB is now getting disabled locally in the color management
code so we don't need to apply this big hammer via the device
info (not that we have other DSB users at the moment).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-12-ville.syrjala@linux.intel.com


Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

The DSB has problem loading the LUTs at the moment. Some
of that is due to the palette anti collision logic, some
due to what seem real hw issues. Disable it the whole
thing locally in the color management code for now.

Note that we currently have this weird situation where on
adl+ we load parts of the LUT with DSB and parts with mmio.
That is due to the fact that only some parts of the LUT code
are using the DSB register write functions (ivb_load_lut_ext*()),
while the rest is using pure mmio (bdw_load_lut_10()). So now
we'll go back to pure mmio temporarily, until the DSB issues
get fixed (at which point we should be going for pure DSB).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-11-ville.syrjala@linux.intel.com


Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

We could have many different uses for the DSB(s) during a
single commit, so the current approach of passing the whole
crtc_state to the DSB functions is far too high level. Lower
the abstraction a little bit so each DSB user can decide where
to stick the command buffer/etc.

v2: Document the intel_dsb_prepare() return value (Ankit)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-10-ville.syrjala@linux.intel.com


Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

Since the color management code is the only user of the DSB
at the moment move the DSB prepare/cleanup there too. The
code has to anyway make decisions on whether to use the DSB
or not (and how to use it). Also we'll need a place where we
actually generate the DSB command buffer ahead of time rather
than the current situation where it gets generated too late
during the mmio programming of the hardware.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-9-ville.syrjala@linux.intel.com


Reviewed-by: Uma Shankar <uma.shankar@intel.com>

The use of DSB has to be done differently on a case by case basis.
So no way this kind of blind mmio fallback in the guts of the DSB
code will work properly. Move it at least one level up into the
LUT loading code. Not sure if this is the way we want do the
DSB vs. mmio handling in the end, but at least it's a bit
closer than what we had before.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-8-ville.syrjala@linux.intel.com


Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

Document the precision of the LUT "max" registers, just
so we don't have to dig through the spec so much.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-7-ville.syrjala@linux.intel.com


Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

Various gamma units on various platforms have some problems loading
the LUT index and auto-increment bit at the same time. We have to
do this in two steps. The first known case was the glk degamma LUT,
but at least ADL has another known case.

We're not going to suffer too badly from a couple of extra register
writes here, so let's just standardize on this practice for all
auto-increment LUT loads/reads. This way we never have to worry about
this specific issue again. And for good measure always reset the
index back to zero at the end (we already did this in a few places).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-6-ville.syrjala@linux.intel.com


Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

Use REG_BIT() & co. for the LUT index registers, and also
use the REG_FIELD_PREP() stuff a bit more consistently when
generating the values for said registers.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-5-ville.syrjala@linux.intel.com


Reviewed-by: Uma Shankar <uma.shankar@intel.com>

I've been frobbing the palette anti-collision logic bit
while playing around with DSB. Not sure we'll have real
use for this but let's define the bit anyways so I don't
have to carry it around locally.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-4-ville.syrjala@linux.intel.com


Reviewed-by: Uma Shankar <uma.shankar@intel.com>

Use REG_BIT() & co. for GAMMA_MODE bits.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-3-ville.syrjala@linux.intel.com


Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

s/GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED/GAMMA_MODE_MODE_12BIT_MULTI_SEG/
to make this thing slightly shorter.

Also fix up the platform comment while at it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123152638.20622-2-ville.syrjala@linux.intel.com


Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>

This patch introduces initial workarounds for mtl platform

v2: switch IS_MTL_DISPLAY_STEP to use IS_METEORLAKE from testing display
ver. (Tvrtko)

v3: clerical issues, extend 16015201720 to mtl. (MattR)

v4: make sure 16015201720 includes display 13. (MattR)

Bspec: 66624

Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221209220543.502047-1-matthew.s.atwood@intel.com

Always include both the encoder and PPS instance information
in the debug prints so that we know what piece of hardware
we're actually dealing with.

v2: Make sure pps is selected before debug prints/etc. in
    intel_pps_vdd_on_unlocked() on vlv/chv
    There is no pps on pipe C on chv
v3: Allow PPS=INVALID_PIPE for vlv/chv

Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221127155239.26973-1-ville.syrjala@linux.intel.com


Reviewed-by: Animesh Manna <animesh.manna@intel.com>

Stray spaces have snuck in where everything else uses tabs.

Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-9-ville.syrjala@linux.intel.com


Reviewed-by: Animesh Manna <animesh.manna@intel.com>

Use the consistent format when dumping out the PPS control/status
registers. Helps with pattern matching.

Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-8-ville.syrjala@linux.intel.com


Reviewed-by: Animesh Manna <animesh.manna@intel.com>

On ICP-ADP the pins used by the second PPS can be alternatively
muxed to some other function. In that case the second power
sequencer is unusable.

Unfortunately (on my ADL Thinkpad T14 gen3 at least) the
BIOS still likes to enable the VDD on the second PPS (due
to the VBT declaring the second bogus eDP panel) even when
not correctly muxed, so we need to deal with it somehow.
For now let's just initialize the PPS as normal, and then
use the normal eDP probe failure VDD off path to turn it off
(and release the wakeref the PPS init grabbed). The
alternative of just declaring that the platform has a single
PPS doesn't really work since it would cause the second eDP
probe to also try to use the first PPS and thus clobber the
state for the first (real) eDP panel.

Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-7-ville.syrjala@linux.intel.com


Reviewed-by: Animesh Manna <animesh.manna@intel.com>

On the PCH side the second PPS was introduced in ICP. Let's
make sure we examine both power sequencer on ICP+ as well.

Note that DG1/2 south block only has the single PPS, so need
to exclude the fake DG1/2 PCHs.

Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-6-ville.syrjala@linux.intel.com


Reviewed-by: Animesh Manna <animesh.manna@intel.com>

Currently on bxt/glk we just grab the power sequencer index from
the VBT data even though it may not have been parsed yet. That
could lead us to using the incorrect power sequencer during the
initial panel probe.

To avoid that let's try to read out the current state of the
power sequencer from the hardware. Unfortunately the power
sequencer no longer has anything in its registers to associate
it with the port, so the best we can do is just iterate through
the power sequencers and pick the first one. This should be
sufficient for single panel cases.

For the dual panel cases we probably need to go back to
parsing the VBT before the panel probe (and hope that
panel_type=0xff is never a thing in those cases). To that
end the code always prefers the VBT panel sequencer, if
available.

v2: Restructure a bit for upcoming icp+ dual PPS support

Cc: Animesh Manna <animesh.manna@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-5-ville.syrjala@linux.intel.com


Reviewed-by: Animesh Manna <animesh.manna@intel.com>

Restate the vlv_pipe_check() stuff in terms of PPS index
(rather than pipe, which it is on VLV/CHV) so that we can
reuse this same mechanim on other platforms as well.

Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-4-ville.syrjala@linux.intel.com

Lots of ADL machines out there with bogus VBTs that declare
two eDP child devices. In order for those to work we need to
figure out which power sequencer to use before we try the EDID
read. So let's do the panel VBT init early if we can, falling
back to the post-EDID init otherwise.

The post-EDID init panel_type=0xff approach of assuming the
power sequencer should already be enabled doesn't really work
with multiple eDP panels, and currently we just end up using
the same power sequencer for both eDP ports, which at least
confuses the wakeref tracking, and potentially also causes us
to toggle the VDD for the panel when we should not.

Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-3-ville.syrjala@linux.intel.com

Introduce a place where we can initialize connector->panel
after it's been allocated. We already have a intel_panel_init()
so had to get creative with the name and came up with
intel_panel_init_alloc().

Cc: Animesh Manna <animesh.manna@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125173156.31689-2-ville.syrjala@linux.intel.com

Remove an unnecessary include.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221208133638.478024-1-jani.nikula@intel.com

Bspecs has updated recently to remove the restriction to disable
DDI/Transcoder before setting PHY test pattern. This update is to
address PHY compliance test failures observed on a port with LTTPR.
The issue is that when Transc. is disabled, the main link signals fed
to LTTPR will be dropped invalidating link training, which will affect
the quality of the phy test pattern when the transcoder is enabled again.

v2: Update commit message (Clint)
v3: Add missing Signed-off in v2
v4: Update Bspec and commit message for pre-gen12 (Jani)

Bspec: 50482, 7555
Fixes: 8cdf7271

 ("drm/i915/dp: Program vswing, pre-emphasis, test-pattern")
Cc: Imre Deak <imre.deak@intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
CC: Jani Nikula <jani.nikula@intel.com>
Tested-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Reviewed-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Khaled Almahallawy <khaled.almahallawy@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221123220926.170034-1-khaled.almahallawy@intel.com

On mtl (at least) clearing the guardband bits in the same write
as the enable bit gets cleared seems to cause an immediate FIFO
underrun. Thus is seems that we need to first clear just the
enable bit, then wait for the VRR live status to indicate the
transcoder has exited VRR mode (this step is documented in Bspec
as well), and finally we can clear out the rest of the TRANS_VRR_CTL
for good measure.

I did this without any RMWs in case we want to toggle VRR on/off
via DSB in the future, and as we know DSB can't read registers.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221202134412.21943-5-ville.syrjala@linux.intel.com


Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

On mtl it looks like disabling VRR after the transcoder has
been disabled can cause the pipe/transcoder to get stuck
when re-enabled in non-vrr mode. Reversing the order seems to
help.

Bspec is extremely confused about the VRR enable/disable sequence
anyway, and this now more closely matches the non-modeset VRR
sequence, whereas the full modeset sequence still claims that
the original order is fine. But since we eventually want to toggle
VRR without a full modeset anyway this seems like the better order
to follow.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221202134412.21943-4-ville.syrjala@linux.intel.com


Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

We are miscalculating both the guardband value, and the resulting
vblank exit length on adl+. This means that our start of vblank
(double buffered register latch point) is incorrect, and we also
think that it's not where it actually is (hence vblank evasion/etc.
may not work properly). Fix up the calculations to match the real
hardware behaviour (as reverse engineered by intel_display_poller).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221202134412.21943-3-ville.syrjala@linux.intel.com


Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

Account for the framestart delay when calculating the "pipeline full"
value for icl/tgl vrr. This puts the start of vblank (ie. where the
double bufferd registers get latched) to a consistent place regardless
of what framestart delay value is used. framestart delay does not
change where start of vblank occurs in non-vrr mode and I can't see
any reason why we'd want different behaviour in vrr mode.

Currently framestart delay is always set to 1, and the hardcoded 4
scanlines in the code means we're currently delaying the start of
vblank by three extra lines. And with framestart delay set to 4 we'd
have no extra delay.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221202134412.21943-2-ville.syrjala@linux.intel.com


Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>

Despite what I claimed in commit c3c5dc1d
("drm/i915/audio: Do the vblank waits") the vblank
interrupts are in fact not enabled yet when we do the
audio enable sequence on VLV/CHV (all other platforms are
fine).

Reorder the enable sequence on VLV/CHV to match that of the
other platforms so that the audio enable happens after the
pipe has been enabled.

Fixes: c3c5dc1d

 ("drm/i915/audio: Do the vblank waits")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221207225219.29060-1-ville.syrjala@linux.intel.com


Reviewed-by: Jani Nikula <jani.nikula@intel.com>

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8c29f4f76c2163da309ead0bf48652024f134f11.1670433372.git.jani.nikula@intel.com

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4992661d93f8d5744e19408dc60ae49a5f2d597a.1670433372.git.jani.nikula@intel.com

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/588815fc60752b6470ee4067246698d478309fa1.1670433372.git.jani.nikula@intel.com

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/05690286d1521ec9c82d680122cca9a90a75b8dd.1670433372.git.jani.nikula@intel.com

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/262a0cf647b37e27a1c7776d3816e1b4ef959a91.1670433372.git.jani.nikula@intel.com

Avoid direct uncore use in display code.

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/bc144ab3565b10e71244cd09f72ce7df86f4b5c6.1670433372.git.jani.nikula@intel.com