- 21 Apr, 2022 8 commits
-
-
Alexander Usyskin authored
Setup char device in spite of firmware handshake failure. In order to provide host access to the firmware status registers and other information required for the manufacturing process. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Tomas Winkler authored
GSC is a graphics system controller, based on CSE, it provides a chassis controller for graphics discrete cards, as well as it supports media protection on selected devices. mei_gsc binds to a auxiliary devices exposed by Intel discrete driver i915. v2: fix error check in mei_gsc_probe v3: update MODULE_LICENSE ("GPL" is preferred over "GPL v2" and they both map to GPL version 2) Signed-off-by: -
Tomas Winkler authored
GSC is a graphics system controller, it provides a chassis controller for graphics discrete cards. There are two MEI interfaces in GSC: HECI1 and HECI2. Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000. GSC is a GT Engine (class 4: instance 6). HECI1 interrupt is signaled via bit 15 and HECI2 via bit 14 in the interrupt register. This patch exports GSC as auxiliary device for mei driver to bind to for HECI2 interface and prepares for HECI1 interface as it will follow up soon. CC: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Vitaly Lubart <vitaly.lubart@intel.com> Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
In order to get the GSC Support merged on drm-intel-gt-next in a clean fashion we needed this ATS-M patch to avoid conflict in i915_pci.c: commit 412c942b ("drm/i915/ats-m: add ATS-M platform info") -- Fixing a silent conflict on drivers/gpu/drm/i915/gt/intel_gt_gmch.c: - if (!intel_vtd_active(i915)) + if (!i915_vtd_active(i915)) Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matthew Auld authored
The compact-pt layout restrictions should only apply to the ppGTT. Also make this play nice on platforms that only have the 64K GTT restriction, and not the compact-pt thing. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Nirmoy Das <nirmoy.das@linux.intel.com> Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Nirmoy Das <nirmoy.das@linux.intel.com> Reviewed-by:
Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220420181613.70033-4-matthew.auld@intel.com
-
Matthew Auld authored
Trying to cast the region id into the region type doesn't work too well, since the i915_vm_min_alignment() won't give us the correct value for the stolen-lmem case. Signed-off-by:
-
Matthew Auld authored
Ensure we check that the size is compatible with the requested page_size. For tiny objects that are automatically annotated with TTM_PL_FLAG_CONTIGUOUS(since they fit within a single page), we currently end up silently overriding the min_page_size, which ends up hiding bugs elsewhere. Signed-off-by:
-
Matthew Auld authored
We can only force migrate an object if the existing object size is compatible with the new destinations min_page_size for the region. Currently we blow up with something like: [ 2857.497462] kernel BUG at drivers/gpu/drm/i915/gt/intel_migrate.c:431! [ 2857.497497] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 2857.497502] CPU: 1 PID: 8921 Comm: i915_selftest Tainted: G U W 5.18.0-rc1-drm-tip+ #27 [ 2857.497513] RIP: 0010:emit_pte.cold+0x11a/0x17e [i915] [ 2857.497646] Code: 00 48 c7 c2 f0 cd c1 a0 48 c7 c7 e9 99 bd a0 e8 d2 77 5d e0 bf 01 00 00 00 e8 08 47 5d e0 31 f6 bf 09 00 00 00 e8 3c 7b 4d e0 <0f> 0b 48 c7 c1 e0 2a c5 a0 ba 34 00 00 00 48 c7 c6 00 ce c1 a0 48 [ 2857.497654] RSP: 0018:ffffc900000f7748 EFLAGS: 00010246 [ 2857.497658] RAX: 0000000000000000 RBX: ffffc900000f77c8 RCX: 0000000000000006 [ 2857.497662] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000009 [ 2857.497665] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001 [ 2857.497668] R10: 0000000000022302 R11: ffff88846dea08f0 R12: 0000000000010000 [ 2857.497672] R13: 0000000001880000 R14: 000000000000081b R15: ffff888106b7c040 [ 2857.497675] FS: 00007f0d4c4e0600(0000) GS:ffff88845da80000(0000) knlGS:0000000000000000 [ 2857.497679] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2857.497682] CR2: 00007f113966c088 CR3: 0000000211e60003 CR4: 00000000003706e0 [ 2857.497686] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2857.497689] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2857.497692] Call Trace: [ 2857.497694] <TASK> [ 2857.497697] intel_context_migrate_copy+0x1e5/0x4f0 [i915] Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220420181613.70033-1-matthew.auld@intel.com
-
- 20 Apr, 2022 1 commit
-
-
José Roberto de Souza authored
A new DG2 workaround added to fix some corner cases hangs. v2: - implementing the second and preferred option for this workaround BSpec: 54077 BSpec: 68173 BSpec: 71488 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419182753.364237-2-jose.souza@intel.com
-
- 19 Apr, 2022 6 commits
-
-
John Harrison authored
The above two workaronuds regarding context isolation are implemented by GuC. The KMD just needs to enable them. Signed-off-by:
John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by:
-
Matthew Brost authored
There is bug in DG2 where if the CCS contexts switches out while the RCS is running it can cause memory corruption. To workaround this add an atomic to a memory address with a value 1 and semaphore wait to the same address for a value of 0. The GuC firmware is responsible for writing 0 to the memory address when it is safe for the context to switch out. Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
Vinay Belgaumkar authored
Enable GuC Wa to reset RCS/CCS before it goes into RC6. Signed-off-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Reviewed-by:
-
John Harrison authored
There are some workarounds for DG2 that are implemented in the GuC firmware. However, the KMD is required to enable these by setting the appropriate flag as GuC does not know what platform it is running on. Wa_16011759253 Wa_14012630569 Wa_14013746162 Signed-off-by:
-
Umesh Nerlige Ramappa authored
Initiating a reset when the command streamer is not idle or in the middle of executing an MI_FORCE_WAKE can result in a hang. Multiple command streamers can be part of a single reset domain, so resetting one would mean resetting all command streamers in that domain. To workaround this, before initiating a reset, ensure that all command streamers within that reset domain are either IDLE or are not executing a MI_FORCE_WAKE. Enable GuC PRE_PARSER WA bit so that GuC follows the WA sequence when initiating engine-resets. For gt-resets, ensure that i915 applies the WA sequence. Opens to address in future patches: - The part of the WA to wait for pending forcewakes is also applicable to execlists backend. - The WA also needs to be applied for gen11 Signed-off-by:
-
Tilak Tangudu authored
Prior to doing a reset, SW must ensure command streamer is stopped, as a workaround, to eliminate a race condition in GPM flow. Setting both the ring stop and prefetch disable bits, will cause the command streamer to halt. Signed-off-by:
Tilak Tangudu <tilak.tangudu@intel.com> Reviewed-by:
-
- 16 Apr, 2022 1 commit
-
-
Rodrigo Vivi authored
v2: * Jordan: Drop stepping/skew checking as suggested by John. Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Signed-off-by:
-
- 15 Apr, 2022 7 commits
-
-
Ashutosh Dixit authored
At present i915 does not fetch busyness information from GuC, resulting in incorrect busyness values in fdinfo. Because engine information is coupled with busyness in fdinfo, skip showing client engine information in fdinfo with GuC submission till fetching busyness is supported in the i915 GuC submission backend. v2 (Daniele): Make commit title and description more precise Add FIXME with brief description at code change s/intel_guc_submission_is_used/intel_uc_uses_guc_submission/ v3 (Daniele): Drop FIXME in comment Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/5564 Fixes: 055634e4 ("drm/i915: Expose client engine utilisation via fdinfo") Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Reviewed-by:
-
Vinay Belgaumkar authored
This will ensure we don't have false positives when we run error injection tests. Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
-
Matt Atwood authored
Newer platforms have DSS that aren't necessarily available for both geometry and compute, two queries will need to exist. This introduces the first, when passing a valid engine class and engine instance in the flags returns a topology describing geometry. Based on past discussion, we currently only support this new query item on Xe_HP and beyond; earlier platforms do not need to worry about geometry and compute pipelines having access to different topology and should continue to use the existing topology query. v2: fix white space errors v3: change flags from hosting 2 8 bit numbers to holding a i915_engine_class_instance struct v4: add error if non rcs engine passed. v5 (by MattR): - Improve kerneldoc and cross references to related structs/enums. (Daniel) - Clarify that geometry query is only supported on render engines (Francisco) - Clarify that the new query is only supported on Xe_HP+. - Fix checkpatch warnings. Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Francisco Jerez <currojerez@riseup.net> UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14143 Testcase: igt@i915_query@test-query-geometry-subslices Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20220414192230.749771-4-matthew.d.roper@intel.com
-
Matt Roper authored
Document the possible options for drm_i915_query_item.query_id with links to the corresponding uapi structures. Signed-off-by:
-
Matt Roper authored
Convert the comments for drm_i915_query_perf_config and drm_i915_perf_oa_config to kerneldoc so that they will show up in the generated documentation. Also correct a couple places that referred to query_id when they actually meant to refer to query_item.flags. Signed-off-by:
-
Matt Roper authored
This structure has a great comment describing the fields, but it's not currently in kerneldoc form and does not show up in the generated documentation. Let's fix that and also clarify the description of what "subslice" refers to on gen12 platforms and beyond and that "slice" is no longer meaningful on Xe_HP and beyond. Signed-off-by:
-
John Harrison authored
The latest GuC firmware drops the context descriptor pool in favour of passing all creation data in the create H2G. It also greatly simplifies the work queue and removes the process descriptor used for multi-LRC submission. So, remove all mention of LRC and process descriptors and update the registration code accordingly. Unfortunately, the new API also removes the ability to set default values for the scheduling policies at context registration time. Instead, a follow up H2G must be sent. The individual scheduling policy update H2G commands are also dropped in favour of a single KLV based H2G. So, change the update wrappers accordingly and call this during context registration.. Of course, this second H2G per registration might fail due to being backed up. The registration code has a complicated state machine to cope with the actual registration call failing. However, if that works then there is no support for unwinding if a further call should fail. Unwinding would require sending a H2G to de-register - but that can't be done because the CTB is already backed up. So instead, add a new flag to say whether the context has a pending policy update. This is set if the policy H2G fails at registration time. The submission code checks for this flag and retries the policy update if set. If that call fails, the submission path early exists with a retry error. This is something that is already supported for other reasons. Signed-off-by:
-
- 14 Apr, 2022 10 commits
-
-
Ramalingam C authored
When we are swapping out the local memory obj on flat-ccs capable platform, we need to capture the ccs data too along with main meory and we need to restore it when we are swapping in the content. When lmem object is swapped into a smem obj, smem obj will have the extra pages required to hold the ccs data corresponding to the lmem main memory. So main memory of lmem will be copied into the initial pages of the smem and then ccs data corresponding to the main memory will be copied to the subsequent pages of smem. ccs data is 1/256 of lmem size. Swapin happens exactly in reverse order. First main memory of lmem is restored from the smem's initial pages and the ccs data will be restored from the subsequent pages of smem. Extracting and restoring the CCS data is done through a special cmd called XY_CTRL_SURF_COPY_BLT v2: Fixing the ccs handling v3: Handle the ccs data at same loop as main memory [Thomas] v4: changes for emit_copy_ccs v5: handle non-flat-ccs scenario Signed-off-by:
Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220405150840.29351-10-ramalingam.c@intel.com
-
Ramalingam C authored
On Xe-HP and later devices, dedicated compression control state (CCS) stored in local memory is used for each surface, to support the 3D and media compression formats. The memory required for the CCS of the entire local memory is 1/256 of the local memory size. So before the kernel boot, the required memory is reserved for the CCS data and a secure register will be programmed with the CCS base address So when an object is allocated in local memory, dont need to explicitly allocate the space for ccs data. But when the obj is evicted into the smem, to hold the compression related data along with the obj extra space is needed in smem. i.e obj_size + (obj_size/256). Hence when a smem pages are allocated for an obj with lmem placement possibility we create with the extra pages required for the ccs data for the obj size. v2: Used imperative wording [Thomas] v3: Inflate the pages only when obj's placement is lmem only v4: GEM_BUG_ON if the ttm->num_pages > obj page size [Thomas] Signed-off-by:
-
Ramalingam C authored
Extend the live migrate selftest, to verify the ccs surface clearing during the Flat-CCS capable lmem obj clear. v2: Look at right places for ccs data [Thomas] Signed-off-by:
-
Ramalingam C authored
Consider the possible round up happened at obj size alignment to min_page_size during the obj allocation. Signed-off-by:
-
Ramalingam C authored
Xe-HP and latest devices support Flat CCS which reserved a portion of the device memory to store compression metadata, during the clearing of device memory buffer object we also need to clear the associated CCS buffer. XY_CTRL_SURF_COPY_BLT is a BLT cmd used for reading and writing the ccs surface of a lmem memory. So on Flat-CCS capable platform we use XY_CTRL_SURF_COPY_BLT to clear the CCS meta data. v2: Fixed issues with platform naming [Lucas] v3: Rebased [Ram] Used the round_up funcs [Bob] v4: Fixed ccs blk calculation [Ram] Added Kdoc on flat-ccs. v5: GENMASK is used [Matt] mocs fix [Matt] Comments Fix [Matt] Flush address programming [Ram] v6: FLUSH_DW is fixed Few coding style fix v7: Adopting the XY_FAST_COLOR_BLT (Thomas] v8: XY_CTRL_SURF_COPY_BLT for ccs clearing. v9: emit_copy_ccs is used. v10: ctrl_surf cmds are filled in caller itself. [Thomas] only one ctrl surf cmd is used as size of lmem is <=8M [Thomas] Signed-off-by:Ayaz A Siddiqui <ayaz.siddiqui@intel.com> Reviewed-by:
-
Ramalingam C authored
When emit_pte doesn't update any PTE with return value as 0, interpret it as -EINVAL. v2: Add missing goto [Thomas] Signed-off-by:
-
Ramalingam C authored
Move the static calculations out of the loops for copy and clear. v2: Fix the loss of proper error code on emit_pte Signed-off-by:
-
Ramalingam C authored
Use faster XY_FAST_COLOR_BLT cmd on graphics version of 12 and more, for clearing (Zero out) the pages of the newly allocated object. XY_FAST_COLOR_BLT is faster than the older XY_COLOR_BLT. v2: Typo fix at title [Thomas] v3: XY_FAST_COLOR_BLT is used only for FLAT_CCS capable gen12+ Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Ramalingam C authored
To make it uniform across copy and clear, use the engine offset directly to calculate the offset in the cmd forming for emit_clear. Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-intel-next-2022-04-13-1' of git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 feature pull for v5.19: Features and functionality: - Add support for new Tile 4 format on DG2 (Stan) - Add support for new CCS clear color compression on DG2 (Mika, Juha-Pekka) - Add support for new render and media compression formats on DG2 (Matt) - Support multiple eDP and LVDS native mode refresh rates (Ville) - Support static DRRS (Ville) - ATS-M platform info (Matt) - RPL-S PCI IDs (Tejas) - Extend DP HDR support to HSW+ (Uma) - Bump ADL-P DMC version to v2.16 (Madhumitha) - Let users disable PSR2 while enabling PSR1 (José) Refactoring and cleanups: - Massive DRRS and panel fixed mode refactoring and cleanups (Ville) - Power well refactoring and cleanup (Imre) - Clean up and refactor crtc readout and compute config (Ville) - Use kernel string helpers (Lucas) - Refactor gmbus pin lookups and allocation (Jani) - PCH display cleanups (Ville) - DPLL and DPLL manager refactoring (Ville) - Include and header refactoring (Jani, Tvrtko) - DMC abstractions (Jani) - Non-x86 build refactoring (Casey) - VBT parsing refactoring (Ville) - Bigjoiner refactoring (Ville) - Optimize plane, pfit, scaler, etc. programming using unlocked writes (Ville) - Split several register writes in commit to noarm+arm pairs (Ville) - Clean up SAGV handling (Ville) - Clean up bandwidth and ddb allocation (Ville) - FBC cleanups (Ville) Fixes: - Fix native HDMI and DP HDMI DFP clock limits on deep color/4:2:0 (Ville) - Fix DMC firmware platform check (Lucas) - Fix cursor coordinates on bigjoiner secondary (Ville) - Fix MSO vs. bigjoiner timing confusion (Ville) - Fix ADL-P eDP voltage swing (José) - Fix VRR capability property update (Manasi) - Log DG2 SNPS PHY calibration errors (Matt, Lucas) - Fix PCODE request status checks (Stan) - Fix uncore unclaimed access warnings (Lucas) - Fix VBT new max TMDS clock parsing (Shawn) - Fix ADL-P non-existent underrun recovery (Swathi Dhanavanthri) - Fix ADL-N stepping info (Tejas) - Fix DPT mapping flags to contiguous (Stan) - Fix DG2 max display bandwidth (Vinod) - Fix DP low voltage SKU checks (Ankit) - Fix RPL-S VT-d translation enable via quirk (Tejas) - Fixes to PSR2 (José) - Fix PIPE_MBUS_DBOX_CTL programming (José) - Fix LTTPR capability read/check on DP 1.2 (Imre) - Fix ADL-P register corruption after DDI clock enabling (Imre) - Fix ADL-P MBUS DBOX BW and B credits (Caz) Merges: - Backmerge drm-next (Rodrigo, Jani) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/874k2xgewe.fsf@intel.com
-
- 13 Apr, 2022 7 commits
-
-
Ville Syrjälä authored
Remove the pointless detour via __intel_fbc_post_update() during frontbuffer flush. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220315140001.1172-8-ville.syrjala@linux.intel.comReviewed-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
Let's make sure FBC is always disabled when we start to take over the hardware state. I suspect this should never really happen, since the only time when we really should be taking over with the display already active is when the previous state was progammed by the BIOS, which likely shouldn't use FBC. This could be driver init, or S4 resume when the boot kernel doesn't load i915. But I suppose no harm in keeping this code around for exra safety since it's quite trivial. Signed-off-by:
-
Ville Syrjälä authored
By the time intel_fbc_global_disable() gets called during driver teardown we should have already disabled all the crtcs, so no way FBC should be enabled at this point. And I have no idea what the other user (i915_restore_display()) is even trying to achieve. So let's just throw intel_fbc_global_disable() into the bin. Signed-off-by:
-
Ville Syrjälä authored
Now that fbc no longer nukes while a flip is pending we can remove the last uncore.lock from the i9xx plane code. Signed-off-by:
-
Ville Syrjälä authored
Don't issue a nuke from frontbuffer flush while a flip is pending. This avoids the DSPADDR/DSPSURF rmw abuse from the pre-snb nuke from racing with the DSPADDR/DSPSURF write being performed by the flip/plane update. The flip itself will already cause the nuke so a double nuke is redundant. Signed-off-by:
-
Ville Syrjälä authored
If the frontbuffer bits say this fbc instance isn't affected just skip the whole thing. Signed-off-by:
-
Ville Syrjälä authored
Not sure what the point of this fbc->possible_frontbuffer_bits is. And especially don't see why it's returning all the bits when fbc is not even enabled. So let's just get rid of this and only say we are interested in the plane's frontbuffer bits when fbc is actually enabled. Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
