An error occurred fetching the project authors.
- 21 Dec, 2023 27 commits
-
-
Daniele Ceraolo Spurio authored
As part of the FW definitions, we declare each blob as required via the MODULE_FIRMWARE() macro. This causes the initramfs update (or equivalent process) to look for the blobs on disk when the kernel is installed; therefore, we need to make sure that all FWs we define are available in linux-firmware. We currently don't plan to push the PVC blob to linux-firmware, while the LNL one will only be pushed once we have machines in CI to test it, so we need to remove them from the list for now. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
HuC authentication via GSC is performed by submitting the appropriate PXP packet to the GSC FW. This packet can trigger a "pending" reply from the FW, so we need to handle that and resubmit. Note that the auth via GSC can only be performed if the HuC has already been authenticated by the GuC. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Reviewed-by:
Vivaik Balasubrawmanian <vivaik.balasubrawmanian@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Michał Winiarski authored
The firmware loading for GuC is about to be moved, and will happen much earlier in the probe process, when local-memory is not yet available. While this has the potential to make the firmware loading process slower, this is only happening during probe and full device reset. Since both are not hot-paths - store all UC-like firmware in system memory. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Michał Winiarski authored
The function does a driver specific "request firmware" step that includes validating the input, followed by wrapping the firmware binary into a buffer object. Split it into smaller parts. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Michał Winiarski authored
A helper for managed BO allocations makes it possible to remove specific "fini" actions and will simplify the following patches adding ability to execute a release action for specific BO directly. Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Fei Yang authored
Confirmed with hardware that setting GGTT memory access for GuC firmware loading is correct for all platforms and required for new platforms going forward. Signed-off-by:
Fei Yang <fei.yang@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20231122204501.1353325-2-fei.yang@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
We track GSC FW based on its compatibility version, which is what determines the interface it supports. Also add a modparam override like the ones for GuC and HuC. v2: fix module param description (John) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
The version is obtained via a dedicated MKHI GSC HECI command. The compatibility version is what we want to match against for the GSC, so we need to call the FW version checker after obtaining the version. Since this is the first time we send a GSC HECI command via the GSCCS, this patch also introduces common infrastructure to send such commands to the GSC. Communication with the GSC FW is done via input/output buffers, whose addresses are provided via a GSCCS command. The buffers contain a generic header and a client-specific packet (e.g. PXP, HDCP); the clients don't care about the header format and/or the GSCCS command in the batch, they only care about their client-specific header. This patch therefore introduces helpers that allow the callers to automatically fill in the input header, submit the GSCCS job and decode the output header, to make it so that the caller only needs to worry about their client-specific input and output messages. v3: squash of 2 separate patches ahead of merge, so that the common functions and their first user are added at the same time Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.Com> #v1 Reviewed-by:
Suraj Kandpal <suraj.kandpal@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
The GSC blob starts with a layout header, from which we can move to the boot directory, which in turns allows us to find the CPD. The CPD uses the same format as the one in the HuC binary, so we can re-use the same parsing code to get to the manifest, which contains the release and security versions of the FW. v2: Fix comments in struct definition (John) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
Add the basic definitions and init function. Same as HuC, GSC is only supported on the media GT on MTL and newer platforms. Note that the GSC requires submission resources which can't be allocated during init (because we don't have the hwconfig yet), so it can't be marked as loadable at the end of the init function. The allocation of those resources will come in the patch that makes use of them to load the FW. v2: better comment, move num FWs define inside the enum (John) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
The GSC firmware, support for which is coming soon for Xe, has both a release version (updated on every release) and a compatibility version (update only on interface changes). The GuC has something similar, with a global release version and a submission version (which is also known as the VF compatibility version). The main difference is that for the GuC we still want to check the driver requirement against the release version, while for the GSC we'll need to check against the compatibility version. Instead of special casing the GSC, this patch reworks the FW logic so that we store both versions at the uc_fw level for all binaries and we allow checking against either of the versions. Initially, we'll use it to support GSC, but the logic could be re-used to allow VFs to check against the GuC compatibility version. Note that the GSC version has 4 numbers (major, minor, hotfix, build), so support for that has been added as part of the rework and will be used in follow-up patches. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Bommithi Sakeena authored
Encapsulate all the module parameters in one single global struct variable. This also removes the extra xe_module.h from includes. v2: naming consistency as suggested by Jani and Lucas v3: fix checkpatch errors/warnings v4: adding blank line after struct declaration Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Bommithi Sakeena <bommithi.sakeena@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
MTL uses a versionless GSC-enabled binary. v2: don't use the filename to identify the header type (Lucas) v3: fix commit msg (Lucas) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
The GSC-enabled HuC binary starts with a GSC header, which is followed by the legacy-style CSS header and the binary itself. We can parse the GSC headers to find the HuC version and the location of the binary to be used for the DMA transfer. The parsing function has been designed to be re-used for the GSC binary, so the entry names are external parameters (because the GSC uses different ones) and the CSS entry is optional (because the GSC doesn't have it). v2: move new code to uc_fw.c, better comments and error checking, split old code move to separate patch (Lucas), move headers and documentation to uc_fw_abi.h. v3: use 2 separate loops, rework marker check (Lucas) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
GSC binaries and newer HuC ones use GSC-style headers instead of the CSS. In preparation for adding support for such parsing, split out the current parsing code to its own function, to make it cleaner to add the new paths. The existing doc section has also been renamed to narrow it to CSS-based binaries. v2: new patch in series, split out from next patch for easier reviewing v3: drop unneeded include (Lucas) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
The PVC GuC version that we're currently using (70.6.4) has a known issue that leads to dropping the disabling of contexts that have pending page faults. This is fixed in newer blobs, so we need to update to a more recent release. Link: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/696Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
When testing a new binary and/or debugging binary-related issues, it is useful to have the option to change which binary is loaded without having to update and re-compile the kernel. To support this option, this patch adds 2 new modparams to override the FW path for GuC and HuC. The HuC modparam can also be set to an empty string to disable HuC loading. Note that those modparams only take effect on platforms where we already have a default FW, so we're sure there is support for FW loading and the kernel isn't going to explode in an undefined path. v2: simplify comment (John), rebase on s/guc_submission_enabled/uc_enabled Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
The current uC status tracking has a few issues: 1) the HuC is moved to "disabled" instead of "not supported" 2) the status is left uninitialized instead of "disabled" when the modparam is used to disable support 3) due to #1, a number of checks are done against "disabled" instead of the appropriate status. Address all of those by making sure to follow the appropriate state transition and checking against the required state. v2: rebase on s/guc_submission_enabled/uc_enabled/ Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
Newer HuC binaries for MTL (8.5.1+) require GuC 70.7 or newer, so we need to move on from 70.6.4. Given that the MTL GuC uses major-only version matching in i915, we can do the same here instead of just bumping the version (and having to push the versioned binaries, because they're not there already for i915). Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Francois Dugast authored
The XE_WARN_ON macro maps to WARN_ON which is not justified in many cases where only a simple debug check is needed. Replace the use of the XE_WARN_ON macro with the new xe_assert macros which relies on drm_*. This takes a struct drm_device argument, which is one of the main changes in this commit. The other main change is that the condition is reversed, as with XE_WARN_ON a message is displayed if the condition is true, whereas with xe_assert it is if the condition is false. v2: - Rebase - Keep WARN splats in xe_wopcm.c (Matt Roper) v3: - Rebase Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Zhanjun Dong authored
Add patch version info on GuC firmware init. This is required info for GuC log decoder. Signed-off-by:
Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://lore.kernel.org/r/20230817213028.838531-1-zhanjun.dong@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
Define the GuC firmware to load on the platform. Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Francois Dugast authored
Replace calls to XE_BUG_ON() with calls XE_WARN_ON() which in turn calls WARN() instead of BUG(). BUG() crashes the kernel and should only be used when it is absolutely unavoidable in case of catastrophic and unrecoverable failures, which is not the case here. Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Rodrigo Vivi authored
The order: 'offset, mask, val'; is more common in other drivers and in special in i915, where any dev could copy a sequence and end up with unexpected behavior. Done with coccinelle: @rule1@ expression gt, reg, val, mask, timeout, out, atomic; @@ - xe_mmio_wait32(gt, reg, val, mask, timeout, out, atomic) + xe_mmio_wait32(gt, reg, mask, val, timeout, out, atomic) spatch -sp_file mmio.cocci *.c *.h compat-i915-headers/intel_uncore.h \ --in-place v2: Rebased after changes on xe_guc_mcr usage of xe_mmio_wait32. Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Francois Dugast authored
Reduce the number of warnings reported by checkpatch.pl from 118 to 48 by addressing those warnings types: LEADING_SPACE LINE_SPACING BRACES TRAILING_SEMICOLON CONSTANT_COMPARISON BLOCK_COMMENT_STYLE RETURN_VOID ONE_SEMICOLON SUSPECT_CODE_INDENT LINE_CONTINUATIONS UNNECESSARY_ELSE UNSPECIFIED_INT UNNECESSARY_INT MISORDERED_TYPE Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Francois Dugast authored
Remove almost all existing style issues of type SPACING reported by checkpatch. Signed-off-by:
Francois Dugast <francois.dugast@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Daniele Ceraolo Spurio authored
The firmware definitions must be ordered based on platform, from newer to older, which means that the DG1 FW must come before the ADL one. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/8699Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20230627222856.3165647-1-daniele.ceraolospurio@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
- 19 Dec, 2023 13 commits
-
-
Matt Roper authored
Since memory and address spaces are a tile concept rather than a GT concept, we need to plumb tile-based handling through lots of memory-related code. Note that one remaining shortcoming here that will need to be addressed before media GT support can be re-enabled is that although the address space is shared between a tile's GTs, each GT caches the PTEs independently in their own TLB and thus TLB invalidation should be handled at the GT level. v2: - Fix kunit test build. Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230601215244.678611-13-matthew.d.roper@intel.comSigned-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
Alderlake P uses TGL HuC and it was not added together with ADL-S, because it was failing for unrelated reasons. Now that those are fixed, allow it to load HuC. # cat /sys/kernel/debug/dri/0/gt0/uc/huc_info HuC firmware: i915/tgl_huc.bin status: RUNNING version: wanted 0.0, found 7.9 uCode: 589504 bytes RSA: 256 bytes HuC status: 0x00090001 Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://lore.kernel.org/r/20230512233649.3218736-1-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Matt Roper authored
ADL-N is pretty much the same as ADL-P (i.e., Xe_LP graphics + Xe_M media + Xe_LPD display). However unlike ADL-P, there's no GuC hwconfig support so the "tgl" GuC firmware should be loaded (i.e., the same situation as ADL-S). Acked-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Ravi Kumar Vodapalli <ravi.kumar.vodapalli@intel.com> Link: https://lore.kernel.org/r/20230419213703.3993439-2-matthew.d.roper@intel.comSigned-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
Convert all the callers to deal with xe_mmio_*() using struct xe_reg instead of plain u32. In a few places there was also a rename s/reg/reg_val/ when dealing with the value returned so it doesn't get mixed up with the register address. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://lore.kernel.org/r/20230508225322.2692066-2-lucas.demarchi@intel.comSigned-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
There's no good reason to keep the GuC registers outside the regs/ directory: move the header with GuC registers under that. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Anusha Srivatsa authored
Rocketlake uses TGL GuC and HuC Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
When debugging issues related to GuC/HuC, it's important to know what is the firmware version being used. The version from the filename can't be relied upon, also because it normally only contains the major version (except for the ones under experimental support). Log the version from the blob after reading the CSS header. Example: xe 0000:03:00.0: [drm] Using GuC firmware (70.5) from i915/dg2_guc_70.bin Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matthew Brost <matthew.brost@intel.com> Link: https://lore.kernel.org/r/20230405224725.1993719-1-lucas.demarchi@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
Update the logic to autoselect GuC/HuC for the platforms with the following improvements: - Document what is the firmware file that is expected to be loaded and what is checked from blob headers - When the platform is under force-probe it's desired to enforce the full-version requirement so the correct firmware is used before widespread adoption and backward-compatibility commitments - Directory from which we expect firmware blobs to be available in upstream linux-firmware repository depends on the platform: for the ones supported by i915 it uses the i915/ directory, but the ones expected to be supported by xe, it's on the xe/ directory. This means that for platforms in the intersection, the firmware is loaded from a different directory, but that is not much important in the firmware repo and it avoids firmware duplication. - Make the table with the firmware definitions clearly state the versions being expected. Now with macros to select the version it's possible to choose between full-version/major-version for GuC and full-version/no-version for HuC. These are similar to the macros used in i915, but implemented in a slightly different way to avoid duplicating the macros for each firmware/type and functionality, besides adding the support for different directories. - There is no check added regarding force-probe since xe should reuse the same firmware files published for i915 for past platforms. This can be improved later with additional kunit checking against a hardcoded list of platforms that falls in this category. - As mentioned in the TODO, the major version fallback was not implemented before as currently each platform only supports one major. That can be easily added later. - GuC version for MTL and PVC were updated to 70.6.4, using the exact full version, while the After this the GuC firmware used by PVC changes to pvc_guc_70.5.2.bin since it's using a file not published yet. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://lore.kernel.org/r/20230324051754.1346390-4-lucas.demarchi@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
Platform order in enum xe_platform started to be used by some parts of the code, like the GuC/HuC firmware loading logic. The order itself is not very important, but it's better to follow a convention: as was documented in the comment above the enum, reorder the platforms by graphics version. While at it, remove the gen terminology. v2: - Use "graphics version" instead of chronological order (Matt Roper) - Also change pciidlist to follow the same order - Remove "gen" from comments around enum xe_platform Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230331230902.1603294-1-lucas.demarchi@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Lucas De Marchi authored
The rev field is always 0 so it ends up never used. In i915 it was introduced because of CML: up to rev 5 it reuses the guc and huc firmware blobs from KBL. After that there is a specific firmware for that platform. This can be reintroduced later if ever needed. With the removal of revid the packed attribute in uc_fw_platform_requirement, which is there only for reducing the space these tables take, can also be removed since it has even more limited usefulness: currently there's only padding of 2 bytes. Remove the attribute to avoid the unaligned access. $ pahole -C uc_fw_platform_requirement build64/drivers/gpu/drm/xe/xe_uc_fw.o struct uc_fw_platform_requirement { enum xe_platform p; /* 0 4 */ const struct uc_fw_blob blob; /* 4 10 */ /* size: 16, cachelines: 1, members: 2 */ /* padding: 2 */ /* last cacheline: 16 bytes */ }; Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://lore.kernel.org/r/20230324051754.1346390-2-lucas.demarchi@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Anusha Srivatsa authored
Alderlake S uses TGL HuC. Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230323224651.1187366-3-lucas.demarchi@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Anusha Srivatsa authored
Follow the new direction of firmware and add macro support for loading unversioned HuC. Keep HuC versioned loading support as well for platforms that fall under force_probe support Add check to ensure driver does not do any version check for HuC if going through unversioned load. v2: unversioned firmware to be the default for platforms not under force_probe. Maintain versioned firmware macro support for platforms under force-probe protection. v3: Minor style and naming adjustments (Lucas) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230323224651.1187366-2-lucas.demarchi@intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Mauro Carvalho Chehab authored
The GuC/HuC firmware files used by Xe drivers are the same as used by i915. Use the already-known location to find those firmware files, for a couple of reasons: 1. Avoid having the same firmware placed on two different places on MODULE_FIRMWARE(), if both 915 and xe drivers are compiled; 2. Having firmware files located on different locations may end creating bigger initramfs, as the same files will be copied twice my mkinitrd/dracut/...; 3. this is the place where those firmware files are located at https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git Upstream doesn't expect them to have on other places; 4. When built with display support, DMC firmware will be loaded from i915/ directory. It is very confusing to have some firmware files on a different place for the same driver. Cc: Matthew Brost <matthew.brost@intel.com> Cc: Lucas de Marchi <lucas.demarchi@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@gmail.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@kernel.org> [ Mostly agree with the direction of "use the firmware blobs from upstream at their current location for these platforms". Previous directory was not wrong as the plan was to have it handled in the upstream firmware repo. For future platforms the location can be changed if the support is only in xe ] Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20230310081338.3275583-1-mauro.chehab@linux.intel.comSigned-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-