- 21 Oct, 2021 16 commits
-
-
Ville Syrjälä authored
Rename intel_hdmi_port_clock() into intel_hdmi_tmds_clock(), and move the 4:2:0 TMDS clock halving into intel_hdmi_tmds_clock() so the callers don't have to worry about such details. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015133921.4609-4-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Introduce a small helper which given the crtc state tells us whether we're output YCbCr 4:2:0 or not. For native HDMI this is rather simple as we just look at the output_format. But I think the helper is beneficial since with DP HDMI DFPs we're going to need a more complex variant, and I want to unify the DP and HDMI sides of that as much as possible. Signed-off-by:
-
Ville Syrjälä authored
intel_hdmi_bpc_possible() is used by the DP code as well where the native HDMI source limits do not apply. So let's split this into a pair of functions: one for the source vs. one for the sink. This is basically reverting some of commit 41828125 ("drm/i915: Move platform checks into intel_hdmi_bpc_possible()") slightly, but in a nicer form. I guess I forgot at the time that the DP side uses this too. Signed-off-by:
-
Ville Syrjälä authored
A bunch of function prototypes were left behind when the plane/crtc code got reshuffled to new files. Move the prototypes as well. Signed-off-by:
-
Imre Deak authored
Instead of open-coding the checks add functions for this, simplifying the handling of CCS modifiers on future platforms. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-12-imre.deak@intel.com
-
Imre Deak authored
Move the function to intel_fb.c and rename it adding the intel_fb_ prefix following the naming of exported functions. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
Future platforms change the location of CCS AUX planes in CCS framebuffers, so add intel_fb_is_ccs_aux_plane() to query for these planes independently of the platform. This function can be used everywhere instead of is_ccs_plane() (or is_ccs_plane() && !cc_plane()), since all the callers are only interested in CCS AUX planes (and not CCS color-clear planes). Add the corresponding intel_fb_is_gen12_ccs_aux_plane(), which can be used everywhere instead of is_gen12_ccs_plane(), based on the above explanation. This change also unexports the is_gen12_ccs_modifier(), is_gen12_ccs_plane(), is_gen12_ccs_cc_plane() functions as they are only used in intel_fb.c v1-v2: Unchanged v3: (Ville) - Use ccs_aux instead of the ccs_ctrl term everywhere. - Use color_plane instead of plane term for FB plane indicies. v4: Fix version range check. (Jani) Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Imre Deak authored
CCS CC planes are quite different from CCS AUX planes, even though we regard the CC planes as a linear buffer having a 64 byte stride. Thus it's clearer to check for either CCS plane types explicitly when we need to handle them; add the required CCS CC planes check here, while the next patch will change all is_ccs_plane()/is_gen12_ccs_plane() checks to consider only the CCS AUX planes. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
On future platforms the index of the color-clear plane will change from the one used by the GEN12 RC CCS CC modifier, so add a way to retrieve the index independently of the platform/modifier. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
Move intel_format_info_is_yuv_semiplanar() to intel_fb.c . The number of planes for YUV semiplanar formats using CCS modifiers will change on future platforms. We can use the modifier descriptors to simplify getting the plane numbers for all modifiers, prepare for that here. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
This function is only used by intel_fb.c, so unexport it. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
Checking the modifiers that support interlacing makes the condition simpler and avoids us having to add new modifiers to the list (presuming all/most of the new modifiers won't support interlacing). Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Imre Deak authored
Add a tiling atttribute to the modifier descriptor, which let's us get the tiling without listing the modifiers twice. v1-v2: Unchanged. v3: - Initialize .tiling to I915_TILING_NONE explicitly (Ville) - Move from previous patch lookup_modifier() to here, where it's first used. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Move the function retrieving the format override information for a given format/modifier to intel_fb.c. We can store a pointer to the format list in each modifier's descriptor instead of the corresponding switch/case logic, avoiding the listing of the modifiers twice. v1: Unchanged. v2: Handle invalid modifiers in intel_fb_get_format_info() passed from userspace. (CI/igt_kms_addfb_basic/addfb25-bad-modifier) v3: Move lookup_modifier() to the next patch, where it's first used. Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Imre Deak authored
Add a table describing all the framebuffer modifiers used by i915 at one place. This has the benefit of deduplicating the listing of supported modifiers for each platform and checking the support of these modifiers on a given plane. This also simplifies in a similar way getting some attribute for a modifier, for instance checking if the modifier is a CCS modifier type. While at it drop the cursor plane filtering from skl_plane_has_rc_ccs(), as the cursor plane is registered with DRM core elsewhere. v1: Unchanged. v2: - Keep the plane caps calculation in the plane code and pass an enum with these caps to intel_fb_get_modifiers(). (Ville) - Get the modifiers calling intel_fb_get_modifiers() in i9xx_plane.c as well. v3: - s/.id/.modifier/ (Ville) - Keep modifier_desc vs. plane_cap filter conditions consistent. (Ville) - Drop redundant cursor plane check from skl_plane_has_rc_ccs(). (Ville) - Use from, until display version fields in modifier_desc instead of a mask. (Jani) - Unexport struct intel_modifier_desc, separate its decl and init. (Jani) - Remove enum pipe, plane_id forward decls from intel_fb.h, which are not needed after v2. v4: - Reuse IS_DISPLAY_VER() instead of open-coding it. (Jani) - Preserve the current modifier order exposed to user space. (Ville) v5: Use }, { on one line to seperate the descriptor array elements. (Jani) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Jani Nikula authored
This reverts commit 05734ca2. It's not graceful, instead it leads to boot time warning splats in the case it is supposed to handle gracefully. Apparently the BIOS/GOP enabling the port we end up skipping leads to state readout problems. Back to the drawing board. References: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_21255/bat-adlp-4/boot0.txt Fixes: 05734ca2 ("drm/i915/bios: gracefully disable dual eDP for now") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
- 20 Oct, 2021 8 commits
-
-
José Roberto de Souza authored
Right now the only user of psr_pause/resume is intel_cdclk but additional users will be added in the future and we may need do reference counting for PSR pause and resume, for now only adding a warn_on so this cases do not go unnoticed. Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jouni Hogander <jouni.hogander@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020003558.222198-2-jose.souza@intel.com
-
José Roberto de Souza authored
This power domain to disable DC states will be used in places outside of DPLL, so making the name more generic. Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Caz Yokoyama <caz.yokoyama@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020003558.222198-1-jose.souza@intel.com
-
Imre Deak authored
Add an assert that lookups from the intel_dp->common_rates[] array are always valid. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
If the DPCD sink rate values read from the sink are invalid, the driver will sanitize this in intel_dp_set_common_rates(), by setting a default 162000 link rate in common rates and printing a WARN(). WARN()s should only be triggered by bugs in the code and not by external factors like the above (an invalid DPCD injected maliciously or read from a buggy monitor). So fixup the invalid DPCD sink rate values already and print an error in this case (since it's still a user visible problem). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Print an error if the DPCD sink max lane count is invalid and fix it up. While at it also add an assert that the link max lane count (derived from intel_dp_max_common_lane_count(), potentially reduced by the LT fallback logic) value is also valid. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Atm until the DPCD for a connector is read the max link rate and lane count params are invalid. If the connector is modeset, in intel_dp_compute_config(), intel_dp_common_len_rate_limit(max_link_rate) will return 0, leading to a intel_dp->common_rates[-1] access. Fix the above by making sure the max link params are always valid. The above access leads to an undefined behaviour by definition, though not causing a user visible problem to my best knowledge, see the previous patch why. Nevertheless it is an undefined behaviour and it triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Imre Deak authored
Atm, there are no sink rate values set for DP (vs. eDP) sinks until the DPCD capabilities are successfully read from the sink. During this time intel_dp->num_common_rates is 0 which can lead to a intel_dp->common_rates[-1] (*) access, which is an undefined behaviour, in the following cases: - In intel_dp_sync_state(), if the encoder is enabled without a sink connected to the encoder's connector (BIOS enabled a monitor, but the user unplugged the monitor until the driver loaded). - In intel_dp_sync_state() if the encoder is enabled with a sink connected, but for some reason the DPCD read has failed. - In intel_dp_compute_link_config() if modesetting a connector without a sink connected on it. - In intel_dp_compute_link_config() if modesetting a connector with a a sink connected on it, but before probing the connector first. To avoid the (*) access in all the above cases, make sure that the sink rate table - and hence the common rate table - is always valid, by setting a default minimum sink rate when registering the connector before anything could use it. I also considered setting all the DP link rates by default, so that modesetting with higher resolution modes also succeeds in the last two cases above. However in case a sink is not connected that would stop working after the first modeset, due to the LT fallback logic. So this would need more work, beyond the scope of this fix. As I mentioned in the previous patch, I don't think the issue this patch fixes is user visible, however it is an undefined behaviour by definition and triggers a BUG() in CONFIG_UBSAN builds, hence CC:stable. v2: Clear the default sink rates, before initializing these for eDP. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4297 References: https://gitlab.freedesktop.org/drm/intel/-/issues/4298Suggested-by:
-
Imre Deak authored
Reading out the DP encoders' DPCD during booting or resume is only required for enabled encoders: such encoders may be modesetted during the initial commit and the link training this involves depends on an initialized DPCD. For DDI encoders reading out the DPCD is skipped, do the same on pre-DDI platforms. Atm, the first DPCD readout without a sink connected - which is a likely scneario if the encoder is disabled - leaves intel_dp->num_common_rates at 0, which resulted in intel_dp_sync_state()->intel_dp_max_common_rate() in a intel_dp->common_rates[-1] access. This by definition results in an undefined behaviour, though to my best knowledge in all HW/compiler configurations it actually results in accessing the array item type value preceding the array. In this case the preceding value happens to be intel_dp->num_common_rates, which is 0, so this issue - by luck - didn't cause a user visible problem. Nevertheless it's still an undefined behaviour and in CONFIG_UBSAN builds leads to a kernel BUG() (which revealed this problem for us), hence CC:stable. A related problem in case the encoder is enabled but the sink is not connected or the DPCD readout fails is fixed by the next patch. v2: Amend the commit message describing the root cause of the CONFIG_UBSAN BUG(). Fixes: a532cde3 ("drm/i915/tc: Fix TypeC port init/resume time sanitization") References: https://gitlab.freedesktop.org/drm/intel/-/issues/4297Reported-and-tested-by:Mat Jonczyk <mat.jonczyk@o2.pl> Cc: Mat Jonczyk <mat.jonczyk@o2.pl> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 19 Oct, 2021 13 commits
-
-
Jani Nikula authored
Use the new link training delay helpers, fixing the delays for 128b/132b. For existing 8b/10b functionality, this will cause additional 1-byte DPCD reads for LTTPR delays instead of using the cached values. It's just too complicated to combine generic helpers with local caching in a sensible way. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Merge tag 'topic/drm-dp-training-delay-helpers-2021-10-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-intel-next Core Changes: - drm dp helpers for figuring out link training delays Merge to drm-intel-next as well after c93ce6a6 ("Merge tag 'topic/drm-dp-training-delay-helpers-2021-10-19' of git://anongit.freedesktop.org/drm/drm-intel into drm-misc-next"). Signed-off-by:
-
Jani Nikula authored
Reuse the 8b/10b link training delay helpers. Functionally this skips the check for invalid values for DPCD 1.4 and later at clock recovery delay (as it's a fixed delay and bypasses the rd_interval) but the same value will be checked and invalid values reported at channel equalization. Reviewed-by:
-
Jani Nikula authored
The link training delays are different and/or available in different DPCD offsets depending on: - Clock recovery vs. channel equalization - DPRX vs. LTTPR - 128b/132b vs. 8b/10b - DPCD 1.4+ vs. earlier Add helpers to get the correct delays in us, reading DPCD if necessary. This is more straightforward than trying to retrofit the existing helpers to take 128b/132b into account. Having to pass in the DPCD receiver cap field seems unavoidable, because reading it involves checking the revision and reading extended receiver cap. So unfortunately the interface is mixed cached and read as needed. v2: Remove delay_us < 0 check and the whole local var (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
Let's add lpt_pch_disable() as the counterpart to lpt_pch_enable(). Note that unlike the ilk+ code the fdi_link_train() and fdi_disable() calls are still left directly in intel_crt.c. If we wanted to move those we'd need to add lpt_pch_pre_enable(). But the two fdi direct fdi calls are pretry symmetric so it doesn't seem too bad to just keep them as is. v2: Make lpt_disable_pch_transcoder() static (lkp@intel.com) Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Ville Syrjälä authored
Reanme intel_ddi_fdi_post_disable() to hsw_fdi_disable() and relocate it next to all the other code dealing with FDI_RX. intel_ddi.c has now been cleansed of FDI_RX. In order to avoid exposing intel_disable_ddi_buf() outside intel_ddi.c we can just open code the DDI_BUF_CTL write. The enable side already has all that stuff open coded so this actually is more symmetric. But we do need to remeber to bring the intel_wait_ddi_buf_idle() call over from inside intel_disable_ddi_buf(). Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Hoover the remaining open coded PCH modeset sequence bits out from ilk_crtc_disable(). Somewhat annoyingly the enable vs. disable is a bit asymmetric so we need two functions for the disable case. Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Move the lpt_get_iclkip() call from hsw_crt_get_config() since that's where we have the lpt_program_iclkip() call as well. Tehcnically this isn't perhaps quite right since iCLKIP is providing the CRT dotclock. So one can argue all of it should be directly in intel_crt.c. But since the CRT port is the only one on the PCH sticking it all into the PCH code seems OK. Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Pull the ilk+ PCH state readout into its own function and relocate to the appropriate file. The clock readout parts are perhaps a bit iffy since we depend on the gmch DPLL readout code. But we can think about the clock readout big picture later. Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Nuke the hsw_get_ddi_port_state() eyesore by putting the readout code into intel_pch_display.c, and calling it directly from hsw_crt_get_config(). Note that the nuked TRANS_DDI_FUNC_CTL readout from hsw_get_ddi_port_state() is now etirely redundant since we get called from the encoder->get_config() so we already know we're dealing with the correct DDI port. Previously the code was called from a place where that wasn't known so it had to checked manually. v2: Clarify the TRANS_DDI_FUNC_CTL change (Dave) Nuke the now unused *TRANS_DDI_FUNC_CTL_VAL_TO_PORT() (Dave) Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Ville Syrjälä authored
Use the clean "atomic_state+crtc" approach of passing arguments to the top level PCH modeset code. And while at it we can also just pass the whole crtc to ilk_disable_pch_transcoder(). v2: Elimiate double space between function args (Dave) Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Start moving the code for PCH modeset sequence/etc. to its own file. Still not sure about the file name though... Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Move the PCH refclk stuff (including all the LPT/WPT iCLKIP/CLKOUT_DP things) to its own file. We also suck in the mPHY programming from intel_fdi.c since we're the only caller. Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 18 Oct, 2021 3 commits
-
-
Rodrigo Vivi authored
There's no such thing as gen13. It is either display 13 or graphics 13. Don't propagate the gen12 confusion further. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
We should stop using the gen name and the "+" to reference the newer platforms. And on this case specifically we can simplify the debug message even further. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Ville Syrjälä authored
intel_load_plane_csc_black() is specific to icl+ so deserves a name reflecting that fact. Also rename the variables to standard form so I won't get confused reading the code. v2: icl+ not glk+ Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Juston Li <juston.li@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Juston Li <juston.li@intel.com>
-
