- 26 Oct, 2023 7 commits
-
-
Jouni Högander authored
Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231024124109.384973-8-jouni.hogander@intel.com
-
Jouni Högander authored
Signed-off-by:
-
Jouni Högander authored
Signed-off-by:
-
Jouni Högander authored
Move psr related module parameters under display. Also fix error in enable_psr2_sel_fetch module parameter descrtiption. It was saying disabled by default while it's vice versa. Also psr_safest_params was missing default value in description. This is now added. v2: - Fix enable_psr2_sel_fetch description. - Add default value into psr_safest_params description. Signed-off-by:
-
Jouni Högander authored
Signed-off-by:
-
Jouni Högander authored
GPU error dump contained all module parameters. If we are moving display parameters to intel_display_params.[ch] they are not dumped into GPU error dump. This patch is adding moved display parameters back to GPU error dump. Display parameters are also included in i915_capabilities v2: Add parameters to i915_capabilities as well Signed-off-by:
-
Jouni Högander authored
Currently all module parameters are handled by i915_param.c/h. This is a problem for display parameters when Xe driver is used. Add a mechanism to add parameters specific to the display. This is mainly copied from i915_[debugfs]_params.[ch]. Parameters are not yet moved. This is done by subsequent patches. v2: - Drop unused predefinition (dentry) - Clarify need for empty INTEL_DISPLAY_PARAMS_FOR_EACH in comment Signed-off-by:
-
- 25 Oct, 2023 1 commit
-
-
Vinod Govindapillai authored
Create a separate debugfs entry to list the display capabilities IGT can rely on this debugfs entry for tests that depend on display device and display runtime info for both xe and i915 drivers. v2: rename the entry to i915_display_capabilities (Chaitanya) Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by:
-
- 23 Oct, 2023 6 commits
-
-
Jani Nikula authored
Remove an unnecessary include. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231011162102.1030354-1-jani.nikula@intel.com
-
Jani Nikula authored
No reason to stick to dev_priv, rename to i915. Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231011201533.1081368-2-jani.nikula@intel.com
-
Jani Nikula authored
Add separate macros for VLV/CHV registers without the implicit dev_priv, and with the display MMIO base baked in. A number of implicitly used dev_priv local variables can be removed. Signed-off-by:
-
Jani Nikula authored
No longer needed after commit 94bcf876 ("drm/i915/mtl: Drop Wa_14017240301"). Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231011142704.985867-1-jani.nikula@intel.com
-
Jouni Högander authored
Xe and i915 objects have differing implementation. Use intel_bo_to_drm_bo instead of obj->base as xe_bo doesn't have base pointer. Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231012072158.4115795-3-jouni.hogander@intel.com
-
Jouni Högander authored
As a preparation for Xe we want to remove all i915_gem_object details away from frontbuffer tacking code. Due to this move releasing gem object reference to i915_gem_object_set_frontbuffer. Signed-off-by:
-
- 18 Oct, 2023 1 commit
-
-
Radhakrishna Sripada authored
Meteor Lake has demonstrated consistent stability for some time. All user-space API modifications tide to its core platform functions are operational. The necessary firmware components are set up and comprehensive testing has been condused over a period. Given the recent faborable CI results, as well, we believe it's time to eliminate the 'force_probe' prerequisite and activate the platform by default. Signed-off-by:
Aditya Chauhan <aditya.chauhan@intel.com> Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by:
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Signed-off-by:
Jonathan Cavitt <jonathan.cavitt@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Lee Shawn C <shawn.c.lee@intel.com> Tested-by:
Karthik B S <karthik.b.s@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231008164824.919262-1-andi.shyti@linux.intel.com
-
- 16 Oct, 2023 22 commits
-
-
Ville Syrjälä authored
Just use a simple {} to zero initialize arrays/structs instead of the hodgepodge of stuff we are using currently. Signed-off-by: -
Ville Syrjälä authored
Just use a simple {} to zero initialize arrays/structs instead of the hodgepodge of stuff we are using currently. Signed-off-by: -
Ville Syrjälä authored
Just use a simple {} to zero initialize arrays/structs instead of the hodgepodge of stuff we are using currently. Signed-off-by: -
Imre Deak authored
The previous patches converted all users of the DSC DPCD caps to look these up from the connector, so remove the version stored in intel_dp. A follow-up patchset will read out the MST connector specific capabilities in intel_dp_add_mst_connector() -> intel_dp_mst_read_decompression_port_dsc_caps(). v2: - Rebased on intel_edp_get_dsc_sink_cap() addition in the patchset. v3: - Rebased on read-out fix for eDP in the patchset. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1) Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231011171606.2540078-3-imre.deak@intel.com
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_mst_mode_valid_ctx(). Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_dsc_compute_config(). Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_mode_valid(). Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_dsc_get_slice_count(). Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_dsc_supports_format(). Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_dsc_compute_params(). Reviewed-by:
-
Imre Deak authored
intel_dp_sink_dsc_version_minor() only requires the DSC DPCD, so pass only this to the function. Reviewed-by:
-
Imre Deak authored
intel_dp_source_dsc_version_minor() only requires the i915 pointer, so pass only this to the function. Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in drm_dp_dsc_sink_supported_input_bpcs(). Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_dsc_max_sink_compressed_bppx16(). Reviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_supports_dsc(). Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_supports_fec(). Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in intel_dp_dsc_compute_max_bpp() instead of the version stored in the encoder. Reviewed-by:
-
Imre Deak authored
Use the connector's DSC DPCD capabilities in i915_dsc_fec_support_show() instead of the version stored in the encoder. Atm the two are identical, but a follow-up patch will store the (MST) connector specific version in the connector. Reviewed-by:
-
Imre Deak authored
Cache the i915 specific device and connector pointers in i915_dsc_fec_support_show(). v2: - s/Cahce/Cache typo in commit log. (Stan) Reviewed-by:
-
Imre Deak authored
Similarly to eDP and SST-DP connectors read out the DSC capabilities for MST connectors as well. Atm these will match the root port's DSC caps and only used after a follow-up change enables the decompression for each stream separately (vs. the current way of enabling it only globally in the first branch device downstream of the root port). Reviewed-by:
-
Imre Deak authored
In an MST topology the DSC capabilities are specific to each connector, retrieved either from the sink if it decompresses the stream, or from a branch device between the source and the sink in case this branch device does the decompression. Accordingly each connector needs to cache its own DSC DPCD and FEC capabilities, along with the AUX device through which the decompression can be enabled. This patch prepares for that by storing the capabilities and the DSC AUX device in the connector, for now these just matching the version stored in intel_dp. The follow-up patches will convert all users to look up these in the connector instead of intel_dp, after which the intel_dp copies are removed. v2: - Rebased on intel_edp_get_dsc_sink_cap() addition in previous patch. v3: - Rebased on read-out fix for eDP in previous patch. Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1) Reviewed-by:
-
Imre Deak authored
Check only the eDP or the DP specific DPCD revision depending on the sink type. Pass the corresponding revision to the function, which allows getting the DSC caps of a branch device (in an MST topology, which has its own DPCD and so DPCD revision). While at it use DP_DPCD_REV_14 instead of open coding it and for clarity add a separate function to read out the DSC capability on eDP. v2: - Use DP_DPCD_REV_14 instead of open coding it. (Stan) - Check EDP_DCPD_REV/DPCD_REV in a clearer way. (Ville) v3: - Fix the read-out for eDP in intel_dp_detect(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2) Signed-off-by:
-
- 13 Oct, 2023 3 commits
-
-
Ville Syrjälä authored
With all the known issues sorted out we can start to use DSB to load the LUTs. Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The display engine does not snoop the caches so we should mark the DSB command buffer as I915_CACHE_NONE. i915_gem_object_create_internal() always gives us I915_CACHE_LLC on LLC platforms. And to make things 100% correct we should also clflush at the end, if necessary. Note that currently this is a non-issue as we always write the command buffer through a WC mapping, so a cache flush is not actually needed. But we might actually want to consider a WB mapping since we also end up reading from the command buffer (in the indexed reg write handling). Either that or we should do something else to avoid those reads (might actually be even more sensible on DGFX since we end up reading over PCIe). But we should measure the overhead first... Anyways, no real harm in adding the belts and suspenders here so that the code will work correctly regardless of how we map the buffer. If we do get a WC mapping (as we request) i915_gem_object_flush_map() will be a nop. Well, apart form a wmb() which may just flush the WC buffer a bit earlier than would otherwise happen (at the latest the mmio accesses would trigger the WC flush). Signed-off-by:
-
Ville Syrjälä authored
Using system memory for the DSB command buffer doesn't appear to work. On DG2 it seems like the hardware internally replaces the actual memory reads with zeroes, and so we end up executing a bunch of NOOPs instead of whatever commands we put in the buffer. To determine that I measured the time it takes to execute the instructions, and the results are always more or less consistent with executing a buffer full of NOOPs from local memory. Another theory I considered was some kind of cache coherency issue. Looks like i915_gem_object_pin_map_unlocked() will in fact give you a WB mapping for system memory on DGFX regardless of what mapping mode was requested (WC in case of the DSB code). But clflush did not change the behaviour at all, so that theory seems moot. On DG1 it looks like the hardware might actually be fetching data from system memory as the logs indicate that we just get underruns. But that is equally bad, so doesn't look like we can really use system memory on DG1 either. Thus always allocate the DSB command buffer from local memory on discrete GPUs. Signed-off-by:
-
