aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2021-10-21drm/i915: Move intel_format_info_is_yuv_semiplanar() to intel_fb.cImre Deak6-11/+36
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 <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-7-imre.deak@intel.com
2021-10-21drm/i915: Unexport is_semiplanar_uv_plane()Imre Deak2-2/+1
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 <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-6-imre.deak@intel.com
2021-10-21drm/i915: Simplify the modifier check for interlaced scanout supportImre Deak1-7/+2
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 <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-5-imre.deak@intel.com
2021-10-21drm/i915: Add tiling attribute to the modifier descriptorImre Deak1-12/+21
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 <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-4-imre.deak@intel.com
2021-10-21drm/i915: Move intel_get_format_info() to intel_fb.cImre Deak3-131/+157
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 <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-3-imre.deak@intel.com
2021-10-21drm/i915: Add a table with a descriptor for all i915 modifiersImre Deak8-184/+237
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: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> (v3) Link: https://patchwork.freedesktop.org/patch/msgid/20211020195138.1841242-2-imre.deak@intel.com
2021-10-21Revert "drm/i915/bios: gracefully disable dual eDP for now"Jani Nikula1-47/+0
This reverts commit 05734ca2a8f76c9eb3890b3c9dfc3467f03105c1. 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: 05734ca2a8f7 ("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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211019114334.24643-1-jani.nikula@intel.com
2021-10-20drm/i915/display: Add warn_on in intel_psr_pause()José Roberto de Souza1-0/+4
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: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020003558.222198-2-jose.souza@intel.com
2021-10-20drm/i915/display: Rename POWER_DOMAIN_DPLL_DC_OFF to POWER_DOMAIN_DC_OFFJosé Roberto de Souza3-7/+7
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: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Caz Yokoyama <caz.yokoyama@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211020003558.222198-1-jose.souza@intel.com
2021-10-20drm/i915/dp: Sanitize link common rate array lookupsImre Deak1-17/+16
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 <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-7-imre.deak@intel.com
2021-10-20drm/i915/dp: Sanitize sink rate DPCD register valuesImre Deak1-1/+20
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 <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-6-imre.deak@intel.com
2021-10-20drm/i915/dp: Ensure sink/link max lane count values are always validImre Deak2-2/+44
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 <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-5-imre.deak@intel.com
2021-10-20drm/i915/dp: Ensure max link params are always validImre Deak1-8/+10
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 <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-4-imre.deak@intel.com
2021-10-20drm/i915/dp: Ensure sink rate values are always validImre Deak1-0/+11
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/4298 Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018143417.1452632-1-imre.deak@intel.com
2021-10-20drm/i915/dp: Skip the HW readout of DPCD on disabled encodersImre Deak1-0/+3
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: a532cde31de3 ("drm/i915/tc: Fix TypeC port init/resume time sanitization") References: https://gitlab.freedesktop.org/drm/intel/-/issues/4297 Reported-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: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018094154.1407705-2-imre.deak@intel.com
2021-10-19drm/i915/dp: use new link training delay helpersJani Nikula1-25/+13
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014150059.28957-3-jani.nikula@intel.com
2021-10-19Merge tag 'topic/drm-dp-training-delay-helpers-2021-10-19' of ↵Jani Nikula1-18/+135
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 c93ce6a6dfbd ("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 <jani.nikula@intel.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/878ryps5b6.fsf@intel.com
2021-10-19drm/dp: reuse the 8b/10b link training delay helpersJani Nikula1-20/+10
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014150059.28957-2-jani.nikula@intel.com
2021-10-19drm/dp: add helpers to read link training delaysJani Nikula1-0/+127
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ä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014150059.28957-1-jani.nikula@intel.com
2021-10-19drm/i915: Introduce lpt_pch_disable()Ville Syrjälä3-6/+15
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-10-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move intel_ddi_fdi_post_disable() to fdi codeVille Syrjälä5-37/+41
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-9-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Introduce ilk_pch_disable() and ilk_pch_post_disable()Ville Syrjälä3-26/+43
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-8-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move iCLKIP readout to the pch codeVille Syrjälä3-7/+6
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-7-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Extract ilk_pch_get_config()Ville Syrjälä4-69/+75
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-6-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move LPT PCH readout codeVille Syrjälä6-45/+26
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018153525.21597-1-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Clean up the {ilk,lpt}_pch_enable() calling conventionVille Syrjälä4-19/+22
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-4-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move PCH modeset code to its own fileVille Syrjälä6-352/+390
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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-3-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-19drm/i915: Move PCH refclock stuff into its own fileVille Syrjälä11-640/+675
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015071625.593-2-ville.syrjala@linux.intel.com Reviewed-by: Dave Airlie <airlied@redhat.com>
2021-10-18drm/i915: Don't propagate the gen split confusion furtherRodrigo Vivi1-1/+1
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: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015091650.87270-1-rodrigo.vivi@intel.com
2021-10-18drm/i915: Clean-up bonding debug message.Rodrigo Vivi1-1/+1
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015091129.83226-1-rodrigo.vivi@intel.com
2021-10-18drm/i915: Rename intel_load_plane_csc_black()Ville Syrjälä1-18/+17
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006235704.28894-5-ville.syrjala@linux.intel.com Reviewed-by: Juston Li <juston.li@intel.com>
2021-10-18drm/i915: Remove the drm_dbg() from the vblank evade critical sectionVille Syrjälä1-2/+0
We are inside the vblank evade critical section here, racing against the raster beam. There is no time to print debug messages. 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006235704.28894-4-ville.syrjala@linux.intel.com Reviewed-by: Juston Li <juston.li@intel.com>
2021-10-18drm/i915: Fix up skl_program_plane() pxp stuffVille Syrjälä1-16/+14
There's lots of expensive stuff inserted between the PLANE_CTL and PLANE_SURF writes even though the comment before the PLANE_CTL write says not to put stuff there. Move it all to a more apporiate place. There's also a weird PLANE_COLOR_CTL RMW in there. I guess because force_black was computed way too late originally, but that is now sorted. 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006235704.28894-3-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2021-10-18drm/i915: Move the pxp plane state computationVille Syrjälä2-30/+18
No real reason to have this pxp state computation in intel_atomic_check_planes(). Just stuff it into skl_plane_check(). There was also some funny state copying being done from the old plane state to the new plane state when the plane is anyway disabled. The one thing we presumably must remember to do is copy over the decrypt state when assigning a Y plane for planar YCbCr scanout, so that the Y plane's PLANE_SURF will get the appropriate bit set. The force_black thing should not matter as I'm pretty sure all that stuff is ignored for the Y plane. I suppose this was the reason for the odd placement for the state computation, but I see no reason to deviate from the standard way of doing these things. This also guarantees that we don't calculate things differently between the linked UV and Y plane. v2: Only do stuff for icl+ since 'force_black' depends on the plane CSC which is an icl+ feature 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006235704.28894-2-ville.syrjala@linux.intel.com Reviewed-by: Juston Li <juston.li@intel.com> #v1
2021-10-18drm/i915: Avoid bitwise vs logical OR warning in snb_wm_latency_quirk()Nathan Chancellor1-3/+3
A new warning in clang points out a place in this file where a bitwise OR is being used with boolean types: drivers/gpu/drm/i915/intel_pm.c:3066:12: warning: use of bitwise '|' with boolean operands [-Wbitwise-instead-of-logical] changed = ilk_increase_wm_latency(dev_priv, dev_priv->wm.pri_latency, 12) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This construct is intentional, as it allows every one of the calls to ilk_increase_wm_latency() to occur (instead of short circuiting with logical OR) while still caring about the result of each call. To make this clearer to the compiler, use the '|=' operator to assign the result of each ilk_increase_wm_latency() call to changed, which keeps the meaning of the code the same but makes it obvious that every one of these calls is expected to happen. Link: https://github.com/ClangBuiltLinux/linux/issues/1473 Reported-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Suggested-by: Dávid Bolvanský <david.bolvansky@gmail.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014211916.3550122-1-nathan@kernel.org
2021-10-15drm/i915: Clean up PXP Kconfig info.Rodrigo Vivi1-5/+5
During the review I focused on stop the using of the "+" to reference the newer platforms, but I forgot that we are in a process of making things more clear and differentiate graphics and display versions. So, let me to clean up this a bit. Also, we don't need any version mentioned in the config menu entry, only in the help. Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015090916.82968-1-rodrigo.vivi@intel.com
2021-10-14drm/i915: Fix oops on platforms w/o hpd supportVille Syrjälä1-1/+1
We don't have hpd support on i8xx/i915 which means hotplug_funcs==NULL. Let's not oops when loading the driver on one those machines. v2: Drop the redundant function pointer check (Jani) Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Fixes: cd030c7c11a4 ("drm/i915: constify hotplug function vtable.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014090941.12159-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-10-14drm/i915: Remove memory frequency calculationJosé Roberto de Souza2-36/+2
This memory frequency calculated is only used to check if it is zero, what is not useful as it will never actually be zero. Also the calculation is wrong, we should be checking other bit to select the appropriate frequency multiplier while this code is stuck with a fixed multiplier. So here dropping it as whole. v2: - Also remove memory frequency calculation for gen9 LP platforms Cc: Yakui Zhao <yakui.zhao@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Fixes: 5d0c938ec9cc ("drm/i915/gen11+: Only load DRAM information from pcode") Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211013010046.91858-1-jose.souza@intel.com
2021-10-14drm/i915: Add all per-lane register definitions for icl combo phyVille Syrjälä4-24/+22
Add the FOO_LN() register macros for all the icl combo phy registers. Also get rid of the semi-pointless FOO_LN0() variants and just use the parametrized version. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-10-14drm/i915: Extract icl_combo_phy_loadgen_select()Ville Syrjälä1-9/+14
Pull the convoluted loadgen calculation into a small helper. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-10-14drm/i915: Remove dead DKL_TX_LOADGEN_SHARING_PMD_DISABLE stuffVille Syrjälä2-9/+0
DKL_TX_LOADGEN_SHARING_PMD_DISABLE doesn't even seem to exist, also the spec says to skip all loadgen stuff. The code was dead anyway since it wasn't actually writing the value anywhere. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-10-14drm/i915: Use standard form terminating condition for lane for loopsVille Syrjälä1-2/+2
Use <4 instead of <=3 as the terminating condition for the loops over the 4 lanes. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-10-14drm/i915: Shrink {icl_mg,tgl_dkl}_phy_ddi_buf_transVille Syrjälä1-6/+6
All the values we have in {icl_mg,tgl_dkl}_phy_ddi_buf_trans fit into u8. Shrink the types accordingly. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-10-14drm/i915: Remove pointless extra namespace from dkl/snps buf trans structsVille Syrjälä3-12/+12
The struct itself already has sufficient namespace. No need to duplicate it in the members. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211006204937.30774-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2021-10-14drm/i915: rename intel_sideband.[ch] to intel_sbi.[ch]Jani Nikula5-29/+13
Now that intel_sideband.[ch] has been decluttered, it's pure lpt/wpt iosf sideband. Let's call it intel_sbi, following the function naming. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: 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/183423ff23b2d259e4a197e74daf6bcd750bfe14.1634207064.git.jani.nikula@intel.com
2021-10-14drm/i915: split out intel_pcode.[ch] to separate fileJani Nikula17-255/+277
The snb+ pcode mailbox code is not sideband, so split it out to a separate file. As can be seen from the #include changes, very few places use both sideband and pcode. Code movement only. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: 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/185deb18eb739e5ae019e27834b9997dcc1347bc.1634207064.git.jani.nikula@intel.com
2021-10-14drm/i915/bios: gracefully disable dual eDP for nowJani Nikula1-0/+47
For the time being, neither the power sequencer nor the backlight code properly support two eDP panels simultaneously. While the software states will be independent, the same sets of registers will be used for both eDP panels, clobbering the hardware state and leading to errors. Gracefully disable dual eDP until proper support has been added. 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> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005175636.24669-1-jani.nikula@intel.com
2021-10-14drm/i915: split out vlv sideband to a separate fileJani Nikula22-382/+405
The VLV/CHV sideband code is pretty distinct from the rest of the sideband code. Split it out to new vlv_sideband.[ch]. Pure code movement with relevant #include changes, and a tiny checkpatch fix on top. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/755ebbbaf01fc6d306b763b6ef60f45e671ba290.1634119597.git.jani.nikula@intel.com
2021-10-12drm/i915/display: remove unused intel-mid.h includeLucas De Marchi1-1/+0
Nothing from intel-mid.h and this is only available on x86, so remove it as we prepare support for other architectures. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211007233212.3896460-4-lucas.demarchi@intel.com
2021-10-12Merge drm/drm-next into drm-intel-nextRodrigo Vivi676-13476/+62697
Need to resync drm-intel-next with TTM and PXP stuff from drm-intel-gt-next that is now in drm/drm-next. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Powered by cgit, Gruvboxed by Blaster4385.