Add support for 420xx devices by including a new device driver that
supports such devices, updates to the firmware loader and capabilities.
Compared to 4xxx devices, 420xx devices have more acceleration engines
(16 service engines and 1 admin) and support the wireless cipher
algorithms ZUC and Snow 3G.
Signed-off-by: Jie Wang <jie.wang@intel.com>
Co-developed-by: Dong Xie <dong.xie@intel.com>
Signed-off-by: Dong Xie <dong.xie@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Relocate the structures adf_fw_objs and adf_fw_config from the file
adf_4xxx_hw_data.c to the newly created adf_fw_config.h.
These structures will be used by new device drivers.
This does not introduce any functional change.
Signed-off-by: Jie Wang <jie.wang@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Move logic that is common between QAT GEN4 accelerators to the
qat_common folder. This includes addresses of CSRs, setters and
configuration logic.
When moved, functions and defines have been renamed from 4XXX to GEN4.
Code specific to the device is moved to the file adf_gen4_hw_data.c.
Code related to configuration is moved to the newly created
adf_gen4_config.c.
This does not introduce any functional change.
Signed-off-by: Jie Wang <jie.wang@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add accel_dev as parameter of the function uof_get_num_objs().
This is in preparation for the introduction of the QAT 420xx driver as
it will allow to reconfigure the ae_mask when a configuration that does
not require all AEs is loaded on the device.
This does not introduce any functional change.
Signed-off-by: Jie Wang <jie.wang@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Move the function get_service_enabled() from adf_4xxx_hw_data.c to
adf_cfg_services.c and rename it as adf_get_service_enabled().
This function is not specific to the 4xxx and will be used by
other QAT drivers.
This does not introduce any functional change.
Signed-off-by: Jie Wang <jie.wang@intel.com>
Reviewed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Document the crypto engine on the SM7280 Platform.
Signed-off-by: Om Prakash Singh <quic_omprsing@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
When the mpi_ec_ctx structure is initialized, some fields are not
cleared, causing a crash when referencing the field when the
structure was released. Initially, this issue was ignored because
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
For example, this error will be triggered when calculating the
Za value for SM2 separately.
Fixes: d58bb7e55a ("lib/mpi: Introduce ec implementation to MPI library")
Cc: stable@vger.kernel.org # v6.5
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
All devices compatible with SM8150 QCE (so SM8250 and newer) do not have
clock inputs (clocks are handled by secure firmware), so explicitly
disallow the clocks in the bindings.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Binding marks several devices as compatible with IPQ4019 QCE. They have
different number of clocks, thus the fallback does not define the
clock constraints per variant and each specific compatible should have
its clocks in if:then: section.
Add missing clocks description for IPQ9574 QCE.
Fixes: 1f5ce01d5d ("dt-bindings: crypto: qcom-qce: add SoC compatible string for ipq9574")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Define SET_RUNTIME_PM_OPS for StarFive TRNG driver.
Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Add compatible string for StarFive JH8100 trng.
Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
The scheduled tasklet needs to be executed on device remove.
Fixes: fed93fb62e ("crypto: virtio - Handle dataq logic with tasklet")
Signed-off-by: wangyangxin <wangyangxin1@huawei.com>
Signed-off-by: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
drm/i915 fixes for v6.7-rc7:
- Fix state readout and check for DSC and bigjoiner combo
- Fix a potential integer overflow
- Reject async flips with bigjoiner
- Fix MTL HDMI/DP PLL clock selection
- Fix various issues by disabling pipe DMC events
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/87plyzsnxi.fsf@intel.com
Add a dependency on CONFIG_64BIT since currently the xe driver doesn't
build on 32bits. It may be enabled again after all the issues are fixed.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20231221222809.4123220-2-lucas.demarchi@intel.com
Xe, is a new driver for Intel GPUs that supports both integrated and
discrete platforms. The experimental support starts with Tiger Lake.
i915 will continue be the main production driver for the platforms
up to Meteor Lake and Alchemist. Then the goal is to make this Intel
Xe driver the primary driver for Lunar Lake and newer platforms.
It uses most, if not all, of the key drm concepts, in special: TTM,
drm-scheduler, drm-exec, drm-gpuvm/gpuva and others.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEbSBwaO7dZQkcLOKj+mJfZA7rE8oFAmWErlkACgkQ+mJfZA7r
E8ptAQf/UILUy63usqMBQx5gGTJ5e6oyGy0r97JdBBWNxhcu3/4uN1SR6V2LSV7p
mnZt/LrHZ/24s73e5D7sh909GCYm/MMWH7v0KypJq5Z74BHb9IePP7+Q4NTfXfqS
5AotYxDEwPBQZpfYLA7y17XrB01yz/gF8wHytBFTPiPOlve7BDAYw4j8o+ocztxy
sLLwPi7A6RJJlpXaDa33DpH5MLpTVYUOuxaIElqu949AJj/Me+LHd26VfoGWt9YT
AWzAm+LLoBhyE5lk9swWxvphGvNoOuKf8soTMEVXr4qxsR6d4LShkrljSYSbtRhl
2QZMgvSL4pGkB3Yvfxb0hidWuVMNfA==
=bubx
-----END PGP SIGNATURE-----
Merge tag 'drm-xe-next-2023-12-21-pr1-1' of https://gitlab.freedesktop.org/drm/xe/kernel into drm-next
Introduce a new DRM driver for Intel GPUs
Xe, is a new driver for Intel GPUs that supports both integrated and
discrete platforms. The experimental support starts with Tiger Lake.
i915 will continue be the main production driver for the platforms
up to Meteor Lake and Alchemist. Then the goal is to make this Intel
Xe driver the primary driver for Lunar Lake and newer platforms.
It uses most, if not all, of the key drm concepts, in special: TTM,
drm-scheduler, drm-exec, drm-gpuvm/gpuva and others.
Signed-off-by: Dave Airlie <airlied@redhat.com>
[airlied: add an extra X86 check, fix a typo, fix drm_exec_init interface
change].
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ZYSwLgXZUZ57qGPQ@intel.com
- Ignore disabled device tree nodes in the Starfive 7100 and
7100 drivers.
- Mask non-wake source pins with interrupt enabled at suspend
in the AMD driver, this blocks unnecessary wakeups from misc
interrupts. This can be power consuming because in many cases
the system doesn't really suspend, it just wakes right back
up.
- Fix a typo breaking compilation of the cy8c95x0 driver, and
fix up bugs in the get/set config callbacks.
- Use a dedicated lock class for the PIO4 drivers IRQ.
This fixes a crash on suspend.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmWEv9gACgkQQRCzN7AZ
XXPDxA/+M/gXlbck8v3YJCa3/u59CPJtl23K27daGFLvuqAf1V+ZOxqq7UinHDRW
OXlCgefX74NRMYkfS1FS9wZfHqdt8j9xX7OEbnst/1Q7DwNDKjry9Ax/yebZ+VEn
B6JxiWpAevdR1vPvt+5FvM/kCChav2p0BoMm4OnCVLAmWYOhr+rx36oKtfuOLoYx
TCxYo7CNkaaTrEWMStAv5VDudddCHjryOqnLHulIy62FQ8u7BJI8NtvTbna3cJD9
yrI2qBqvPFAAPANfsNikUPghyXUluqbRAPKyqNSBH6c5e2dbeRF4mNP16dawYOMF
KM7qykob03IhcPOmYEjKTJZ2b8g3w2WFY/U/zw/cE1IXPqW+DMBz/C+jL2L5bRGc
H3Xc3g/QVj4cdaNMOmKT4jtp1OOgkRwUiWh7ryoospb1ZuRL2nM9RQbnIx8Y//OP
CRaDJ/SKLelf18JSiMeD+qX1mmjpBiTTQpAq++B4sr1StNzcJOTK9mx7zJG6YTDL
WuKK809Dta1EXQtYFiKM8Qf5wYCXeID2D0xkn6lFumQ5RmywPiqJ38kfSww2poRh
R0qEQEFaWTHEAWFn7G5m/RYKRQuoHiTTohUgWJj1FzAZeEOyXHUD3lRCwxfdmHRR
pUQs0yoqPcoRlxrc9QHdIoNyNknRN2iO3Mg9yrgsvyunjPwl1Ns=
=eKv/
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v6.7-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Some driver fixes for v6.7, all are in drivers, the most interesting
one is probably the AMD laptop suspend bug which really needs fixing.
Freedestop org has the bug description:
https://gitlab.freedesktop.org/drm/amd/-/issues/2812
Summary:
- Ignore disabled device tree nodes in the Starfive 7100 and 7100
drivers.
- Mask non-wake source pins with interrupt enabled at suspend in the
AMD driver, this blocks unnecessary wakeups from misc interrupts.
This can be power consuming because in many cases the system
doesn't really suspend, it just wakes right back up.
- Fix a typo breaking compilation of the cy8c95x0 driver, and fix up
bugs in the get/set config callbacks.
- Use a dedicated lock class for the PIO4 drivers IRQ. This fixes a
crash on suspend"
* tag 'pinctrl-v6.7-4' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: at91-pio4: use dedicated lock class for IRQ
pinctrl: cy8c95x0: Fix get_pincfg
pinctrl: cy8c95x0: Fix regression
pinctrl: cy8c95x0: Fix typo
pinctrl: amd: Mask non-wake source pins with interrupt enabled at suspend
pinctrl: starfive: jh7100: ignore disabled device tree nodes
pinctrl: starfive: jh7110: ignore disabled device tree nodes
A freezable kernel thread can enter frozen state during freezing by
either calling try_to_freeze() or using wait_event_freezable() and its
variants. So for the following snippet of code in a kernel thread loop:
try_to_freeze();
wait_event_interruptible_timeout();
We can change it to a simple wait_event_freezable_timeout() and then
eliminate a function call.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
The kernel thread function gfs2_logd() and gfs2_quotad() invoke the
try_to_freeze() in its loop. But all the kernel threads are no-freezable
by default. So if we want to make a kernel thread to be freezable,
we have to invoke set_freezable() explicitly.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
'rustup override' is required to be set for the build directory and not
necessarily the kernel source tree (unless the build directory is its
subdir).
Clarify the same in the Quick Start guide.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Originally-pointed-out-by: Masahiro Yamada <masahiroy@kernel.org>
Link: f2238e7
Link: https://lore.kernel.org/r/e2b943eca92abebbf035447b3569f09a7176c770.1702366951.git.viresh.kumar@linaro.org
[ Reworded and fixed quotes for `--path` and `set`. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Searching the Rust kernel documentation all existing Rust Make
targets (rustavailable, rustfmt, rustfmtcheck, rustdoc and
rust-analyzer) are explicitly documented with their Make commands.
While the Make target rusttest is mentioned two times in the
existing documentation, it's Make command is not explicitly
documented, yet. Add a test section to document this.
While at it, add some info about the more important KUnit testing
too.
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Link: https://lore.kernel.org/r/20231212081313.226120-1-dirk.behme@de.bosch.com
[ Added "the", newline and quotes for `.config`. Expanded "repos". ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Nowadays all architectures except s390 recommend using `LLVM=1` instead of
`CC=clang`, and since commit a3c6bfba44 ("Documentation/llvm: refresh
docs") the Kbuild LLVM documentation makes `LLVM=1` the way to go:
We want to encourage the use of ``LLVM=1`` rather than just
``CC=clang``. Make that suggestion "above the fold" and "front and
center" in our docs.
In particular, that commit removes the examples with `CC=clang`.
Thus do the same in the Rust Quick Start guide, i.e. remove the `CC=clang`
mentions, especially since the architectures that have had their Rust
support upstreamed (or soon to be upstreamed) are all `LLVM=1` ones.
And perhaps by the time Rust is supported for s390 (or new architectures),
it may have moved to `LLVM=1` anyway. Otherwise, this can be added back
if needed (or perhaps an extra link to Documentation/kbuild/llvm.rst).
This should also help avoiding potential confusion around `CC=clang` [1].
Link: https://lore.kernel.org/rust-for-linux/6df6e8e5-8d5b-4d3d-91b5-bc0e90c424ea@nvidia.com/ [1]
Reviewed-by: Ariel Miculas <amiculas@cisco.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Benno Lossin <benno.lossin@proton.me>
Reviewed-by: Justin Stitt <justinstitt@google.com>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Martin Rodriguez Reboredo <yakoyoku@gmail.com>
Link: https://lore.kernel.org/r/20231215124751.175191-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Although it does not seem to have any untoward side-effects, the use
of ';' to separate to assignments seems more appropriate than ','.
Flagged by clang-17 -Wcomma
No functional change intended. Compile tested only.
Signed-off-by: Simon Horman <horms@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Dave Marchevsky <davemarchevsky@fb.com>
Link: https://lore.kernel.org/bpf/20231221-bpf-verifier-comma-v1-1-cde2530912e9@kernel.org
We're currently sending non-blocking H2G messages using the EVENT type,
which suppresses all CTB protocol replies from the GuC, including the
failure cases. This might cause errors to slip through and manifest as
unexpected behavior (e.g. a context state might not be what the driver
thinks it is because the state change command was silently rejected by
the GuC). To avoid this kind of problems, we can use the FAST_REQUEST
type instead, which suppresses the reply only on success; this way we
still get the advantage of not having to wait for an ack from the GuC
(i.e. the H2G is still non-blocking) while still detecting errors.
Since we can't escalate to the caller when a non-blocking message
fails, we need to escalate to GT reset instead.
Note that FAST_REQUEST failures are NOT expected and are usually a sign
that the H2G was either malformed or requested an illegal operation.
v2: assign fence values to FAST_REQUEST messages, fix abi doc, use xe_gt
printers (Michal).
v3: fix doc alignment, fix and improve prints (Michal)
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>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com> #v2
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Wa_14019877138 is also needed for xe_lpg graphics 12.70/71
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
Add few tests to make sure that basic usage scenarios of the GuC
Doorbells Manager are implemented correctly.
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://lore.kernel.org/r/20231218190629.502-11-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Tests might use locking, better to have LOCKDEP enabled.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20231218190629.502-10-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Replace drm_kunit_helper_alloc_drm_device with xe helper.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20231218190629.502-8-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Current KUnit implementation does not reset test->priv in case of
parametrized tests and that may lead to wrongly treat our output
pointer to fake xe_device from first call as input pointer with
xe_pci_fake_data on subsequent calls. Restore test->priv to
original value to avoid invalid access.
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20231218190629.502-7-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
There will be more KUnit tests added that will require fake device.
Define generic helper functions to avoid code duplications.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20231218190629.502-6-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
We want to add code that will check the driver's SR-IOV mode.
Update xe_pci_fake_device_init() and struct xe_pci_fake_data to
either explicitly specify desired SR-IOV mode of the fake device
or fallback to the default bare-metal mode.
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20231218190629.502-5-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
The GFX doorbell solution provides a mechanism for submission of
workload to the graphics hardware by a ring3 application without
the penalty of ring transition for each workload submission.
This feature is not currently used by the Linux drivers, but in
SR-IOV mode the doorbells are treated as shared resource and the
PF driver must be able to provision exclusive range of doorbells
IDs across all enabled VFs.
Introduce simple GuC doorbell ID manager that will be used by the
PF driver for VFs provisioning and can later be used by submission
code once we are ready to switch from H2G based notifications to
doorbells mechanism.
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Piotr Piórkowski <piotr.piorkowski@intel.com>
Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Link: https://lore.kernel.org/r/20231218190629.502-4-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
We track TLB invalidation seqno per GT and we have GT oriented
message helpers, so it's better to use GT oriented log functions.
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20231218190629.502-3-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Instead of using generic drm_err_printer() that just adds static
prefix, or drm_info_printer() that outputs only device name, add
new helpers that create dedicated drm_printers that use our GT
oriented xe_gt_err() and xe_gt_info() functions.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://lore.kernel.org/r/20231218190629.502-2-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
There are small differences in handling of the register based
interrupts on the VF driver as some registers are not accessible
to the VF driver. Additionally VFs must support Memory Based
Interrupts. Add VF specific interrupt handler for this.
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20231214185955.1791-11-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
When Memory Based Interrupts are used, the VF driver must provide
to the GuC references to the Source and Status Report Pages.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20231214185955.1791-10-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
When Memory Based Interrupts are used, the VF driver must provide
in the LRC the references to the Source and Status Report Pages.
Update the LRC according to the requirements.
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20231214185955.1791-9-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
The register based interrupts infrastructure does not scale
efficiently to allow delivering interrupts to a large number
of virtual machines. Memory based interrupt reporting provides
an efficient and scalable infrastructure.
Define handler to read and dispatch memory based interrupts.
We will use this handler in upcoming patch.
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20231214185955.1791-8-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
When we map BO in GGTT, then by default we are using PAT index
that corresponds to XE_CACHE_WB but ppcoming feature will require
use of the PAT index of the XE_CACHE_UC. Define new BO flag that
could be used during BO creation to force alternate caching.
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20231214185955.1791-7-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
When interrupts are delivered using memory based mechanism, engines
will write status to the report page at the offset (in bytes) that
corresponds to their interrupt bit from the GT_INTR_DW register.
Add engine interrupt offset definitions to engine info as we will
need this to process memory based interrupts.
Bspec: 46149, 50829, 50844
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20231214185955.1791-6-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
The new memory based interrupt processing uses additional entries
in the context. Add required definitions.
Bspec: 45585, 60184
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20231214185955.1791-4-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
The RING_INT_SRC_RPT_PTR register points to a cacheline in memory
to which an engine must report as source of interrupt prior to
generating an interrupt to the host.
The RING_INT_STATUS_RPT_PTR register points to the first cacheline
of the Interrupt Status Report (ISR) page (4KB) in graphics memory
to which all engines report their interrupt status.
The RING_IMR register has the interrupt enables and interrupt masks
for an engine.
We will refer to these registers shortly.
Bspec: 45963, 45964, 45965
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20231214185955.1791-3-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
We will need this shortly during context state preparation.
Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://lore.kernel.org/r/20231214185955.1791-2-michal.wajdeczko@intel.com
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
