From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3E6F3815C7 for ; Wed, 25 Feb 2026 13:57:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772027881; cv=none; b=pPEDqCR312leP6PGU5rozb/KCBwD1BAmVGqTkd6qt644EJs0HgrwpVMRAxgvGgHsLz3avY3f0zLtwG5TO/Z6RzWtkigQC/Ml125Qloqq/wFLUlS7jZv8lEF6ZMnSmHwXQHgr5BhVL2E9iqa8Lgo+iUrVYfPtq1lCYjHIU2fwUkM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772027881; c=relaxed/simple; bh=hlHju+yEK+dVSqqOuwhlGHgNoqF1e/GghjjlCMjf4Uo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=jTbGjG/BB4HnhouUpC0i9e4Ns/SiwWTcPjoLl/PH9eY2i6AlEL2buOO+DgobhxfCGNDxlo7v9tJUAGu7mUVdVwOXB3KLoPs25hIZE2lt2PcoVWG7HK335vEha+mkoKuFLrbX78t7yxmw9Zpkpsm/7LJMZYOAP6ys455iMR4pQYQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=SngD41I0; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=TiTqNl8D; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="SngD41I0"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="TiTqNl8D" Received: from pps.filterd (m0279871.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 61P9SCee806798 for ; Wed, 25 Feb 2026 13:57:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= xBYPi7uwmyms6qiKiYpOhYR8HyAd/7uAOTP2ZQu479c=; b=SngD41I08N36oMO6 tYE2d77d7x+/raH5JgVXcHVUQ8nEjcQrITPqEa2e5yAVeU+u8gH7S2lRGIQI5Ndo YIFsSxzcACHZasaST4AD5xRn+hRi1qSKrOjgYRFwlHOaN7W0GGcO+Q8fG0QHEuZa m++zp+42KeBUePer+VKMgN7g1bXlLaxRku0dtgMveJpJo+BdO5hzMytiBzI9PZg4 imrJ2iANeWWl7UP/vlyld9XiBLlmJvC/nfDREkeHpLCqOJilokGRtUxeay9tdy5D tIJZVjcEtDoNhTlItSWFjDrNRrpHkPkHgiDx83dp9Q6EsDpPZrqe6h+KS6IoY2SL 8eTE8Q== Received: from mail-pl1-f200.google.com (mail-pl1-f200.google.com [209.85.214.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4chr5p9t6c-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 25 Feb 2026 13:57:58 +0000 (GMT) Received: by mail-pl1-f200.google.com with SMTP id d9443c01a7336-2aae146bab0so72761275ad.0 for ; Wed, 25 Feb 2026 05:57:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1772027878; x=1772632678; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=xBYPi7uwmyms6qiKiYpOhYR8HyAd/7uAOTP2ZQu479c=; b=TiTqNl8DGFWLHMsEelq+HqKEIYRqjjPWJljlLvxcPiZSJz3ukNIAyVEzQGbATBBL/T hEc9VcUgcgwXsNy4hkH01k9x/cZ1wfzngquHRbMdQG0ZD82H2xRREIQKy0p2Ku3wDCKq sML5hO9NBpQdaIKjUVjg8Aki2HwyoIYGqqI9jpnO7ttufLKjsbZJZM0jxEhfhyrFLD1s zVSegAdwFm806QD0hYDhqFWQS9YuOaS2dDgINNVnsJlsmODt0gmixPPNA+8A22MQT85f oiwtgorWNwKQag5kY1vpM/FNGHHJXJDCdpD2j2EGk/wjSiC9cT4pbvjjY0YmRm0ch2a0 IDYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772027878; x=1772632678; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xBYPi7uwmyms6qiKiYpOhYR8HyAd/7uAOTP2ZQu479c=; b=iaNJv9+ndTb9Q6alLU7OrGhK2/l8+fIbgGIMXLTe7LMdX/bf3+dKGVHjY4AnNiujl1 OvlrveY+ST6OGwnrxTHp+dqlv4OaqJzF2xJ4jpcwA5E/mX41rUMcvGYAOGRl+qKBToIf m760s6B2mxRuCtM9PeGsZL0OIE7oz5aYSdQtklyTDzrucnHIbILZJe7FHWcGu8sM3Zht 1DDOSwLUjvhxd5CNB1IB28Q9Ex0XbQG/dZCRMgYe/cEA9J5XlQXmuVjTNNNQsn54spTc A8rhc6Fl/t4lhrA+agXW2M/eApIFGtkExlnZwFsV/OC0lsI57pCc5ZX4B9XhRPAt8XHr pdYQ== X-Forwarded-Encrypted: i=1; AJvYcCXLuW5JjK/kaASxGtXF79wFBezbRC2vKyltLHzgVRoK+Rj+G9MPmZ2b8qD6yOJLFQNePR0c5HdqEYW5/kYs@vger.kernel.org X-Gm-Message-State: AOJu0Yw1oY/ib8zhLTM59yHV9edpudg7N9ua+aBCz90Vkx958FWLHpHN ad7BpRqxUjXq97IMhlhvq7lDTZx743bz2RjF+g70vWpvjtQepWn/5nmWgE2EgBisORtM0KPrTUw BDwKLxziUHWMkxTWuV3LPt7nHzNmCGhX96k7dzJQXVVCR+Uonk6hEqOKoMrQiCQ/+zu7U X-Gm-Gg: ATEYQzzWUaaXQ+Bo1NSsFlpR5lp/vYBEQECpxXxZ4BJ1AuosAx0zoy1lbgUfgFpMTqM TmKp70aXS3RLhpHTrF9G4XwECGGuirK6Vzj+WUs03GLx2SpFz89qtkFVT+F+KBwkS6D44OaZN6D JHlTyB4nMhX1LW4yJE2jZGWdRei8OXAI7H6p5W1zvDFlQMIIHzjzG2kuufpvE+MFhDX7aGvR3/u YDgGhfI55lVZTp+7rSMG+C9X5FNw5c4p6LCfO7rYQkJx/vSg6dp6SVkblZD4xwRP9aw6bxPZHW+ D1V4m7qXmx6AUmPxRev0uCixdrhhukUv1NWa5KHLIt+DDStR/XeL9dcEE1QCRfpvkfdPxFe1vMv fLOaCQjudZmoJt5IIYdwm5VeIoUSO93g15hx/t6r22V0HI4H/sao= X-Received: by 2002:a17:903:22d2:b0:2ad:ca65:a398 with SMTP id d9443c01a7336-2adca65a58cmr27706705ad.57.1772027877462; Wed, 25 Feb 2026 05:57:57 -0800 (PST) X-Received: by 2002:a17:903:22d2:b0:2ad:ca65:a398 with SMTP id d9443c01a7336-2adca65a58cmr27706515ad.57.1772027876861; Wed, 25 Feb 2026 05:57:56 -0800 (PST) Received: from [192.168.1.5] ([171.61.227.247]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ad750275d0sm175587235ad.61.2026.02.25.05.57.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Feb 2026 05:57:55 -0800 (PST) Message-ID: Date: Wed, 25 Feb 2026 19:27:47 +0530 Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 01/18] accel/qda: Add Qualcomm QDA DSP accelerator driver docs To: Dmitry Baryshkov Cc: Oded Gabbay , Jonathan Corbet , Shuah Khan , Joerg Roedel , Will Deacon , Robin Murphy , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Simona Vetter , Sumit Semwal , =?UTF-8?Q?Christian_K=C3=B6nig?= , dri-devel@lists.freedesktop.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, iommu@lists.linux.dev, linux-media@vger.kernel.org, linaro-mm-sig@lists.linaro.org, Srinivas Kandagatla , Bharath Kumar , Chenna Kesava Raju References: <20260224-qda-firstpost-v1-0-fe46a9c1a046@oss.qualcomm.com> <20260224-qda-firstpost-v1-1-fe46a9c1a046@oss.qualcomm.com> Content-Language: en-US From: Ekansh Gupta In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwMjI1MDEzMyBTYWx0ZWRfX+InZ9kUW3aTZ 0WfnIOr7pvOIXyDNspiyWr2MDndZ4oTUiZP9Jpdru+PPuAE30ziXwIF6YyfE8HkA/aAkdQfgUHZ O2Kg+CTdOh8FPfzoA+nAFAsoi+q3Lf0tzkSbqwhFrCKhCE00Xq8ZIoa/ffnSze1Gp3FWAIfY6L8 tFVHC5apu9tlAXVBgygEj6K7tiv4CxS/DSw9JmggJNYLwGXDkO7rEUI/59eP41PGDrw1wwJmYpw Q8KQnjeCOCQlch+/LDARUs5pW+bDYv79oTLF6kyTiYEsKBN60vDGNmhH52oOdCjTGdVpAGutRx/ kdpkot/6EX+IKDioaBUNOaSOoKgeqE9Je2Z34MMu2QARwWpT2Q30dEH0MN8PgRawKlGzCxkzM6k suRT6kWZpm0iUliO142ZsGcJH1Tq878W+zCkqyBt22m2FdtzsoVurYQpJXHxIsR6UKjrqVFPzTW Za64ERTB0ejACJwH2uA== X-Authority-Analysis: v=2.4 cv=GstPO01C c=1 sm=1 tr=0 ts=699effe6 cx=c_pps a=IZJwPbhc+fLeJZngyXXI0A==:117 a=CLJ8B99oKJtQbdnoKiLypA==:17 a=IkcTkHD0fZMA:10 a=HzLeVaNsDn8A:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=3WHJM1ZQz_JShphwDgj5:22 a=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=7m3UXCOrzlUTUB1U0ZMA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=uG9DUKGECoFWVXl0Dc02:22 X-Proofpoint-GUID: LwWdI5Y9Eb3h5evhp9CNYLOAcr_Qp9Br X-Proofpoint-ORIG-GUID: LwWdI5Y9Eb3h5evhp9CNYLOAcr_Qp9Br X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.51,FMLib:17.12.100.49 definitions=2026-02-25_01,2026-02-25_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 impostorscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2602130000 definitions=main-2602250133 On 2/24/2026 2:47 AM, Dmitry Baryshkov wrote: > On Tue, Feb 24, 2026 at 12:38:55AM +0530, Ekansh Gupta wrote: >> Add initial documentation for the Qualcomm DSP Accelerator (QDA) driver >> integrated in the DRM accel subsystem. >> >> The new docs introduce QDA as a DRM/accel-based implementation of >> Hexagon DSP offload that is intended as a modern alternative to the >> legacy FastRPC driver in drivers/misc. The text describes the driver >> motivation, high-level architecture and interaction with IOMMU context >> banks, GEM-based buffer management and the RPMsg transport. >> >> The user-space facing section documents the main QDA IOCTLs used to >> establish DSP sessions, manage GEM buffer objects and invoke remote >> procedures using the FastRPC protocol, along with a typical lifecycle >> example for applications. >> >> Finally, the driver is wired into the Compute Accelerators >> documentation index under Documentation/accel, and a brief debugging >> section shows how to enable dynamic debug for the QDA implementation. >> >> Signed-off-by: Ekansh Gupta >> --- >> Documentation/accel/index.rst | 1 + >> Documentation/accel/qda/index.rst | 14 +++++ >> Documentation/accel/qda/qda.rst | 129 ++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 144 insertions(+) >> >> diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst >> index cbc7d4c3876a..5901ea7f784c 100644 >> --- a/Documentation/accel/index.rst >> +++ b/Documentation/accel/index.rst >> @@ -10,4 +10,5 @@ Compute Accelerators >> introduction >> amdxdna/index >> qaic/index >> + qda/index >> rocket/index >> diff --git a/Documentation/accel/qda/index.rst b/Documentation/accel/qda/index.rst >> new file mode 100644 >> index 000000000000..bce188f21117 >> --- /dev/null >> +++ b/Documentation/accel/qda/index.rst >> @@ -0,0 +1,14 @@ >> +.. SPDX-License-Identifier: GPL-2.0-only >> + >> +============================== >> + accel/qda Qualcomm DSP Driver >> +============================== >> + >> +The **accel/qda** driver provides support for Qualcomm Hexagon DSPs (Digital >> +Signal Processors) within the DRM accelerator framework. It serves as a modern >> +replacement for the legacy FastRPC driver, offering improved resource management >> +and standard subsystem integration. >> + >> +.. toctree:: >> + >> + qda >> diff --git a/Documentation/accel/qda/qda.rst b/Documentation/accel/qda/qda.rst >> new file mode 100644 >> index 000000000000..742159841b95 >> --- /dev/null >> +++ b/Documentation/accel/qda/qda.rst >> @@ -0,0 +1,129 @@ >> +.. SPDX-License-Identifier: GPL-2.0-only >> + >> +================================== >> +Qualcomm Hexagon DSP (QDA) Driver >> +================================== >> + >> +Introduction >> +============ >> + >> +The **QDA** (Qualcomm DSP Accelerator) driver is a new DRM-based >> +accelerator driver for Qualcomm's Hexagon DSPs. It provides a standardized >> +interface for user-space applications to offload computational tasks ranging >> +from audio processing and sensor offload to computer vision and AI >> +inference to the Hexagon DSPs found on Qualcomm SoCs. >> + >> +This driver is designed to align with the Linux kernel's modern **Compute >> +Accelerators** subsystem (`drivers/accel/`), providing a robust and modular >> +alternative to the legacy FastRPC driver in `drivers/misc/`, offering >> +improved resource management and better integration with standard kernel >> +subsystems. >> + >> +Motivation >> +========== >> + >> +The existing FastRPC implementation in the kernel utilizes a custom character >> +device and lacks integration with modern kernel memory management frameworks. >> +The QDA driver addresses these limitations by: >> + >> +1. **Adopting the DRM accel Framework**: Leveraging standard uAPIs for device >> + management, job submission, and synchronization. >> +2. **Utilizing GEM for Memory**: Providing proper buffer object management, >> + including DMA-BUF import/export capabilities. >> +3. **Improving Isolation**: Using IOMMU context banks to enforce memory >> + isolation between different DSP user sessions. >> + >> +Key Features >> +============ >> + >> +* **Standard Accelerator Interface**: Exposes a standard character device >> + node (e.g., `/dev/accel/accel0`) via the DRM subsystem. >> +* **Unified Offload Support**: Supports all DSP domains (ADSP, CDSP, SDSP, >> + GDSP) via a single driver architecture. >> +* **FastRPC Protocol**: Implements the reliable Remote Procedure Call >> + (FastRPC) protocol for communication between the application processor >> + and DSP. >> +* **DMA-BUF Interop**: Seamless sharing of memory buffers between the DSP >> + and other multimedia subsystems (GPU, Camera, Video) via standard DMA-BUFs. >> +* **Modular Design**: Clean separation between the core DRM logic, the memory >> + manager, and the RPMsg-based transport layer. >> + >> +Architecture >> +============ >> + >> +The QDA driver is composed of several modular components: >> + >> +1. **Core Driver (`qda_drv`)**: Manages device registration, file operations, >> + and bridges the driver with the DRM accelerator subsystem. >> +2. **Memory Manager (`qda_memory_manager`)**: A flexible memory management >> + layer that handles IOMMU context banks. It supports pluggable backends >> + (such as DMA-coherent) to adapt to different SoC memory architectures. >> +3. **GEM Subsystem**: Implements the DRM GEM interface for buffer management: >> + >> + * **`qda_gem`**: Core GEM object management, including allocation, mmap >> + operations, and buffer lifecycle management. >> + * **`qda_prime`**: PRIME import functionality for DMA-BUF interoperability, >> + enabling seamless buffer sharing with other kernel subsystems. >> + >> +4. **Transport Layer (`qda_rpmsg`)**: Abstraction over the RPMsg framework >> + to handle low-level message passing with the DSP firmware. >> +5. **Compute Bus (`qda_compute_bus`)**: A custom virtual bus used to >> + enumerate and manage the specific compute context banks defined in the >> + device tree. > I'm really not sure if it's a bonus or not. I'm waiting for iommu-map > improvements to land to send patches reworking FastRPC CB from using > probe into being created by the main driver: it would remove some of the > possible race conditions between main driver finishing probe and the CB > devices probing in the background. > > What's the actual benefit of the CB bus? I tried following the Tegra host1x logic here as was discussed here[1]. My understanding is that with this the CB will become more manageable reducing the scope of races that exists in the current fastrpc driver. That said, I'm not completely aware about the iommu-map improvements. Is it the one being discussed for this patch[2]? If it helps in main driver to create CB devices directly, then I would be happy to adapt the design. [1] https://lore.kernel.org/all/245d602f-3037-4ae3-9af9-d98f37258aae@oss.qualcomm.com/ [2] https://lore.kernel.org/all/20260126-kaanapali-iris-v1-3-e2646246bfc1@oss.qualcomm.com/ > >> +6. **FastRPC Core (`qda_fastrpc`)**: Implements the protocol logic for >> + marshalling arguments and handling remote invocations. >> + >> +User-Space API >> +============== >> + >> +The driver exposes a set of DRM-compliant IOCTLs. Note that these are designed >> +to be familiar to existing FastRPC users while adhering to DRM standards. >> + >> +* `DRM_IOCTL_QDA_QUERY`: Query DSP type (e.g., "cdsp", "adsp") >> + and capabilities. >> +* `DRM_IOCTL_QDA_INIT_ATTACH`: Attach a user session to the DSP's protection >> + domain. >> +* `DRM_IOCTL_QDA_INIT_CREATE`: Initialize a new process context on the DSP. > You need to explain the difference between these two. Ack. > >> +* `DRM_IOCTL_QDA_INVOKE`: Submit a remote method invocation (the primary >> + execution unit). >> +* `DRM_IOCTL_QDA_GEM_CREATE`: Allocate a GEM buffer object for DSP usage. >> +* `DRM_IOCTL_QDA_GEM_MMAP_OFFSET`: Retrieve mmap offsets for memory mapping. >> +* `DRM_IOCTL_QDA_MAP` / `DRM_IOCTL_QDA_MUNMAP`: Map or unmap buffers into the >> + DSP's virtual address space. > Do we need to make this separate? Can we map/unmap buffers on their > usage? Or when they are created? I'm thinking about that the > virtualization. The lib provides ways(fastrpc_mmap/remote_mmap64) for users to map/unmap the buffers on DSP as per processes requirement. The ioctls are added to support the same. > An alternative approach would be to merge > GET_MMAP_OFFSET with _MAP: once you map it to the DSP memory, you will > get the offset. _MAP is not need for all the buffers. Most of the remote call buffers that are passed to DSP are automatically mapped by DSP before invoking the DSP implementation so the user-space does not need to call _MAP for these. Some buffers(e.g., shared persistent buffers) do require explicit mapping, which is why MAP/MUNMAP exists in FastRPC. Because of this behavioral difference, merging GET_MMAP_OFFSET with MAP is not accurate. GET_MMAP_OFFSET is for CPU‑side mmap via GEM, whereas MAP is specifically for DSP virtual address assignment. > >> + >> +Usage Example >> +============= >> + >> +A typical lifecycle for a user-space application: >> + >> +1. **Discovery**: Open `/dev/accel/accel*` and check >> + `DRM_IOCTL_QDA_QUERY` to find the desired DSP (e.g., CDSP for >> + compute workloads). >> +2. **Initialization**: Call `DRM_IOCTL_QDA_INIT_ATTACH` and >> + `DRM_IOCTL_QDA_INIT_CREATE` to establish a session. >> +3. **Memory**: Allocate buffers via `DRM_IOCTL_QDA_GEM_CREATE` or import >> + DMA-BUFs (PRIME fd) from other drivers using `DRM_IOCTL_PRIME_FD_TO_HANDLE`. >> +4. **Execution**: Use `DRM_IOCTL_QDA_INVOKE` to pass arguments and execute >> + functions on the DSP. >> +5. **Cleanup**: Close file descriptors to automatically release resources and >> + detach the session. >> + >> +Internal Implementation >> +======================= >> + >> +Memory Management >> +----------------- >> +The driver's memory manager creates virtual "IOMMU devices" that map to >> +hardware context banks. This allows the driver to manage multiple isolated >> +address spaces. The implementation currently uses a **DMA-coherent backend** >> +to ensure data consistency between the CPU and DSP without manual cache >> +maintenance in most cases. >> + >> +Debugging >> +========= >> +The driver includes extensive dynamic debug support. Enable it via the >> +kernel's dynamic debug control: >> + >> +.. code-block:: bash >> + >> + echo "file drivers/accel/qda/* +p" > /sys/kernel/debug/dynamic_debug/control > Please add documentation on how to build the test apps and how to load > them to the DSP. Ack. > >> -- >> 2.34.1 >>