review.tizen.org Git - platform/kernel/linux-starfive.git/log

drm/i915: Define bitmasks for ilk pfit window pos/size

Define and use the bitmasks for the x/y components
of the ilk+ panel filter window pos/size registers.

Note that we stick to the full 16 bit mask even though
the actual hardware limits are lower (and somewhat
platform dependent). BDW is actually limited to
13 bits horizontal and 12 bits vertical, with the high
bits being hardwired to zero. HSW should have the same
limits as BDW. And pre-HSW should be limited to 12bits
in both directions as that's already the limit of the
transcoder timing registers. Curiously on HSW and earlier
platforms all 16 bits can actually be set, but presumably
the hardware ignores the high bits.

v2: Switch back to full 16bit masks since that's what
we use transcoder timign regs and PIPESRC as well

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

drm/i915/display/dp: 128/132b LT requirement

For 128b/132b LT prior to LT DPTX should set power state, DP channel
coding and then link rate.

v2: added separate function to avoid code duplication(Jani N)
v3: DP2.1 section 3.5.2.16 is ordered, 3.5.1.2 is unordered and hence
discarding <Ville>

Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230425025944.151744-1-arun.r.murthy@intel.com

drm/i915/mtl: Enable TC ports

Finally, we can enable TC ports for Meteorlake.

Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-14-mika.kahola@intel.com

drm/i915/mtl: Pin assignment for TypeC

Unlike previous platforms that used PORT_TX_DFLEXDPSP
for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1
from which the max_lanes has to be calculated.

Bspec: 50235, 65380

Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-13-mika.kahola@intel.com

drm/i915/mtl: TypeC HPD live status query

The HPD live status for MTL has to be read from different set of
registers. MTL deserves a new function for this purpose
and cannot reuse the existing HPD live status detection

Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-12-mika.kahola@intel.com

drm/i915/mtl: Power up TCSS

Add register writes to enable powering up Type-C subsystem i.e. TCSS.
For MeteorLake we need to request TCSS to power up and check the TCSS
power state after 500 us.

In addition, for PICA we need to set/clear the Type-C PHY ownnership
bit when Type-C device is connected/disconnected.

Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-11-mika.kahola@intel.com

drm/i915/mtl: Define mask for DDI AUX interrupts

Xe_LPD+ defines interrupt bits for only DDI ports in the DE Port
Interrupt registers. The bits for Type-C ports are defined in the PICA
interrupt registers.

BSpec: 50064

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-10-mika.kahola@intel.com

drm/i915/mtl: Readout Thunderbolt HW state

Readout hw state for Thunderbolt.

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-9-mika.kahola@intel.com

drm/i915/mtl: Enabling/disabling sequence Thunderbolt pll

Enabling and disabling sequence for Thunderbolt PLL.

Bspec: 64568

v2: Use intel_de_wait_for_register() (RK)

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-8-mika.kahola@intel.com

drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA

Use MPLLA for DP2.0 rates 10G and 20G, when ssc is enabled.

v2: Fix typo in commit message (Animesh)

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-7-mika.kahola@intel.com

drm/i915/mtl: Add voltage swing sequence for C20

DP1.4 and DP20 voltage swing sequence for C20 phy.

Bspec: 65449, 67636, 67610

Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-6-mika.kahola@intel.com

drm/i915/mtl: C20 port clock calculation

Calculate port clock with C20 phy.

BSpec: 64568

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-5-mika.kahola@intel.com

drm/i915/mtl: Dump C20 pll hw state

As we already do with C10 chip, let's dump the pll
hw state for C20 as well.

Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-4-mika.kahola@intel.com

drm/i915/mtl: C20 HW readout

Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates.
The PLL settings are based on table, not for algorithmic alternative.
For DP 1.4 only MPLLB is in use.

Once register settings are done, we read back C20 HW state.

BSpec: 64568

v2: Updated pll tables (RK)
MPLLB selection fix (RK)

Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-3-mika.kahola@intel.com

drm/i915/mtl: C20 PLL programming

C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and
HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add
4 lane support for c20.

v2: Add 6.48Gbps and 6.75Gbps modes for eDP (RK)
    Fix lane check (RK)
    Fix multiline commenting (Arun)
    use usleep_range() instead of msleep() (Andi)

Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com>
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-2-mika.kahola@intel.com

drm/i915/dsi: Use unconditional msleep() instead of intel_dsi_msleep()

The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have
a version of 3 or newer and the panel is in vid-mode.

This is based on the big comment around line 730 which starts with
"Panel enable/disable sequences from the VBT spec.", where
the "v3 video mode seq" column does not have any wait t# entries.

Checking the Windows driver shows that it does always honor
the VBT delays independent of the version of the VBT sequences.

Commit 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for
the panel_on_delay when there is no reset-deassert MIPI-sequence")
switched to a direct msleep() instead of intel_dsi_msleep()
when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix
the panel on an Acer Aspire Switch 10 E SW3-016 not turning on.

And now testing on a Nextbook Ares 8A shows that panel_on_delay
must always be honored otherwise the panel will not turn on.

Instead of only always using regular msleep() for panel_on_delay
do as Windows does and always use regular msleep() everywhere
were intel_dsi_msleep() is used and drop the intel_dsi_msleep()
helper.

