#
074146f4 |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Annotate more of the BIOS fb takeover failure paths 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
|
#
a8153627 |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Try to relocate the BIOS fb to the start of ggtt 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>
|
#
ea5e150a |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Tweak BIOS fb reuse check 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>
|
#
30865e4a |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Simplify intel_initial_plane_config() calling convention 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>
|
#
6bfdb06d |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Split the smem and lmem plane readout apart 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
|
#
27fbcaf7 |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/phys_base/dma_addr/ 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
|
#
f46fb694 |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix MTL initial plane readout 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
|
#
d74f3a93 |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix region start during initial plane readout 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
|
#
6b757e1d |
|
02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Fix PTE decode during initial plane readout 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
|
#
eebc1525 |
|
12-Oct-2023 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915/display: Clean up zero initializers 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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231012122442.15718-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
#
c1464a89 |
|
30-Aug-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: add minimal i915_gem_object_frontbuffer.h Split out frontbuffer related declarations and static inlines from gem/i915_gem_object.h into new gem/i915_gem_object_frontbuffer.h. The main goal is to reduce header interdependencies. With gem/i915_gem_object.h including display/intel_frontbuffer.h, modification of the latter causes a whopping 300+ objects to be rebuilt, while many of the source files actually needing it aren't explicitly including it at all. After the change, only 21 objects depend on display/intel_frontbuffer.h, directly or indirectly. Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230830085127.2416842-1-jani.nikula@intel.com
|
#
ddb78a51 |
|
04-Apr-2023 |
Nirmoy Das <nirmoy.das@intel.com> |
drm/i915/display: Set I915_BO_ALLOC_USER for fb Framebuffer is exposed to userspace so make sure we set proper flags for it. Set I915_BO_PREALLOC for prealloced fb so that ttm won't clear existing data. Cc: Matthew Auld <matthew.auld@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404143100.10452-2-nirmoy.das@intel.com
|
#
1eca0778 |
|
16-Jan-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: add struct i915_dsm to wrap dsm members together Wrap the stolen memory related struct drm_i915_private members (dsm, dsm_reserved, and stolen_usable_size) together in a a new struct i915_dsm. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230116173422.1858527-1-jani.nikula@intel.com
|
#
3b10f851 |
|
24-Aug-2022 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: add display sub-struct to drm_i915_private In another long-overdue cleanup, add a display sub-struct to drm_i915_private, and start moving display related members there. Start with display funcs that need a rename anyway to not collide with the new display member. Add a new header under display/ for defining struct intel_display. Rename struct drm_i915_display_funcs to intel_display_funcs while at it. v2: - Fix multi-line comment style (Arun) - Use display as the member name Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d44cae096b664f7015f8c797d6dfd4964226d4f8.1661346845.git.jani.nikula@intel.com
|
#
fa732088 |
|
18-Mar-2022 |
Andi Shyti <andi.shyti@linux.intel.com> |
drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0 With the upcoming multitile support each tile will have its own local memory. Mark the current LMEM with the suffix '0' to emphasise that it belongs to the root tile. Suggested-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220318233938.149744-2-andi.shyti@linux.intel.com
|
#
7fe7c2a6 |
|
15-Mar-2022 |
Matthew Auld <matthew.auld@intel.com> |
drm/i915: fixup the initial fb base on DGFX On integrated it looks like the GGTT base should always 1:1 maps to somewhere within DSM. On discrete the base seems to be pre-programmed with a normal lmem address, and is not 1:1 mapped with the base address. On such devices probe the lmem address directly from the PTE. v2(Ville): - The base is actually the pre-programmed GGTT address, which is then meant to 1:1 map to somewhere inside dsm. In the case of dgpu the base looks to just be some offset within lmem, but this also happens to be the exact dsm start, on dg1. Therefore we should only need to fudge the physical address, before allocating from stolen. - Bail if it's not located in dsm. v3: - Scratch that. There doesn't seem to be any relationship with the base and PTE address, on at least DG1. Let's instead just grab the lmem address from the PTE itself. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315181425.576828-7-matthew.auld@intel.com
|
#
51dc0e1a |
|
15-Mar-2022 |
CQ Tang <cq.tang@intel.com> |
drm/i915/display: Check mappable aperture when pinning preallocated vma When system does not have mappable aperture, ggtt->mappable_end=0. In this case if we pass PIN_MAPPABLE when pinning vma, the pinning code will return -ENOSPC. So conditionally set PIN_MAPPABLE if HAS_GMCH(). Suggested-by: Chris P Wilson <chris.p.wilson@intel.com> Signed-off-by: CQ Tang <cq.tang@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Ap Kamal <kamal.ap@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315181425.576828-6-matthew.auld@intel.com
|
#
9b78b5da |
|
15-Mar-2022 |
Matthew Auld <matthew.auld@intel.com> |
drm/i915: add i915_gem_object_create_region_at() Add a generic interface for allocating an object at some specific offset, and convert stolen over. Later we will want to hook this up to different backends. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315181425.576828-4-matthew.auld@intel.com
|
#
072ce416 |
|
18-Jan-2022 |
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> |
drm/i915/dg2: Tile 4 plane format support Tile4 in bspec format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY which will be supported by Display13. v2: - Moved Tile4 associating struct for modifier/display to the beginning(Imre Deak) - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier checks(Imre Deak) - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12 (Imre Deak) v3: - Rebased patch on top of new changes related to plane_caps. - Added static assert to check that PLANE_CTL_TILING_YF matches PLANE_CTL_TILING_4(Nanley Chery) - Fixed naming and layout description for Tile 4 in drm uapi header(Nanley Chery) v4: - Extracted drm_fourcc changes to separate patch(Nanley Chery) Reviewed-by: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220118115544.15116-3-stanislav.lisovskiy@intel.com
|
#
a6e7a006 |
|
03-Feb-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Change bigjoiner state tracking to use the pipe bitmask Get rid of the inflexible bigjoiner_linked_crtc pointer thing and just track things as a bitmask of pipes instead. We can also nuke the bigjoiner_slave boolean as the role of the pipe can be determined from its position in the bitmask. It might be possible to nuke the bigjoiner boolean as well if we make encoder.compute_config() do the bitmask assignment directly for the master pipe. But for now I left that alone so that encoer.compute_config() will just flag the state as needing bigjoiner, and the intel_atomic_check_bigjoiner() is still responsible for determining the bitmask. But that may have to change as the encoder may be in the best position to determine how exactly we should populate the bitmask. Most places that just looked at the single bigjoiner_linked_crtc now iterate over the whole bitmask, eliminating the singular slave pipe assumption. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220203183823.22890-11-ville.syrjala@linux.intel.com Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
|
#
165bbfba |
|
28-Jan-2022 |
Ramalingam C <ramalingam.c@intel.com> |
drm/i915: align the plane_vma to min_page_size of stolen mem Align the plane vma size to the stolem memory regions' min_page_size. Signed-off-by: Ramalingam C <ramalingam.c@intel.com> cc: Matthew Auld <matthew.auld@intel.com> cc: Chris P Wilson <chris.p.wilson@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220128185209.18077-3-ramalingam.c@intel.com
|
#
59dc4632 |
|
19-Dec-2021 |
Michał Winiarski <michal.winiarski@intel.com> |
drm/i915/display: Use to_gt() helper for GGTT accesses GGTT is currently available both through i915->ggtt and gt->ggtt, and we eventually want to get rid of the i915->ggtt one. Use to_gt() for all i915->ggtt accesses to help with the future refactoring. Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211219212500.61432-5-andi.shyti@linux.intel.com
|
#
15162c5a |
|
01-Dec-2021 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915/display: stop including i915_drv.h from intel_display_types.h Break the dependency on i915_drv.h. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ee740f494e416d875e057c2eda585f4e66d65500.1638366969.git.jani.nikula@intel.com
|
#
86c82c8a |
|
24-Nov-2021 |
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> |
Revert "drm/i915/dg2: Tile 4 plane format support" Tile4 patch still needs an ack from userspace, IGT tests and some essential fixes, related to new .plane_caps attribute being added. This reverts commit 3c542cfa8266e3364938d055b3d548b7bed7f08e. Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124092355.16668-1-stanislav.lisovskiy@intel.com
|
#
3c542cfa |
|
22-Nov-2021 |
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> |
drm/i915/dg2: Tile 4 plane format support TileF(Tile4 in bspec) format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY which will be supported by Display13. v2: - Fixed wrong case condition(Jani Nikula) - Increased I915_FORMAT_MOD_F_TILED up to 12(Imre Deak) v3: - s/I915_TILING_F/TILING_4/g - s/I915_FORMAT_MOD_F_TILED/I915_FORMAT_MOD_4_TILED/g - Removed unneeded fencing code v4: - Rebased, fixed merge conflict with new table-oriented format modifier checking(Stan) - Replaced the rest of "Tile F" mentions to "Tile 4"(Stan) v5: - Still had to remove some Tile F mentionings - Moved has_4tile from adlp to DG2(Ramalingam C) - Check specifically for DG2, but not the Display13(Imre) v6: - Moved Tile4 associating struct for modifier/display to the beginning(Imre Deak) - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier checks(Imre Deak) - Fixed I915_FORMAT_MOD_4_TILED to be 9 instead of 12 (Imre Deak) v7: - Fixed display_ver to { 13, 13 }(Imre Deak) - Removed redundant newline(Imre Deak) Reviewed-by: Imre Deak <imre.deak@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211122211420.31584-1-stanislav.lisovskiy@intel.com
|
#
1cd967c6 |
|
11-Oct-2021 |
Dave Airlie <airlied@redhat.com> |
drm/i915/display: refactor initial plane config to a separate file This moves this functionality out of intel_display.c to separate self-contained file. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211012043502.1377715-5-airlied@gmail.com
|