- 13 Feb, 2024 2 commits
-
-
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:
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
-
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:
Jani Nikula <jani.nikula@intel.com> Signed-off-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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240208151720.7866-14-ville.syrjala@linux.intel.comReviewed-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:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
- 07 Feb, 2024 9 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:
-
Ville Syrjälä authored
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:
-
- 06 Feb, 2024 11 commits
-
-
Ville Syrjälä authored
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: -
Ville Syrjälä authored
The address we read from the PTE is a dma address, not a physical address. Rename the variable to say so. Reviewed-by:
-
Ville Syrjälä authored
MTL stolen memory looks more like local memory, so use the (now fixed) lmem path when doing the initial plane readout. Reviewed-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
Nirmoy Das <nirmoy.das@intel.com> Tested-by:
-
Ville Syrjälä authored
0x108100 and 0x1080c0 have been around since snb. Rename the defines appropriately. v2: Rebase Reviewed-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
- 05 Feb, 2024 2 commits
-
-
Ville Syrjälä authored
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ä authored
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:
-
