Normally we could be in a deep PkgC state all the way up to the
point when DSB starts its execution at the transcoders undelayed
vblank. The DSB will then have to wait for the hardware to
wake up before it can execute anything. This will waste a huge
chunk of the vblank time just waiting, and risks the DSB execution
spilling into the vertical active period. That will be very bad,
especially when programming the LUTs as the anti-collision logic
will cause DSB to corrupt LUT writes during vertical active.

To avoid these problems we can instruct the DSB to pre-wake the
display engine on a specific scanline so that everything will
be 100% ready to go when we hit the transcoder's undelayed vblank.

One annoyance is that the scanline is specified as just that,
a single scanline. So if we happen to start the DSB execution
after passing said scanline no DEwake will happen and we may drop
back into some PkgC state before reaching the transcoder's undelayed
vblank. To prevent that we'll use the "force DEwake" bit to manually
force the display engine to stay awake. We'll then have to clear
the force bit again after the DSB is done (the force bit remains
effective even when the DSB is otherwise disabled).

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


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

Add a helper to convert our idea of a scanline to the hw's idea
of the same scanline (ie. apply crtc->scanline_offset in reverse).
We'll need this to tell the DSB do stuff on a specific scanline.

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


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

The DSB code will want to know the maximum PkgC latency
it has to contend with. Add a helper to expose that
information.

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


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

We want to start the DSB execution from the transcoder's undelayed
vblank, so in order to guarantee atomicity with the all the other
mmio register writes we need to evade both vblanks.

Note that currently we don't add any vblank delay, so this is
effectively a nop. But in the future when we start to program
double buffered registers from the DSB we'll need to delay the
pipe's vblank to provide the register programming "window2"
for the DSB.

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


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

The DSB has problems writing the legacy LUT. The two workarounds
I've discoverted are:
- write each entry twice back to back
- use non-posted writes

Let's use non-posted writes as that seems a bit more standard.

TODO: measure which is faster

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


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

Loading LUTs with the DSB outside of vblank doesn't really
work due to the palette anti-collision logic. Apparently the
DSB register writes don't get stalled like CPU mmio writes
do and instead we end up corrupting the LUT entries. Disabling
the anti-collision logic would allow us to successfully load
the LUT outside of vblank, but presumably that risks the LUT
reads from the scanout (temporarily) getting corrupted data
from the LUT instead.

The anti-collision logic isn't active during vblank so that
is when we can successfully load the LUT with the DSB. That is
what we want to do anyway to avoid tearing.

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


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

Using the DSB for LUT loading during full modesets would require
some actual though. Let's just use mmio for the time being.

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


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

Writing specific transcoder registers (and as it turns out, the
legacy LUT as well) via DSB needs a magic sequence to emit
non-posted register writes. Add a helper for this.

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


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

Add a function for emitting masked register writes.

Note that the mask is implemented through byte enables,
so can only mask off aligned 8bit sets of bits.

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


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

Add a helper for emitting a number of DSB NOOPs commands.

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


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

Add some defines to specify what goes inside certain DSB
instructions.

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


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

Define all the DSB register bits so I don't have to look through
bspec to find them.

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


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

Avoid the locking overhead for DSB registers. We don't need the locks
and intel_dsb_commit() in particular needs to be called from the
vblank evade critical section and thus needs to be fast.

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


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

Avoid including the world from headers when forward declarations
suffice.

Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230921155325.3851197-1-jani.nikula@intel.com

Convert aux_ch_name() to a helper that prints a string to a caller
provided buffer, and use it to get more consistent aux channel
debugs. Now that all users of aux_ch_name() are in intel_dp_aux.c, we
can make it static too.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230922105645.3991066-1-jani.nikula@intel.com

Starting with Xe_LP+, GFX_MSTR_IRQ contains status bits that have W1C
behavior. If we do not properly reset them, we would miss delivery of
interrupts if a pending bit is set when enabling IRQs.

As an example, the display part of our probe routine contains paths
where we wait for vblank interrupts. If a display interrupt was already
pending when enabling IRQs, we would time out waiting for the vblank.

Avoid the potential issue by clearing GFX_MSTR_IRQ as part of the IRQ
reset.

