- 11 May, 2023 1 commit
-
-
Jani Nikula authored
The display prefix is unnecessary within the display sub-directory. Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230511085553.799321-1-jani.nikula@intel.com
-
- 09 May, 2023 1 commit
-
-
Jani Nikula authored
For development and testing purposes, the i915.force_probe module parameter and DRM_I915_FORCE_PROBE kconfig option allow probing of devices that aren't supported by the driver. The i915.force_probe module parameter is "unsafe" and setting it taints the kernel. However, using the kconfig option does not. Always taint the kernel when force probing a device that is not supported. v2: Drop "depends on EXPERT" to avoid build breakage (kernel test robot) Fixes: 7ef5ef5c ("drm/i915: add force_probe module parameter to replace alpha_support") Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 08 May, 2023 1 commit
-
-
Stanislav Lisovskiy authored
By my own mistake, after adding !IS_DG2 into wrong branch, bxt_set_cdclk started to execute code intended for platforms gen < 11, which is wrong. Move IS_DG2 check to better place. Fixes: ceb0cc3b ("drm/i915: Communicate display power demands to pcode") Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by: Vinod Govindapillai <vinod.govindapillai@intel.com Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230506144217.26075-1-stanislav.lisovskiy@intel.com
-
- 05 May, 2023 11 commits
-
-
Ville Syrjälä authored
On g4x the hardware has only one audio/video DIP block. Thus only one HDMI port can transmit audio/infoframes at a time. Currently we pretend that multiple ports can do it at the same time, but that doesn't actually work for two reasons: - the state of the single hw block will get clobbered by the multiple ports, leading to state checker failures - the hardware will automagically disable audio/infoframe transmission when enabled on multiple ports To fix this let's allow only one of the ports to transmit audio/infoframes at a time. We'll just go over all the HDMI ports and pick the first one that is otherwise capable of audio/infoframes. Further HDMI ports will be treated as if they had a DVI sink connected. In order to compute this consistently we'll also need to always add all HDMI ports to the atomic state. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221107194604.15227-6-ville.syrjala@linux.intel.comReviewed-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
We'll be wanting to compute has_hdmi_sink a bit differently for some platforms. To that end compute it in the encoder .compute_config_hook() before we call intel_hdmi_compute_config(). intel_hdmi_compute_has_hdmi_sink() will do the basic lifting beyond any platform specific stuff. Signed-off-by:
-
Ankit Nautiyal authored
Check for MODE_H_ILLEGAL before calculating max rates, lanes etc. Move comments about compressed bpp U6.4 format closer to where it is used. Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
-
Ankit Nautiyal authored
Common function to get the sink format for a given mode for DP. Signed-off-by:
-
Ankit Nautiyal authored
Start passing the sink_format, to all functions that take a bool ycbcr420_output as parameter. This will make the functions generic, and will serve as a slight step towards 4:2:2 support later. v2: Rebased. v3: Correct the checks in places concerned with pipe output. (Ville) Other minor styling and refactoring fixes, as suggested by Ville. Suggested-by:
-
Ankit Nautiyal authored
Handle the case with DP to HDMI PCON, where sink_format is set to YCbCr444. In that case PCON is required to be configured to convert from given output_format to YCbCR444. v2: Drop drm_WARN for invalid case, let MISSING_CASE catch it. (Ville) Signed-off-by:
-
Ankit Nautiyal authored
The decision to use DFP output format conversion capabilities should be during compute_config phase. This patch uses the members of intel_dp->dfp to only store the format conversion capabilities of the DP device and uses the crtc_state sink_format member, to program the protocol-converter for colorspace/format conversion. v2: Use sink_format to determine the color conversion config for the pcon (Ville). v3: Fix typo: missing 'break' in switch case (lkp kernel test robot). v4: Add helper to check if DP supports YCBCR420. v5: Simplify logic for computing output_format, based on the given sink_format. (Ville). Added scaler constraint for YCbCr420 output. v6: Split the patch for Scaler constraint for Ycbcr420. v7: Simplify the policy for selecting output_format: Always try for RGB first, followed by YCBCR444, and finally by YCBCR420. v8: Removed redundant comments, minor refactoring. (Ville) v9: Added member for ycbcr420 passthrough cap, fixed minor issues. (Ville) Signed-off-by:
-
Ankit Nautiyal authored
The decision to use DFP output format conversion capabilities should be during compute_config phase. This patch adds new member to crtc_state to represent the final output_format to the sink. In case of a DFP this can be different than the output_format, as per the format conversion done via the PCON. This will help to store only the format conversion capabilities of the DP device in intel_dp->dfp, and use crtc_state to compute and store the configuration for color/format conversion for a given mode. v2: modified the new member to crtc_state to represent the final output_format that eaches the sink, after possible conversion by PCON kind of devices. (Ville) v3: Addressed comments from Ville: -Added comments to clarify difference between sink_format and output_format. -Corrected the order of setting sink_format and output_format. -Added readout for sink_format in get_pipe_config hooks. v4: Set sink_format for intel_sdvo too. (Ville) v5: Rebased. v6: Fixed condition to go for YCbCr420 format for dp and hdmi. (Ville) v7: Fix the condition to set sink_format for HDMI. Set hdmi output_format simply as sink_format. (Ville) Signed-off-by:
-
Nikita Zhandarovich authored
drm_dp_dsc_sink_max_slice_count() may return 0 if something goes wrong on the part of the DSC sink and its DPCD register. This null value may be later used as a divisor in intel_dsc_compute_params(), which will lead to an error. In the unlikely event that this issue occurs, fix it by testing the return value of drm_dp_dsc_sink_max_slice_count() against zero. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: a4a15777 ("drm/i915/dp: Compute DSC pipe config in atomic check") Signed-off-by:
Nikita Zhandarovich <n.zhandarovich@fintech.ru> Reviewed-by:
-
Stanislav Lisovskiy authored
intel_atomic_get_new_crtc_state can return NULL, unless crtc state wasn't obtained previously with intel_atomic_get_crtc_state, so we must check it for NULLness here, just as in many other places, where we can't guarantee that intel_atomic_get_crtc_state was called. We are currently getting NULL ptr deref because of that, so this fix was confirmed to help. Fixes: 74a75dc9 ("drm/i915/display: move plane prepare/cleanup to intel_atomic_plane.c") Signed-off-by:
-
Stanislav Lisovskiy authored
Display to communicate display pipe count/CDCLK/voltage configuration to Pcode for more accurate power accounting for DG2. Existing sequence is only sending the voltage value to the Pcode. Adding new sequence with current cdclk associate with voltage value masking. Adding pcode request when any pipe power well will disable or enable. v2: - Make intel_cdclk_need_serialize static to make CI compiler happy. v3: - Removed redundant return(Jani Nikula) - Changed intel_cdclk_power_usage_to_pcode_(pre|post)_notification to be static and also naming to intel_cdclk_pcode_(pre|post)_notify(Jani Nikula) - Changed u8 to be u16 for cdclk parameter in intel_pcode_notify function, as according to BSpec it requires 10 bits(Jani Nikula) - Replaced dev_priv's with i915's(Jani Nikula) - Simplified expression in intel_cdclk_need_serialize(Jani Nikula) - Removed redundant kernel-doc and indentation(Jani Nikula) v4: - Fixed some checkpatch warnings v5: - According to HW team comments that change should affect only DG2, fix correspodent platform check to account this. v6: - Added one more missing IS_DG2 check(Vinod Govindapillai) Signed-off-by:Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230504093959.12085-1-stanislav.lisovskiy@intel.com
-
- 04 May, 2023 6 commits
-
-
Ville Syrjälä authored
Pimp the skl+ scaler register bits with REG_BIT()/etc. Reviewed-by:
-
Ville Syrjälä authored
Define and use the bitmasks for the x/y components of the skl+ scaler window pos/size registers. We stick to the full 16 bits mask here even though the hardware limits are actually lower. The current (ADL) hardware maximums are in fact: 14 bits for X size, 13 bits for X pos, 13 bits for Y size/pos. Yes, that is correct, X pos has less bits than the X size for some reason. But that doesn't actually matter for now as we don't currently even support such wide displays without the use of bigjoiner (due to max plane width limit). v2: Switch back to full 16bit masks since that's what we use transcoder timign regs and PIPESRC as well Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: -
Ville Syrjälä authored
Fix a typo in the PS_COEF_INDEX_AUTO_INC define. Reviewed-by:
-
Ville Syrjälä authored
Rename the scaler binding bits to match the spec more closely. Also call the parameters 'plane_id' to make it a bit more clear what to pass in. v2: Don't break gvt Reviewed-by:
-
Ville Syrjälä authored
We have some duplicated scaler register defines that are never used. Remove them. Reviewed-by:
-
Ville Syrjälä authored
Define and use the bitmasks for the x/y components of the ilk+ panel filter window pos/size registers. Note that we stick to the full 16 bit mask even though the actual hardware limits are lower (and somewhat platform dependent). BDW is actually limited to 13 bits horizontal and 12 bits vertical, with the high bits being hardwired to zero. HSW should have the same limits as BDW. And pre-HSW should be limited to 12bits in both directions as that's already the limit of the transcoder timing registers. Curiously on HSW and earlier platforms all 16 bits can actually be set, but presumably the hardware ignores the high bits. v2: Switch back to full 16bit masks since that's what we use transcoder timign regs and PIPESRC as well Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 02 May, 2023 1 commit
-
-
Arun R Murthy authored
For 128b/132b LT prior to LT DPTX should set power state, DP channel coding and then link rate. v2: added separate function to avoid code duplication(Jani N) v3: DP2.1 section 3.5.2.16 is ordered, 3.5.1.2 is unordered and hence discarding <Ville> Signed-off-by:Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by:
-
- 28 Apr, 2023 14 commits
-
-
Mika Kahola authored
Finally, we can enable TC ports for Meteorlake. Reviewed-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230428095433.4109054-14-mika.kahola@intel.com
-
Anusha Srivatsa authored
Unlike previous platforms that used PORT_TX_DFLEXDPSP for max_lane calculation, MTL uses only PORT_TX_DFLEXPA1 from which the max_lanes has to be calculated. Bspec: 50235, 65380 Reviewed-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Imre Deak authored
The HPD live status for MTL has to be read from different set of registers. MTL deserves a new function for this purpose and cannot reuse the existing HPD live status detection Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Mika Kahola authored
Add register writes to enable powering up Type-C subsystem i.e. TCSS. For MeteorLake we need to request TCSS to power up and check the TCSS power state after 500 us. In addition, for PICA we need to set/clear the Type-C PHY ownnership bit when Type-C device is connected/disconnected. Reviewed-by:
-
Gustavo Sousa authored
Xe_LPD+ defines interrupt bits for only DDI ports in the DE Port Interrupt registers. The bits for Type-C ports are defined in the PICA interrupt registers. BSpec: 50064 Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
-
Mika Kahola authored
Readout hw state for Thunderbolt. Reviewed-by:
-
Mika Kahola authored
Enabling and disabling sequence for Thunderbolt PLL. Bspec: 64568 v2: Use intel_de_wait_for_register() (RK) Reviewed-by:
-
Mika Kahola authored
Use MPLLA for DP2.0 rates 10G and 20G, when ssc is enabled. v2: Fix typo in commit message (Animesh) Reviewed-by:
-
Mika Kahola authored
DP1.4 and DP20 voltage swing sequence for C20 phy. Bspec: 65449, 67636, 67610 Reviewed-by:
-
Mika Kahola authored
Calculate port clock with C20 phy. BSpec: 64568 Reviewed-by:
-
Mika Kahola authored
As we already do with C10 chip, let's dump the pll hw state for C20 as well. Reviewed-by:
-
Mika Kahola authored
Create a table for C20 DP1.4, DP2.0 and HDMI2.1 rates. The PLL settings are based on table, not for algorithmic alternative. For DP 1.4 only MPLLB is in use. Once register settings are done, we read back C20 HW state. BSpec: 64568 v2: Updated pll tables (RK) MPLLB selection fix (RK) Signed-off-by: -
Mika Kahola authored
C20 phy PLL programming sequence for DP, DP2.0, HDMI2.x non-FRL and HDMI2.x FRL. This enables C20 MPLLA and MPLLB programming sequence. add 4 lane support for c20. v2: Add 6.48Gbps and 6.75Gbps modes for eDP (RK) Fix lane check (RK) Fix multiline commenting (Arun) use usleep_range() instead of msleep() (Andi) Reviewed-by:Bhanuprakash Modem <bhanuprakash.modem@intel.com> Signed-off-by:
-
Hans de Goede authored
The intel_dsi_msleep() helper skips sleeping if the MIPI-sequences have a version of 3 or newer and the panel is in vid-mode. This is based on the big comment around line 730 which starts with "Panel enable/disable sequences from the VBT spec.", where the "v3 video mode seq" column does not have any wait t# entries. Checking the Windows driver shows that it does always honor the VBT delays independent of the version of the VBT sequences. Commit 6fdb335f ("drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence") switched to a direct msleep() instead of intel_dsi_msleep() when there is no MIPI_SEQ_DEASSERT_RESET sequence, to fix the panel on an Acer Aspire Switch 10 E SW3-016 not turning on. And now testing on a Nextbook Ares 8A shows that panel_on_delay must always be honored otherwise the panel will not turn on. Instead of only always using regular msleep() for panel_on_delay do as Windows does and always use regular msleep() everywhere were intel_dsi_msleep() is used and drop the intel_dsi_msleep() helper. Changes in v2: - Replace all intel_dsi_msleep() calls instead of just the intel_dsi_msleep(panel_on_delay) call Cc: stable@vger.kernel.org Fixes: 6fdb335f ("drm/i915/dsi: Use unconditional msleep for the panel_on_delay when there is no reset-deassert MIPI-sequence") Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
- 27 Apr, 2023 1 commit
-
-
Suraj Kandpal authored
Type-C PHYs are taking longer than expected for Aux IO Power Enabling. Workaround: Increase the timeout. ---v2 -change style on how we mention WA [Ankit] -fix bat error by creating new func that is only called for aux power well scenarios so we can avoid null pointer error as it is called everywhere. --v3 -Add non-default enable_timeout to power well descriptor which avoids adding more platform checks [Imre] --v4 -Remove Bspec link from top to bottom remove WA link from commit put it on comment [Jani] -enable_timeout in ms and add .fixed_enable_delay too [Imre] --v5 -move power_wells instead of duplicating them [Imre] Bspec: 55480 Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230418131425.1285088-1-suraj.kandpal@intel.com
-
- 26 Apr, 2023 1 commit
-
-
Radhakrishna Sripada authored
CPU transcoder mask is used to iterate over the available CPU transcoders in the macro for_each_cpu_transcoder(). The macro is broken on MTL and got highlighted when audio state was being tracked for each transcoder added in [1]. Add the missing CPU transcoder mask which is similar to ADL-P mask but without DSI transcoders. [1]: https://patchwork.freedesktop.org/patch/523723/ Fixes: 78353039 ("drm/i915/mtl: Add MeteorLake PCI IDs") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Haridhar Kalvala <haridhar.kalvala@intel.com> Reviewed-by:
-
- 25 Apr, 2023 1 commit
-
-
Imre Deak authored
On ADLP+ Bspec allows DC5/6 to be enabled while power well 2 is enabled. Since the AUX and DDI power wells (except for port A/B) are also backed by power well 2, this would suggest that DC5/6 can be enabled while any of these AUX or DDI port functionalities are used. As opposed to this AUX transfers will time out on ADLP TypeC ports while DC6 is enabled. Until the restriction for DC5/6 is clarified in Bspec let's assume that the intention is to allow for using these power states while pipe A/B is enabled, but only for combo ports which can be used with eDP outputs. Similarly assume that AUX transaction initiated by the driver on any port requires DC states to be disabled. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Fixes: 88c48793 ("drm/i915: Use separate "DC off" power well for ADL-P and DG2") Signed-off-by:
-
- 21 Apr, 2023 2 commits
-
-
Radhakrishna Sripada authored
Communicating QGV points restriction to PUnit happens via PM Demand instead of the Pcode mailbox in the previous platforms. GV point restriction is handled by the PM demand code. Signed-off-by:
-
José Roberto de Souza authored
drm/i915: Initialize dkl_phy spin lock from display code path Start moving the initialization of display locks from i915_driver_early_probe(). Display locks should be initialized from display-only code paths. It was also agreed that if a variable is only used in one file, it should be initialized only in that file, so intel_dkl_phy_init() was added. v2: - added intel_display_locks_init() v3: - rebased v4: - dropped intel_display_locks_init() v5: - moved intel_dkl_phy_init() to the beginning of file Cc: intel-gfx@lists.freedesktop.org Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
