I accidentally added the compliance test hacks only to
intel_dp_hotplug() which doesn't even get used on any DDI
platform. Put the same crap into intel_ddi_hotplug().

Cc: Imre Deak <imre.deak@intel.com>
Fixes: 193af12c ("drm/i915: Shove the PHY test into the hotplug work")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-7-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

Currently we claim to use TPS7 when using TPS4. That is just
confusing, so let's fix the debug print.

And while we're touching this let's add the customary
encoder id/name as well.

v2: Add MISSING_CASE() (Manasi)
Reviewed-by: NManasi Navare <manasi.d.navare@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114205046.8247-2-ville.syrjala@linux.intel.com

DP spec says:
"The Source device shall start sending the idle pattern after
 it has cleared the Training_Pattern byte in the DPCD."

Currently we do these in operations in the opposite order.
Swap them around to match the spec.

Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210118162107.18424-1-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

There are two CSC on pipeline on gen11 and later platform.
User space application is allowed to enable CTM and RGB
to YCbCr coversion at the same time now.

v2: check csc capability in {}_color_check function.
v3: can't support two CSC at the same time in {ivb,glk}_color_check.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Cooper Chiou <cooper.chiou@intel.com>
Cc: Shankar Uma <uma.shankar@intel.com>
Signed-off-by: NLee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210118022753.8798-1-shawn.c.lee@intel.com

