On 10/7/2026 12:51 AM, Krzysztof Kozlowski wrote:
On 07/10/2026 01:51, Oreoluwa Babatunde wrote:
On 10/1/2026 1: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.
The reason for putting this in soc/qcom is because this is a qcom HW
Every qcom HW driver is a qcom HW driver and they DO NOT go to drivers/soc.
Again: soc is not a dumping ground.
ACK. We are looking at the crypto driver to see if it fits our use of
the qpace HW block.
Do you have other suggestions for where this would better fit besides
the crypto framework?
Thanks,
Oreoluwa