- 19 Feb, 2024 2 commits
-
-
Jiri Slaby (SUSE) authored
Both struct intel_vgpu_pipe_format and intel_vgpu_fb_format were never used since its addition in commit 9f31d106 (drm/i915/gvt: Add framebuffer decoder support). Drop them. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
Jiri Slaby (SUSE) <jirislaby@kernel.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Acked-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240216065326.6910-3-jirislaby@kernel.org
-
Jiri Slaby (SUSE) authored
struct intel_dvo_dev_ops's ::create_resources(), ::prepare(), ::commit::, and get_modes() are all unused since their addition in 79e53945 (DRM: i915: add mode setting support). Drop all of them. Found by https://github.com/jirislaby/clang-struct. Signed-off-by:
-
- 16 Feb, 2024 4 commits
-
-
Ville Syrjälä authored
Add a bit of documentation to briefly explain the methods by which we can change the CDCLK frequency. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240207013334.29606-5-ville.syrjala@linux.intel.comReviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com>
-
Ville Syrjälä authored
cdclk_compute_crawl_and_squash_midpoint() was still assuming that cd2x divider == 1 (ie. full divider == 2). Remove that assumption by computing the dividers properly. We'll also toss in a WARN in case the divider somehow ends up different between the old and new cdclk configs. That should never happen given we have div==2 in all the cdclk table entries for the affected platforms. If in the future we need a config where the divider also needs to be changed then we likely need to add an extra step into the cdclk programming sequence to make sure things stay within legal limits throughout the process. Signed-off-by:
-
Ville Syrjälä authored
Have cdclk_squash_waveform() return a u16 since that's how many bits we have in the waveform. We alreday use u16 everywhere else. Signed-off-by:
-
Ville Syrjälä authored
Extract the cdclk divider calculation into a helper. We'll have more users of this soon. We can now also get rid of the intermediate 'unsquashed_cdclk' variable. Signed-off-by:
-
- 14 Feb, 2024 7 commits
-
-
Ville Syrjälä authored
There's nothing magical about vlv+ platforms vs. fastboot. If it works somewhere it should work everywhere, assuming we've not missed any crucial state checks. That seems unlikely on older platforms with less state to check anyway. Just enable fastboot across the board, and the remove the remnants of the optional stuff (we already removed the modparam for fastboot anyway). Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
GMCH DPLL state check was mistakenly removed in commit 87fc875a ("drm/i915/dg2: Skip shared DPLL handling"). Bring it back. Signed-off-by:
-
Gustavo Sousa authored
Extend the list of ADL-N PCI IDs to contain two new entries. Bspec: 68397 Signed-off-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
-
Ravi Kumar Vodapalli authored
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:
-
- 13 Feb, 2024 3 commits
-
-
Imre Deak authored
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 bab87ef4 ("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: bab87ef4 ("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
-
Imre Deak authored
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:
-
Stanislav Lisovskiy authored
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:
-
- 09 Feb, 2024 14 commits
-
-
Ville Syrjälä authored
Prefer sizeof(*variable) to sizeof(type) to make it a bit harder to screw things up. Signed-off-by:
-
Ville Syrjälä authored
The dvo 'dev_priv' is void* so no need for an explicit cast. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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ä authored
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ä authored
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ä authored
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ä authored
The VBT code is all about displays, so switch to UT_KMS debugs from UT_DRIVER. Signed-off-by:
-
Ville Syrjälä authored
Switch to drm_dbg_kms() in the fb code so we see which device generated the debugs. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
Realign a bunch of code that has become messy. Signed-off-by:
-
Ville Syrjälä authored
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ä authored
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ä authored
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:
-
- 08 Feb, 2024 2 commits
-
-
Manasi Navare authored
Commit bd077259 ("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: bd077259 ("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:
-
Juha-Pekka Heikkila authored
With Xe2 always treat tile4 as if it was using flat ccs. Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Reviewed-by:
-
- 07 Feb, 2024 8 commits
-
-
Jouni Högander authored
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:
Arun R Murthy <arun.r.murthy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240130111130.3298779-5-jouni.hogander@intel.com
-
Jouni Högander authored
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 authored
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 authored
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:
-
Ville Syrjälä authored
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ä authored
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:
Lucas De Marchi <lucas.demarchi@intel.com>
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