Changes in v2:
- Replace all intel_dsi_msleep() calls instead of just
the intel_dsi_msleep(panel_on_delay) call

Cc: stable@vger.kernel.org
Fixes: 6fdb335f1c9c ("drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence")
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230425194441.68086-1-hdegoede@redhat.com

drm/i915/display: Increase AUX timeout for Type-C

Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
Workaround: Increase the timeout.

---v2
-change style on how we mention WA [Ankit]
-fix bat error by creating new func that is only called for aux power
well scenarios so we can avoid null pointer error as it is called
everywhere.

--v3
-Add non-default enable_timeout to power well descriptor which avoids
adding more platform checks [Imre]

--v4
-Remove Bspec link from top to bottom remove WA link from commit put it
on comment [Jani]
-enable_timeout in ms and add .fixed_enable_delay too [Imre]

--v5
-move power_wells instead of duplicating them [Imre]

Bspec: 55480

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418131425.1285088-1-suraj.kandpal@intel.com

drm/i915/mtl: Add the missing CPU transcoder mask in intel_device_info

CPU transcoder mask is used to iterate over the available
CPU transcoders in the macro for_each_cpu_transcoder().

The macro is broken on MTL and got highlighted when audio
state was being tracked for each transcoder added in [1].

Add the missing CPU transcoder mask which is similar to ADL-P
mask but without DSI transcoders.

[1]: https://patchwork.freedesktop.org/patch/523723/

Fixes: 7835303982d1 ("drm/i915/mtl: Add MeteorLake PCI IDs")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Acked-by: Haridhar Kalvala <haridhar.kalvala@intel.com>
Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230420221248.2511314-1-radhakrishna.sripada@intel.com

drm/i915/adlp+: Disable DC5/6 states for TC port DDI/AUX and for combo port AUX

On ADLP+ Bspec allows DC5/6 to be enabled while power well 2 is enabled.
Since the AUX and DDI power wells (except for port A/B) are also backed
by power well 2, this would suggest that DC5/6 can be enabled while any
of these AUX or DDI port functionalities are used. As opposed to this
AUX transfers will time out on ADLP TypeC ports while DC6 is enabled.

Until the restriction for DC5/6 is clarified in Bspec let's assume that
the intention is to allow for using these power states while pipe A/B is
enabled, but only for combo ports which can be used with eDP outputs.
Similarly assume that AUX transaction initiated by the driver on any port
requires DC states to be disabled.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Fixes: 88c487938414 ("drm/i915: Use separate "DC off" power well for ADL-P and DG2")
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230424200205.1732941-1-imre.deak@intel.com

drm/i915/mtl: Skip pcode qgv restrictions for MTL

Communicating QGV points restriction to PUnit happens via PM Demand
instead of the Pcode mailbox in the previous platforms. GV point
restriction is handled by the PM demand code.

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

drm/i915: Initialize dkl_phy spin lock from display code path

drm/i915: Initialize dkl_phy spin lock from display code path

Start moving the initialization of display locks from
i915_driver_early_probe().
Display locks should be initialized from display-only code paths.

It was also agreed that if a variable is only used in one file, it
should be initialized only in that file, so intel_dkl_phy_init() was
added.

v2:
- added intel_display_locks_init()

v3:
- rebased

v4:
- dropped intel_display_locks_init()

v5:
- moved intel_dkl_phy_init() to the beginning of file

Cc: intel-gfx@lists.freedesktop.org
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230420170558.35398-1-jose.souza@intel.com

drm/i915/mtl: Set has_llc=0

On MTL, LLC is not shared between GT and CPU, set has_llc=0.

Signed-off-by: Fei Yang <fei.yang@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Signed-off-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230420102349.15302-1-nirmoy.das@intel.com

drm/i915/psr: Sprinkle cpu_transcoder variables around

Reduce the 'intel_dp' stuff a bit by introducing local
cpu_transcoder variables.

Ideally I'd like the whole PSR code to stop using intel_dp
except during a full modeset, but dunno yet if that's
possible. But the less 'intel_dp' we have sprad around
the easier that should be to figure out eventually.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-9-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Include PSR_PERF_CNT in debugfs output on all platforms

The fact that DC states reset the PSR perofrmance counter
is no reason not to include it in the debug output.
But let's keep the comment there to remind people about
that caveat.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-8-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Add a FIXME for the PSR vs. AUX usage conflict

We need to disable PSR when we are doing AUX by hand, otherwise
it's possible that the PSR hardware could be using the AUX CH
while we try to do our manual stuff. Add a FIXME for now.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-7-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Define more PSR mask bits

Define more of the PSR mask bits, and describe in detail
what some of them do. Even if we don't set them all from
the driver they can be very useful during PSR debugging.
Having to trawl through bspec every time to find them is
not fun, and re-reverse engineering the behaviour every
time is time consuming (even if a bit more fun than spec
trawling).

v2: Moar bits
    Put the description into a comment to be easily available
v2: Fix the BDW_UNMASK_VBL_TO_REGS_IN_SRD/HSW_UNMASK_VBL_TO_REGS_IN_SRD
    description
    Rebase due to intel_psr_regs.h

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-6-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Use intel_de_rmw()

Replace some hand rolled RMW stuff with intel_de_rmw().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-5-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915/psr: Clean up PSR register defininitions