v2:
  - Move logic from gen11_gt_irq_reset() to dg1_irq_reset(). (Matt)

BSpec: 50875, 54028
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230920195351.59421-2-gustavo.sousa@intel.com

Recent refactoring left an unsightly block of empty lines. Remove them.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230920085715.6905-1-tvrtko.ursulin@linux.intel.com

Separate the printing of display version and feature flags from the main
driver probe to inside the display initialization. This is in alignment
with isolating the display code from the main driver and helps Xe driver
to resuse it.

v2: Replace drm_info_printer with drm_debug_printer (Jani)

Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230921105954.2002469-1-balasubramani.vivekanandan@intel.com

We have the same h/vsync_end vs. h/vtotal quirk in the VBT parser
that was also present in EDID parser. Adjust the VBT parser the
same way as was done for hte EDID parser to fixup h/vsync_end
instead of h/vtotal. While I'm not currently aware of any machines
that need this for the VBT it seems prudent to keep both parsers
in sync.

And while at it let's add some debugs here as well. A bit
lackluster but didn't feel like plumbing the connector all
the way down at this time.

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


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

Introduce correspondent definitions for choosing between CD2X CDCLK
and PLL CDCLK as a source. All the entries in cdclk table for xe2lpd are
defined with PLL CDCLK as source, so simply set it. Also
skl_cdclk_decimal() shouldn't be set in CDCLK_CTL anymore, so skip it
for display version 20 and above.

v2:
  - Remove unneeded comment and use REG_BIT() (Matt Roper)
  - Rename CDCLK_SOURCE_SEL_CDCLK_PLL() to MDCLK_SOURCE_SEL_CDCLK_PLL
    to match spec (Lucas)

Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-22-lucas.demarchi@intel.com

Xe2_LPD supports DC5, DC6, and DC9 (DC3CO no longer exists).  The
overall programming and requirements to enter DC states are similar to
those of Xe_LPD+ although AUX transactions do not require DC5/DC6 exit
as they did previously.

Bspec: 68851, 68857, 68886, 69115
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-21-lucas.demarchi@intel.com

Add Display Power Well for Xe2_LPD. It's mostly the same as Xe_LPD+,
so reuse the code. PGPICA1 contains type-C capable port slices
which requires the well to power powered up, so add new power well
definition for it.

The DC_OFF fake power well will be added in a follow up commit.

v2: Do not rmw as bit 31 is the only R/W bit in the register (Matt Roper)

BSpec: 68886
Signed-off-by: Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-20-lucas.demarchi@intel.com

Add a new CDCLK table for Lunar Lake.

v2:
  - Remove mdclk from the table as it's not needed (Matt Roper)
  - Update waveform values to the latest from spec (Matt Roper)
  - Rename functions and calculation to match by pixel rate (Lucas)
v3: Keep only the table: as far as intel_pixel_rate_to_cdclk()
    is concerned, the minimum cdclk should still be half the pixel
    rate on Xe2 (bspec 68858:
    "Pipe maximum pixel rate = 2 * CDCLK frequency * Pipe Ratio")
    (Matt Roper)

Bspec: 68861, 68858
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-19-lucas.demarchi@intel.com

LNL's south display uses the same table as MTP. Check for LNL's fake PCH
to make it consistent with the other checks.

The VBT table doesn't contain the VBT -> spec mapping for LNL. Like in
other cases, uses the same as the previous platform.

Bspec: 68971, 20124
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-18-lucas.demarchi@intel.com

Xe2_LPD also needs workaround 15010685871. While adding the new display
version, also re-order the condition to follow the convention of new
version first.

v2: Remove redundant HAS_CDCLK_SQUASH(). As the platform or IP version
    needing the workaround are handpicked, there is no need to also
    check if tha platform has squashing support (Matt Roper)

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-17-lucas.demarchi@intel.com

Hotplug setup for Xe2_LPD differs from Xe_LPD+ by the fact that the
extra programming for hotplug inversion and DDI HPD filter duration is
not necessary anymore. As mtp_hpd_irq_setup() is reasonably small,
prefer to fork it into a new function for Xe2_LPD instead of adding a
platform check.

