On 10/1/2026 11:50 AM, Krzysztof Kozlowski wrote: > On Wed, Sep 30, 2026 at 07:52:11AM -0700, Georgi Djakov wrote: >> Add a platform driver for the Qualcomm Page Compression Engine (QPaCE), a >> hardware block that accelerates compression and decompression of memory >> pages. >> >> Provide the urgent command path for synchronous single-page compression and >> decompression. This exposes the low-latency operations needed by >> compressed-memory users such as zram, especially for page decompression on >> the read path. >> >> Signed-off-by: Georgi Djakov <[email protected]> >> --- >> drivers/soc/qcom/Kconfig | 14 + >> drivers/soc/qcom/Makefile | 1 + >> drivers/soc/qcom/qpace.c | 764 ++++++++++++++++++++++++++++++ >> drivers/soc/qcom/qpace_internal.h | 84 ++++ >> include/linux/soc/qcom/qpace.h | 154 ++++++ >> 5 files changed, 1017 insertions(+) >> create mode 100644 drivers/soc/qcom/qpace.c >> create mode 100644 drivers/soc/qcom/qpace_internal.h >> create mode 100644 include/linux/soc/qcom/qpace.h >> >> diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig >> index 535c8619197b..6bcb86dcd726 100644 >> --- a/drivers/soc/qcom/Kconfig > > Sorry, but no. Soc is not a dumping ground. This has clear function of > compression offload, so it should have some dedicated maintainers like > other offload engines.
Thanks Krzysztof, and thanks Sergey for the input on the zram side. Before I respin, let me elaborate on a possible structure, so we can choose the direction we want to go. The QPaCE driver splits into one engine and (up to) two consumers, following the IAA/idxd driver model split where the engine exports an in-kernel API and the crypto side is a separate, thin layer: Engine: drivers/soc/qcom/qpace.c + include/linux/soc/qcom/qpace.h - decompress primitives. It stays under soc/qcom, interacts with LLCC slices etc. zram: drivers/block/zram/backend_qpace.c - A zcomp backend calling the engine's in-kernel API directly. The zram intentionally does not use the crypto API today (917a59e81c34). zswap (?): drivers/crypto/qcom/qpace_crypto.c - Registers qpace-lz4 as a crypto acomp algorithm for crypto consumers (zswap maybe?). It will share the engine's primitives, so this would be a thin wrapper. If zram switches to the acomp API in the future, zram can use QPaCE through the acomp algorithm and backend_qpace.c simply goes away - so this will be compatible with that direction without depending on it. Krzysztof, does engine-in-soc/qcom + the crypto acomp address your concern? Or would you still prefer the engine live somewhere other than soc/qcom? An alternative would be to put it in drivers/crypto/qcom/ as a crypto driver - register with acomp, but there will be no user, and zram would still use the exported in-kernel API. Sergey, is a native backend_qpace.c the right thing for zram now, with acomp left as the future path rather than something I add to zram core today? Thanks, Georgi
