summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-02-15drm/i915: Add PLL .compare_hw_state() vfuncVille Syrjälä
Chunk up the humongous dpll_hw_state comparison check into per-platform variants, implemented in the dpll_mgr. This is step one in allowing each platform (or perhaps even PLL) type to have a custom hw state structure instead of having to smash it all into one. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240209183809.16887-5-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2024-02-15drm/i915: Reuse ibx_dump_hw_state() for gmch platformsVille Syrjälä
GMCH platform DPLLs are similar to the IBX+ PCH DPLLs so we can just use the same state dump function for both. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240209183809.16887-4-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2024-02-15drm/i915: Include the CRTC name in the ELD buffer mismatchVille Syrjälä
Most crtc state mismatches include the CRTC id+name in the prints. Also include it in the ELD buffer mismatch prints. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240209183809.16887-3-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2024-02-15drm/i915: Fix PLL state check for gmch platformsVille Syrjälä
GMCH DPLL state check was mistakenly removed in commit 87fc875a2b85 ("drm/i915/dg2: Skip shared DPLL handling"). Bring it back. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240209183809.16887-2-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com>
2024-02-14drm/i915: Update ADL-N PCI IDsGustavo Sousa
Extend the list of ADL-N PCI IDs to contain two new entries. Bspec: 68397 Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240214144629.106702-2-gustavo.sousa@intel.com
2024-02-14drm/i915/display: update pll values in sync with Bspec for MTLRavi Kumar Vodapalli
DP/eDP and HDMI C20 PHY PLL values were updated for MTL platform Signed-off-by: Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240214070930.1028456-1-ravi.kumar.vodapalli@intel.com
2024-02-13drm/i915: Prevent HW access during init from connector get_modes hooksImre Deak
Prevent accessing the HW from the get_modes hooks of connectors deriving the mode list from the display's EDID. drm_edid_connector_add_modes() will return the mode list based on the EDID which was cached during a previous detection/get_modes call. This also fixes the NULL deref problem (10085) which was introduced/revealed by commit bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during driver init/shutdown") After the above change MST connectors will not change state during driver init/shutdown; thus some of these connectors with no I2C/DDC adapter registered for them (since the given MST port has no sink connected) may stay then in the 'unknown' connector status. The get_modes() hook should not try to use the I2C/DDC adapter in this state (which would lead to the above NULL deref) which this patch ensures. v2: - Remove the redundant check from intel_crt_ddc_get_modes(). - Rebase on latest drm-tip. - Add Fixes: line / related commit notes. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10085 Fixes: bab87ef4db9a ("drm/i915: Disable hotplug detection handlers during driver init/shutdown") Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212175237.2625812-2-imre.deak@intel.com
2024-02-13drm/i915: Prevent HW access during init from SDVO TV get_modes hookImre Deak
Prevent accessing the HW from the SDVO/TV get_modes connector hook. Returning 0 from the hook will make the caller - drm_helper_probe_single_connector_modes() - return a default/EDID override mode list to users. This matches the case where intel_sdvo_get_tv_modes() fails to retrieve the current mode list due to a HW access failure. v2: Clarify the commit message wrt. which modes get_modes() returns. (Jouni) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212175237.2625812-1-imre.deak@intel.com
2024-02-13drm/i915: Add bigjoiner force enable option to debugfsStanislav Lisovskiy
For validation purposes, it might be useful to be able to force Bigjoiner mode, even if current dotclock/resolution do not require that. Lets add such to option to debugfs. v2: - Apparently intel_dp_need_bigjoiner can't be used, when debugfs entry is created so lets just check manually the DISPLAY_VER. v3: - Switch to intel_connector from drm_connector(Jani Nikula) - Remove redundant modeset lock(Jani Nikula) - Use kstrtobool_from_user for boolean value(Jani Nikula) v4: - Apply the changes to proper function(Jani Nikula) v5: - Removed unnecessary check from i915_bigjoiner_enable_show (Ville Syrjälä) - Added eDP connector check to intel_connector_debugfs_add (Ville Syrjälä) - Removed debug message in order to prevent dmesg flooding (Ville Syrjälä) v6: - Assume now always that m->private is intel_connector - Fixed other similar conflicts v7: - Move bigjoiner force option to intel_connector(Ville Syrjälä) - Use DEFINE_SHOW_STORE_ATTRIBUTE instead of defining fops manually.(Ville Syrjälä) v8: - Pass intel_connector to debugfs_create_file, instead of drm_connector. (Jani Nikula) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240212125011.66174-1-uma.shankar@intel.com
2024-02-09drm/i915/dvo: Use sizeof(*variable) instead of sizeof(type)Ville Syrjälä
Prefer sizeof(*variable) to sizeof(type) to make it a bit harder to screw things up. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-14-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/dvo/ns2501: Nuke pointless castsVille Syrjälä
The dvo 'dev_priv' is void* so no need for an explicit cast. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/wm: Use per-device debugs ilk wm codeVille Syrjälä
Switch to drm_dbg_kms() in the ilk wm code so we see which device generated the debugs. Need to plumb i915 a bit deeper to make that happen. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-12-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/wm: Use per-device debugs in pre-ilk wm codeVille Syrjälä
Switch to drm_dbg_kms() in the pre-ilk wm code so we see which device generated the debugs. Need to plumb i915 a bit deeper to make that happen. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-11-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/wm: Pass the whole i915 to intel_get_cxsr_latency()Ville Syrjälä
Just pass the whole i915 to intel_get_cxsr_latency() instead of having each caller dig out bits and pieces. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-10-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/hdcp: Use per-device debugsVille Syrjälä
Switch to per-device debugs in the hdcp code so we see at least which device is involved. Should proably also print the connector/encoder/etc. in there, but left that for the future. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-9-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/bios: Use per-device debugs for VBT related stuffVille Syrjälä
Switch to drm_dbg_kms() in the VBT code so we see which device generated the debugs. Need to plumb i915 a bit deeper to make that happen. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-8-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/bios: Switch to kms debugsVille Syrjälä
The VBT code is all about displays, so switch to UT_KMS debugs from UT_DRIVER. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-7-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/fb: Use per-device debugsVille Syrjälä
Switch to drm_dbg_kms() in the fb code so we see which device generated the debugs. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-6-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/color: Use per-device debugsVille Syrjälä
Switch to drm_dbg_kms() in the LUT validation code so we see which device generated the debugs. Need to plumb i915 a bit deeper to make that happen. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/sdvo: Fix up code alignmentVille Syrjälä
Realign a bunch of code that has become messy. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/sdvo: Convert to per-device debugsVille Syrjälä
Use drm_dbg_kms() instead of DRM_DEBUG_KMS() in the sdvo code to get the device name into the debug prints. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915: Correct for_each_old_global_obj_in_state() argumentsVille Syrjälä
for_each_old_global_obj_in_state() gives us the old state, not the new state. Correct the name of the macro argument. Note that while the argument was misnamed the macro did work correctly regardless. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-09drm/i915/dp: Limit SST link rate to <=8.1GbpsVille Syrjälä
Limit the link rate to HBR3 or below (<=8.1Gbps) in SST mode. UHBR (10Gbps+) link rates require 128b/132b channel encoding which we have not yet hooked up into the SST/no-sideband codepaths. Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208154552.14545-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2024-02-08drm/i915/dsc: Fix the macro that calculates DSCC_/DSCA_ PPS reg addressManasi Navare
Commit bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS register") defines a new macro to calculate the DSC PPS register addresses with PPS number as an input. This macro correctly calculates the addresses till PPS 11 since the addresses increment by 4. So in that case the following macro works correctly to give correct register address: _MMIO(_DSCA_PPS_0 + (pps) * 4) However after PPS 11, the register address for PPS 12 increments by 12 because of RC Buffer memory allocation in between. Because of this discontinuity in the address space, the macro calculates wrong addresses for PPS 12 - 16 resulting into incorrect DSC PPS parameter value read/writes causing DSC corruption. This fixes it by correcting this macro to add the offset of 12 for PPS >=12. v3: Add correct paranthesis for pps argument (Jani Nikula) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10172 Fixes: bd077259d0a9 ("drm/i915/vdsc: Add function to read any PPS register") Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Sean Paul <sean@poorly.run> Cc: Drew Davenport <ddavenport@chromium.org> Signed-off-by: Manasi Navare <navaremanasi@chromium.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240205204619.1991673-1-navaremanasi@chromium.org
2024-02-08drm/i915/display: On Xe2 always enable decompression with tile4Juha-Pekka Heikkila
With Xe2 always treat tile4 as if it was using flat ccs. Signed-off-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202150602.430036-2-juhapekka.heikkila@gmail.com
2024-02-07drm/i915/alpm: Alpm aux wake configuration for lnlJouni Högander
Lunarlake has some configurations in ALPM_CTL register for legacy ALPM as well. Write these. Bspec: 71477 v2: move version check to lnl_alpm_configure Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240130111130.3298779-5-jouni.hogander@intel.com
2024-02-07drm/i915/alpm: Calculate ALPM Entry checkJouni Högander
ALPM Entry Check represents the number of lines needed to put the main link to sleep and keep it in the sleep state before it can be taken out of the SLEEP state (eDP requires the main link to be in the SLEEP state for a minimum of 5us). Bspec: 71477 v2: move display version check into _lnl_compute_alpm_param Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240130111130.3298779-4-jouni.hogander@intel.com
2024-02-07drm/i915/psr: Add alpm_parameters structJouni Högander
Add new alpm_parameters struct into intel_psr for all calculated alpm parameters. v2: Move alpm_parameters struct definition to intel_psr struct Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240130111130.3298779-3-jouni.hogander@intel.com
2024-02-07drm/i915/alpm: Add ALPM register definitionsJouni Högander
Add ALPM register definitions for Lunar Lake. v3: - Fix ALPM_CTL2_A address - Remove duplicate defines v2: - Use REG_BIT instead of BIT - Add commit message Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240130111130.3298779-2-jouni.hogander@intel.com
2024-02-07drm/i915: Annotate more of the BIOS fb takeover failure pathsVille Syrjälä
Annotate a few more of the failure paths on the initial BIOS fb takeover to avoid having to guess why things aren't working the way we expect. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-17-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Try to relocate the BIOS fb to the start of ggttVille Syrjälä
On MTL the GOP (for whatever reason) likes to bind its framebuffer high up in the ggtt address space. This can conflict with whatever ggtt_reserve_guc_top() is trying to do, and the result is that ggtt_reserve_guc_top() fails and then we proceed to explode when trying to tear down the driver. Thus far I haven't analyzed what causes the actual fireworks, but it's not super important as even if it didn't explode we'd still fail the driver load and the user would be left with an unusable GPU. To remedy this (without having to figure out exactly what ggtt_reserve_guc_top() is trying to achieve) we can attempt to relocate the BIOS framebuffer to a lower ggtt address. We can do this at this early point in driver init because nothing else is supposed to be clobbering the ggtt yet. So we simply change where in the ggtt we pin the vma, the original PTEs will be left as is, and the new PTEs will get written with the same dma addresses. The plane will keep on scanning out from the original PTEs until we are done with the whole process, and at that point we rewrite the plane's surface address register to point at the new ggtt address. Since we don't need a specific ggtt address for the plane (apart from needing it to land in the mappable region for normal stolen objects) we'll just try to pin it without a fixed offset first. It should end up at the lowest available address (which really should be 0 at this point in the driver init). If that fails we'll fall back to just pinning it exactly to the origianal address. To make sure we don't accidentlally pin it partially over the original ggtt range (as that would corrupt the original PTEs) we reserve the original range temporarily during this process. v2: Try to pin explicitly to ggtt offset 0 as otherwise DG2 puts it even higher (atm we have no PIN_LOW flag to force it low) v3: "fix" xe Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-16-ville.syrjala@linux.intel.com Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-02-07drm/i915: Tweak BIOS fb reuse checkVille Syrjälä
Currently we assume that we bind the BIOS fb exactly into the same ggtt address where the BIOS left it. That is about to change, and in order to keep intel_reuse_initial_plane_obj() working as intended we need to compare the original ggtt offset (called 'base' here) as opposed to the actual vma ggtt offset we selected. Otherwise the first plane could change the ggtt offset, and then subsequent planes would no longer notice that they are in fact using the same ggtt offset that the first plane was already using. Thus the reuse check will fail and we proceed to turn off these subsequent planes. TODO: would probably make more sense to do the pure readout first for all the planes, then check for fb reuse, and only then proceed to pin the object into the final location in the ggtt... v2: "fix" xe Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-15-ville.syrjala@linux.intel.com Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-02-07drm/i915/fbdev: Fix smem_start for LMEMBAR stolen objectsVille Syrjälä
The "io" address of an object is its dma address minus the region.start. Subtract the latter to make smem_start correct. The current code happens to work for genuine LMEM objects as LMEM region.start==0, but for LMEMBAR stolen objects region.start!=0. TODO: perhaps just set smem_start=0 always as our .fb_mmap() implementation no longer depends on it? Need to double check it's not needed for anything else... Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-14-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Simplify intel_initial_plane_config() calling conventionVille Syrjälä
There's no reason the caller of intel_initial_plane_config() should have to loop over the CRTCs. Pull the loop into the function to make life simpler for the caller. v2: "fix" xe Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-13-ville.syrjala@linux.intel.com Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-02-07drm/i915: Split the smem and lmem plane readout apartVille Syrjälä
Declutter initial_plane_vma() a bit by pulling the lmem and smem readout paths into their own functions. TODO: the smem path should still be fixed to get and validate the dma address from the pte as well Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-12-ville.syrjala@linux.intel.com
2024-02-07drm/i915: s/phys_base/dma_addr/Ville Syrjälä
The address we read from the PTE is a dma address, not a physical address. Rename the variable to say so. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-11-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Fix MTL initial plane readoutVille Syrjälä
MTL stolen memory looks more like local memory, so use the (now fixed) lmem path when doing the initial plane readout. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-10-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Fix region start during initial plane readoutVille Syrjälä
On MTL the stolen region starts at offset 8MiB from the start of LMEMBAR. The dma addresses are thus also offset by 8MiB. However the mm_node/etc. is zero based, and i915_pages_create_for_stolen() will add the appropriate region.start into the sg dma address. So when we do the readout we need to convert the dma address read from the PTE to be zero based as well. Note that currently we don't take this path on MTL, but we should and thus this needs to be fixed. For lmem this works correctly already as the lmem region.start==0. While at it let's also make sure the address points to somewhere within the memory region. We don't need to check the size as i915_gem_object_create_region_at() should later fail if the object size exceeds the region size. Reviewed-by: Uma Shankar <uma.shankar@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-9-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Fix PTE decode during initial plane readoutVille Syrjälä
When multiple pipes are enabled by the BIOS we try to read out each in turn. But we do the readout for the second only after the inherited vma for the first has been rebound into its original place (and thus the PTEs have been rewritten). Unlike the BIOS we set some high caching bits in the PTE on MTL which confuses the readout for the second plane. Filter out the non-address bits from the PTE value appropriately to fix this. I suppose it might also be possible that the BIOS would already set some caching bits as well, in which case we'd run into this same issue already for the first plane. TODO: - should abstract the PTE decoding to avoid details leaking all over - should probably do the readout for all the planes before we touch anything (including the PTEs) so that we truly read out the BIOS state Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-8-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Rename the DSM/GSM registersVille Syrjälä
0x108100 and 0x1080c0 have been around since snb. Rename the defines appropriately. v2: Rebase Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-7-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Disable the "binder"Ville Syrjälä
Now that the GGTT PTE updates go straight to GSMBASE (bypassing GTTMMADR) there should be no more risk of system hangs? So the "binder" (ie. update the PTEs via MI_UPDATE_GTT) is no longer necessary, disable it. My main worry with the MI_UPDATE_GTT are: - only used on this one platform so very limited testing coverage - async so more opprtunities to screw things up - what happens if the engine hangs while we're waiting for MI_UPDATE_GTT to finish? - requires working command submission, so even getting a working display now depends on a lot more extra components working correctly TODO: MI_UPDATE_GTT might be interesting as an optimization though, so perhaps someone should look into always using it (assuming the GPU is alive and well)? v2: Keep using MI_UPDATE_GTT on VM guests v3: use i915_direct_stolen_access() Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-6-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory accessVille Syrjälä
On MTL accessing stolen memory via the BARs is somehow borked, and it can hang the machine. As a workaround let's bypass the BARs and just go straight to DSMBASE/GSMBASE instead. Note that on every other platform this itself would hang the machine, but on MTL the system firmware is expected to relax the access permission guarding stolen memory to enable this workaround, and thus direct CPU accesses should be fine. The raw stolen memory areas won't be passed to VMs so we'll need to risk using the BAR there for the initial setup. Once command submission is up we should switch to MI_UPDATE_GTT which at least shouldn't hang the whole machine. v2: Don't use direct GSM/DSM access on guests Add w/a number v3: Check register 0x138914 to see if pcode did its job Add some debug prints Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-5-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Remove ad-hoc lmem/stolen debugsVille Syrjälä
Now that intel_memory_regions_hw_probe() prints out each and every memory region there's no reason to have ad-hoc debugs to do similar things elsewhere. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-4-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Print memory region info during probeVille Syrjälä
Dump the details about every memory region into dmesg at probe time. Avoids having to dig those out from random places when debugging stuff. Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-3-ville.syrjala@linux.intel.com
2024-02-07drm/i915: Use struct resource for memory region IO as wellVille Syrjälä
mem->region is a struct resource, but mem->io_start and mem->io_size are not for whatever reason. Let's unify this and convert the io stuff into a struct resource as well. Should make life a little less annoying when you don't have juggle between two different approaches all the time. Mostly done using cocci (with manual tweaks at all the places where we mutate io_size by hand): @@ struct intel_memory_region *M; expression START, SIZE; @@ - M->io_start = START; - M->io_size = SIZE; + M->io = DEFINE_RES_MEM(START, SIZE); @@ struct intel_memory_region *M; @@ - M->io_start + M->io.start @@ struct intel_memory_region M; @@ - M.io_start + M.io.start @@ expression M; @@ - M->io_size + resource_size(&M->io) @@ expression M; @@ - M.io_size + resource_size(&M.io) Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by: Nirmoy Das <nirmoy.das@intel.com> Tested-by: Paz Zcharya <pazz@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240202224340.30647-2-ville.syrjala@linux.intel.com
2024-02-05drm/i915/hdcp: Pin the hdcp gsc message high in ggttVille Syrjälä
AFAICS there is no hardware restriction on where in ggtt the hdcp gsc message object needs to be bound. And as it's a regular shmem object we don't need it be in the mappabe range either. So pin it high to make avoid needlessly wasting the precious mappable range for it. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@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/20231215110933.9188-3-ville.syrjala@linux.intel.com Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
2024-02-05drm/i915/hdcp: Do intel_hdcp_component_init() much later during initVille Syrjälä
intel_hdcp_component_init()->...->intel_hdcp_gsc_initialize_message() will allocate ggtt address space for some hdcp gsc message thing. That is currently being done way too early as we haven't even taken over the BIOS fb yet. So this has the potential of corrupting ggtt PTEs that need to be preserved until the BIOS fb takover is done. Only call intel_hdcp_component_init() once all the BIOS fb takeover, and full ggtt init (which currently also needs to reserve very specific ranges of ggtt, thus assuming that no one else has stolen them yet) is done. Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@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/20231215110933.9188-2-ville.syrjala@linux.intel.com Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com>
2024-02-02drm/i915/fbc: Allow FBC with CCS modifiers on SKL+Ville Syrjälä
Only display workarounds 0391 and 0475 call for disabling FBC with render compression, and those are listed only for pre-prod SKL steppings. So it should be safe to enable FB+CCS on production hardware. AFAIK CCS is limited to 50% bandwidth reduction (perhaps clear color can do better?). FBC can exceed that number by quite a bit, given the right kind of framebuffer contents. So piling on both kinds of compressions could still make sense. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10125 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240123090244.30025-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-02-02drm/i915: Extract intel_atomic_swap_state()Ville Syrjälä
Pull all the state swap stuff into its own function to declutter intel_atomic_commit() a bit. Note that currently the state swap is spread across both sides of the unprepare branch in intel_atomic_commit(), but we can pull all of it ahead a bit since we bail on the first error, and thus there is no change in behaviour from the reordering. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231219130756.25986-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2024-02-02drm/i915: Rework global state serializaitonVille Syrjälä
Instead of injecting extra crtc commits to serialize the global state let's hand roll a bit of commit machinery to take care of the hardware synchronization. Rather than basing everything on the crtc commits we track these as their own thing. I think this makes more sense as the hardware blocks we are working with are not in any way tied to the pipes, so the completion should not be tied in with the vblank machinery either. The difference to the old behaviour is that: - we no longer pull extra crtcs into the commit which should make drm_atomic_check_only() happier - since those crtcs don't get pulled in we also don't end up reprogamming them and thus don't need to wait their vblanks to pass/etc. So this should be tad faster as well. TODO: perhaps have each global object complete its own commit once the post-plane update phase is done? Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6728 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231219130756.25986-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-07-29 02:07:27 +0000