v2: Add extra bspec reference and fix missing else (Matt Roper)

BSpec: 68970, 69940
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-16-lucas.demarchi@intel.com

Enable odd size and panning for planar yuv formats.

Cc: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-15-lucas.demarchi@intel.com

Starting from display version 20, we need to read the pin assignment
from the IOM TCSS_DDI_STATUS register instead of reading it from the
FIA.

We use the pin assignment to decide the maximum lane count.  So, to
support this change, add a new lnl_tc_port_get_max_lane_count() function
that reads from the TCSS_DDI_STATUS register and decides the maximum
lane count based on that.

BSpec: 69594
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-14-lucas.demarchi@intel.com

Differently from previous version, Xe2_LPD groups all port AUX interrupt
bits into PICA interrupt registers.

While at it, drop some trailing newlines.

BSpec: 68958, 69697
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-13-lucas.demarchi@intel.com

The address of CTL and DATA registers for DP AUX were changed in Xe2_LPD:
now they are all in a single range, with CH_A and CH_B coming right after
the USBC instances. Like was done when moving registers to PICA, use
a helper macro to remap the ch passed to an index that can be used to
calculate the right offset.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-12-lucas.demarchi@intel.com

XELPDP_DP_AUX_CH_CTL() and XELPDP_DP_AUX_CH_DATA() use 2 ranges. Prefer
using _PICK_EVEN_2RANGES() over PICK().

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-11-lucas.demarchi@intel.com

Fix some whitespace issues for register definitions and keep the defines
for DP_AUX_CH_CTL and DP_AUX_CH_DATA in the right place: together with
the bit definition.

While at it add a TODO entry that those defines shouldn't be using an
implicit dev_priv.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-10-lucas.demarchi@intel.com

Do not read DE_RRMR register after display version 20. This register
contains display state information during GFX state dumps.

Bspec: 69456
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-9-lucas.demarchi@intel.com

Since Xe2LPD technically has FlatCCS, it doesn't have AuxCCS registers
like PLANE_AUX_DIST.  However we currently have HAS_FLAT_CCS hardcoded
to 0 since compression isn't ready; we need to make sure this doesn't
cause the display code to go back to trying to write this register.

Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-8-lucas.demarchi@intel.com

We now start calculating relative plane data rate for cursor plane as
well, as instructed by BSpec and also treat cursor plane same way as
other planes, when doing allocation, i.e not using fixed allocation for
cursor anymore.

Bspec: 68907
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-7-lucas.demarchi@intel.com

Xe2_LPD doesn't have south display engine on a PCH, it's actually
on the SoC die (while north display engine is on compute die). As
such it makes no sense to go through the PCI devices looking for
an ISA bridge. The approach used by BXT/GLK can't be used here since
leaving it with PCH_NONE would mean taking the wrong code paths.

For the places we currently use a PCH check, it's enough for now to just
check the north display version. Use that to define a fake PCH to be
used across the driver. Eventually these PCH checks may need to be
re-designed as this is already the third platform using/needing a
fake PCH.

v2: Match on display IP version rather than on platform (Matt Roper)
v3: Extend and clarify commit message (Matt Roper / Ville)

Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-6-lucas.demarchi@intel.com

Follow the convention of checking the last platform first and reword the
comment to convey there are more platforms than just DG1.

Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-5-lucas.demarchi@intel.com

If a particular pipe is disabled by fuse also remove the FBC for that
pipe.

Bspec: 69464
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-4-lucas.demarchi@intel.com

FBC is no longer limited by pipe: add the defines for pipes B and C that
will be used by platforms supporting FBC on such pipes.

Bspec: 68881, 68904
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-3-lucas.demarchi@intel.com

Add Lunar Lake platform definitions for i915 display. The support for
LNL will be added to the xe driver, with i915 only driving the display
side. Xe2 display is derived from the Xe_LPD+ IP; additional feature
deltas will be introduced in subsequent patches, so here it's just
adding a separate xe2_lpd_display struct.

v2: Use a LPDP_FEATURES macro (Matt Roper)

Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230919192128.2045154-2-lucas.demarchi@intel.com