Use REG_BIT() & co. to make the PSR register definitions
nicer.

v2: Rebase due to intel_psr_regs.h

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-4-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Clean up various display chicken registers

Modernize a bunch of display chicken registers by using
REG_BIT() & co.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-3-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Fix up whitespace in some display chicken registers

Fix a bunch of whitespace issues in some display register
definitons. Only touching the bits alerayd using REG_BIT() &
co. here. The rest will come later.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411191429.29895-2-ville.syrjala@linux.intel.com
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>

drm/i915: Drop a useless forward declararion

ilk_pfit_enable() is defined before the first use. No need
for a forwared declaration.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-9-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use REG_BIT() & co. for ilk+ pfit registers

Polish the ilk+ pfit registers with REG_BIT() & co., and
also take the opportunity to unify the ivb/hsw vs. not checks
in ilk_pfit_enable() and ilk_get_pfit_config().

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-8-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Namespace pfit registers properly

Give the PFIT_CONTROL bits a consistent namespace.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Use REG_BIT() & co for the pre-ilk pfit registers

Modernize the gmch pfit register definitions using REG_BIT/etc.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-6-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Relocate skl_get_pfit_config()

Move skl_get_pfit_config() next to the other skl+ scaler code
and rename it to skl_scaler_get_config() so that it has a consistnet
namespace.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915: Relocate intel_atomic_setup_scalers()

Move intel_atomic_setup_scalers() next to the other scaler
code in skl_scaler.c.

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

drm/i915: Relocate VBLANK_EVASION_TIME_US

Move the VBLANK_EVASION_TIME_US definition to a slightly
better place.

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

drm/i915: Check pipe source size when using skl+ scalers

The skl+ scalers only sample 12 bits of PIPESRC so we can't
do any plane scaling at all when the pipe source size is >4k.

Make sure the pipe source size is also below the scaler's src
size limits. Might not be 100% accurate, but should at least be
safe. We can refine the limits later if we discover that recent
hw is less restricted.

Cc: stable@vger.kernel.org
Tested-by: Ross Zwisler <zwisler@google.com>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8357
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418175528.13117-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/display: throw out struct intel_load_detect_pipe

An error-valued pointer can handle all in one without the wrapper
struct.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417153741.1074692-2-jani.nikula@intel.com

drm/i915/display: split out load detect to a separate file

Load detect is shared between tv and crt but otherwise isolated in
intel_display.c.

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

drm/i915/wm: remove stale and unused ilk_wm_max_level() declaration

The declaration was removed earlier, but got accidentally resurrected in
i915xx_wm.[ch] refactoring. Remove harder.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230419115449.422214-1-jani.nikula@intel.com

drm/i915/mtl: Re-use ADL-P's "DC off" power well

As with ADL-P, MTL's "DC off" power well should be a dependency of the
PGC and PGD power wells, not the entire PG2 well. In fact, the DC5/DC6
requirements between the two platforms are the same, so the Xe_LPD "DC
off" well definition can just be re-used for Xe_LPD+.

Bspec: 49193
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418220446.2205509-3-radhakrishna.sripada@intel.com

drm/i915: Use separate "DC off" power well for ADL-P and DG2

Although ADL-P and DG2 both use the same general power well setup, the
DC5/DC6 requirements are slightly different which means each platform
should have its own "DC off" power well.

DG2 (i.e., Xe_HPD IP) requires that DC5 be disabled whenever PG2 is
active. However ADL-P (i.e., Xe_LPD IP) only requires DC5/DC6 to be
disabled when the PGC or PGD subwells are active; we should be able to
remain in these DC states when PGB and general PG2 functionality is in
use.

v2: Use dc_of as power well name.
Move xehpd power domain definitions near power well definition.(Imre)

Bspec: 49193
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230418220446.2205509-2-radhakrishna.sripada@intel.com

drm/i915: use explicit includes for i915_reg.h and i915_irq.h

A lot of places include i915_reg.h implicitly via i915_irq.h, which gets
included implicitly via intel_display_trace.h. Remove the includes from
the headers, and include i915_reg.h and i915_irq.h explicitly where
needed.

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

drm/i915/dp_mst: Fix active port PLL selection for secondary MST streams

The port PLL selection needs to be up-to-date in the CRTC state of both
the primary and all secondary MST streams. The commit removing the
encoder update_prepare/complete hooks (see Fixes: below), stopped doing
this for secondary streams, fix this up.

Fixes: 0f752b2178c9 ("drm/i915: Remove the encoder update_prepare()/complete() hooks")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8336
Cc: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230414173800.590790-1-imre.deak@intel.com

drm/i915: Reuse <platform>_hotplug_mask() in .hpd_detection_setup()

Replace the hardcoded masks with just a loop over all hpd
pins using the <platform>_hotplug_mask() functions.

v2: Deal with mtp

Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-5-ville.syrjala@linux.intel.com

drm/i915: Check HPD live state during eDP probe

We need to untangle the mess where some SKL machines (at least)
declare both DDI A and DDI E to be present in their VBT, and
both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a
real DP->VGA converter.

Currently that is handled by checking the VBT child devices
for conflicts before output probing. But that kind of solution
will not work for the ADL phantom dual eDP VBTs. I think on
those we just have to probe the eDP first. And would be nice
to use the same probe scheme for everything.

