Re: [PATCH 2/6] soc: qcom: qpace: Add Qualcomm Page Compression Engine driver

[Georgi Djakov <georgi.djakov@oss.qualcomm.com>]

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 <georgi.djakov@oss.qualcomm.com>
>> ---
>>  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