#
e22103b9 |
| 17-Jun-2024 |
Andi Shyti <andi.shyti@linux.intel.com> |
drm/i915/gem: Use the correct format specifier for resource_size_t
Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup warning") adds a debug message where the "lmem_size" and "dsm_base"
drm/i915/gem: Use the correct format specifier for resource_size_t
Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup warning") adds a debug message where the "lmem_size" and "dsm_base" variables are printed using the %lli identifier.
However, these variables are defined as resource_size_t, which are unsigned long for 32-bit machines and unsigned long long for 64-bit machines.
The documentation (core-api/printk-formats.rst) recommends using the %pa specifier for printing addresses and sizes of resources.
Replace %lli with %pa.
This patch also mutes the following sparse warning when compiling with:
make W=1 ARCH=i386 drivers/gpu/drm/i915
>> drivers/gpu/drm/i915/gem/i915_gem_stolen.c:941:5: error: format '%lli' expects argument of type 'long long int', but argument 5 has type 'resource_size_t' {aka 'unsigned int'} [-Werror=format=]
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240617184243.330231-3-andi.shyti@linux.intel.com
show more ...
|
#
3bece98b |
| 17-Jun-2024 |
Andi Shyti <andi.shyti@linux.intel.com> |
drm/i915/gem: Return NULL instead of '0'
Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup warning") returns '0' from i915_gem_stolen_lmem_setup(), but it's supposed to return a pointe
drm/i915/gem: Return NULL instead of '0'
Commit 05da7d9f717b ("drm/i915/gem: Downgrade stolen lmem setup warning") returns '0' from i915_gem_stolen_lmem_setup(), but it's supposed to return a pointer to the intel_memory_region structure.
Sparse complains with the following message:
>> drivers/gpu/drm/i915/gem/i915_gem_stolen.c:943:32: sparse: sparse: Using plain integer as NULL pointer
Return NULL.
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240617184243.330231-2-andi.shyti@linux.intel.com
show more ...
|
#
05da7d9f |
| 22-Apr-2024 |
Jonathan Cavitt <jonathan.cavitt@intel.com> |
drm/i915/gem: Downgrade stolen lmem setup warning
In the case where lmem_size < dsm_base, hardware is reporting that stolen lmem is unusable. In this case, instead of throwing a warning, we can con
drm/i915/gem: Downgrade stolen lmem setup warning
In the case where lmem_size < dsm_base, hardware is reporting that stolen lmem is unusable. In this case, instead of throwing a warning, we can continue execution as normal by disabling stolen LMEM support. For example, this change will allow the following error report from ATS-M to no longer apply:
<6> [144.859887] pcieport 0000:4b:00.0: bridge window [mem 0xb1000000-0xb11fffff] <6> [144.859900] pcieport 0000:4b:00.0: bridge window [mem 0x3bbc00000000-0x3bbc17ffffff 64bit pref] <6> [144.859917] pcieport 0000:4c:01.0: PCI bridge to [bus 4d-4e] <6> [144.859932] pcieport 0000:4c:01.0: bridge window [mem 0xb1000000-0xb11fffff] <6> [144.859945] pcieport 0000:4c:01.0: bridge window [mem 0x3bbc00000000-0x3bbc17ffffff 64bit pref] <6> [144.859984] i915 0000:4d:00.0: [drm] BAR2 resized to 256M <6> [144.860640] i915 0000:4d:00.0: [drm] Using a reduced BAR size of 256MiB. Consider enabling 'Resizable BAR' or similar, if available in the BIOS. <4> [144.860719] -----------[ cut here ]----------- <4> [144.860727] WARNING: CPU: 17 PID: 1815 at drivers/gpu/drm/i915/gem/i915_gem_stolen.c:939 i915_gem_stolen_lmem_setup+0x38c/0x430 [i915] <4> [144.861430] Modules linked in: i915 snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core snd_pcm vgem drm_shmem_helper prime_numbers i2c_algo_bit ttm video drm_display_helper drm_buddy fuse x86_pkg_temp_thermal coretemp kvm_intel kvm ixgbe mdio irqbypass ptp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pps_core i2c_i801 mei_me i2c_smbus mei wmi acpi_power_meter [last unloaded: i915] <4> [144.861611] CPU: 17 PID: 1815 Comm: i915_module_loa Tainted: G U 6.8.0-rc5-drmtip_1515-g78f49af27723+ #1 <4> [144.861624] Hardware name: Intel Corporation WHITLEY/WHITLEY, BIOS SE5C6200.86B.0020.P41.2109300305 09/30/2021 <4> [144.861632] RIP: 0010:i915_gem_stolen_lmem_setup+0x38c/0x430 [i915] <4> [144.862287] Code: ff 41 c1 e4 05 e9 ac fe ff ff 4d 63 e4 48 89 ef 48 85 ed 74 04 48 8b 7d 08 48 c7 c6 10 a3 7b a0 e8 e9 90 43 e1 e9 ee fd ff ff <0f> 0b 49 c7 c4 ed ff ff ff e9 e0 fd ff ff 0f b7 d2 48 c7 c6 00 d9 <4> [144.862299] RSP: 0018:ffffc90005607980 EFLAGS: 00010207 <4> [144.862315] RAX: fffffffffff00000 RBX: 0000000000000003 RCX: 0000000000000000
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10833 Suggested-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240422135959.4127003-1-jonathan.cavitt@intel.com
show more ...
|
#
03c7918d |
| 30-May-2024 |
Jani Nikula <jani.nikula@intel.com> |
drm: move i915_drm.h under include/drm/intel
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory.
v2: Also fix comment in intel_pci_con
drm: move i915_drm.h under include/drm/intel
Clean up the top level include/drm directory by grouping all the Intel specific files under a common subdirectory.
v2: Also fix comment in intel_pci_config.h (Ilpo)
Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Dave Airlie <airlied@gmail.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0e344a72e9be596ac2b8b55a26fd674a96f03cdc.1717075103.git.jani.nikula@intel.com
show more ...
|
#
f8ae1d52 |
| 02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Rename the DSM/GSM registers
0x108100 and 0x1080c0 have been around since snb. Rename the defines appropriately.
v2: Rebase
Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Acked-by:
drm/i915: Rename the DSM/GSM registers
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
show more ...
|
#
c08c3641 |
| 02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access
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 j
drm/i915: Bypass LMEMBAR/GTTMMADR for MTL stolen memory access
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
show more ...
|
#
8f7cf0a2 |
| 02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Remove ad-hoc lmem/stolen debugs
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.
R
drm/i915: Remove ad-hoc lmem/stolen debugs
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
show more ...
|
#
3c0fa9f4 |
| 02-Feb-2024 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: Use struct resource for memory region IO as well
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
drm/i915: Use struct resource for memory region IO as well
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
show more ...
|
#
43dea469 |
| 27-Oct-2023 |
Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> |
drm/i915/mtl: Add Wa_14019821291
This workaround is primarily implemented by the BIOS. However if the BIOS applies the workaround it will reserve a small piece of our DSM (which should be at the to
drm/i915/mtl: Add Wa_14019821291
This workaround is primarily implemented by the BIOS. However if the BIOS applies the workaround it will reserve a small piece of our DSM (which should be at the top, right below the WOPCM); we just need to keep that region reserved so that nothing else attempts to re-use it.
v2: Declare regs in intel_gt_regs.h (Matt Roper)
v3: Shift WA implementation before calculation of *base (Matt Roper)
v4: - Change condition gscpmi base to be fall in DSM range.(Matt Roper)
Signed-off-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@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/20231027195052.3676632-1-dnyaneshwar.bhadane@intel.com
show more ...
|
#
1d47074c |
| 14-Jun-2023 |
Jouni Högander <jouni.hogander@intel.com> |
drm/i915: Move stolen memory handling into i915_gem_stolen
We are preparing for Xe. Xe stolen memory handling differs from i915 so we want to move stolen memory handling details into i915_gem_stolen
drm/i915: Move stolen memory handling into i915_gem_stolen
We are preparing for Xe. Xe stolen memory handling differs from i915 so we want to move stolen memory handling details into i915_gem_stolen.
Also add a common type for fbc compressed fb and use it from fbc code instead of underlying type directly. This way we can have common type i915_stolen_fb for both i915 and Xe.
v2: Fix couple of checkpatch warnings
Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230614051731.745821-2-jouni.hogander@intel.com
show more ...
|
#
306f7a5b |
| 25-Jul-2023 |
Andi Shyti <andi.shyti@linux.intel.com> |
drm/i915: Replace i915->gt0 with to_gt(i915)
Quite surprised to see that around i915 there are still i915->gt0 references. Replace them with the to_gt() helper.
Signed-off-by: Andi Shyti <andi.shyt
drm/i915: Replace i915->gt0 with to_gt(i915)
Quite surprised to see that around i915 there are still i915->gt0 references. Replace them with the to_gt() helper.
Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230725103330.1041394-1-andi.shyti@linux.intel.com
show more ...
|
#
9275277d |
| 09-May-2023 |
Fei Yang <fei.yang@intel.com> |
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for buffer objects. This is flaky because the PAT index which really controls th
drm/i915: use pat_index instead of cache_level
Currently the KMD is using enum i915_cache_level to set caching policy for buffer objects. This is flaky because the PAT index which really controls the caching behavior in PTE has far more levels than what's defined in the enum. In addition, the PAT index is platform dependent, having to translate between i915_cache_level and PAT index is not reliable, and makes the code more complicated.
From UMD's perspective there is also a necessity to set caching policy for performance fine tuning. It's much easier for the UMD to directly use PAT index because the behavior of each PAT index is clearly defined in Bspec. Having the abstracted i915_cache_level sitting in between would only cause more ambiguity. PAT is expected to work much like MOCS already works today, and by design userspace is expected to select the index that exactly matches the desired behavior described in the hardware specification.
For these reasons this patch replaces i915_cache_level with PAT index. Also note, the cache_level is not completely removed yet, because the KMD still has the need of creating buffer objects with simple cache settings such as cached, uncached, or writethrough. For kernel objects, cache_level is used for simplicity and backward compatibility. For Pre-gen12 platforms PAT can have 1:1 mapping to i915_cache_level, so these two are interchangeable. see the use of LEGACY_CACHELEVEL.
One consequence of this change is that gen8_pte_encode is no longer working for gen12 platforms due to the fact that gen12 platforms has different PAT definitions. In the meantime the mtl_pte_encode introduced specfically for MTL becomes generic for all gen12 platforms. This patch renames the MTL PTE encode function into gen12_pte_encode and apply it to all gen12. Even though this change looks unrelated, but separating them would temporarily break gen12 PTE encoding, thus squash them in one patch.
Special note: this patch changes the way caching behavior is controlled in the sense that some objects are left to be managed by userspace. For such objects we need to be careful not to change the userspace settings.There are kerneldoc and comments added around obj->cache_coherent, cache_dirty, and how to bypass the checkings by i915_gem_object_has_cache_level. For full understanding, these changes need to be looked at together with the two follow-up patches, one disables the {set|get}_caching ioctl's and the other adds set_pat extension to the GEM_CREATE uAPI.
Bspec: 63019
Cc: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Fei Yang <fei.yang@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230509165200.1740-3-fei.yang@intel.com
show more ...
|
#
b90b044c |
| 04-Apr-2023 |
Nirmoy Das <nirmoy.das@intel.com> |
drm/i915/mtl: Disable stolen memory backed FB for A0
Stolen memory is not usable for MTL A0 stepping beyond certain access size and we have no control over userspace access size of /dev/fb which can
drm/i915/mtl: Disable stolen memory backed FB for A0
Stolen memory is not usable for MTL A0 stepping beyond certain access size and we have no control over userspace access size of /dev/fb which can be backed by stolen memory. So disable stolen memory backed fb by setting i915->dsm.usable_size to zero.
v2: remove hsdes reference and fix commit message(Andi) v3: use revid as we want to target SOC stepping(Radhakrishna)
Cc: Matthew Auld <matthew.auld@intel.com> Cc: Andi Shyti <andi.shyti@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230404181342.23362-1-nirmoy.das@intel.com
show more ...
|
#
8d8d062b |
| 28-Mar-2023 |
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> |
drm/i915/mtl: Fix MTL stolen memory GGTT mapping
The PTEs expect the offset from the base of the fake LMEM region (i.e. the base of stolen) and not from the base of the DSM. Quoting the specs: "Driv
drm/i915/mtl: Fix MTL stolen memory GGTT mapping
The PTEs expect the offset from the base of the fake LMEM region (i.e. the base of stolen) and not from the base of the DSM. Quoting the specs: "Driver will set the Device Memory bit = 1 in the PTE when pointing to a page in DSM and program the PTE with offset from LMEM_BAR. Device Memory Offset from LMEM_BAR is same as offset from BGSM."
DSM starts 8MBs from BGSM, so we set dsm_base = 8MB.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Cc: Fei Yang <fei.yang@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230328012430.2524330-1-daniele.ceraolospurio@intel.com
show more ...
|
#
01f0411f |
| 02-Feb-2023 |
Nirmoy Das <nirmoy.das@intel.com> |
drm/i915: Make sure dsm_size has correct granularity
DSM granularity is 1MB so make sure we stick to that.
The address set by firmware in GEN12_DSMBASE in driver initialization doesn't mean "anythi
drm/i915: Make sure dsm_size has correct granularity
DSM granularity is 1MB so make sure we stick to that.
The address set by firmware in GEN12_DSMBASE in driver initialization doesn't mean "anything above that and until end of lmem is part of DSM". In fact, there may be a few KB that is not part of DSM on the end of lmem. How large is that space is platform-dependent, but since it's always less than the DSM granularity, it can be simplified by simply aligning the size down.
v2: replace "1 * SZ_1M" with SZ_1M (Andrzej). v3: reword commit message to explain why the round down is needed (Lucas)
Cc: Matthew Auld <matthew.auld@intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230202180243.23637-1-nirmoy.das@intel.com
show more ...
|
#
e5405178 |
| 16-Jan-2023 |
Jani Nikula <jani.nikula@intel.com> |
drm/i915: drop cast from DEFINE_RES_MEM() usage
Since commit 52c4d11f1dce ("resource: Convert DEFINE_RES_NAMED() to be compound literal") it's no longer necessary to cast DEFINE_RES_MEM() to struct
drm/i915: drop cast from DEFINE_RES_MEM() usage
Since commit 52c4d11f1dce ("resource: Convert DEFINE_RES_NAMED() to be compound literal") it's no longer necessary to cast DEFINE_RES_MEM() to struct resource.
This also fixes sparse warnings "cast from non-scalar" and "cast to non-scalar".
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-2-jani.nikula@intel.com
show more ...
|
#
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_
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
show more ...
|
#
8c949515 |
| 08-Nov-2022 |
Matthew Auld <matthew.auld@intel.com> |
drm/i915: use i915_sg_dma_sizes() for all backends
We rely on page_sizes.sg in setup_scratch_page() reporting the correct value if the underlying sgl is not contiguous, however in get_pages_internal
drm/i915: use i915_sg_dma_sizes() for all backends
We rely on page_sizes.sg in setup_scratch_page() reporting the correct value if the underlying sgl is not contiguous, however in get_pages_internal() we are only looking at the layout of the created pages when calculating the sg_page_sizes, and not the final sgl, which could in theory be completely different. In such a situation we might incorrectly think we have a 64K scratch page, when it is actually only 4K or similar split over multiple non-contiguous entries, which could lead to broken behaviour when touching the scratch space within the padding of a 64K GTT page-table. For most of the other backends we already just call i915_sg_dma_sizes() on the final mapping, so rather just move that into __i915_gem_object_set_pages() to avoid such issues coming back to bite us later.
v2: Update missing conversion in gvt
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221108103238.165447-1-matthew.auld@intel.com
show more ...
|
#
03eababb |
| 05-Oct-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/i915: s/HAS_BAR2_SMEM_STOLEN/HAS_LMEMBAR_SMEM_STOLEN/
The fact that LMEMBAR is BAR2 should be of no real interest to anyone. So use the name of the BAR rather than its index.
Signed-off-by: Vil
drm/i915: s/HAS_BAR2_SMEM_STOLEN/HAS_LMEMBAR_SMEM_STOLEN/
The fact that LMEMBAR is BAR2 should be of no real interest to anyone. So use the name of the BAR rather than its index.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221005154159.18750-3-ville.syrjala@linux.intel.com Acked-by: Matthew Auld <matthew.auld@intel.com>
show more ...
|
#
0da9493e |
| 05-Oct-2022 |
Matthew Auld <matthew.auld@intel.com> |
drm/i915: restore stolen memory behaviour for DG2
Restore the previous behaviour here where we compare the pci_resource_len() with the actual lmem_size, and not the dsm size, since dsm here is just
drm/i915: restore stolen memory behaviour for DG2
Restore the previous behaviour here where we compare the pci_resource_len() with the actual lmem_size, and not the dsm size, since dsm here is just some subset snipped off the end of the lmem. Otherwise we will incorrectly report an io_size > 0 on small-bar systems.
It doesn't looks like MTL is expecting small-bar with its stolen memory, based on:
GEM_BUG_ON(pci_resource_len(pdev, GEN12_LMEM_BAR) != SZ_256M) GEM_BUG_ON((dsm_size + SZ_8M) > lmem_size)
So just move the HAS_BAR2_SMEM_STOLEN() check first, which then ignores the small bar part, and we can go back to checking lmem_size against the BAR size.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7007 Fixes: dbb2ffbfd708 ("drm/i915/mtl: enable local stolen memory") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221005153148.758822-2-matthew.auld@intel.com
show more ...
|
#
49d1310a |
| 05-Oct-2022 |
Matthew Auld <matthew.auld@intel.com> |
drm/i915: add back GEN12_BDSM_MASK
The mask was added in commit e5f415bfc5c2 ("drm/i915: Add missing mask when reading GEN12_DSMBASE"), but then looks to be dropped in some unrelated code movement i
drm/i915: add back GEN12_BDSM_MASK
The mask was added in commit e5f415bfc5c2 ("drm/i915: Add missing mask when reading GEN12_DSMBASE"), but then looks to be dropped in some unrelated code movement in commit dbb2ffbfd708 ("drm/i915/mtl: enable local stolen memory") without explanation. Add it back.
Fixes: dbb2ffbfd708 ("drm/i915/mtl: enable local stolen memory") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221005153148.758822-1-matthew.auld@intel.com
show more ...
|
#
dbb2ffbf |
| 29-Sep-2022 |
Aravind Iddamsetty <aravind.iddamsetty@intel.com> |
drm/i915/mtl: enable local stolen memory
As an integrated GPU, MTL does not have local memory and HAS_LMEM() returns false. However the platform's stolen memory is presented via BAR2 (i.e., the BAR
drm/i915/mtl: enable local stolen memory
As an integrated GPU, MTL does not have local memory and HAS_LMEM() returns false. However the platform's stolen memory is presented via BAR2 (i.e., the BAR we traditionally consider to be the GMADR on IGFX) and should be managed by the driver the same way that local memory is on dgpu platforms (which includes setting the "lmem" bit on page table entries). We use the term "local stolen memory" to refer to this model.
The major difference from the traditional BAR2 (GMADR) is that the stolen area is mapped via the BAR2 while in the former BAR2 is an aperture into the GTT VA through which access are made into stolen area.
BSPEC: 53098, 63830
v2: 1. dropped is_dsm_invalid, updated valid_stolen_size check from Lucas (Jani, Lucas) 2. drop lmembar_is_igpu_stolen 3. revert to referring GFXMEM_BAR as GEN12_LMEM_BAR (Lucas)
v3:(Jani) 1. rename get_mtl_gms_size to mtl_get_gms_size 2. define register for MMIO address
v4:(Matt) 1. Use REG_FIELD_GET to read GMS value 2. replace the calculations with SZ_256M/SZ_8M
v5: Include more details to commit message on how it is different from earlier platforms (Anshuman)
Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: CQ Tang <cq.tang@intel.com> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Original-author: CQ Tang 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/20220929114658.145287-1-aravind.iddamsetty@intel.com
show more ...
|
#
c40bd3b1 |
| 16-Sep-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915/dgfx: Make failure to setup stolen non-fatal
There is no reason to consider the setup of Data Stolen Memory fatal on dgfx and non-fatal on integrated. Move the debug and error propagation a
drm/i915/dgfx: Make failure to setup stolen non-fatal
There is no reason to consider the setup of Data Stolen Memory fatal on dgfx and non-fatal on integrated. Move the debug and error propagation around so both have the same behavior: non-fatal. Before this change, loading i915 on a system with TGL + DG2 would result in just TGL succeeding the initialization (without stolen).
Now loading i915 on the same system with an injected failure in i915_gem_init_stolen():
$ dmesg | grep stolen i915 0000:00:02.0: [drm] Injected failure, disabling use of stolen memory i915 0000:00:02.0: [drm:init_stolen_smem [i915]] Skip stolen region: failed to setup i915 0000:03:00.0: [drm] Injected failure, disabling use of stolen memory i915 0000:03:00.0: [drm:init_stolen_lmem [i915]] Skip stolen region: failed to setup
Both GPUs are still available:
$ sudo build/tools/lsgpu card1 Intel Dg2 (Gen12) drm:/dev/dri/card1 └─renderD129 drm:/dev/dri/renderD129 card0 Intel Tigerlake (Gen12) drm:/dev/dri/card0 └─renderD128 drm:/dev/dri/renderD128
Reviewed-by: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220915-stolen-v2-3-20ff797de047@intel.com
show more ...
|
#
3d99597c |
| 16-Sep-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: Split i915_gem_init_stolen()
Add some helpers: adjust_stolen(), request_smem_stolen_() and init_reserved_stolen() that are now called by i915_gem_init_stolen() to initialize each part of t
drm/i915: Split i915_gem_init_stolen()
Add some helpers: adjust_stolen(), request_smem_stolen_() and init_reserved_stolen() that are now called by i915_gem_init_stolen() to initialize each part of the Data Stolen Memory region.
Main goal is to split the reserved part within the stolen, also known as WOPCM, as its calculation changes often per platform and is a big source of confusion when handling stolen memory.
Reviewed-by: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220915-stolen-v2-2-20ff797de047@intel.com
show more ...
|
#
e5f415bf |
| 16-Sep-2022 |
Lucas De Marchi <lucas.demarchi@intel.com> |
drm/i915: Add missing mask when reading GEN12_DSMBASE
DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20 of the base address of stolen. For the supported platforms bits 0-19 are
drm/i915: Add missing mask when reading GEN12_DSMBASE
DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20 of the base address of stolen. For the supported platforms bits 0-19 are zero but that may not be true in future. Add the missing mask.
v2: Use REG_GENMASK64()
Acked-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Reviewed-by: Caz Yokoyama <caz@caztech.com> Reviewed-by: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220915-stolen-v2-1-20ff797de047@intel.com
show more ...
|