- 10 Jul, 2023 1 commit
-
-
Stanislav Lisovskiy authored
Currently we are using dsc_split and bigjoiner variables for determining amount of VDSC instances, however that might change in future, if we happen to have more of those. So lets pack all that logic into single function for convenience, so that at least this isn't hardcoded throughout the whole VDSC code. v2: - s/u8/int/ (Jani Nikula) Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230704131758.14024-2-stanislav.lisovskiy@intel.com
-
- 05 Jul, 2023 7 commits
-
-
Ville Syrjälä authored
Try to deal with duplicate child devices for the same DDI port by attempting to initialize them in VBT defined order The first on to succeed for a specific DDI port will be the one we use. We'll also get rid of i915->display.vbt.ports[] here as any conflicts will now be handled at encoder registration time rather than during VBT parsing. Note that intel_bios_encoder_data_lookup() still remaims for pre-DDI DP/HDMI ports as those don't (at least yet) use VBT driven initialization. TODO: DSI dual link handling is sketchy at best v2: Leave intel_bios_encoder_port() to the encoder callback (Jani) 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/20230630155846.29931-7-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
We'll have a few places where we need to do the full (incl. ICL+ DSI) DVO port->port conversion, so extract the code for that into a helper. Suggested-by:
-
Ville Syrjälä authored
Stop with the VBT AUX CH sanitation, and instead just check that the appropriate AUX CH is still available when initializing a DP/TC port. The reason being that we want to start initializing ports in VBT order to deal with VBTs that declare child devices with seemingly conflicting ports. As the encoder initialization can fail for other reasons (at least for eDP+AUX) we can't know upfront which way the conflicts should be resolved. Note that the old way of sanitizing gave priority to the last port declared in the VBT, but now we sort of do the opposite by favoring the first encoder to successfully initialize. The reason for the old "last port wins" preference was eg. Asrock B250M-HDV where port A (eDP) and port E (DP->VGA) have an AUX CH conflict and we need to prefer port E. However with the new way port A (eDP) will be probed first, but will fail to probe due to HPD and thus port E will still win in the end. v2: Pimp the commit message (Jani) Reviewed-by:
-
Ville Syrjälä authored
Stop with the VBT DDC pin sanitation, and instead just check that the appropriate DDC pin is still available when initializing a HDMI connector. The reason being that we want to start initializing ports in VBT order to deal with VBTs that declare child devices with seemingly conflicting ports. As the encoder initialization can fail for other reasons (at least for eDP+AUX) we can't know upfront which way the conflicts should be resolved. Note that the old way of sanitizing gave priority to the last port declared in the VBT, but now we sort of do the opposite by favoring the first encoder to successfully initialize. So far we're not aware of HDMI/DDC use cases where this would matter but for AUX CH (will be subject to a similar change) there are known cases where it matters. Also note that the old code fell back to the platform default DDC pin if the VBT pin was populated but invalid. That doesn't seem like such a great idea because the VBT might have later declared another port using that platform default pin, and so we might just be creating more DDC pin conflicts here. So lets not second guess the VBT and simply reject the entire HDMI encoder if the VBT DDC pin is invalid. v2: Pimp the commit message (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Mixing VBT based AUX CH with platform defaults seems like a recipe for conflicts. Let's only populate AUX CH if we absolutely need it, that is only if we are dealing with a DP output or a TC port (which need it due to some power well shenanigans). TODO: double check that real VBTs do in fact populate the AUX CH for HDMI TC legacy ports... Reviewed-by: -
Ville Syrjälä authored
Make sure dig_port->aux_ch is trustworthy by initializing it to NONE (-1) at the start. The encoder init will later fill in the actual value, if appropriate. Reviewed-by:
-
Stanislav Lisovskiy authored
Currently we just clamp that value to the highest supported one, however that means, we are not able to fit this into our available bandwidth range, so we might see glitches or FIFO underruns. While choosing less compressed bpp than min bpp required to handle the mode is harmless and might even save some bandwidth, choosing higher compressed bpp than min bpp required to handle the required mode config, can cause issues. So in that case lets just conclude that even with DSC, we are not able to comply with bandwidth requirements and fail. v2: - s/clamp_t/min_t/ (Luca Coelho) Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230629122534.8815-1-stanislav.lisovskiy@intel.com
-
- 04 Jul, 2023 3 commits
-
-
Jani Nikula authored
The __raw_uncore_* interface is supposed to be intel_uncore.[ch] internal only. Replace the remaining outside user with intel_uncore_read_fw(), which is essentially the same thing. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230627105849.274263-1-jani.nikula@intel.com
-
Jani Nikula authored
Add a helper for accessing uncore->regs instead of doing it directly. This will help display code reuse with the xe driver. Cc: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
-
Stanislav Lisovskiy authored
If we are using Bigjoiner dpll_hw_state is supposed to be exactly same as for master crtc, so no need to save it's state for slave crtc. Signed-off-by:
-
- 29 Jun, 2023 7 commits
-
-
Jani Nikula authored
Finally we can get rid of the pseudo-const write-once device info, and convert it into a const pointer to device info in rodata. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f31933222f44e4a9224e41399a96896eb243e653.1687878757.git.jani.nikula@intel.com
-
Jani Nikula authored
Continue moving all things display further into display files and structures. v2: Sort includes (Matt) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Jani Nikula authored
Prefer DISPLAY_INFO() over INTEL_INFO()->display. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Jani Nikula authored
Add new function intel_display_device_info_print() and print the display device info there instead of intel_device_info_print(). This also fixes the display runtime info printing to use the actual runtime info instead of the static defaults. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Jani Nikula authored
The mock device creation was the only place that needed to modify platform_engine_mask and memory_regions runtime. With mock_info in place for mock devices, we can move them to device info. Signed-off-by:
-
Jani Nikula authored
Instead of modifying the device info on the fly, use static const mock device info. It's not okay to modify device info at runtime; we've added separate runtime info for info that needs to be modified at runtime. We've added safeguards to device info to prevent it from being modified, but commit 5e352e32 ("drm/i915: preparation for using PAT index") just cast the const away and modified it anyway. This prevents device info from being moved to rodata. Fixes: 5e352e32 ("drm/i915: preparation for using PAT index") Suggested-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Fei Yang <fei.yang@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b0db62045a96a3fd4cf123685da88cc777f9b485.1687878757.git.jani.nikula@intel.com
-
Gustavo Sousa authored
That function is not defined anywhere. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Signed-off-by:
-
- 26 Jun, 2023 8 commits
-
-
Jani Nikula authored
Fix Sphinx warning about unexpected indent. Signed-off-by:
-
Jani Nikula authored
We have duplicate kernel-doc directives for the same struct, leading to: /home/jani/src/linux/Documentation/gpu/driver-uapi.rst:2279: WARNING: Duplicate C declaration, also defined at rfc/i915_scheduler:3. Declaration is '.. c:struct:: i915_context_engines_parallel_submit'. Use the Sphinx C domain namespace for the rfc document to fix this. Signed-off-by:
-
Imre Deak authored
DC states are disabled / re-enabled around each modeset, which may lead to a needless off->on->off toggling of the DC_off power well. This has some overhead as toggling DC states involves running a DMC firmware handler and also running a periodic firmware handler while DC states are enabled. The limit of when DC states have a benefit is at 30 FPS (using DC3co) and below 30 FPS (using DC5/6), where the firmware can actually disable clocks / power off power wells. Accordingly delay powering off the DC_off powerwell (which re-enables DC states) by 17 ms at the end of a modeset to avoid the above overhead at or above 60 FPS. Reviewed-by:
Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230616185104.2502003-4-imre.deak@intel.com
-
Imre Deak authored
Add support for specifying a delay different than the current 100 ms default for powering off a display power domain. This is needed by the next patch which delays re-enabling DC states during modesets to avoid the off->on->off toggling overhead of the DC_off power well, but does this using a < 100 ms delay for a better utilization of DC power saving states. Reviewed-by:
-
Imre Deak authored
Remove the forward declarations for enums and structs from display power header files that aren't used in prototypes. Reviewed-by:
-
Imre Deak authored
Add the seq_file struct forward declaration to intel_display_power.h fixing the build error below. While at it add the rest of missing forward declarations/includes to the display power header files. In file included from <command-line>: ./../drivers/gpu/drm/i915/display/intel_display_power.h:255:70: error: 'struct seq_file' declared inside parameter list will not be visible outside of this definition or declaration [-Werror] 255 | void intel_display_power_debug(struct drm_i915_private *i915, struct seq_file *m); | ^~~~~~~~ Closes: https://lore.kernel.org/intel-gfx/89adc1ac-25a0-6eb6-4cc9-ab6cc8d49730@infradead.org/Reported-by:Randy Dunlap <rdunlap@infradead.org> Acked-by:
-
Suraj Kandpal authored
Add a debug statement at hdcp2 capability check which indicates if GSC CS is causing hdcp2 incapability --v2 -correcttypo in commit header --v3 -correct the other typo in commit header [Jani] Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by:
-
Suraj Kandpal authored
Currently hdcp->content_type is being assigned the content_type field in drm_connector_state which is wrong and instead it needs to be assigned hdcp_content_type field from drm_connector_state Fixes: 4c4279a8 ("drm/i915/hdcp: add intel_atomic_state argument to hdcp_enable function") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Signed-off-by:
-
- 21 Jun, 2023 1 commit
-
-
Jouni Högander authored
Encoder compute config is changing hw.adjusted mode. Uapi.adjusted mode doesn't get updated before psr compute config gets called. This causes io and fast wake line calculation using adjusted mode containing values before encoder adjustments. Fix this by using hw.adjusted mode instead of uapi.adjusted mode. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230620111745.2870706-1-jouni.hogander@intel.com
-
- 20 Jun, 2023 12 commits
-
-
Radhakrishna Sripada authored
The hdmi_level_shifter part of General Bytes definition in VBT, which was used for choosing different levels on earlier platforms is now a hidden optin and shows the default value of 0. The level shifter is now to be deduced from hdmi_default_entry in intel_ddi_buf_trans for each phy. Skip providing the default hw provided value to force driver to choose hdmi default entry. Bspec: 20124 Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Cc: Lee Shawn C <shawn.c.lee@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230616210028.1601533-1-radhakrishna.sripada@intel.com
-
Radhakrishna Sripada authored
Driver does not clear the default SSC for MPLLA. This causes link training failure when trying to use 10G and 20G rates. Fix the behaviour and enable ssc only when we really want. Fixes: 237e7be0 ("drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Khaled Almahallawy <khaled.almahallawy@intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by:
Khaled Almahallawy <khaled.almahallawy@intel.com> Reviewed-by:
-
Lee Shawn C authored
Add vswing table to support DP 1.4 for C20 phy. v2: rename mtl_c10_trans v3: add default_entry for mtl_c20_trans_dp14 v4: rename mtl_cx0_trans_dp14 Bspec: 74104 Signed-off-by:
Lee Shawn C <shawn.c.lee@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Reviewed-by:
-
Lee Shawn C authored
Update preset 15 setting to align the latest bspec value. Bspec: 74104 Signed-off-by:
-
Ville Syrjälä authored
Make HSW/BDW use port_mask for output probing as well. To achieve that the strap checks are moved into intel_ddi_init() itself. Or should we move them to the runtime port_mask init instead? Maybe not since the hardware is still there, just not connected to anything. v2: Account for DDI-E in strap detection Keep to the old CRT->DDI init order Reviewed-by: -
Ville Syrjälä authored
Instead of listing every platform's possible DDI outputs in intel_setup_outputs() just loop over the new port_mask to achieve the same thing. HSW/BDW were left as is since they still look at the straps as well. DSI is still a mess. For now just check for the relevant platforms explicitly. Reviewed-by:
-
Ville Syrjälä authored
The SDVO code already warns when the port in question doesn't actually support SDVO. Let's make that also bail the encoder registration like the generic assert_port_valid() we added. And add a similar thing for g4x HDMI, mainly because on g4x itsefl port D only supports DP but not SDVO/HDMI. For the other platforms the generic port_mask check should actually be sufficient, but since we're here might as well list the ports. Reviewed-by:
-
Ville Syrjälä authored
Sprinkle some asserts to catch any mishaps in the port_mask vs. output init. For DDI/DP/HDMI/SDVO I decided that we want to bail out for an invalid port since those are the encoder types where we might want consider driving the whole thing from the VBT child device list, and bogus VBTs could be a real issue (if for no other reason than the i915.vbt_firmware). For DVO and HSW/BDW CRT port I just threw the assert in there for good measure. Reviewed-by:
-
Ville Syrjälä authored
Sprinkle in some BUILD_BUG_ON()s to make sure some of the bitmasks used in the device info have enough bits. Do we have a better place for this sort of stuff? v2: Relocate to the new place Reviewed-by:
-
Ville Syrjälä authored
Declare the available DVO/SDVO/HDMI/DP/DDI ports in the device info. The other outputs (LVDS/TV/DSI/VGA) are left out since for most of them we don't consider them as "ports". DSI we should probably perhaps include somehow in the device info. Just not sure how. Or we just introduce a HAS_DSI() and call it a day? TODO: figure out what to do about the subplatform stuff. Would it be better to declare those directly with a different device info or not? Also not sure the icl port-f stuff matters even. Bspec claims there are icl SKUs with far less ports than that and we don't seem to check for those either? v2: Fix TC5 vs. TC6 mixup on TGL (Jani) Drop DDI C for now on TGL, and add a FIXME (Jani) Reviewed-by:Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Ville Syrjälä authored
HSW/BDW don't have DDI-F so don't go looking for one. Seems to have been accidentally left behind when the skl+ stuff got split out in commit 097d9e90 ("drm/i915/display: remove strap checks from gen 9"). Reviewed-by:
-
Imre Deak authored
A recent bspec update added a restriction on when DC states can be enabled: [Before enabling DC states:] """ PG2 can be kept enabled only because PGB requires PG2. Do not use PG2 functions, such as type-C DDIs. DMC will dynamically control PG1, PGA, PG2, PGB. """ Accordingly prevent DC states if PW2 (aka PG2) is enabled for any other functionality. Bpsec: 49193 Fixes: 88c48793 ("drm/i915: Use separate "DC off" power well for ADL-P and DG2") Reported-by:
Kai Vehmanen <kai.vehmanen@intel.com> Tested-by:
Ambica Pramod <ambica.pramod@intel.com> Reviewed-by:
-
- 16 Jun, 2023 1 commit
-
-
Ville Syrjälä authored
All known issues fixed now, so re-enable PSR1 on hsw/bdw. Signed-off-by:
-
