aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2022-03-21drm/i915: Fix renamed struct fieldLucas De Marchi1-1/+1
Earlier versions of commit a5b7ef27da60 ("drm/i915: Add struct to hold IP version") named "ver" as "arch" and then when it was renamed it missed the rename on MEDIA_VER_FULL() since it it's currently not used. Fixes: a5b7ef27da60 ("drm/i915: Add struct to hold IP version") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220316234538.434357-1-lucas.demarchi@intel.com (cherry picked from commit b4ac33b973233dc08a56c8ef9d3c2edeab7a4370) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2022-03-21drm/i915: Fix PSF GV point mask when SAGV is not possibleVille Syrjälä1-1/+2
Don't just mask off all the PSF GV points when SAGV gets disabled. This should in fact cause the Pcode to reject the request since at least one PSF point must remain enabled at all times. Cc: stable@vger.kernel.org Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 192fbfb76744 ("drm/i915: Implement PSF GV point support") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-7-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit 0fed4ddd18f064d2359b430c6e83ee60dd1f49b1) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2022-03-21drm/i915: Treat SAGV block time 0 as SAGV disabledVille Syrjälä1-4/+6
For modern platforms the spec explicitly states that a SAGV block time of zero means that SAGV is not supported. Let's extend that to all platforms. Supposedly there should be no systems where this isn't true, and it'll allow us to: - use the same code regardless of older vs. newer platform - wm latencies already treat 0 as disabled, so this fits well with other related code - make it a bit more clear when SAGV is used vs. not - avoid overflows from adding U32_MAX with a u16 wm0 latency value which could cause us to miscalculate the SAGV watermarks on tgl+ Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit d8f5855b31c0523ea3b171db8dfb998830e8735d) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2022-03-21drm/i915: Reject unsupported TMDS rates on ICL+Ville Syrjälä1-0/+9
ICL+ PLLs can't genenerate certain frequencies. Running the PLL algorithms through for all frequencies 25-594MHz we see a gap just above 500 MHz. Specifically 500-522.8MHZ for TC PLLs, and 500-533.2 MHz for combo PHY PLLs. Reject those frequencies hdmi_port_clock_valid() so that we properly filter out unsupported modes and/or color depths for HDMI. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5247 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220311212845.32358-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com> (cherry picked from commit e5086cb3f3d3f94091be29eec38cf13f8a75a778) Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2022-03-21drm/selftest: plane_helper: Put test structures in static storageNathan Chancellor1-4/+4
Clang warns on certain 32-bit architectures: drivers/gpu/drm/selftests/test-drm_plane_helper.c:76:5: warning: stack frame size (1064) exceeds limit (1024) in 'igt_check_plane_state' [-Wframe-larger-than] int igt_check_plane_state(void *ignored) ^ 1 warning generated. The structures in igt_check_plane_state() total 1008 bytes, so any small amount of inlining will cause the stack frame to exceed the 32-bit limit of 1024, triggering the warning. Move these structures to static storage, which dramatically reduces the amount of stack space in igt_check_plane_state(). There is no testing impact, as igt_check_plane_state() is only called once in the driver. Fixes: 943e6a8beeac ("mock a drm_plane in igt_check_plane_state to make the test more robust") Link: https://github.com/ClangBuiltLinux/linux/issues/1600 Reported-by: kernel test robot <lkp@intel.com> Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220302235909.784935-1-nathan@kernel.org
2022-03-21drm/ttm: Fix a kernel oops due to an invalid readZack Rusin1-1/+1
The res is initialized here only if there's no errors so passing it to ttm_resource_fini in the error paths results in a kernel oops. In the error paths, instead of the unitialized res, we have to use to use node->base on which ttm_resource_init was called. Sample affected backtrace: Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d8 Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000106ac0000 [00000000000000d8] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 96000004 [#1] SMP Modules linked in: bnep vsock_loopback vmw_vsock_virtio_transport_common vsock snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep > CPU: 0 PID: 1197 Comm: gnome-shell Tainted: G U 5.17.0-rc2-vmwgfx #2 Hardware name: VMware, Inc. VBSA/VBSA, BIOS VEFI 12/31/2020 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ttm_resource_fini+0x5c/0xac [ttm] lr : ttm_range_man_alloc+0x128/0x1e0 [ttm] sp : ffff80000d783510 x29: ffff80000d783510 x28: 0000000000000000 x27: ffff000086514400 x26: 0000000000000300 x25: ffff0000809f9e78 x24: 0000000000000000 x23: ffff80000d783680 x22: ffff000086514400 x21: 00000000ffffffe4 x20: ffff80000d7836a0 x19: ffff0000809f9e00 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000800 x12: ffff0000f2600a00 x11: 000000000000fc96 x10: 0000000000000000 x9 : ffff800001295c18 x8 : 0000000000000000 x7 : 0000000000000300 x6 : 0000000000000000 x5 : 0000000000000000 x4 : ffff0000f1034e20 x3 : ffff0000f1034600 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000600000 Call trace: ttm_resource_fini+0x5c/0xac [ttm] ttm_range_man_alloc+0x128/0x1e0 [ttm] ttm_resource_alloc+0x58/0x90 [ttm] ttm_bo_mem_space+0xc8/0x3e4 [ttm] ttm_bo_validate+0xb4/0x134 [ttm] vmw_bo_pin_in_start_of_vram+0xbc/0x200 [vmwgfx] vmw_framebuffer_pin+0xc0/0x154 [vmwgfx] vmw_ldu_primary_plane_atomic_update+0x8c/0x6e0 [vmwgfx] drm_atomic_helper_commit_planes+0x11c/0x2e0 drm_atomic_helper_commit_tail+0x60/0xb0 commit_tail+0x1b0/0x210 drm_atomic_helper_commit+0x168/0x400 drm_atomic_commit+0x64/0x74 drm_atomic_helper_set_config+0xdc/0x11c drm_mode_setcrtc+0x1c4/0x780 drm_ioctl_kernel+0xd0/0x1a0 drm_ioctl+0x2c4/0x690 vmw_generic_ioctl+0xe0/0x174 [vmwgfx] vmw_unlocked_ioctl+0x24/0x30 [vmwgfx] __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x54/0x184 do_el0_svc+0x34/0x9c el0_svc+0x48/0x1b0 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a4/0x1a8 Code: 35000260 f9401a81 52800002 f9403a60 (f9406c23) ---[ end trace 0000000000000000 ]--- Signed-off-by: Zack Rusin <zackr@vmware.com> Fixes: de3688e469b0 ("drm/ttm: add ttm_resource_fini v2") Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Martin Krastev <krastevm@vmware.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220318174332.440068-6-zack@kde.org
2022-03-21drm/i915/gt: Add sysfs throttle frequency interfacesSujaritha Sundaresan4-0/+107
Throttling here refers to the GT frequency being clipped. Each of the throttle reason attributes will have a 0 or 1 value depending upon whether there is throttling and also the specific reason for it. The following is a brief description of the sysfs throttle frequency attributes added: - throttle_reason_status: when set indicates that there is GT frequency clipping. - throttle_reason_pl1: when set indicates that PBM PL1 (platform or package PL1) has caused GT frequency clipping. - throttle_reason_pl2: when set indicates that PBM PL2 or PL3 (platform or package PL2 or PL3) has caused GT frequency clipping. - throttle_reason_pl4: when set indicates that PL4 or IccMax has caused GT frequency clipping. - throttle_reason_thermal: when set indicates that Thermal event has caused GT frequency clipping. - throttle_reason_prochot: when set indicates that PROCHOT# has caused GT frequency clipping. - throttle_reason_ratl: when set indicates that Running Average Thermal Limit has caused GT frequency clipping. - throttle_reason_vr_thermalert: when set indicates that Hot VR (any processor VR) has caused GT frequency clipping. - throttle_reason_vr_tdc: when set indicates that VR TDC (Thermal Design Current) has caused GT frequency clipping. Signed-off-by: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Dale B Stimson <dale.b.stimson@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-8-andi.shyti@linux.intel.com
2022-03-21drm/i915/gt: Create per-tile RPS sysfs interfacesAndi Shyti2-177/+283
Now tiles have their own sysfs interfaces under the gt/ directory. Because RPS is a property that can be configured on a tile basis, then each tile should have its own interface The new sysfs structure will have a similar layout for the 4 tile case: /sys/.../card0 ├── gt │   ├── gt0 │   │   ├── id │   │   ├── rc6_enable │   │   ├── rc6_residency_ms │   │   ├── rps_act_freq_mhz │   │   ├── rps_boost_freq_mhz │   │   ├── rps_cur_freq_mhz │   │   ├── rps_max_freq_mhz │   │   ├── rps_min_freq_mhz │   │   ├── rps_RP0_freq_mhz │   │   ├── rps_RP1_freq_mhz │   │  └── rps_RPn_freq_mhz . . . . . . │   └── gtN │   ├── id │   ├── rc6_enable │   ├── rc6_residency_ms │   ├── rps_act_freq_mhz │   ├── rps_boost_freq_mhz │   ├── rps_cur_freq_mhz │   ├── rps_max_freq_mhz │   ├── rps_min_freq_mhz │   ├── rps_RP0_freq_mhz │   ├── rps_RP1_freq_mhz │   └── rps_RPn_freq_mhz ├── gt_act_freq_mhz -+ ├── gt_boost_freq_mhz | ├── gt_cur_freq_mhz | Original interface ├── gt_max_freq_mhz +─-> kept as existing ABI; ├── gt_min_freq_mhz | it points to gt0/ ├── gt_RP0_freq_mhz | ├── gt_RP1_freq_mhz | └── gt_RPn_freq_mhz -+ The existing interfaces have been kept in their original location to preserve the existing ABI. They act on all the GTs: when writing they loop through all the GTs and write the information on each interface. When reading they provide the average value from all the GTs. This patch is not really adding exposing new interfaces (new ABI) other than adapting the existing one to more tiles. In any case this new set of interfaces will be a basic tool for system managers and administrators when using i915. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@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-7-andi.shyti@linux.intel.com
2022-03-21drm/i915/gt: Create per-tile RC6 sysfs interfaceAndi Shyti5-128/+279
Now tiles have their own sysfs interfaces under the gt/ directory. Because RC6 is a property that can be configured on a tile basis, then each tile should have its own interface The new sysfs structure will have a similar layout for the 4 tile case: /sys/.../card0 ├── gt │   ├── gt0 │   │   ├── id │   │   ├── rc6_enable │   │   ├── rc6_residency_ms . . . . . . . . │   └── gtN │   ├── id │   ├── rc6_enable │   ├── rc6_residency_ms │ . │ . │ └── power/ -+ ├── rc6_enable | Original interface ├── rc6_residency_ms +-> kept as existing ABI; . | it multiplexes over . | the GTs -+ The existing interfaces have been kept in their original location to preserve the existing ABI. They act on all the GTs: when reading they provide the average value from all the GTs. This patch is not really adding exposing new interfaces (new ABI) other than adapting the existing one to more tiles. In any case this new set of interfaces will be a basic tool for system managers and administrators when using i915. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@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-6-andi.shyti@linux.intel.com
2022-03-21drm/i915/gt: create per-tile sysfs interfaceAndi Shyti7-1/+151
Now that we have tiles we want each of them to have its own interface. A directory "gt/" is created under "cardN/" that will contain as many diroctories as the tiles. In the coming patches tile related interfaces will be added. For now the sysfs gt structure simply has an id interface related to the current tile count. The directory structure will follow this scheme: /sys/.../card0 └── gt    ├── gt0    │   └── id : : └─- gtN       └── id This new set of interfaces will be a basic tool for system managers and administrators when using i915. Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Sujaritha Sundaresan <sujaritha.sundaresan@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-5-andi.shyti@linux.intel.com
2022-03-21drm/i915: Prepare for multiple GTsTvrtko Ursulin10-46/+184
On a multi-tile platform, each tile has its own registers + GGTT space, and BAR 0 is extended to cover all of them. Up to four GTs are supported in i915->gt[], with slot zero shadowing the existing i915->gt0 to enable source compatibility with legacy driver paths. A for_each_gt macro is added to iterate over the GTs and will be used by upcoming patches that convert various parts of the driver to be multi-gt aware. Only the primary/root tile is initialized for now; the other tiles will be detected and plugged in by future patches once the necessary infrastructure is in place to handle them. Signed-off-by: Abdiel Janulgue <abdiel.janulgue@gmail.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@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-4-andi.shyti@linux.intel.com
2022-03-21drm/i915/gt: add gt_is_root() helperAndi Shyti1-0/+5
The "gt_is_root(struct intel_gt *gt)" helper return true if the gt is the root gt, which means that its id is 0. Return false otherwise. 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-3-andi.shyti@linux.intel.com
2022-03-21drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0Andi Shyti9-16/+16
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
2022-03-21Merge tag 'amd-drm-next-5.18-2022-03-18' of https://gitlab.freedesktop.org/agd5f/linux into drm-nextDave Airlie116-2942/+3939
amd-drm-next-5.18-2022-03-18: amdgpu: - Aldebaran fixes - SMU 13.0.5 fixes - DCN 3.1.5 fixes - DCN 3.1.6 fixes - Pipe split fixes - More display FP cleanup - DP 2.0 UHBR fix - DC GPU reset fix - DC deep color ratio fix - SMU robustness fixes - Runtime PM fix for APUs - IGT reload fixes - SR-IOV fix - Misc fixes and cleanups amdkfd: - CRIU fixes - SVM fixes UAPI: - Properly handle SDMA transfers with CRIU Proposed user mode change: https://github.com/checkpoint-restore/criu/pull/1709 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220318203717.5833-1-alexander.deucher@amd.com
2022-03-18drm/i915: Add logical mapping for video decode enginesMatthew Brost1-5/+17
Add logical mapping for VDBOXs. This mapping is required for split-frame workloads, which otherwise fail with 00000000-F8C53528: [GUC] 0441-INVALID_ENGINE_SUBMIT_MASK ... if the application is using the logical id to reorder the engines and then using it for the batch buffer submission. It's not a big problem on media version 11 and 12 as they have only 2 instances of VCS and the logical to physical mapping is monotonically increasing - if the application is not using the logical id. Changing it for the previous platforms allows the media driver implementation for the next ones (12.50 and above) to be the same, checking the logical id. It should also not introduce any bug for the old versions of userspace not checking the id. The mapping added here is the complete map needed by XEHPSDV. Previous platforms with only 2 instances will just use a partial map and should still work. v2: Remove static from map variable (José) Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> [ Extend the mapping to media versions 11 and 12 and give proper justification in the commit message why ] Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220316234538.434357-2-lucas.demarchi@intel.com
2022-03-18drm/i915: Fix renamed struct fieldLucas De Marchi1-1/+1
Earlier versions of commit a5b7ef27da60 ("drm/i915: Add struct to hold IP version") named "ver" as "arch" and then when it was renamed it missed the rename on MEDIA_VER_FULL() since it it's currently not used. Fixes: a5b7ef27da60 ("drm/i915: Add struct to hold IP version") Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220316234538.434357-1-lucas.demarchi@intel.com
2022-03-18drm/i915: Rename QGV request/response bitsVille Syrjälä2-10/+17
Name all the ICL_PCODE_SAGV_DE_MEM_SS_CONFIG request/response bits in a manner that we can actually understand what they're doing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-9-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Unconfuses QGV vs. PSF point masksVille Syrjälä2-19/+19
Use separate bitmasks for QGV vs. PSF GV points during the computation. Makes the whole thing a lot less confusing. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-8-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Fix PSF GV point mask when SAGV is not possibleVille Syrjälä1-1/+2
Don't just mask off all the PSF GV points when SAGV gets disabled. This should in fact cause the Pcode to reject the request since at least one PSF point must remain enabled at all times. Cc: stable@vger.kernel.org Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 192fbfb76744 ("drm/i915: Implement PSF GV point support") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-7-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Rename pre-icl SAGV enable/disable functionsVille Syrjälä1-18/+14
Give the pre-icl SAGV control functions a skl_ prefix instead of the intel_ prefix to make it a bit more clear that they are not some kind of universal things that can be called on any platform. Also make the functions void since we never use the return value anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-6-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Reject excessive SAGV block timeVille Syrjälä1-0/+6
If the mailbox returns an exceesively large SAGV block time let's just reject it. This avoids having to worry about overflows when we add the SAGV block time to the wm0 latency. We shall put the limit arbitrarily at U16_MAX. >65msec latency doesn't really make sense to me in any case. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-5-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Probe whether SAGV works on pre-iclVille Syrjälä1-0/+14
Instead of leaving the SAGV enable/disable to the first commit let's try to disable it first thing to see if we can do it or not (disabling SAGV is a safe thing to at any time). This avoids running the code in this funny intermediate state where we don't know if SAGV is available or not. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-4-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Rework SAGV block time probingVille Syrjälä1-15/+21
I'd like to see the SAGV block time we got from the mailbox in the logs regardless of whether other factors prevent the use of SAGV. So let's adjust the code to always query the SAGV block time, log it, and then reset it if SAGV is not actually supported. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-3-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915: Treat SAGV block time 0 as SAGV disabledVille Syrjälä1-4/+6
For modern platforms the spec explicitly states that a SAGV block time of zero means that SAGV is not supported. Let's extend that to all platforms. Supposedly there should be no systems where this isn't true, and it'll allow us to: - use the same code regardless of older vs. newer platform - wm latencies already treat 0 as disabled, so this fits well with other related code - make it a bit more clear when SAGV is used vs. not - avoid overflows from adding U32_MAX with a u16 wm0 latency value which could cause us to miscalculate the SAGV watermarks on tgl+ Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220309164948.10671-2-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2022-03-18drm/i915/dg2: Add preemption changes for Wa_14015141709Akeem G Abodunrin2-1/+4
Starting with DG2, preemption can no longer be controlled using userspace on a per-context basis. Instead, the hardware only allows us to enable or disable preemption in a global, system-wide basis. Also, we lose the ability to specify the preemption granularity (such as batch-level vs command-level vs object-level). v2 (MattR): - Move debugfs interface to a separate patch. (Jani) v3 (MattR): - Drop the debugfs support completely for now. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220318021051.2073847-1-matthew.d.roper@intel.com
2022-03-18drm/panel: ili9341: fix optional regulator handlingDaniel Mack1-1/+3
If the optional regulator lookup fails, reset the pointer to NULL. Other functions such as mipi_dbi_poweron_reset_conditional() only do a NULL pointer check and will otherwise dereference the error pointer. Fixes: 5a04227326b04c15 ("drm/panel: Add ilitek ili9341 panel driver") Signed-off-by: Daniel Mack <daniel@zonque.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220317225537.826302-1-daniel@zonque.org
2022-03-18Merge tag 'drm-intel-next-fixes-2022-03-17' of git://anongit.freedesktop.org/drm/drm-intel into drm-nextDave Airlie5-6/+10
- Do not re-enable PSR after it was marked as not reliable (Jose) - Add missing boundary check in vm_access to avoid out-of-bounds access (Mastan) - Naming fix for HPD short pulse handling for eDP (Jose) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YjLnofpe5sMHX7Pt@jlahtine-mobl.ger.corp.intel.com
2022-03-17drm/i915/uapi: Add query for hwconfig blobRodrigo Vivi1-0/+23
In this interface i915 is returning a blob of data which it receives from the guc software. This blob provides some useful data about the hardware for drivers. The format of this blob will be documented in the Programmer Reference Manuals when released. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Kenneth Graunke <kenneth.w.graunke@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Slawomir Milczarek <slawomir.milczarek@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> Tested-by: Jordan Justen <jordan.l.justen@intel.com> Acked-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220306232157.1174335-3-jordan.l.justen@intel.com
2022-03-17drm/i915/guc: Add fetch of hwconfig blobJohn Harrison7-0/+199
Implement support for fetching the hardware description table from the GuC. The call is made twice - once without a destination buffer to query the size and then a second time to fill in the buffer. The table is stored in the GT structure so that it can be fetched once at driver load time. Keeping inside a GuC structure would mean it would be release and reloaded on a GuC reset (part of a full GT reset). However, the table does not change just because the GT has been reset and the GuC reloaded. Also, dynamic memory allocations inside the reset path are a problem. Note that the table is only available on ADL-P and later platforms. v2 (John's v2 patch): * Move to GT level to avoid memory allocation during reset path (and unnecessary re-read of the table on a reset). v5 (of Jordan's posting): * Various changes made by Jordan and recommended by Michal - Makefile ordering - Adjust "struct intel_guc_hwconfig hwconfig" comment - Set Copyright year to 2022 in intel_guc_hwconfig.c/.h - Drop inline from hwconfig_to_guc() - Replace hwconfig param with guc in __guc_action_get_hwconfig() - Move zero size check into guc_hwconfig_discover_size() - Change comment to say zero size offset/size is needed to get size - Add has_guc_hwconfig to devinfo and drop has_table() - Change drm_err to notice in __uc_init_hw() and use %pe v6 (of Jordan's posting): * Added a couple more small changes recommended by Michal * Merge in John's v2 patch, but note: - Using drm_notice as recommended by Michal - Reverted Michal's suggestion of using devinfo v7 (of Jordan's posting): * Change back to drm_err as preferred by John Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Acked-by: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220306232157.1174335-2-jordan.l.justen@intel.com
2022-03-17drm/panel-edp: add LQ140M1JW46 edp panel entrySankeerth Billakanti1-0/+1
Add panel identification entry for the sharp LQ140M1JW46 eDP panel with power sequencing delay information. Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1647452154-16361-5-git-send-email-quic_sbillaka@quicinc.com
2022-03-17drm/i915: include uapi/drm/i915_drm.h directly where neededJani Nikula5-3/+7
Remove the uapi/drm/i915_drm.h include from drm/i915_drm.h, and stop being a proxy for uapi/drm/i915_drm.h. Include uapi/drm/i915_drm.h and drm/i915_drm.h only where needed. 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/20220311100639.114685-2-jani.nikula@intel.com
2022-03-17drm/gma500: Cosmetic cleanup of irq codePatrik Jakobsson7-92/+57
Use the gma_ prefix instead of psb_ since the code is common for all chips. Various coding style fixes. Removal of unused code. Removal of duplicate function declarations. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220317092555.17882-4-patrik.r.jakobsson@gmail.com
2022-03-17drm/gma500: Don't store crtc_funcs in psb_opsPatrik Jakobsson5-6/+1
The drm_crtc_funcs are all generic and no chip specific functions are necessary. We can therefore directly put gma_crtc_funcs into the drm_crtc. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220317092555.17882-3-patrik.r.jakobsson@gmail.com
2022-03-17drm/gma500: Move gma_intel_crtc_funcs into gma_display.cPatrik Jakobsson7-25/+17
All functions live in gma_display.c already so move the vtable. Also shorten the name to gma_crtc_funcs. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220317092555.17882-2-patrik.r.jakobsson@gmail.com
2022-03-17drm/gma500: Remove unused declarations and other cruftPatrik Jakobsson1-74/+1
Most of these are old leftovers from one of the driver merges. This is all dead code. Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220317092555.17882-1-patrik.r.jakobsson@gmail.com
2022-03-17drm/vc4: add tracepoints for CL submissionsMelissa Wen3-0/+107
Trace submit_cl_ioctl and related IRQs for CL submission and bin/render jobs execution. It might be helpful to get a rendering timeline and track job throttling. Signed-off-by: Melissa Wen <mwen@igalia.com> Reviewed-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220201212651.zhltjmaokisffq3x@mail.igalia.com
2022-03-17drm/ssd130x: Reduce temporary buffer sizesGeert Uytterhoeven1-3/+6
ssd130x_clear_screen() allocates a temporary buffer sized to hold one byte per pixel, while it only needs to hold one bit per pixel. ssd130x_fb_blit_rect() allocates a temporary buffer sized to hold one byte per pixel for the whole frame buffer, while it only needs to hold one bit per pixel for the part that is to be updated. Pass dst_pitch to drm_fb_xrgb8888_to_mono(), as we have already calculated it anyway. Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-5-geert@linux-m68k.org
2022-03-17drm/ssd130x: Fix rectangle updatesGeert Uytterhoeven1-4/+11
The rectangle update functions ssd130x_fb_blit_rect() and ssd130x_update_rect() do not behave correctly when x1 != 0 or y1 != 0, or when y1 or y2 are not aligned to display page boundaries. E.g. when used as a text console, only the first line of text is shown on the display. 1. The buffer passed by ssd130x_fb_blit_rect() points to the first byte of monochrome bitmap data, and thus has its origin at (x1, y1), while ssd130x_update_rect() assumes it is at (0, 0). Fix ssd130x_update_rect() by changing the vertical and horizontal loop ranges, and adding the offsets only when needed. 2. In ssd130x_fb_blit_rect(), align y1 and y2 to the display page boundaries before doing the color conversion, so the full page is converted and updated. Remove the correction for an unaligned y1 from ssd130x_update_rect(), and add a check to make sure y1 is aligned. Fixes: a61732e808672cfa ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-4-geert@linux-m68k.org
2022-03-17drm/format-helper: Fix XRGB888 to monochrome conversionGeert Uytterhoeven1-37/+18
The conversion functions drm_fb_xrgb8888_to_mono() and drm_fb_gray8_to_mono_line() do not behave correctly when the horizontal boundaries of the clip rectangle are not multiples of 8: a. When x1 % 8 != 0, the calculated pitch is not correct, b. When x2 % 8 != 0, the pixel data for the last byte is wrong. Simplify the code and fix (a) by: 1. Removing start_offset, and always storing the first pixel in the first bit of the monochrome destination buffer. Drivers that require the first pixel in a byte to be located at an x-coordinate that is a multiple of 8 can always align the clip rectangle before calling drm_fb_xrgb8888_to_mono(). Note that: - The ssd130x driver does not need the alignment, as the monochrome buffer is a temporary format, - The repaper driver always updates the full screen, so the clip rectangle is always aligned. 2. Passing the number of pixels to drm_fb_gray8_to_mono_line(), instead of the number of bytes, and the number of pixels in the last byte. Fix (b) by explicitly setting the target bit, instead of always setting bit 7 and shifting the value in each loop iteration. Remove the bogus pitch check, which operates on bytes instead of pixels, and triggers when e.g. flashing the cursor on a text console with a font that is 8 pixels wide. Drop the confusing comment about scanlines, as a pitch in bytes always contains a multiple of 8 pixels. While at it, use the drm_rect_height() helper instead of open-coding the same operation. Update the comments accordingly. Fixes: bcf8b616deb87941 ("drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-3-geert@linux-m68k.org
2022-03-17drm/format-helper: Rename drm_fb_xrgb8888_to_mono_reversed()Geert Uytterhoeven3-18/+17
There is no "reversed" handling in drm_fb_xrgb8888_to_mono_reversed(): the function just converts from color to grayscale, and reduces the number of grayscale levels from 256 to 2 (i.e. brightness 0-127 is mapped to 0, 128-255 to 1). All "reversed" handling is done in the repaper driver, where this function originated. Hence make this clear by renaming drm_fb_xrgb8888_to_mono_reversed() to drm_fb_xrgb8888_to_mono(), and documenting the black/white pixel mapping. Fixes: bcf8b616deb87941 ("drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220317081830.1211400-2-geert@linux-m68k.org
2022-03-17drm: Don't make DRM_PANEL_BRIDGE dependent on DRM_KMS_HELPERSThomas Zimmermann2-1/+2
Fix a number of undefined references to drm_kms_helper.ko in drm_dp_helper.ko: arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_mst_duplicate_state': drm_dp_mst_topology.c:(.text+0x2df0): undefined reference to `__drm_atomic_helper_private_obj_duplicate_state' arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_delayed_destroy_work': drm_dp_mst_topology.c:(.text+0x370c): undefined reference to `drm_kms_helper_hotplug_event' arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_mst_up_req_work': drm_dp_mst_topology.c:(.text+0x7938): undefined reference to `drm_kms_helper_hotplug_event' arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in function `drm_dp_mst_link_probe_work': drm_dp_mst_topology.c:(.text+0x82e0): undefined reference to `drm_kms_helper_hotplug_event' This happens if panel-edp.ko has been configured with DRM_PANEL_EDP=y DRM_DP_HELPER=y DRM_KMS_HELPER=m which builds DP helpers into the kernel and KMS helpers sa a module. Making DRM_PANEL_EDP select DRM_KMS_HELPER resolves this problem. To avoid a resulting cyclic dependency with DRM_PANEL_BRIDGE, don't make the latter depend on DRM_KMS_HELPER and fix the one DRM bridge drivers that doesn't already select DRM_KMS_HELPER. As KMS helpers cannot be selected directly by the user, config symbols should avoid depending on it anyway. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 3755d35ee1d2 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP") Acked-by: Sam Ravnborg <sam@ravnborg.org> Tested-by: Brian Masney <bmasney@redhat.com> Reported-by: kernel test robot <lkp@intel.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Naresh Kamboju <naresh.kamboju@linaro.org> Cc: Linux Kernel Functional Testing <lkft@linaro.org> Cc: Lyude Paul <lyude@redhat.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: Dave Airlie <airlied@redhat.com> Cc: Thierry Reding <thierry.reding@gmail.com> Link: https://patchwork.freedesktop.org/patch/478296/
2022-03-17Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann113-472/+1236
Backmerging drm/drm-fixes for commit 3755d35ee1d2 ("drm/panel: Select DRM_DP_HELPER for DRM_PANEL_EDP"). Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
2022-03-17drm/i915: move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch]Jani Nikula5-10/+13
Move i915_gem_object_needs_bit17_swizzle() to i915_gem_tiling.[ch] as a i915_gem_object function related to tiling. Also un-inline while at it; does not seem like this is a function needed in hot paths. v2: i915_gem_tiling.[ch] instead of intel_ggtt_fencing.[ch] (Chris) Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220316095018.137998-1-jani.nikula@intel.com
2022-03-16drm/nouveau: Fix spelling mistake "endianess" -> "endianness"Colin Ian King1-1/+1
There is a spelling mistake in a nvdev_error error message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315221929.2959700-1-colin.i.king@gmail.com
2022-03-16drm/i915: fixup the initial fb base on DGFXMatthew Auld1-6/+44
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
2022-03-16drm/i915/display: Check mappable aperture when pinning preallocated vmaCQ Tang1-1/+5
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
2022-03-16drm/i915/ttm: wire up the object offsetMatthew Auld6-6/+28
For the ttm backend we can use existing placements fpfn and lpfn to force the allocator to place the object at the requested offset, potentially evicting stuff if the spot is currently occupied. 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-5-matthew.auld@intel.com
2022-03-16drm/i915: add i915_gem_object_create_region_at()Matthew Auld12-74/+77
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
2022-03-16drm/i915/stolen: consider I915_BO_ALLOC_GPU_ONLYMatthew Auld1-0/+8
Keep the behaviour consistent with normal lmem, where we assume CPU access if by default required. 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-3-matthew.auld@intel.com
2022-03-16drm/i915/stolen: don't treat small BAR as an errorAkeem G Abodunrin2-19/+46
On client platforms with reduced LMEM BAR, we should be able to continue with driver load with reduced io_size. Instead of using the BAR size to determine the how large stolen should be, we should instead use the ADDR_RANGE register to figure this out(at least on platforms like DG2). For simplicity we don't attempt to support partially mappable stolen. v2: rearrange the io_mapping_init_wc slightly, since the stolen setup might result in reduced io_size. Signed-off-by: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Co-developed-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> Reviewed-by: Nirmoy Das <nirmoy.das@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315181425.576828-2-matthew.auld@intel.com
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.