Lucas De Marchi [Tue, 3 May 2022 06:15:56 +0000 (23:15 -0700)]
drm/i915/gem: Make drop_pages() return bool
Commit 71676245eae2 ("drm/i915: Change shrink ordering to use locking
around unbinding.") changed the return type to int without changing the
return values or their meaning to "0 is success". Move it back to
boolean.
drm/i915: Only setup private tmpfs mount when needed and fix logging
If i915 does not want to use huge pages there is a) no point in setting up
the private mount and b) should former fail, it is misleading to log THP
support is disabled in the caller, which does not even know if callee
tried to enable it.
Fix both by restructuring the flow in i915_gemfs_init and at the same time
note the failure to set it up in all cases.
We have a statement from HW designers that the GPU read regression when
using 2M pages was fixed from Icelake onwards, which was also confirmed
by bencharking Eero did last year:
"""
When IOMMU is disabled, enabling THP causes following perf changes on
TGL-H (GT1):
In the above 3D benchmark names, * means all the variants of tests with
the same prefix. For example "SynMark TexMem*", means both TexMem128 &
TexMem512 tests in the synthetic (Intel internal) SynMark test suite.
In the (public, but proprietary) GfxBench & GLB(enchmark) test suites,
there are both onscreen and offscreen variants of each test. Unless
explicitly stated otherwise, numbers are for both variants.
All tests are run with FullHD monitor. All tests are fullscreen except
for GLB and GpuTest ones, which are run in 1/2 screen window (GpuTest
triangle is run both in fullscreen and 1/2 screen window).
"""
Since the only regression is MemBW GPU blend, against many more gains,
it sounds it is time to enable THP on Gen11+.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
References: https://gitlab.freedesktop.org/drm/intel/-/issues/430 Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100414.647857-1-tvrtko.ursulin@linux.intel.com
No need to have this parameter in intel_device_info struct
as all platforms with display version 9 or newer has this feature.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as the requirement to support it is the DDI support.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as all platforms with display version 9 or newer, haswell or broadwell
supports it.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
drm/i915: Drop has_logical_ring_elsq from device info
No need to have this parameter in intel_device_info struct
as all platforms with graphics version 11 or newer has this feature.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as all platforms with graphics version 7 or newer can reset engines.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as all platforms with graphics version 6 or newer have software
support for this feature.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
No need to have this parameter in intel_device_info struct
as all platforms with graphics version 9 or newer has graphics
microcontroller.
As a side effect of the of removal this flag, it will not be printed
in dmesg during driver load anymore and developers will have to rely
on to check the macro and compare with platform being used and IP
versions of it.
Tvrtko Ursulin [Thu, 5 May 2022 11:00:07 +0000 (12:00 +0100)]
drm/i915: Don't use DRM_DEBUG_WARN_ON for ring unexpectedly not idle
DRM_DEBUG_WARN_ON should only be used when we are certain CI is guaranteed
to exercise a certain code path, so in case of values coming from MMIO
reads we cannot be sure CI will have all the possible SKUs and parts, or
that it will catch all possible error conditions. Use drm_warn instead.
Tvrtko Ursulin [Thu, 5 May 2022 11:00:06 +0000 (12:00 +0100)]
drm/i915: Don't use DRM_DEBUG_WARN_ON for unexpected l3bank/mslice config
DRM_DEBUG_WARN_ON should only be used when we are certain CI is guaranteed
to exercise a certain code path, so in case of values coming from MMIO
reads we cannot be sure CI will have all the possible SKUs and parts.
Use drm_warn instead and move logging to init phase while at it.
drm/i915/huc: Don't fail the probe if HuC init fails
The previous patch introduced new failure cases in the HuC init flow
that can be hit by simply changing the config, so we want to avoid
failing the probe in those scenarios. HuC load failure is already
considered a non-fatal error and we have a way to report to userspace
if the HuC is not available via a dedicated getparam, so no changes
in expectation there.
The error message in the HuC init code has also been lowered to info to
avoid throwing error message for an expected behavior.
HuC loading via GSC is performed via a PXP command sent through the mei
modules, so we need both MEI_GSC and MEI_PXP to be available. Given that
the GSC will do both the transfer and the authentication, the legacy HuC
loading paths can be safely skipped.
Also note that the GSC-loaded HuC survives GT reset.
v2: move the huc_is_authenticated() function to this patch.
drm/i915/huc: Add fetch support for gsc-loaded HuC binary
On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of
HuC loading has been moved from the GuC to the GSC. As part of the
change, the header format of the HuC binary has been updated and does not
match the GuC anymore. The GSC will perform all the required checks on
the binary size, so we only need to check that the version matches.
Note that since we still haven't added any gsc-loaded FWs, the
loaded_via_gsc variable will always be kept to its initialization value
of zero.
v2: Add a note about loaded_via_gsc being zero (Alan)
The function name is confusing, because it doesn't check the actual auth
status in HW but the SW status. Given that there is only one user (the
huc_auth function itself), just get rid of it and use the FW status
checker directly.
Matthew Brost [Wed, 4 May 2022 23:46:36 +0000 (16:46 -0700)]
drm/i915/guc: Support programming the EU priority in the GuC descriptor
In GuC submission mode the EU priority must be updated by the GuC rather
than the driver as the GuC owns the programming of the context descriptor.
Given that the GuC code uses the GuC priorities, we can't use a generic
function using i915 priorities for both execlists and GuC submission.
The existing function has therefore been pushed to the execlists
back-end while a new one has been added for GuC.
v2: correctly use the GuC prio.
Cc: John Harrison <john.c.harrison@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Aravind Iddamsetty <aravind.iddamsetty@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220504234636.2119794-1-daniele.ceraolospurio@intel.com
Ramalingam C [Mon, 2 May 2022 14:26:17 +0000 (19:56 +0530)]
drm/i915/gt: optimize the ccs_sz calculation per chunk
Calculate the ccs_sz that needs to be emitted based on the src
and dst pages emitted per chunk. And handle the return value of emit_pte
for the ccs pages.
Chris Wilson [Mon, 25 Apr 2022 15:23:17 +0000 (20:53 +0530)]
drm/i915/gt: Clear SET_PREDICATE_RESULT prior to executing the ring
Userspace may leave predication enabled upon return from the batch
buffer, which has the consequent of preventing all operation from the
ring from being executed, including all the synchronisation, coherency
control, arbitration and user signaling. This is more than just a local
gpu hang in one client, as the user has the ability to prevent the
kernel from applying critical workarounds and can cause a full GT reset.
We could simply execute MI_SET_PREDICATE upon return from the user
batch, but this has the repercussion of modifying the user's context
state. Instead, we opt to execute a fixup batch which by mixing
predicated operations can determine the state of the
SET_PREDICATE_RESULT register and restore it prior to the next userspace
batch. This allows us to protect the kernel's ring without changing the
uABI.
Suggested-by: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com> Signed-off-by: Chris Wilson <chris.p.wilson@intel.com> Cc: Zbigniew Kempczynski <zbigniew.kempczynski@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220425152317.4275-4-ramalingam.c@intel.com
Chris Wilson [Mon, 25 Apr 2022 15:23:16 +0000 (20:53 +0530)]
drm/i915/selftests: Skip poisoning SET_PREDICATE_RESULT on dg2
When predication is enabled all commands baring a few (such as MI_BB_END)
are nop'ed. If we accidentally enable predication while poisoning the
context, not only is the rest of the poisoning skipped (thus disabling
the test), but the closing instructions of the poison request are
nop'ed. Not only do we then not signal the waiting context, but we even
prevent re-enabling arbitration and the GPU will not perform a context
switch at the end of the request.
drm/i915/xehpsdv/dg1/tgl: Fix issue with LRI relative addressing
When bit 19 of MI_LOAD_REGISTER_IMM instruction opcode is set on tgl+
devices, HW does not care about certain register address offsets, but
instead check the following for valid address ranges on specific engines:
RCS && CCS: BITS(0 - 10)
BCS: BITS(0 - 11)
VECS && VCS: BITS(0 - 13)
Also, tgl+ now support relative addressing for BCS engine - So, this
patch fixes issue with live_gt_lrc selftest that is failing where there is
mismatch between LRC register layout generated during init and HW
default register offsets.
Matt Roper [Thu, 28 Apr 2022 04:19:24 +0000 (21:19 -0700)]
drm/i915/xehp: Add register for compute engine's MMIO-based TLB invalidation
Compute engines have a separate register that the driver should use to
perform MMIO-based TLB invalidation.
Note that the term "context" in this register's bspec description is
used to refer to the engine instance (in the same way "context" is used
on bspec 46167).
Matt Roper [Thu, 28 Apr 2022 04:19:23 +0000 (21:19 -0700)]
drm/i915/uapi: Add kerneldoc for engine class enum
We'll be adding a new type of engine soon. Let's document the existing
engine classes first to help make it clear what each type of engine is
used for.
John Harrison [Wed, 27 Apr 2022 16:55:50 +0000 (09:55 -0700)]
drm/i915/dg2: Define GuC firmware version for DG2
First release of GuC for DG2.
Signed-off-by: John Harrison <John.C.Harrison@Intel.com> CC: Tomasz Mistat <tomasz.mistat@intel.com> CC: Ramalingam C <ramalingam.c@intel.com> CC: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220427165550.3636686-3-John.C.Harrison@Intel.com
Add a hook to retrieve the firmware version of the
GSC devices to bus-fixup.
GSC has a different MKHI clients GUIDs but the same message structure
to retrieve the firmware version as MEI so mei_fwver() can be reused.
CC: Ashutosh Dixit <ashutosh.dixit@intel.com> 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: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220419193314.526966-6-daniele.ceraolospurio@intel.com
mei: gsc: setup char driver alive in spite of firmware handshake failure
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.
Tomas Winkler [Tue, 19 Apr 2022 19:33:09 +0000 (12:33 -0700)]
mei: add support for graphics system controller (gsc) devices
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)
Tomas Winkler [Tue, 19 Apr 2022 19:33:08 +0000 (12:33 -0700)]
drm/i915/gsc: add gsc as a mei auxiliary device
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.
Matthew Auld [Wed, 20 Apr 2022 18:16:13 +0000 (19:16 +0100)]
drm/i915/selftests: tweak the misaligned_case
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 [Wed, 20 Apr 2022 18:16:12 +0000 (19:16 +0100)]
drm/i915/selftests: fixup min_alignment usage
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 <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-3-matthew.auld@intel.com
Matthew Auld [Wed, 20 Apr 2022 18:16:11 +0000 (19:16 +0100)]
drm/i915/buddy: sanity check the size
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.
Matthew Auld [Wed, 20 Apr 2022 18:16:10 +0000 (19:16 +0100)]
drm/i915: consider min_page_size when migrating
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:
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.
John Harrison [Fri, 15 Apr 2022 22:40:22 +0000 (15:40 -0700)]
drm/i915/guc: Enable GuC based workarounds for DG2
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
drm/i915/guc: Enable Wa_22011802037 for gen12 GuC based platforms
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
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.
Rodrigo Vivi [Thu, 31 Mar 2022 23:17:37 +0000 (16:17 -0700)]
drm/i915/hwconfig: Add DG2 support
v2:
* Jordan: Drop stepping/skew checking as suggested by John.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Jordan Justen <jordan.l.justen@intel.com> Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331231737.315957-1-jordan.l.justen@intel.com
Ashutosh Dixit [Fri, 15 Apr 2022 00:25:11 +0000 (17:25 -0700)]
drm/i915: Don't show engine information in fdinfo with GuC submission
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: 6932f0eba7e2 ("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: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b614c2c61a954de06fbe2c3a7c70d3a91804407e.1649982207.git.ashutosh.dixit@intel.com
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: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Francisco Jerez <currojerez@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20220414192230.749771-4-matthew.d.roper@intel.com
Matt Roper [Thu, 14 Apr 2022 19:22:28 +0000 (12:22 -0700)]
drm/i915/doc: Convert perf UAPI comments to kerneldoc
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.
Matt Roper [Thu, 14 Apr 2022 19:22:27 +0000 (12:22 -0700)]
drm/i915/doc: Convert drm_i915_query_topology_info comment to kerneldoc
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.
John Harrison [Tue, 12 Apr 2022 22:59:55 +0000 (15:59 -0700)]
drm/i915/guc: Update to GuC version 70.1.1
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.
Ramalingam C [Tue, 5 Apr 2022 15:08:40 +0000 (20:38 +0530)]
drm/i915/migrate: Evict and restore the flatccs capable lmem obj
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
Ramalingam C [Tue, 5 Apr 2022 15:08:39 +0000 (20:38 +0530)]
drm/i915/gem: Add extra pages in ttm_tt for ccs data
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]
Ramalingam C [Tue, 5 Apr 2022 15:08:36 +0000 (20:38 +0530)]
drm/i915/gt: Clear compress metadata for Flat-ccs objects
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]
Dave Airlie [Thu, 14 Apr 2022 02:03:08 +0000 (12:03 +1000)]
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)
Ville Syrjälä [Tue, 15 Mar 2022 14:00:00 +0000 (16:00 +0200)]
drm/i915/fbc: Introduce intel_fbc_sanitize()
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.
Ville Syrjälä [Tue, 15 Mar 2022 13:59:59 +0000 (15:59 +0200)]
drm/i915/fbc: Remove intel_fbc_global_disable()
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.
Ville Syrjälä [Tue, 15 Mar 2022 13:59:57 +0000 (15:59 +0200)]
drm/i915/fbc: Skip nuke when flip is pending
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.
Ville Syrjälä [Tue, 15 Mar 2022 13:59:55 +0000 (15:59 +0200)]
drm/i915/fbc: Eliminate possible_framebuffer_bits
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.
Manasi Navare [Thu, 3 Mar 2022 23:32:22 +0000 (15:32 -0800)]
drm/i915/display/vrr: Reset VRR capable property on a long hpd
With some VRR panels, user can turn VRR ON/OFF on the fly from the panel settings.
When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA bit
in the DPCD. Currently the driver parses that onevery HPD but fails to reset
the corresponding VRR Capable Connector property.
Hence the userspace still sees this as VRR Capable panel which is incorrect.
Fix this by explicitly resetting the connector property.
v2: Reset vrr capable if status == connector_disconnected
v3: Use i915 and use bool vrr_capable (Jani Nikula)
v4: Move vrr_capable to after update modes call (Jani N)
Remove the redundant comment (Jan N)
v5: Fixes the regression on older platforms by resetting the VRR
only if HAS_VRR
v6: Remove the checks from driver, add in drm core before
setting VRR prop (Ville)
v7: Move VRR set/reset to set/unset_edid (Ville)
Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: f10fa7204344 ("drm/i915/display/vrr: Reset VRR capable property on a long hpd") Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220303233222.4698-1-manasi.d.navare@intel.com
drm/i915/dg2: Add support for DG2 clear color compression
Add support for the DG2 specific render compression with clear color
framebuffer format.
DG2 onwards discrete gfx has support for new flat CCS mapping,
which brings in display feature in to avoid Aux walk for compressed
surface. This support build on top of Flat CCS support added in XEHPSDV.
FLAT CCS surface base address should be 64k aligned,
Compressed displayable surfaces must use tile4 format.
Mika Kahola [Mon, 11 Apr 2022 14:34:04 +0000 (17:34 +0300)]
drm/fourcc: Introduce format modifier for DG2 clear color
DG2 clear color render compression uses Tile4 layout. Therefore, we need
to define a new format modifier for uAPI to support clear color rendering.
v2:
Display version is fixed. [Imre]
KDoc is enhanced for cc modifier. [Nanley & Lionel]
v3:
Split out the modifier addition to a separate patch.
Clarify the modifier layout description.
Matt Roper [Mon, 11 Apr 2022 14:34:03 +0000 (17:34 +0300)]
drm/i915/dg2: Add support for DG2 render and media compression
Add support for DG2 render and media compression, for the description of
buffer layouts see the previous patch adding the corresponding
frame buffer modifiers.
v2:
Display version fix [Imre]
v3:
Split out modifier addition to separate patch.
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by: Mika Kahola <mika.kahola@intel.com>
cc: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Signed-off-by: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220411143405.1073845-3-imre.deak@intel.com
Matt Roper [Mon, 11 Apr 2022 14:34:02 +0000 (17:34 +0300)]
drm/fourcc: Introduce format modifiers for DG2 render and media compression
The render/media engines on DG2 unify render compression and media
compression into a single format for the first time, using the Tile 4
layout for main surfaces. The compression algorithm is different from
any previous platform and the display engine must still be configured to
decompress either a render or media compressed surface; as such, we
need new RC and MC framebuffer modifiers to represent buffers in this
format.
Dave Airlie [Tue, 12 Apr 2022 07:39:45 +0000 (17:39 +1000)]
Merge tag 'drm-misc-next-2022-04-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.19:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- atomic: Add atomic_print_state to private objects
- edid: Constify the EDID parsing API, rework of the API
- dma-buf: Add dma_resv_replace_fences, dma_resv_get_singleton, make
dma_resv_excl_fence private
- format: Support monochrome formats
- fbdev: fixes for cfb_imageblit and sys_imageblit, pagelist
corruption fix
- selftests: several small fixes
- ttm: Rework bulk move handling
Driver Changes:
- Switch all relevant drivers to drm_mode_copy or drm_mode_duplicate
- bridge: conversions to devm_drm_of_get_bridge and panel_bridge,
autosuspend for analogix_dp, audio support for it66121, DSI to DPI
support for tc358767, PLL fixes and I2C support for icn6211
- bridge_connector: Enable HPD if supported
- etnaviv: fencing improvements
- gma500: GEM and GTT improvements, connector handling fixes
- komeda: switch to plane reset helper
- mediatek: MIPI DSI improvements
- omapdrm: GEM improvements
- panel: DT bindings fixes for st7735r, few fixes for ssd130x, new
panels: ltk035c5444t, B133UAN01, NV3052C
- qxl: Allow to run on arm64
- sysfb: Kconfig rework, support for VESA graphic mode selection
- vc4: Add a tracepoint for CL submissions, HDMI YUV output,
HDMI and clock improvements
- virtio: Remove restriction of non-zero blob_flags,
- vmwgfx: support for CursorMob and CursorBypass 4, various
improvements and small fixes
Ville Syrjälä [Tue, 5 Apr 2022 17:33:54 +0000 (20:33 +0300)]
drm/i915/bios: Validate the panel_name table
In addition to the fp_timing,dvo_timing,panel_pnp_id tables
there also exists a panel_name table. Unlike the others this
is just one offset+table_size even though there are still 16
actual panel_names in the data block.
The panel_name table made its first appearance somewhere
around VBT version 156-163. The exact version is not known.
But we don't need to know that since we can just check whether
the pointers block has enough room for it or not.
Ville Syrjälä [Tue, 5 Apr 2022 17:33:51 +0000 (20:33 +0300)]
drm/i915/bios: Use the copy of the LFP data table always
Currently get_lvds_fp_timing() still returns a pointer to the original
data block rather than our copy. Let's convert the data pointer offsets
to be relative to the data block rather than the whole BDB. With that
we can make get_lvds_fp_timing() return a pointer to the copy.
Ville Syrjälä [Wed, 6 Apr 2022 13:38:17 +0000 (16:38 +0300)]
drm/i915/bios: Make copies of VBT data blocks
Make a copy of each VBT data block with a guaranteed minimum
size. The extra (if any) will just be left zeroed.
This means we don't have to worry about going out of bounds
when accessing any of the structure members. Otherwise that
could easliy happen if we simply get the version check wrong,
or if the VBT is broken/malicious.
v2: Don't do arithmetic between bdb header and copy
of the LFP data block (Jani)
v3: Make all the copies up front
v4: Only WARN about min_size==0 if we found the block
Ville Syrjälä [Tue, 5 Apr 2022 17:33:49 +0000 (20:33 +0300)]
drm/i915/bios: Use the cached BDB version
We have the BDB version cached, use it. We're going to have to
start doing some of the BDB block parsing later, at which point
we may no longer have the VBT around anymore (we free it at the
end of intel_bios_init() when it didn't come via OpRegion).
Lucas De Marchi [Sun, 10 Apr 2022 06:15:36 +0000 (23:15 -0700)]
drm/i915/dg2: Do not explode on phy calibration error
When the PHY fails on calibration we were previously skipping the ddi
initialization. However the driver is not really prepared for that,
ultimately leading to a NULL pointer dereference:
[ 75.748348] i915 0000:03:00.0: [drm:intel_modeset_init_nogem [i915]] SNPS PHY A failed to calibrate; output will not be used.
...
[ 75.750336] i915 0000:03:00.0: [drm:intel_modeset_setup_hw_state [i915]] [CRTC:80:pipe A] hw state readout: enabled
...
We skip the initialization of PHY A, but later we try to find out what
is the phy for that power well and dereference dig_port, which is NULL.
Failing the PHY calibration could be left as a warning or error, like it
was before commit bde9210c231d ("drm/i915/dg2: Skip output init on PHY
calibration failure"). However that often fails for outputs not being
used, which would make the warning/error appear on systems that have no
visible issues. Anyway, there is still a need to fix those failures,
but that is left for later.
drm/i915: Swap ret and status returned from skl_pcode_request
If ret isn't zero, it is almost for sure ETIMEDOUT, because
we use it in wait_for macro which does continuous retries
until timeout is reached. If we still ran out of time and
retries, we most likely would be interested in getting status,
to understand what was the actual error propagated from PCode,
rather than to find out that we had a time out, which is anyway
quite obvious, if the function fails.
v2: Make it status ? status : ret(thanks Vinod for the hint)
Currently skl_pcode_try_request function doesn't
properly handle return value it gets from
snb_pcode_rw, but treats status != 0 as success,
returning true, which basically doesn't allow
to use retry/timeout mechanisms if PCode happens
to be busy and returns EGAIN or some other status
code not equal to 0.
We saw this on real hw and also tried simulating this
by always returning -EAGAIN from snb_pcode_rw for 6 times, which
currently will just result in false success, while it should
have tried until timeout is reached:
We see en error because higher level api, still notices that status was wrong,
however we still did try only once.
We fix it by requiring _both_ the status to be 0 and
request/reply match for success(true) and function
should return failure(false) if either status turns
out to be EAGAIN, EBUSY or whatever or reply/request
masks do not match.
Merge tag 'tty-5.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty
Pull serial driver fix from Greg KH:
"This is a single serial driver fix for a build issue that showed up
due to changes that came in through the tty tree in 5.18-rc1 that were
missed previously. It resolves a build error with the mpc52xx_uart
driver.
It has been in linux-next this week with no reported problems"
* tag 'tty-5.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
tty: serial: mpc52xx_uart: make rx/tx hooks return unsigned, part II.
Merge tag 'staging-5.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fix from Greg KH:
"Here is a single staging driver fix for 5.18-rc2 that resolves an
endian issue for the r8188eu driver. It has been in linux-next all
this week with no reported problems"
* tag 'staging-5.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
staging: r8188eu: Fix PPPoE tag insertion on little endian systems
Merge tag 'driver-core-5.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core
Pull driver core updates from Greg KH:
"Here are two small driver core changes for 5.18-rc2.
They are the final bits in the removal of the default_attrs field in
struct kobj_type. I had to wait until after 5.18-rc1 for all of the
changes to do this came in through different development trees, and
then one new user snuck in. So this series has two changes:
- removal of the default_attrs field in the powerpc/pseries/vas code.
The change has been acked by the PPC maintainers to come through
this tree
- removal of default_attrs from struct kobj_type now that all
in-kernel users are removed.
This cleans up the kobject code a little bit and removes some
duplicated functionality that confused people (now there is only
one way to do default groups)
Both of these have been in linux-next for all of this week with no
reported problems"
* tag 'driver-core-5.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
kobject: kobj_type: remove default_attrs
powerpc/pseries/vas: use default_groups in kobj_type
Merge tag 'char-misc-5.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fix from Greg KH:
"A single driver fix. It resolves the build warning issue on 32bit
systems in the habannalabs driver that came in during the 5.18-rc1
merge cycle.
It has been in linux-next for all this week with no reported problems"
* tag 'char-misc-5.18-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
habanalabs: Fix test build failures
Merge tag 'powerpc-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
Pull powerpc fixes from Michael Ellerman:
- Fix KVM "lost kick" race, where an attempt to pull a vcpu out of the
guest could be lost (or delayed until the next guest exit).
- Disable SCV (system call vectored) when PR KVM guests could be run.
- Fix KVM PR guests using SCV, by disallowing AIL != 0 for KVM PR
guests.
- Add a new KVM CAP to indicate if AIL == 3 is supported.
- Fix a regression when hotplugging a CPU to a memoryless/cpuless node.
- Make virt_addr_valid() stricter for 64-bit Book3E & 32-bit, which
fixes crashes seen due to hardened usercopy.
- Revert a change to max_mapnr which broke HIGHMEM.
Thanks to Christophe Leroy, Fabiano Rosas, Kefeng Wang, Nicholas Piggin,
and Srikar Dronamraju.
* tag 'powerpc-5.18-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
Revert "powerpc: Set max_mapnr correctly"
powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit
KVM: PPC: Move kvmhv_on_pseries() into kvm_ppc.h
powerpc/numa: Handle partially initialized numa nodes
powerpc/64: Fix build failure with allyesconfig in book3s_64_entry.S
KVM: PPC: Use KVM_CAP_PPC_AIL_MODE_3
KVM: PPC: Book3S PR: Disallow AIL != 0
KVM: PPC: Book3S PR: Disable SCV when AIL could be disabled
KVM: PPC: Book3S HV P9: Fix "lost kick" race
projects / kernel.git / log