This just refactors out the fdi code to a separate file.
Signed-off-by: NDave Airlie <airlied@redhat.com>
[Jani: cleaned up intel_fdi.h a bit.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f9d52c3d91f0973af308ede16e266fc9b753ecf9.1610622609.git.jani.nikula@intel.com

This pulls a large chunk of the pll calculation code out of
intel_display.c to a new file.

One function makes sense to be an inline, otherwise this
is pretty much a straight copy cover. Also all the
remaining hooks for g45 and older end up the same now.
Signed-off-by: NDave Airlie <airlied@redhat.com>
[Jani: cleaned up intel_dpll.h a bit, de-duped intel_panel_use_ssc().]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/74b58e0572858b5d1734818ca594a23040d7d44f.1610622609.git.jani.nikula@intel.com

There may be more crtc code that can be pulled out, but this
is a good start.

v2: move plane before this.
Signed-off-by: NDave Airlie <airlied@redhat.com>
[Jani: cleaned up intel_crtc.h a bit.]
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/eacbe964f90d189c5940c12af5e09091b37a19c3.1610622609.git.jani.nikula@intel.com

Let's not enable the 4:4:4->4:2:0 conversion bit in the DFP unless we're
actually outputting YCbCr 4:4:4. It would appear some protocol
converters blindy consult this bit even when the source is outputting
RGB, resulting in a visual mess.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2914Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111164111.13302-1-ville.syrjala@linux.intel.com
Fixes: 181567aa ("drm/i915: Do YCbCr 444->420 conversion via DP protocol converters")
Reviewed-by: NJani Nikula <jani.nikula@intel.com>

In the next commit where we split PWM related backlight functions from
higher-level backlight functions, we'll want to be able to retrieve the
backlight level for the current display panel from the
intel_panel_bl_funcs->setup() function using pwm_funcs->get(). Since
intel_panel_bl_funcs->setup() is called before we've fully read in the
current hardware state into our atomic state, we can't grab atomic
modesetting locks safely anyway in intel_panel_bl_funcs->setup(), and some
PWM backlight functions (vlv_get_backlight() in particular) require knowing
the currently used pipe we need to be able to discern the current display
pipe through other means. Luckily, we're already passing the current
display pipe to intel_panel_bl_funcs->setup() so all we have to do in order
to achieve this is pass down that parameter to intel_panel_bl_funcs->get().

So, fix this by accepting an additional pipe parameter in
intel_panel_bl_funcs->get(), and leave figuring out the current display
pipe up to the caller.
Signed-off-by: NLyude Paul <lyude@redhat.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114221709.2261452-2-lyude@redhat.com

Some vmm like hyperv and crosvm don't supply any ISA bridge to their guest,
when igd passthrough is equipped on these vmm, guest i915 display may
couldn't work as guest i915 detects PCH_NONE pch type.

When i915 runs as guest, this patch guess pch type through gpu type even
without ISA bridge.

v2: Fix CI warning
v3: Add HAS_DISPLAY()= true condition beforce guessing virt pch, then
    refactori.
v4: Fix CI warning
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Co-developed-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NXiong Zhang <xiong.y.zhang@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210114005819.4290-1-xiong.y.zhang@intel.com

drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op?
drivers/gpu/drm/i915/display/intel_dp.c:6922 intel_dp_update_420() warn: should this be a bitwise op?
drivers/gpu/drm/i915/display/intel_dp.c:6923 intel_dp_update_420() warn: should this be a bitwise op?

Inside drm_dp_downstream_rgb_to_ycbcr_conversion(), that parameter
'color_spc' is used as return port_cap[3] & color_spc, implying that it
is indeed a mask and not a boolean value.

Fixes: 522508b6 ("drm/i915/display: Let PCON convert from RGB to YCbCr if it can")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201223103917.14687-1-chris@chris-wilson.co.uk

We dropped the other redundant master_transcoder assignments
earlier, but this one slipped through. Get rid of it as well.
The crtc state gets fully reset before readout so there is
no point in doing this.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201019214337.19330-1-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

DG1 is missing those two WA so instead of copy and paste it to the DG1
function, here calling the function that implements it.

While at it also renaming tgl_init_clock_gating to
gen12lp_init_clock_gating as it is also used by DG1, RKL and ADL-S.

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113133759.72055-1-jose.souza@intel.com

Always prefer the kernel types over stdint types in i915.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113141317.30765-1-jani.nikula@intel.com

There are a number of functions that "init" pps in various ways. Try to
find some more consistency in the naming.

Rename:
 - intel_dp_init_panel_power_sequencer -> pps_init_delays
 - intel_dp_init_panel_power_sequencer_registers -> pps_init_registers
 - intel_dp_init_panel_power_timestamps -> pps_init_timestamps

as this is what the functions do. Skip the intel_ prefix here to
emphasize these are static and not exported.

No functional changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/15260c28060f3f90276ab395da4d3999ccdb641f.1610127741.git.jani.nikula@intel.com

This function is a bit of an outlier, but try to change to a name that
is more in line with the rest of the intel_pps functions. No functional
changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/644b89c1d88d4d2cd7a9426ec7d7ea14eb65a8bc.1610127741.git.jani.nikula@intel.com

Prefer keeping the unlocked variants hidden if possible. No functional
changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4b712770deab9de8c3aeea8df35269433977038a.1610127741.git.jani.nikula@intel.com

Follow the usual naming pattern for functions. "reset all" because it
iterates over all DP encoders. No functional changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b10013e2c976ca140b1ad62669e18a2e9f1e8c35.1610127741.git.jani.nikula@intel.com

Follow the usual naming pattern for functions. No functional changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f03f7195fb62b250847909e0972f69a151095529.1610127741.git.jani.nikula@intel.com

Add an "encoder reset" call to hide some more pps functions, and clean
up the callers. A minor functional change is not holding the pps lock
across the whole operation in intel_dp_encoder_reset, but instead doing
it in two steps.

v2: rename intel_pps_reinit to intel_pps_encoder_reset for clarity
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/84a50f2700b19c6719cd3e1e931c64f1e2027551.1610127741.git.jani.nikula@intel.com

Add a new init call to be called only once, unlike some of the other
various init calls. This lets us hide more functions within
intel_pps.c. No functional changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/290865ed9b0ea79120222a24c233a2d596239076.1610127741.git.jani.nikula@intel.com

Add a locked version of intel_pps_vdd_off_sync_unlocked() that does
everything the callers expect it to. No functional changes.

v2: Fix typo (Anshuman)
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1e722290208d827c5cae107fe41dbfe41a494793.1610127741.git.jani.nikula@intel.com

Follow the usual naming pattern for functions, both for the prefix and
the _unlocked suffix for functions that expect the lock to be held when
calling. No functional changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/d119605ba3d9c86647a524375de2d7e3d57a5676.1610127741.git.jani.nikula@intel.com

Follow the usual naming pattern for functions. We don't need to repeat
"panel" here. No functional changes.

v2: Fix comment (Anshuman)
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b858271bd4d9c4a2ce15a13301d7bd9f7d121eb5.1610127741.git.jani.nikula@intel.com

Follow the usual naming pattern for functions. No functional changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9887e4e278ed9a20da064bbf1d0845e52b7c3b3d.1610127741.git.jani.nikula@intel.com

Start following the usual naming pattern for functions. No functional
changes.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e37623750c592c08720f3b340cf85862d0f0ca12.1610127741.git.jani.nikula@intel.com

In a long overdue refactoring, split out all panel sequencer code from
intel_dp.c to new intel_pps.[ch].

The first part is mostly just code movement as-is, without cleanups or
functional changes.

We need to add a vlv_get_dpll() helper to get at the vlv/chv dpll from
pps code.

v2: Rebase.
Reviewed-by: NAnshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/14cc59d5734432ad976cd49ff8efce8fa413e5b2.1610127741.git.jani.nikula@intel.com

Always prefer the kernel types over stdint types in i915.

Cc: Imre Deak <imre.deak@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113141158.25513-1-jani.nikula@intel.com

skl_scaler_get_filter_select() isn't static and can't be inline.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113143726.19701-1-jani.nikula@intel.com

Some rcs0 workarounds were being incorrectly applied to the GT, and so
we failed to restore the expected register settings after a reset.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113225144.30810-2-chris@chris-wilson.co.uk

Some rcs0 workarounds were being incorrectly applied to the GT, and so
we failed to restore the expected register settings after a reset.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113225144.30810-1-chris@chris-wilson.co.uk

In the legacy ringbuffer submission, we still had an open-coded version
of intel_engine_stop_cs() with one additional verification step. Transfer
that verification to intel_engine_stop_cs() itself, and call it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113204709.15020-1-chris@chris-wilson.co.uk

Since we are system_highpri_wq, we expected the heartbeat to be
scheduled promptly. However, we see delays of over 10ms upsetting our
assertions. Accept this as inevitable and bump the minimum error
threshold to 20ms (from 6 jiffies).

<6> [616.784749] rcs0: Heartbeat delay: 3570us [2802, 9188]
<6> [616.807790] bcs0: Heartbeat delay: 2111us [745, 4372]
<6> [616.853776] vcs0: Heartbeat delay: 6485us [2424, 11637]
<3> [616.859296] vcs0: Heartbeat delay was 6485us, expected less than 6000us
<3> [616.860901] i915/intel_heartbeat_live_selftests: live_heartbeat_fast failed with error -22

v2: More context from CI.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113163115.5740-2-chris@chris-wilson.co.uk

Inject a fault into the engine reset and check that the outstanding
requests are completed despite the failed reset.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113205049.22565-1-chris@chris-wilson.co.uk

The DP PHY vswing/pre-emphasis level programming the driver does is
related to the DPTX -> first LTTPR link segment only. Accordingly it
should be only programmed when link training the first LTTPR and kept
as-is when training subsequent LTTPRs and the DPRX. For these latter
PHYs the vs/pe levels will be set in response to writing the
DP_TRAINING_LANEx_SET_PHY_REPEATERy DPCD registers (by an upstream LTTPR
TX PHY snooping this write access of its downstream LTTPR/DPRX RX PHY).
The above is also described in DP Standard v2.0 under 3.6.6.1.

While at it simplify and add the LTTPR that is link trained to the debug
message in intel_dp_set_signal_levels().

Fixes: b30edfd8 ("drm/i915: Switch to LTTPR non-transparent mode link training")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-2-imre.deak@intel.com

intel_dp_set_signal_levels() is needed for link training, so move it to
intel_dp_link_training.c.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201229172201.4155327-1-imre.deak@intel.com

Initialize all required entries from guc_set_default_submission, instead
of calling the execlists function. The previously inherited setup has
been copied over from the execlist code and simplified by removing the
execlists submission-specific parts.

v2: move setting of relative_mmio flag to engine_setup_common (Chris)
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: John Harrison <john.c.harrison@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113021236.8164-5-daniele.ceraolospurio@intel.com

Instead of starting the engine in execlists submission mode and then
switching to GuC, start directly in GuC submission mode. The initial
setup functions have been copied over from the execlists code
and simplified by removing the execlists submission-specific parts.

v2: remove unneeded unexpected starting state check (Chris)
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: John Harrison <john.c.harrison@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113021236.8164-4-daniele.ceraolospurio@intel.com

GuC owns the execlists state and the context IDs used for submission, so
the status of the ports and the CSB entries are not something we control
or can decode from the i915 side, therefore we can avoid dumping it. A
follow-up patch will also stop setting the csb pointers when using GuC
submission.

GuC dumps all the required events in the GuC logs when verbosity is set
high enough.
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113021236.8164-3-daniele.ceraolospurio@intel.com

Delete GuC code unused in future patches that rewrite the GuC interface
to work with the new firmware. Most of the code deleted relates to
workqueues or execlist port. The code is safe to remove because we still
don't allow GuC submission to be enabled, even when overriding the
modparam, so it currently can't be reached.

The defines + structs for the process descriptor and workqueue remain.
Although the new GuC interface does not require either of these for the
normal submission path multi-lrc submission does. The usage of the
process descriptor and workqueue for multi-lrc will be quite different
from the code that is deleted in this patch. A future patch will
implement multi-lrc submission.

v2: add a code in the commit message about the code being safe to
remove (Chris)
Signed-off-by: NMatthew Brost <matthew.brost@intel.com>
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: John Harrison <john.c.harrison@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210113021236.8164-2-daniele.ceraolospurio@intel.com