ILK is the only platform that we consider "gen5" and SNB is the only
platform we consider "gen6." Add an IS_SANDYBRIDGE() macro and then
replace numeric platform tests for these two generations with direct
platform tests with the following Coccinelle semantic patch:
@@ expression dev_priv; @@
- IS_GEN(dev_priv, 5)
+ IS_IRONLAKE(dev_priv)
@@ expression dev_priv; @@
- IS_GEN(dev_priv, 6)
+ IS_SANDYBRIDGE(dev_priv)
@@ expression dev_priv; @@
- IS_GEN_RANGE(dev_priv, 5, 6)
+ IS_IRONLAKE(dev_priv) || IS_SANDYBRIDGE(dev_priv)
This will simplify our upcoming patches which eliminate INTEL_GEN()
usage in the display code.
v2:
- Reverse ilk/snb order for IS_GEN_RANGE conversion. (Ville)
- Rebase + regenerate from semantic patch
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-2-matthew.d.roper@intel.com
Use the correct DSS CTL registers for ICL DSI transcoders.
As a side effect, this also brings back the sanity check for trying to
use pipe DSC registers on pipe A on ICL.
Fixes: 8a029c113b ("drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave")
References: http://lore.kernel.org/r/87eegxq2lq.fsf@intel.com
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: <stable@vger.kernel.org> # v5.11+
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319115333.8330-1-jani.nikula@intel.com
(cherry picked from commit 5706d02871)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The enabled_planes bitmask was supposed to track logically enabled
planes (ie. fb!=NULL and crtc!=NULL), but instead we end up putting
even disabled planes into the bitmask since
intel_plane_atomic_check_with_state() only takes the early exit
if the plane was disabled and stays disabled. I think I misread
the early said codepath to exit whenever the plane is logically
disabled, which is not true.
So let's fix this up properly and set the bit only when the plane
actually is logically enabled.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: ee42ec19ca ("drm/i915: Track logically enabled planes for hw state")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
(cherry picked from commit 97bc7ffa1b)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
By the specification the 0xF0000 - 0xF02FF range is only valid if the
LTTPR revision at 0xF0000 is at least 1.4. Disable the LTTPR support
otherwise.
Fixes: 7b2a4ab8b0 ("drm/i915: Switch to LTTPR transparent mode link training")
Cc: <stable@vger.kernel.org> # v5.11
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-4-imre.deak@intel.com
(cherry picked from commit 1663ad4936)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
By the specification the 0xF0000-0xF02FF range is only valid when the
DPCD revision is 1.4 or higher. Disable LTTPR support if this isn't so.
Trying to detect LTTPRs returned corrupted values for the above DPCD
range at least on a Skylake host with an LG 43UD79-B monitor with a DPCD
revision 1.2 connected.
v2: Add the actual version check.
v3: Fix s/DRPX/DPRX/ typo.
Fixes: 7b2a4ab8b0 ("drm/i915: Switch to LTTPR transparent mode link training")
Cc: <stable@vger.kernel.org> # v5.11
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317190149.4032966-1-imre.deak@intel.com
(cherry picked from commit 264613b406)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The spec requires to use at least 3.2ms for the AUX timeout period if
there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming
spec update makes this more specific, by requiring a 3.2ms minimum
timeout period for the LTTPR detection reading the 0xF0000-0xF0007
range (3.6.5.1).
Accordingly disable LTTPR detection until GLK, where the maximum timeout
we can set is only 1.6ms.
Link training in the non-transparent mode is known to fail at least on
some SKL systems with a WD19 dock on the link, which exposes an LTTPR
(see the References below). While this could have different reasons
besides the too short AUX timeout used, not detecting LTTPRs (and so not
using the non-transparent LT mode) fixes link training on these systems.
While at it add a code comment about the platform specific maximum
timeout values.
v2: Add a comment about the g4x maximum timeout as well. (Ville)
Reported-by: Takashi Iwai <tiwai@suse.de>
Reported-and-tested-by: Santiago Zarate <santiago.zarate@suse.com>
Reported-and-tested-by: Bodo Graumann <mail@bodograumann.de>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166
Fixes: b30edfd8d0 ("drm/i915: Switch to LTTPR non-transparent mode link training")
Cc: <stable@vger.kernel.org> # v5.11
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-2-imre.deak@intel.com
(cherry picked from commit 984982f3ef)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Use the correct DSS CTL registers for ICL DSI transcoders.
As a side effect, this also brings back the sanity check for trying to
use pipe DSC registers on pipe A on ICL.
Fixes: 8a029c113b ("drm/i915/dp: Modify VDSC helpers to configure DSC for Bigjoiner slave")
References: http://lore.kernel.org/r/87eegxq2lq.fsf@intel.com
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Animesh Manna <animesh.manna@intel.com>
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: <stable@vger.kernel.org> # v5.11+
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319115333.8330-1-jani.nikula@intel.com
The enabled_planes bitmask was supposed to track logically enabled
planes (ie. fb!=NULL and crtc!=NULL), but instead we end up putting
even disabled planes into the bitmask since
intel_plane_atomic_check_with_state() only takes the early exit
if the plane was disabled and stays disabled. I think I misread
the early said codepath to exit whenever the plane is logically
disabled, which is not true.
So let's fix this up properly and set the bit only when the plane
actually is logically enabled.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: ee42ec19ca ("drm/i915: Track logically enabled planes for hw state")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
hdcp2_enable_stream_encryption shouldn't get called in case
of any port authentication or encryption error, though
hdcp2_enable_stream_encryption checks for link encryption
before enabling stream encryption and returns error but
this return error code won't be correct in case of any error
due to port authentication and encryption.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319100208.5886-4-anshuman.gupta@intel.com
When stream encryption enabling fails due to Link encryption status
has stopped, prepare HDCP2 for recovery by disabling port authentication
and encryption such that it can re-attempt port authentication
and encryption.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319100208.5886-3-anshuman.gupta@intel.com
DP MST Link Check performed only for the connector involved with
HDCP port authentication and encryption, for other connector it
simply returns link check with true and update the uevent.
Therefore in case of HDCP 2.2 link failure, disable HDCP encryption
and de-authenticate the port so next time it can enable port
authentication and encryption.
Cc: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319100208.5886-2-anshuman.gupta@intel.com
It requires to check streams type1 capability in mst topology
by checking Rxinfo instead connector HDCP2.x capability in
order to enforce type0 stream encryption in a mix of
HDCP {1.x,2.x} mst topology.
Rxcaps always shows HDCP 2.x capability of immediate downstream
connector. Let's use Rxinfo HDCP1_DEVICE_DOWNSTREAM bit to
detect a HDCP {1.x,2.x} mix mst topology.
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Ramalingam C <ramalingam.c@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210319091732.17547-1-anshuman.gupta@intel.com
Extract the g4x+ HDMI low level code to its own file,
leaving intel_hdmi.c to deal with higher level issues.
The infoframe support I decided to leave in intel_hdmi.c
since I think we need to move that as a whole to its own file.
It is after all used also for DP SDPs, so no longer HDMI
specific.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318161015.22070-7-ville.syrjala@linux.intel.com
Move the g4x+ DP code into a new file. This will leave mostly
platform agnostic code in intel_dp.c. Well, the misplaced phy
test stuff pretty much ruins that, but let's squint real hard
for now.
v2: Add comment exlaining which platforms are covered (Daniel)
Leave intel_dp_unused_lane_mask() be since it is pretty generic
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210318161015.22070-6-ville.syrjala@linux.intel.com
By the specification the 0xF0000 - 0xF02FF range is only valid if the
LTTPR revision at 0xF0000 is at least 1.4. Disable the LTTPR support
otherwise.
Fixes: 7b2a4ab8b0 ("drm/i915: Switch to LTTPR transparent mode link training")
Cc: <stable@vger.kernel.org> # v5.11
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-4-imre.deak@intel.com
By the specification the 0xF0000-0xF02FF range is only valid when the
DPCD revision is 1.4 or higher. Disable LTTPR support if this isn't so.
Trying to detect LTTPRs returned corrupted values for the above DPCD
range at least on a Skylake host with an LG 43UD79-B monitor with a DPCD
revision 1.2 connected.
v2: Add the actual version check.
v3: Fix s/DRPX/DPRX/ typo.
Fixes: 7b2a4ab8b0 ("drm/i915: Switch to LTTPR transparent mode link training")
Cc: <stable@vger.kernel.org> # v5.11
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317190149.4032966-1-imre.deak@intel.com
The spec requires to use at least 3.2ms for the AUX timeout period if
there are LT-tunable PHY Repeaters on the link (2.11.2). An upcoming
spec update makes this more specific, by requiring a 3.2ms minimum
timeout period for the LTTPR detection reading the 0xF0000-0xF0007
range (3.6.5.1).
Accordingly disable LTTPR detection until GLK, where the maximum timeout
we can set is only 1.6ms.
Link training in the non-transparent mode is known to fail at least on
some SKL systems with a WD19 dock on the link, which exposes an LTTPR
(see the References below). While this could have different reasons
besides the too short AUX timeout used, not detecting LTTPRs (and so not
using the non-transparent LT mode) fixes link training on these systems.
While at it add a code comment about the platform specific maximum
timeout values.
v2: Add a comment about the g4x maximum timeout as well. (Ville)
Reported-by: Takashi Iwai <tiwai@suse.de>
Reported-and-tested-by: Santiago Zarate <santiago.zarate@suse.com>
Reported-and-tested-by: Bodo Graumann <mail@bodograumann.de>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/3166
Fixes: b30edfd8d0 ("drm/i915: Switch to LTTPR non-transparent mode link training")
Cc: <stable@vger.kernel.org> # v5.11
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210317184901.4029798-2-imre.deak@intel.com
Remove code for resetting frl related members from intel_disable_dp, as
this is not applicable for older platforms.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210309043915.1921-3-ankit.k.nautiyal@intel.com
Add intel_bios_encoder_data pointer to encoder, and use it for hdmi and
dp iboost. For starters, we only set the encoder->devdata for DDI
encoders, i.e. we can only use it for data that is used by DDI encoders.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.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/4bc49244ce68e136e5b21db4c4e6554bec9ac0fb.1615998927.git.jani.nikula@intel.com
Stop caching the information in ddi_port_info. We're phasing out
ddi_port_info usage completely, and prefer using the VBT child device
information directly using the provided helpers.
v2:
- Remove supports_typec_usb & supports_tbt from ddi_vbt_port_info (Lucas)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.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/b04bd183e7554aeb4bc3962af90d63171aa32fc2.1615998927.git.jani.nikula@intel.com
Start using struct intel_bios_encoder_data directly. We'll start
sanitizing the child device data directly as well, instead of the cached
data in ddi_port_info[]. The one downside here is having to store a
non-const pointer back to intel_bios_encoder_data.
Eventually we'll be able to have a direct pointer from encoder to
intel_bios_encoder_data, removing the need to go through the
ddi_port_info[] array altogether. And we'll be able to remove all the
cached data in ddi_port_info[].
v2:
- Remove supports_dp and supports_edp from ddi_port_info too
- Add devdata != NULL check in intel_bios_is_port_edp()
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> # v1
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/061df32a012ff640060920fcd730fb23f8717ee8.1615998927.git.jani.nikula@intel.com
These will be exposed to the rest of the driver and replace other
functions. Everything will operate on the child devices.
v2:
- Rebased, removed stray blank line
- Also abstracted intel_bios_encoder_supports_crt (Lucas)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.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/2bd40ccc093796d16300742d1789d78ffac3c450.1615998927.git.jani.nikula@intel.com
Instead of initialing data directly in ddi_port_info array, create fake
child devices for default outputs when the VBT is missing. This makes
further unification of output handling easier.
This will make intel_bios_is_port_present() return true for the fake
child devices. This may cause subtle changes in a handful of places.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.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/91675b40a78bd04bf138598d979661257181880d.1615998927.git.jani.nikula@intel.com
There are two main cases where the default outputs are useful when the
VBT is missing:
- There are some DDI-platform Chromebooks out there that do not have a
VBT, which worked by coincidence because of the default outputs. The
machines need to continue to work.
- Early platform enabling when the VBT might not be available. (This
could be circumvented by using the i915.vbt_firmware parameter.)
Prepare for generating fake child devices for the default outputs by
limiting the number of outputs. We don't want to generate excessive
amounts of fake child devices. This could be perhaps be limited even
more in the future, but match what's possible on all DDI platforms.
Note that limiting the defaults to non-TypeC ports in commit
828ccb31cf ("drm/i915/icl: Add TypeC ports only if VBT is present") is
a more strict limit, and makes this a no-op on recent platforms.
v2: Rewrote commit message
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.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/5c9c9743af1c7265a2c976d582b7a6685ec0c414.1615998927.git.jani.nikula@intel.com
Pre-DDI and non-CHV aren't using the information created here anyway, so
don't bother setting the defaults for them. This should be a
non-functional change, but is separated here to catch any regressions in
a single commit.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/41526a4eee5fb0de8d7f1ffe4c09965b63ccbaa8.1615998927.git.jani.nikula@intel.com
Highlights:
- Alderlake S enabling, via topic branch (Aditya, Anusha, Caz, José, Lucas, Matt, Tejas)
- Refactor display code to shrink intel_display.c etc. (Dave)
- Support more gen 9 and Tigerlake PCH combinations (Lyude, Tejas)
- Add eDP MSO support (Jani)
Display:
- Refactor to support multiple PSR instances (Gwan-gyeong)
- Link training debug logging updates (Sean)
- Updates to eDP fixed mode handling (Jani)
- Disable PSR2 on JSL/EHL (Edmund)
- Support DDR5 and LPDDR5 for bandwidth computation (Clint, José)
- Update VBT DP max link rate table (Shawn)
- Disable the QSES check for HDCP2.2 over MST (Juston)
- PSR updates, refactoring, selective fetch (José, Gwan-gyeong)
- Display init sequence refactoring (Lucas)
- Limit LSPCON to gen 9 and 10 platforms (Ankit)
- Fix DDI lane polarity per VBT info (Uma)
- Fix HDMI vswing programming location in mode set (Ville)
- Various display improvements and refactorings and cleanups (Ville)
- Clean up DDI clock routing and readout (Ville)
- Workaround async flip + VT-d corruption on HSW/BDW (Ville)
- SAGV watermark fixes and cleanups (Ville)
- Silence pipe tracepoint WARNs (Ville)
Other:
- Remove require_force_probe protection from RKL, may need to be revisited (Tejas)
- Detect loss of MMIO access (Matt)
- GVT display improvements
- drm/i915: Disable runtime power management during shutdown (Imre)
- Perf/OA updates (Umesh)
- Remove references to struct drm_device.pdev, via topic branch (Thomas)
- Backmerge (Jani)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87v99rnk1g.fsf@intel.com
One instance of DRM_DEBUG_KMS was leftover in dp_link_training, convert
it to the new shiny.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210310214845.29021-2-sean@poorly.run
This patch adds some newlines which are missing from debug messages.
This will prevent logs from being stacked up in dmesg.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210310214845.29021-1-sean@poorly.run
Rename a bunch of the skl+ watermark struct members to
have sensible names. Avoids me having to think what
plane_res_b/etc. means.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210305153610.12177-7-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Let's check that we actually found the PLL before doing the
port_clock readout, just in case the hardware was severly
misprogrammed by the previous guy. Not sure the hw would
even survive such misprogramming without hanging but no
real harm in checking anyway.
Cc: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210310194351.6233-1-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Now that all the encoder clock stuff is uniformly abstracted
for all hsw+ platforms, let's extend icl_sanitize_encoder_pll_mapping()
to cover all of them.
Not sure there is a particular benefit in doing so, but less special
cases always makes me happy.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-7-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Support reading out the current state of the DDI clock.
Not sure we really want this. Seems a bit excessive just to
restore the debug print to icl_sanitize_encoder_pll_mapping()?
But maybe there's more use for it?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-6-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Move the *_get_ddi_pll() stuff into the encodet->get_config() hook.
There it neatly sits next to the matching .{enable,disable}_clock()
functions.
In order to avoid excessive boilerplate I changed the behaviour
such that all platforms now do the readout via
crtc_state->port_dpll[].
ICL+ TC is still a bit special due to TBTPLL not having a functional
.get_freq(). Should probably change that by adopting the LCPLL
approach, but that would require a fairly substantial rework of the
DPLL ID handling. So leave it for later.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-5-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
All the other places we have use pipes instead of crtc indices
when tracking resource usage. Life is easier when we do it
the same way always, so switch the dpll mgr to using pipes as
well. Looks like it was actually mixing these up in some cases
so it would not even have worked correctly except when the
device has a contiguous set of pipes starting from pipe A.
Granted, that is the typical case but supposedly it may not
always hold on modern hw.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-4-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
The clock readout for DDI encoders needs to moved into the encoders.
To that end intel_dpll_readout_hw_state() needs to happen after
the encoder readout as otherwise it can't correctly populate
the PLL crtc_mask/active_mask bitmasks.
v2: Populate DPLL ref clocks before the encoder->get_config()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210225161225.30746-1-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Stop assuming intel_ddi_get_config() is all we need from the primary
encoder, and instead call it via the .get_config() vfunc. This
will allow customized .get_config() for the primary, which I plan
to use to handle the differences in the clock readout between various
platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210224144214.24803-2-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
commit 33267703df ("drm/i915/dsi: Enable software vblank counter")
claims to get the mode_flags from the crtc_state, but in fact does
not. Fix it to do it right.
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
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/20210304170421.10901-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
For platforms/outputs without hardware frame counters we can't
call drm_crtc_accurate_vblank_count() when the vblank support is
disabled or we just get a WARN due to the crtc timings
(vblank->hwmode) being considered invalid. Note that until the
pipe in question has been enabled and drm_crtc_set_max_vblank_count()
has been called on it we would also take this path on platforms
which have a working frame counter. So getting the WARN is rather
likely on any platform unless you always boot with lots of displays
plugged in.
Also even on hardware with a working frame counter we may not be
able to read the actual frame counter register on disabled pipes
due the relevant power well being disabled. Ie. would just result
in the unclaimed reg spew.
So let's just avoid all this an directly report zero in case
the pipe is disabled.
Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-3-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
On platforms/outputs without a working frame counter we rely
on the vblank code to cook up the frame counter from the timestamps.
That requires that vblank support is enabled. Thus we need to
move the pipe enable/disable tracepoints to the other side
of the drm_vblank_{on,off}() calls. There shouldn't really be
much happening between these old and new call sites so the
tracepoints should still provide reasonable data.
The alternative would be to give up on having the frame counter
values in the trace which would render the tracepoints more or
less pointless.
v2: Missed one case in intel_ddi_post_disable()
Drop the now useless i915_trace.h includes
Reported-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Tested-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210304170421.10901-2-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
In the case of MSO (Multi-SST Operation), the EDID contains the timings
for a single panel segment. We'll want to hide the fact from userspace,
and expose modes that span the entire display.
Don't modify the EDID, as the userspace should not use that for
modesetting, only modify the actual modes.
v3: Use pixel overlap if available.
v2: Rename intel_dp_mso_mode_fixup -> intel_edp_mso_mode_fixup
Cc: Nischal Varide <nischal.varide@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/2862284eb033bb0ffc96134b7d5b11bf29e4587f.1614682842.git.jani.nikula@intel.com
Add splitter configuration to crtc state, and read it where
supported. Also add splitter state dumping. The stream splitter will be
required for eDP MSO.
v4:
- Catch invalid splitter configuration (Uma)
v3:
- Convert segment timings to full panel timings.
- Refer to splitter instead of mso in crtc state.
- Dump splitter state.
v2: Add warning for mso being enabled on pipes other than A.
Cc: Nischal Varide <nischal.varide@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/95cbe1c9d45edf3e3ec252e49fb49055def98155.1614682842.git.jani.nikula@intel.com
Get rid of the nonsense cursor special case in verify_wm_state()
by just iterating through all the planes. And let's use the
canonical [PLANE:..] style in the debug prints while at it.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-8-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
We know which WM0 (normal vs. SAGV) we supposedly programmed
into the hardware, so just check against that instead of accepting
either watermark as valid.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-7-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Seems to me that if we calculate WM0 using the bumped up SAGV latency
we need to calculate the transition watermark accordingly. Track it
alongside the other watermarks.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-6-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
We'll want a SAGV transition watermark as well. Prepare
for that by collecting SAGV wm0 into a sub-strcture.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210226153204.1270-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Populate conn_state->max_bpc with something sensible from the start.
Otherwise it's possible that we get to compute_sink_pipe_bpp() with
max_bpc==0.
The specific scenario goes as follows:
1. Initial connector state allocated with max_bpc==0
2. Trigger a modeset on the crtc feeding the connector, without
actually adding the connector to the commit
3. drm_atomic_connector_check() is skipped because the
connector has not yet been added, hence conn_state->max_bpc
retains its current value
4. drm_atomic_helper_check_modeset() ->
drm_atomic_add_affected_connectors() -> the connector
is now part of the commit
5. compute_baseline_pipe_bpp() -> MISSING_CASE(max_bpc==0)
Note that pipe_bpp itself may not be populated on pre-g4x machines,
in which case we just fall back to max_bpc==8 and let .compute_config()
limit the resulting pipe_bpp further if necessary.
Cc: Daniel Vetter <daniel@ffwll.ch>
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210216160035.4780-1-ville.syrjala@linux.intel.com
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
core:
- vblank fence timing improvements
dma-buf:
- improve error handling
ttm:
- memory leak fix
msm:
- a6xx speedbin support
- a508, a509, a512 support
- various a5xx fixes
- various dpu fixes
- qseed3lite support for sm8250
- dsi fix for msm8994
- mdp5 fix for framerate bug with cmd mode panels
- a6xx GMU OOB race fixes that were showing up in CI
- various addition and removal of semicolons
- gem submit fix for legacy userspace relocs path
amdgpu:
- Clang warning fix
- S0ix platform shutdown/poweroff fix
- Misc display fixes
i915:
- color format fix
- -Wuninitialised reenabled
- GVT ww locking, cmd parser fixes
atyfb:
- fix build
rockchip:
- AFBC modifier fix
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJgN/iUAAoJEAx081l5xIa+HZQP/RiK+wO8OvSrLeflUWEr2gUC
5NBbhGBB2dTNXeL7zFYXk4hC5HLYG/aDVfgXDctWVVcUslziEu3vsnHUuQQZrqxM
8MYRIaOvb+Ic/ZzU8A6Jz6gK3zv8Rmu2/PXOLjkYFTfpwAKPDhipCr6momn3rGLz
cwzcKwCCHVPIUb6Hp+4739dsI8TsxhBcuIpjj+8yRZHxFNUue+40n1nPh6GTWXwf
rbnr/sR0SnfUwv8pwzjLeH4Fuj8w2S65Cdbjap868jO2b0qVrGyLpRBTd3611L1X
/HhFOnJ7BHHvZ28Jsgl3cbtaKqlB1geBq1Yh04xZWrHxcMhVC+J2cOtW2wyMJZ99
RayxPyxnCig0BuSHQzuWMT4o2wKbTgxBWL/Ys+QFVwZd0Y+BbKVrFPn2pRJ1vtb8
LNAQVppcyfdAIXF9eqse+JhqTn2Z2BgjM4cm/8EA7yvX6afRm+GJKghrLjWKYqrI
2iZKc8e4pgc532D3NseK2Xu4otIp7xPSW0wL6+g2ozLvHnwH+GJGI8TY85PoVJF2
ZrWkDWxW68v3mpxeJnX3VoMS9RUhBJjRoqcBsetf+bLL/qHeIdqEpPaTa9PAOGY4
CVR5vW6qvXfCjLCht8x/BTvLIToTFaHMIun6QYgCX1HbGu2k9ghpyC/IwiwwLsxV
Yh9wHBR6Bzi/FRnZh23z
=hrdL
-----END PGP SIGNATURE-----
Merge tag 'drm-next-2021-02-26' of git://anongit.freedesktop.org/drm/drm
Pull more drm updates from Dave Airlie:
"This is mostly fixes but I missed msm-next pull last week. It's been
in drm-next.
Otherwise it's a selection of i915, amdgpu and misc fixes, one TTM
memory leak, nothing really major stands out otherwise.
core:
- vblank fence timing improvements
dma-buf:
- improve error handling
ttm:
- memory leak fix
msm:
- a6xx speedbin support
- a508, a509, a512 support
- various a5xx fixes
- various dpu fixes
- qseed3lite support for sm8250
- dsi fix for msm8994
- mdp5 fix for framerate bug with cmd mode panels
- a6xx GMU OOB race fixes that were showing up in CI
- various addition and removal of semicolons
- gem submit fix for legacy userspace relocs path
amdgpu:
- clang warning fix
- S0ix platform shutdown/poweroff fix
- misc display fixes
i915:
- color format fix
- -Wuninitialised reenabled
- GVT ww locking, cmd parser fixes
atyfb:
- fix build
rockchip:
- AFBC modifier fix"
* tag 'drm-next-2021-02-26' of git://anongit.freedesktop.org/drm/drm: (60 commits)
drm/panel: kd35t133: allow using non-continuous dsi clock
drm/rockchip: Require the YTR modifier for AFBC
drm/ttm: Fix a memory leak
drm/drm_vblank: set the dma-fence timestamp during send_vblank_event
dma-fence: allow signaling drivers to set fence timestamp
dma-buf: heaps: Rework heap allocation hooks to return struct dma_buf instead of fd
dma-buf: system_heap: Make sure to return an error if we abort
drm/amd/display: Fix system hang after multiple hotplugs (v3)
drm/amdgpu: fix shutdown and poweroff process failed with s0ix
drm/i915: Nuke INTEL_OUTPUT_FORMAT_INVALID
drm/i915: Enable -Wuninitialized
drm/amd/display: Remove Assert from dcn10_get_dig_frontend
drm/amd/display: Add vupdate_no_lock interrupts for DCN2.1
Revert "drm/amd/display: reuse current context instead of recreating one"
drm/amd/pm/swsmu: Avoid using structure_size uninitialized in smu_cmn_init_soft_gpu_metrics
fbdev: atyfb: add stubs for aty_{ld,st}_lcd()
drm/i915/gvt: Introduce per object locking in GVT scheduler.
drm/i915/gvt: Purge dev_priv->gt
drm/i915/gvt: Parse default state to update reg whitelist
dt-bindings: dp-connector: Drop maxItems from -supply
...
In Bspec the TGL TypeC ports are TC1-6, the AUX power well request flags
are USBC1-6/TBT1-6, so for clarity use these names in the port power
domain names instead of the D-I terminology (which Bspec uses only for
the ICL TypeC ports).
A domain name should follow the <domain>_<pipe/transcoder/port/aux_ch>
format. Add the new aliases based on this, leaving a change to rename
all the rest accordingly for a follow-up.
No functional change.
v2: Add comment to commit log about unifying domain names. (Jose)
Cc: Souza Jose <jose.souza@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210222210400.940158-1-imre.deak@intel.com
Even though GEN12+ HW supports PSR + DC3CO, DMC's HW DC3CO exit mechanism
has an issue with using of Selective Fecth and PSR2 manual tracking.
And as some GEN12+ platforms (RKL, ADL-S) don't support PSR2 HW tracking,
Selective Fetch will be enabled by default on that platforms.
Therefore if the system enables PSR Selective Fetch / PSR manual tracking,
it does not allow DC3CO dc state, in that case.
When this DC3CO exit issue is addressed while PSR Selective Fetch is
enabled, this restriction should be removed.
v2: Address Jose's review comment.
- Fix typo
- Move check routine of DC3CO ability to
tgl_dc3co_exitline_compute_config()
v3: Change the check routine of enablement of psr2 sel fetch. (Jose)
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210222213006.1609085-1-gwan-gyeong.mun@intel.com
We tend to use output_format!=RGB as a shorthand for YCbCr, but
this fails if we have a disabled crtc where output_format==INVALID.
We're now getting some fail from intel_color_check() when we have:
hw.enable==false
hw.ctm!=NULL
output_format==INVALID
Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the
dumpster, and thus everything defaults to RGB when the crtc
is disabled.
This does beg the deeper question of how much of the state
should we in fact be validating when hw/uapi.enable==false.
And should we even be doing the uapi->hw copy when
uapi.enable==false? So far I've not been able to come up with
satisfactory answers for myself, so I'm putting it off for the
moment.
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Fixes: 0aa5c3835c ("drm/i915: support two CSC module on gen11 and later")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205202322.27608-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
(cherry picked from commit 7e07c68f06)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Read and debug log the eDP sink MSO configuration. Do not actually do
anything with the information yet besides logging.
FIXME: The pixel overlap is present in DisplayID 2.0, but we don't have
parsing for that. Assume zero for now. We could also add quirks for
non-zero pixel overlap before DisplayID 2.0 parsing.
v3: Add placeholder for pixel overlap.
v2: Rename intel_dp_mso_init -> intel_edp_mso_init
Cc: Nischal Varide <nischal.varide@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/24ef61574e5af12cd86d5b85afbfbd4ac2f9de25.1613054234.git.jani.nikula@intel.com
This will set the right value of source_support when the port
encoder/port supports PSR but sink don't.
This change will also be needed in future for panel replay as psr
struct needs to be initialized even if disconnected or current sink
don't support PSR.
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-4-jose.souza@intel.com
If source_support is set the platform supports PSR so no need to check
it again at every CAN_PSR().
Also removing the intel_dp_is_edp() calls, if sink_support is set
the sink connected is for sure a eDP panel.
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-3-jose.souza@intel.com
There is no support for two pipes one transcoder for PSR and if we had
that the current code should not use cpu_transcoder.
Also I can't see a scenario where crtc_state->enable_psr2_sel_fetch is
set and PSR is not enabled and if by a bug it happens PSR HW will just
ignore any value in set in PSR2_MAN_TRK_CTL.
So dropping all the rest and keeping the same behavior that we have
with intel_psr2_program_plane_sel_fetch().
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209181439.215104-2-jose.souza@intel.com
Right now CI is blacklisting module reload, so we need to be able to
enable PSR2 selective fetch in run time to test this feature before
enable it by default.
Changes in IGT will also be needed.
v2:
- Fixed handling of I915_PSR_DEBUG_ENABLE_SEL_FETCH in
intel_psr_debug_set()
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209205036.351076-1-jose.souza@intel.com
According to Bspec #20124, max link rate table for DP was updated
at BDB version 230. Max link rate can support upto UHBR.
After migrate to BDB v230, the definition for LBR, HBR2 and HBR3
were changed. For backward compatibility. If BDB version was
from 216 to 229. Driver have to follow original rule to configure
DP max link rate value from VBT.
v2: split the mapping table to two for old and new BDB definition.
v3: return link rate instead of assigning it.
v4: remove the useless variable.
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: William Tseng <william.tseng@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
[vsyrjala: Try to retain the comment that VBT version 216 added some of this]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210218052333.16109-1-shawn.c.lee@intel.com
When we sanitize planes let's wait for the scanout to stop
before we let the subsequent code tear down the ggtt mappings
and whatnot. Cures an underrun on my ivb when I boot with
VT-d enabled and the BIOS fb gets thrown out due to stolen
being considered unusable with VT-d active.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210217162050.13803-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
We tend to use output_format!=RGB as a shorthand for YCbCr, but
this fails if we have a disabled crtc where output_format==INVALID.
We're now getting some fail from intel_color_check() when we have:
hw.enable==false
hw.ctm!=NULL
output_format==INVALID
Let's avoid that by throwing INTEL_OUTPUT_FORMAT_INVALID to the
dumpster, and thus everything defaults to RGB when the crtc
is disabled.
This does beg the deeper question of how much of the state
should we in fact be validating when hw/uapi.enable==false.
And should we even be doing the uapi->hw copy when
uapi.enable==false? So far I've not been able to come up with
satisfactory answers for myself, so I'm putting it off for the
moment.
Cc: Lee Shawn C <shawn.c.lee@intel.com>
Fixes: 0aa5c3835c ("drm/i915: support two CSC module on gen11 and later")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2964
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205202322.27608-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Switch DRM drivers from drm_get_format_name() to %p4cc. This gets rid of a
large number of temporary variables at the same time.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20210216155723.17109-4-sakari.ailus@linux.intel.com
ilk+ planes get notably unhappy when the plane x+w exceeds
the stride. This wasn't a problem previously because we
always aligned SURF to the closest tile boundary so the
x offset never got particularly large. But now with async
flips we have to align to 256KiB instead and thus this
becomes a real issue.
On ilk/snb/ivb it looks like the accesses just wrap
early to the next tile row when scanout goes past the
SURF+n*stride boundary, hsw/bdw suffer more heavily and
start to underrun constantly. i965/g4x appear to be immune.
vlv/chv I've not yet checked.
Let's borrow another trick from the skl+ code and search
backwards for a better SURF offset in the hopes of getting the
x offset below the limit. IIRC when I ran into a similar issue
on skl years ago it was causing the hardware to fall over
pretty hard as well.
And let's be consistent and include i965/g4x in the check
as well, just in case I just got super lucky somehow when
I wasn't able to reproduce the issue. Not that it really
matters since we still use 4k SURF alignment for i965/g4x
anyway.
Fixes: 6ede6b0616 ("drm/i915: Implement async flips for vlv/chv")
Fixes: 4bb18054ad ("drm/i915: Implement async flip for ilk/snb")
Fixes: 2a636e240c ("drm/i915: Implement async flip for ivb/hsw")
Fixes: cda195f13a ("drm/i915: Implement async flips for bdw")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209021918.16234-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 59fb8218c8)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
[Rodrigo also exported some functions from intel_display.c during backport]
Instead of every new platform having yet another masive
copy of the whole PLL sanitation code, let's just reuse the
.disable_clock() hook for this purpose. We do need to plug
this into the ICL+ DSI code for that, but fortunately it
already has a suitable function we can use.
We do lose the debug message though on account of not bothering
to check if the clock is actually enabled or not before turning
it off. We could introduce yet another vfunc to query the current
state, but not sure it's worth the hassle?
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-14-ville.syrjala@linux.intel.com
Since .{enable,disable}_clock() are already vfuncs it's a bit silly to
have if-ladders inside them. Just provide specialized version for adl-s
and rkl so we don't need any of that.
v2: s/dev_priv/i915/ (Lucas)
Fix typos in platform names (Lucas)
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-13-ville.syrjala@linux.intel.com
The other DDI .enable_clock() functions are trying to protect us
against pll==NULL. A bit tempted to throw out all the WARNs as
just unnecessary noise, but I guess they might have some use
when poking around the shared_dpll code (not sure it wouldn't
oops elsewhere though). So let's unify it all and sprinkle in
the missing WARNs for icl/dg1.
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-11-ville.syrjala@linux.intel.com
The current code attempts to protect the RMWs into global
clock routing registers with a mutex, but forgets to do so
in a few places. Let's remedy that.
Note that at the moment we serialize all modesets onto single
wq, so this shouldn't actually matter. But maybe one day we
wish to attempt parallel modesets again...
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-10-ville.syrjala@linux.intel.com
For ICL+ we have several styles of clock routing for DDIs:
1) TC DDI + TC PHY
-> needs DDI_CLK_SEL==MG/TBT part form intel_ddi_clk_{select,disable}()
and ICL_DPCLKA_CFGCR0_TC_CLK_OFF part form icl_{map,unmap}_plls_to_ports()
2) ICL/TGL combo DDI + combo PHY
-> just need the stuff from icl_{map,unmap}_plls_to_ports()
3) JSL/EHL TC DDI + combo PHY
-> needs DDI_CLK_SEL==MG part from intel_ddi_clk_{select,disable}() and
the full combo style clock selection from icl_{map,unmap}_plls_to_ports()
4) ADLS/RKL
-> these use both TC and combo DDIs with combo PHYs, however they
always use the full combo style clock selection as per
icl_{map,unmap}_plls_to_ports() and do not use DDI_CLK_SEL at all,
thus get treated the same as 2)
We extract all that from the current mess in the following way:
1) icl_ddi_tc_{enable,disable}_clock()
2) icl_ddi_combo_{enable,disable}_clock()
3) jsl_ddi_tc_{enable,disable}_clock()
4) for now we reuse icl_ddi_combo_{enable,disable}_clock() here
v2: s/dev_priv/i915/ (Lucas)
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-8-ville.syrjala@linux.intel.com
Yank out the HSW/BDW code from intel_ddi_clk_{select,disable}()
and put it into the new encoder .{enable,disable}_clock() vfuncs.
v2: s/dev_priv/i915/ (Lucas)
v3: Deal with FDI
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-4-ville.syrjala@linux.intel.com
The current code dealing with the clock routing for DDI encoders
is a maintenance nightmare. Let's start cleaning it up by allowing
the encoder to provide vfuncs for enablign/disabling the clock.
We leave them initially unimplemented, falling back to the old
if-else approach.
v2: Convert the FDI enable sequence
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> #v2
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-3-ville.syrjala@linux.intel.com
We want to put all DDI clock routing code into one place.
Unify the FDI enable sequence to use the standard function
instead of hand rolling its own. The disable sequence already
uses the normal thing.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210205214634.19341-2-ville.syrjala@linux.intel.com
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
intel_init_audio_hooks() sets up hooks in the display struct and only
makes sense when we have display. Move it inside
intel_init_display_hooks() so it isn't called when we don't have
display.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210213042756.953007-4-lucas.demarchi@intel.com
Now that all display-related functions are grouped in
i915_driver_register(), move them to display/ so we reduce the amount of
display calls from the rest of the driver.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20210213042756.953007-3-lucas.demarchi@intel.com
Apparently the new gen9_bc platforms that Intel has introduced don't
provide us with a STRAP config register to read from for initializing DDI
B, C, and D detection. So, workaround this by hard-coding our strap config
in intel_setup_outputs().
Changes since v4:
* Split this into it's own commit
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209212832.1401815-5-lyude@redhat.com
Next, let's start introducing the HPD pin mappings for Intel's new gen9_bc
platform in order to make hotplugging display connectors work. Since
gen9_bc is just a TGP PCH along with a CML CPU, except with the same HPD
mappings as ICL, we simply add a skl_hpd_pin function that is shared
between gen9 and gen9_bc which handles both the traditional gen9 HPD pin
mappings and the Icelake HPD pin mappings that gen9_bc uses.
Changes since v4:
* Split this into its own commit
* Introduce skl_hpd_pin() like vsyrjala suggested and use that instead of
sticking our HPD pin mappings in TGP code
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
[originally from Tejas's work]
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210209212832.1401815-4-lyude@redhat.com