On these SKL systems if we probe DDI A first (which is only
natural given it's declared by VBT first) we will get an answer
via AUX, but it came from the DP->VGA converter hooked to the
DDI E, not DDI A. Thus we mistakenly register eDP on DDI A
and screw up the real DP device in DDI E.

To fix this let's check the HPD live state during the eDP probe.
If we got an answer via DPCD but HPD is still down let's assume
we got the answer from someone else.

Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and
I also tested turning off all HPD hardware prior to loading
i915 to make sure it all comes up properly. And I simulated
the failure path too by not turning on HPD sense and that
correctly gave up on eDP.

I *think* Windows might just fully depend on HPD here. I
couldn't really find any other way they probe displays. And
I did find code where they also check the live state prior
to AUX transfers (something Imre and I have also talked
about perhaps doing). That would also solve this as we'd
not succeed in the eDP probe DPCD reads.

Other solutions I've considered:

- Reintrduce DDI strap checks on SKL. Unfortunately we just
  don't have any idea how reliable they are on real production
  hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap
  is forever, always init DDI A") does suggest that not very.
  Sadly that commit is very poor in details :/

  Also the systems (Asrock B250M-HDV at least) fixed by commit
  41e35ffb380b ("drm/i915: Favor last VBT child device with
  conflicting AUX ch/DDC pin") might still not work since we
  don't know what their straps indicate. Stupid me for not
  asking the reporter to check those at the time :(

  We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k
  both MS-7B54/Z370M) that also declare both DDI A and DDI E
  in VBT to use AUX A, and on these the DDI A strap is also
  set. There doesn't seem to be anything hooked up to either
  DDI however. But given the DDI A strap is wrong on these it
  might well be wrong on the Asrock too.

  Most other CI machines seem to have straps that generally
  match the VBT. fi-kbl-soraka is an exception though as DDI D
  strap is not set, but it is declared in VBT as a DP++ port.
  No idea if there's a real physical port to go with it or not.

- Some kind of quirk just for the cases where both DDI A and DDI E
  are present in VBT. Might be feasible given we've ignored
  DDI A in these cases up to now successfully. But feels rather
  unsatisfactory, and not very future proof against funny VBTs.

References: https://bugs.freedesktop.org/show_bug.cgi?id=111966
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-4-ville.syrjala@linux.intel.com

drm/i915: Introduce intel_hpd_enable_detection()

Add a mechanism by which we can enable the HPD sense for
individual encoders.

This will be used during eDP probing to figure out if
anything is actually connected. The normal intel_hpd_irq_setup()
thing doesn't work since we only do that after probing the
outputs, and we only enable HPD sense for encoders that were
successfully probed.

The other idea that crossed my minds was to just turn on
HPD sense for all pins before output probing and let hpd_irq_setup()
clean it up afterwards. But that doesn't work for BXT/GLK where
the HPD invert information comes from the VBT child device.
So looks like this really needs to be per-encoder.

v2: Give it a better name (Jani)
v3: Deal with mtl

Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> #v2
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-3-ville.syrjala@linux.intel.com

drm/i915: Introduce <platform>_hotplug_mask()

Pair each <platform>_hotplug_enables() function with
a corresponding <platform>_hotplug_mask() function so that
we can determine right bits to clear on a per hpd_pin basis.
We'll need this for turning on HPD sense for a specific
encoder rather than just all of them.

v2: Drop the unused 'i915' param (Jani)
v3: Drop the _foo_hotplug_enables() redirection too
v4: Deal with mtp

Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com> #v3
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417131728.7705-2-ville.syrjala@linux.intel.com

drm/i915/pps: use intel_de_rmw() for panel unlock

Use rmw where needed.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230417085742.793379-1-jani.nikula@intel.com

drm/i915/display: add intel_display_driver_early_probe()

Add intel_display_driver_early_probe() as the early probe call to
replace intel_init_display_hooks(). The latter will be "demoted" to
setting up hooks in intel_display.c only.

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0b02311e5343527b501b44671d2188f2a1b30a7d.1681465222.git.jani.nikula@intel.com

drm/i915/display: rename intel_display_driver_suspend/resume functions

Follow the usual naming conventions. Switch to i915 arguments and naming
while at it.

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/cdd4228337678609967ed176dcfc9690de5d490b.1681465222.git.jani.nikula@intel.com

drm/i915/display: move display suspend/resume to intel_display_driver.[ch]

High level display functionality only called from driver top level code.

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/11fdd82437370d8f341cd546d546de5e934c000f.1681465222.git.jani.nikula@intel.com

drm/i915/display: add intel_display_reset.[ch]

Split out the display reset functionality to a separate file to
declutter intel_display.c. Rename the functions accordingly. The minor
downside is having to expose __intel_display_resume().

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5e98e2fc5f0c09490e02d22250c8201342852288.1681465222.git.jani.nikula@intel.com

drm/i915/display: rename intel_display_driver_* functions

Follow the usual naming conventions.

v2:
- Also rename references in comments (Gustavo)

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/6ff7b76018bf4cf611037d7bf027c975cddfe2af.1681465222.git.jani.nikula@intel.com

drm/i915/display: move modeset probe/remove functions to intel_display_driver.c

High level display functionality only called from driver top level code.

v2:
- Remove unnecessary declarations for intel_sanitize_watermarks() and
intel_atomic_check() (Gustavo)

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c00df5cfc233520bc28dd972296197a8a619a6a0.1681465222.git.jani.nikula@intel.com

drm/i915/display: rename intel_modeset_probe_defer() -> intel_display_driver_probe_defer()

Follow the usual naming conventions.

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ab5023570d8ae55c0d9c98c78f588e51c0790b6c.1681465222.git.jani.nikula@intel.com

drm/i915/display: move intel_modeset_probe_defer() to intel_display_driver.[ch]

High level display functionality only called from driver top level code.

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/831ed4d0356b51526704269038a6d2d72739e779.1681465222.git.jani.nikula@intel.com

drm/i915/display: start high level display driver file

The only way to truly clean up intel_display.[ch] is to move stuff out
of them until there's absolutely nothing left.

Start moving the high level display driver entry points, i.e. functions
called from top level driver code only, to a new file, which we'll call
intel_display_driver.c. The intention is that there's no low-level
display code or details here. This is an in-between layer.

Initially, move intel_display_driver_register() and
intel_display_driver_unregister() there.

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e42cc037881a4c6042948a34bd4a9698f9e8487c.1681465222.git.jani.nikula@intel.com

drm/i915/display: remove intel_display_commit_duplicated_state()

This seems like an unnecessary wrapper layer. Removing it will be
helpful later.

Reviewed-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/a38f08e259221d71314ce6d764431147b0fba218.1681465222.git.jani.nikula@intel.com

drm/i915: Make intel_{mpllb,c10pll}_state_verify() safer

intel_{mpllb,c10pll}_state_verify() blows up if you call them
for a non-modeset/fastset commit on account of the relevant
connector not being part of the overall atomic state.
Currently the state checker only runs for modeset/fastset
commits, but for testing purposes it is sometimes desirable
to run it for other commits too. Check for modeset/fastset
in intel_{mpllb,c10pll}_state_verify() itself to make this safe.

v2: Give the new intel_c10pll_state_verify() the same treatment
Add comment to explain why we do this

Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230414190159.7904-1-ville.syrjala@linux.intel.com

drm/i915: Make intel_get_crtc_new_encoder() less oopsy

The point of the WARN was to print something, not oops
straight up. Currently that is precisely what happens
if we can't find the connector for the crtc in the atomic
state. Get the dev pointer from the atomic state instead
of the potentially NULL encoder to avoid that.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413200602.6037-2-ville.syrjala@linux.intel.com
Fixes: 3a47ae201e07 ("drm/i915/display: Make WARN* drm specific where encoder ptr is available")
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/i915/mtl: Initial DDI port setup

Initialization sequences and C10 phy are in place to be able to enable
the first 2 ports of MTL. The other ports use C20 phy that still need
to be properly added. Enable the first ports for now, keeping a TODO
comment about the others.

Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-10-radhakrishna.sripada@intel.com

drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI

MTL requires the PORT_CTL_WIDTH, TRANS_DDI_FUNC_CTL and DDI_BUF_CTL
to be filled with 4 lanes for TMDS mode.
This patch enables D2D link and fills PORT_WIDTH in appropriate
registers.

v2:
  - Added fixes from Clint's Add HDMI implementation changes.
  - Modified commit message.
v3:
  - Use TRANS_DDI_PORT_WIDTH() instead of DDI_PORT_WIDTH() for the value
    of TRANS_DDI_FUNC_CTL_*. (Gustavo)

Cc: Taylor, Clinton A <clinton.a.taylor@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-9-radhakrishna.sripada@intel.com

drm/i915/mtl: Add C10 phy programming for HDMI

Like DG2, we still don't have a proper algorithm that can be used
for calculating PHY settings, but we do have tables of register
values for a handful of the more common link rates. Some support is
better than none, so let's go ahead and add/use these tables when we
can, and also add some logic to hdmi_port_clock_valid() to filter the
modelist to just the modes we can actually support with these link
rates.

Hopefully we'll have a proper / non-encumbered algorithm to calculate
these registers by the time we upstream and we'll be able to replace
this patch with something more general purpose.

Bspec: 64568

v2: Rebasing with Clint's HDMI C10 PLL tables (Mika)
v3: Remove the extra hdmi clock check pruning.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-8-radhakrishna.sripada@intel.com

drm/i915/mtl/display: Implement DisplayPort sequences

The differences between MTL and TGL DP sequences are big enough to
MTL have its own functions.

Also it is much easier to follow MTL sequences against spec with
its own functions.

One change worthy to mention is the move of
'intel_display_power_get(dev_priv, dig_port->ddi_io_power_domain)'.
This call is not necessary for MTL but we have _put() counter part in
intel_ddi_post_disable_dp() that needs to balanced.
We could add a display version check on it but instead here it is
moving it to intel_ddi_pre_enable_dp() so it is executed for all
platforms in a single place and this will not cause any harm in MTL
and newer platforms.

v2:
- Fix logic to wait for buf idle.
- Use the right register to wait for ddi active.(RK)
v3:
- Increase wait timeout for ddi buf active (Mika)
v4:
- Increase idle timeout for ddi buf idle (Mika)
v5: use rmw in mtl_disable_ddi_buf. Donot clear
link training mask(Imre)

BSpec: 65448 65505
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Satyeshwar Singh <satyeshwar.singh@intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-7-radhakrishna.sripada@intel.com

drm/i915/mtl: MTL PICA hotplug detection

PICA is used for DP alt mode and TBT modes. Hotplug interruption is routed
from PICA chip to south display engine and from there to north display
engine. This patch adds functionality to enable hotplug detection for
all Type-C ports (4 ports available).

Differently from HPD in south display, PICA provides a dedicated HPD
control register for each supported port, so we loop over ports
ourselves instead of using intel_hpd_hotplug_enables() or
intel_get_hpd_pins().

BSpec: 49305, 55726, 65107, 65300

Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com>
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-6-radhakrishna.sripada@intel.com

drm/i915/mtl: Add vswing programming for C10 phys

C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
Program the levels directly to the fields in the VDR Registers.

Bspec: 65449

v2: From table "C10: Tx EQ settings for DP 1.4x" it shows level 1
    and preemphasis 1 instead of two times of level 1 preemphasis 0.
    Fix this in the driver code as well.
v3: VSwing update (Clint)
v4: Add vboost termination ctl programming(Imre)
    Fix tx llogic and other nits
    Restrict C10 vdr ctl register access for C10 phy(RK)
v5: Program vboots, termination ctl for both lanes(Imre)

Cc: Imre Deak <imre.deak@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>(v3)
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-5-radhakrishna.sripada@intel.com

drm/i915/mtl: Add Support for C10 PHY message bus and pll programming

XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
has a dedicated PIPE 5.2 Message bus for configuration. This message
bus is used to configure the phy internal registers.

XELPDP has C10 phys to drive output to the EDP and the native output
from the display engine. Add structures, programming hardware state
readout logic. Port clock calculations are similar to DG2. Use the DG2
formulae to calculate the port clock but use the relevant pll signals.
Note: PHY lane 0 is always used for PLL programming.

Add sequences for C10 phy enable/disable phy lane reset,
powerdown change sequence and phy lane programming.

Bspec: 64539, 64568, 64599, 65100, 65101, 65450, 65451, 67610, 67636

v2: Squash patches related to C10 phy message bus and pll
    programming support (Jani)
    Move register definitions to a new file i.e. intel_cx0_reg_defs.h (Jani)
    Move macro definitions (Jani)
    DP rates as separate patch (Jani)
    Spin out xelpdp register definitions into a separate file (Jani)
    Replace macro to select registers based on phy lane with
    function calls (Jani)
    Fix styling issues (Jani)
    Call XELPDP_PORT_P2M_MSGBUS_STATUS() with port instead of phy (Lucas)
v3: Move clear request flag into try-loop
v4: On PHY idle change drm_err_once() as drm_dbg_kms() (Jani)
    use __intel_de_wait_for_register() instead of __intel_wait_for_register
    and uncomment intel_uncore.h (Jani)
    Add DP-alt support for PHY lane programming (Khaled)
v4: Add tx and cmn on c10mpllb_state (Imre)
    Add missing waits for pending transactions between two message bus
    writes (Imre)
    General cleanups and simplifications (Imre)
v5: Few nit cleanups from rev4 (imre)
    s/dev_priv/i915/ , s/c10mpllb/c10pll/ (RK)
    Rebase
v6: Move the mtl code from intel_c10pll_calc_port_clock to mtl function
    Fix typo in comment for REG_FIELD_PREP8 definition(Imre)

Cc: Mika Kahola <mika.kahola@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Gustavo Sousa <gustavo.sousa@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v4)
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-4-radhakrishna.sripada@intel.com

drm/i915/mtl: Create separate reg file for PICA registers

Create a separate file to store registers for PICA chips
C10 and C20.

v2: Rename file (Jani)
v3: Use _PICK_EVEN_2RANGES() macro (Lucas)
Coding style fixed (Lucas)
v4: Redefine macros (Imre)

Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-3-radhakrishna.sripada@intel.com

drm/i915/mtl: Add DP rates

Add DP rates for Meteorlake.

Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Mika Kahola <mika.kahola@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413212443.1504245-2-radhakrishna.sripada@intel.com

drm/i915: hide mkwrite_device_info() better

The goal has been to just make device info a pointer to static const
data, i.e. the static const structs in i915_pci.c. See [1]. However,
there were issues with intel_device_info_runtime_init() clearing the
display sub-struct of device info on the !HAS_DISPLAY() path, which
consequently disables a lot of display functionality, like it
should. Looks like we'd have to cover all those paths, and maybe
sprinkle HAS_DISPLAY() checks in them, which we haven't gotten around
to.

In the mean time, hide mkwrite_device_info() better within
intel_device_info.c by adding a intel_device_info_driver_create() for
the very early initialization of the device info and initial runtime
info. This also lets us declutter i915_drv.h a bit, and stops promoting
mkwrite_device_info() as something that could be used.

[1] https://lore.kernel.org/r/a0422f0a8ac055f65b7922bcd3119b180a41e79e.1655712106.git.jani.nikula@intel.com

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411105643.292416-1-jani.nikula@intel.com

drm/i915/debugfs: New debugfs for display clock frequencies

Instead of mixing display & non-display stuff together, move
display specific clock info to new debugfs. This patch will
create a new debugfs "i915_cdclk_info" to expose Current & Max
cdclk and Max pixel clock frequency info.

Example:
$ cat /sys/kernel/debug/dri/0/i915_cdclk_info
Current CD clock frequency: 163200 kHz
Max CD clock frequency: 652800 kHz
Max pixel clock frequency: 1305600 kHz

V2: - s/i915_display_clock_info/i915_cdclk_info/ (Jani)
- Move the logic to intel_cdclk.c (Jani)
- Don't remove info from i915_frequency_info (Jani)
V3: - Drop locking (Jani)

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230413114502.1105288-1-bhanuprakash.modem@intel.com

drm/i915: Use min() instead of hand rolling it

Most places in the vblank code use min() to clamp scanline
counters below vtotal. But we missed one in the gen3/4
pixel counter based codepath.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230404175431.23064-3-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>

drm/i915: Evade transcoder's vblank when doing seamless M/N changes

The transcoder M/N values are double buffered on the transcoder's
undelayed vblank. So when doing seamless M/N fastsets we need to
evade also that.

Note that currently the pipe's delayed vblank == transcoder's
undelayed vblank, so this is still a nop change. But in the
future when we may have to delay the pipe's vblank to create
a register programming window ("window2") for the DSB.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230404175431.23064-2-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com

drm/i915: Allow arbitrary refresh rates with VRR eDP panels

If the panel supports VRR it must be capable of accepting
timings with arbitrary vblank length, within the valid VRR
range. Use that fact to allow the user to request any refresh
rate they like. We simply pick the next highest fixed mode
from our list, and adjust the vblank to get the desired refresh
rate in the end.

Of course currently everything to do with the vrefresh is
using 1Hz precision, so might not be exact. But we can improve
that in the future by just upping our vrefresh precision.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230404175431.23064-1-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>

drm/i915/color: Fix typo for Plane CSC indexes

Replace _PLANE_INPUT_CSC_RY_GY_2_* with _PLANE_CSC_RY_GY_2_*
for Plane CSC

Fixes: 6eba56f64d5d ("drm/i915/pxp: black pixels on pxp disabled")

Cc: <stable@vger.kernel.org>
Signed-off-by: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Animesh Manna <animesh.manna@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230330150104.2923519-1-chaitanya.kumar.borah@intel.com

drm/i915: Flag purely internal commits to not clear crtc_state->inherited

If we have to force the hardware to go through a full modeset
due to eg. cdclk reprogramming, we need to preserve
crtc_state->inherited for all crtcs that have not otherwise
gone through the whole compute_config() stuff after connectors
have been detected.

Otherwise eg. cdclk induced modeset glk_force_audio_cdclk()
will clear the inherited flag, and thus the first real commit
coming from userspace later on will not be forced through
the full .compute_config() path and so eg. audio state may
not get properly recomputed.

But instead of adding all kinds of ad-hoc crtc_state->inherited
preservation hacks all over, let's change things so that we
only clear it for the crtcs directly included in userspace/client
initiated commits.

Should be far less fragile since now we just need to remember
to flag the internal commits, and not worry about where new
crtcs might get pulled in.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5260
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230328122357.1697-1-ville.syrjala@linux.intel.com
Reviewed-by: Luca Coelho <luciano.coelho@intel.com>

drm/i915/vrr: Allow VRR to be toggled during fastsets

Now that VRR enable/disable are called from convenient places
it is trivial to allow it to change state during fastsets.
Make it so.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7542
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320203352.19515-7-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>

drm/i915/vrr: Relocate VRR enable/disable

Move VRR enabling/disabling into a place where it also works
for fastsets.

With this we always start the transcoder up in non-VRR mode.
Granted we already did that but for a very short period of
time. But now that we might end up doing a bit more with the
transcoder in non-VRR mode it seems prudent to also update
the active timings as the transcoder changes its operating
mode.

crtc_state->vrr.enable still tracks whether VRR is actually
enabled or not, but now we configure all the other VRR timing
registers whenever VRR is possible (whether we actually enable
it or not). crtc_state->vrr.flipline can now serve as our
"is VRR possible" bit of state.

I decided to leave the MSA timing ignore bit set all the time
whether VRR is actually enabled or not. If the sink can figure
out the timings with that information when VRR is active then
surely it can also do it when VRR is inactive.

v2: Protect intel_vrr_set_transcoder_timings() with HAS_VRR()

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230321135615.27338-1-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>

drm/i915/vrr: Tell intel_crtc_update_active_timings() about VRR explicitly

In order to move VRR enable/disable to a place where it's also
applicable to fastsets we need to be prepared to configure
the pipe into non-VRR mode initially, and then later switch
to VRR mode. To that end allow the active timings to be configured
in non-VRR mode temporarily even when the crtc_state says we're
going to be using VRR.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320203352.19515-5-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>

drm/i915/vrr: Make delayed vblank operational in VRR mode on adl/dg2

On adl/dg2 a chicken bit needs to be set for TRANS_SET_CONTENXT_LATENCY
to take effect in VRR mode. Can't really think of a reason why we'd
ever disable that chicken bit, so let's just always set it.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320203352.19515-4-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>

drm/i915/vrr: Eliminate redundant function arguments

Some of the VRR functions take redundant arguments. Get rid
of them to make life simpler.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320203352.19515-3-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>

drm/i915: Generalize planes_{enabling,disabling}()

I want to use the same logic that planes_{enabling,disabling}()
are using for other features as well. Generlize the thing
into a pair of macros.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230320203352.19515-2-ville.syrjala@linux.intel.com
Reviewed-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>

drm/i915/display: remove unnecessary i915_debugfs.h includes

Leftovers from before display debugfs was separated to its own file.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Nirmoy Das <nirmoy.das@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230411131922.401602-1-jani.nikula@intel.com

drm/i915: Hook up csc into state checker

Have the state checker validate that the csc matrices
look correct when read back from the hardware.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-12-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Include the csc matrices in the crtc state dump

Include the csc matrices in the state dump. The format being
hardware specific we just dump as hex for now. Might have
to think of some way to get a bit more human readable
output...

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-11-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Implement chv cgm csc readout

Read out the csc matrix on chv, and stash the result into the
correct spot in the crtc state.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-10-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Add hardware csc readout for ilk+

Read out the pipe/output csc matrices on ilk+ and stash the results
(in the hardware specific format) into the appropriate place
in the crtc state.

Note that on skl/glk/icl the pipe csc unit suffers from an issue
where *reads* of the coefficient/offset registers also disarm
the double buffer update (if currently armed via CSC_MODE write).
So it's rather important that the readout only happens after the
csc registers have been latched. Fortunately the state checker
only runs after the start of vblank where the latching happens.

And on skl/glk the DMC + CSC register read has the potential to
corrupt the latched CSC register values, so let's add a comment
reminding us that the DC states should remain off until the
readout has been completed.

TODO: maybe we could somehow check to make sure PSR has in fact
latched the new register values already, and that DC states
have been off all along?

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-9-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Sprinke a few sanity check WARNS during csc assignment

Make sure the csc enable bit(s) match the way we're about to
fill the csc matrices.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-8-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Utilize crtc_state->csc on chv

Store the chv cgm csc matrix in the crtc state as well. We
shall store it in the same place where we store the ilk+
pipe csc matrix (as opposed to the output csc matrix).

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-7-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Store ilk+ csc matrices in the crtc state

Embed a pair of intel_csc_matrix structs in the crtc state,
and fill them out appropriately during atomic_check().

Since pre-ivb platforms don't have programmable post offsets
we shall leave those zeroed, mainly in preparation for
state readout+check.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-6-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Start using struct intel_csc_matrix for chv cgm csc

Convert chv_cgm_csc_convert_ctm() over to using the new
intel_csc_matrix structure. No pre/post offsets on this
hardware so only the coefficients get filled out.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-5-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Split chv_load_cgm_csc() into pieces

Split chv_cgm_csc_convert_ctm() out from chv_load_cgm_csc() so
that we have functions with clear jobs. This is also how the ilk+
code is already structured.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-4-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Introduce intel_csc_matrix struct

Introduce a structure that can hold our CSC matrices. In there
we shall have the preoffsets, postoffsets, and coefficients,
all in platform specific format (at least for now).

We shall start by converting the ilk+ code to make use of
the new structure. chv will come later.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-3-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915: Fix limited range csc matrix

Our current limited range matrix is a bit off. I think it
was originally calculated with rounding, as if we wanted
the normal pixel replication type of behaviour.
That is, since the 8bpc max value is 0xeb we assumed the
16bpc max value should be 0xebeb, but what the HDMI spec
actually says it should be is 0xeb00.

So to get what we want we make the formula
out = in * (235-16) << (12-8) / in_max + 16 << (12-8),
with 12 being precision of the csc, 8 being the precision
of the constants we used.

The hardware takes its coefficients as floating point
values, but the (235−16)/255 = ~.86, so exponent 0
is what we want anyway, so it works out perfectly without
having to hardcode it in hex or start playing with floats.

In terms of raw numbers we are feeding the hardware the
post offset changes from 0x101 to 0x100, and the coefficient
changes from 0xdc0 to 0xdb0 (~.860->~.855). So this should
make everything come out just a tad darker.

I already used better constants in lut_limited_range() earlier
so the output of the two paths should be closer now.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230329135002.3096-2-ville.syrjala@linux.intel.com
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>

drm/i915/wakeref: fix kernel-doc comment

Fix the warning:

drivers/gpu/drm/i915/intel_wakeref.h:118: warning: expecting prototype
for intel_wakeref_get_if_in_use(). Prototype was for
intel_wakeref_get_if_active() instead

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230405104142.766598-2-jani.nikula@intel.com

drm/i915/tc: demote a kernel-doc comment to a regular comment

There's not much point in a static work function having a kernel-doc
comment. Just clean it up and make it a regular comment.

This fixes the kernel-doc warnings:

drivers/gpu/drm/i915/display/intel_tc.c:1370: warning: Function
parameter or member 'work' not described in
'intel_tc_port_disconnect_phy_work'

drivers/gpu/drm/i915/display/intel_tc.c:1370: warning: Excess function
parameter 'dig_port' description in 'intel_tc_port_disconnect_phy_work'

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230405104142.766598-1-jani.nikula@intel.com