On 20/08/2026 10:52, Dmitry Baryshkov wrote:
On Wed, Aug 19, 2026 at 04:18:51PM +0200, Krzysztof Kozlowski wrote:
On 19/08/2026 15:17, Ekansh Gupta wrote:
On 19-08-2026 00:40, Krzysztof Kozlowski wrote:
On 17/08/2026 06:47, Ekansh Gupta wrote:
Add the skeleton of the Qualcomm DSP Accelerator (QDA) driver, a DRM accel driver for the Hexagon DSPs found on Qualcomm SoCs.
This patch registers a DRM accel device, exposing a /dev/accel/accelN character device node, and binds it to the RPMsg channel used to reach the DSP. Buffer management, IOMMU context banks and the FastRPC protocol are added by later patches in this series.
qda_drv.c / qda_drv.h define the drm_driver ops table, the per-file private state (qda_file_priv) and the main device structure (qda_dev), which embeds drm_device so that it can be recovered with container_of().
qda_rpmsg.c binds to the "qcom,fastrpc" compatible via module_rpmsg_driver(), reads the DSP domain name from the "label" device-tree property, and registers the DRM device.
Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Ekansh Gupta ekansh.gupta@oss.qualcomm.com
Changes in v2:
- Use module_rpmsg_driver() and drop the qda_rpmsg_register()/ _unregister() wrappers, module_init()/module_exit() and qda_rpmsg.h entirely (Dmitry Baryshkov)
- Read the "label" property directly into qdev->dsp_name (Dmitry Baryshkov)
- Drop the probe/remove/init log messages (Dmitry Baryshkov)
- Return the result of qda_register_device() directly (Dmitry Baryshkov)
- Clarify the Kconfig help text (Dmitry Baryshkov)
drivers/accel/Kconfig | 1 + drivers/accel/Makefile | 1 + drivers/accel/qda/Kconfig | 30 ++++++++++++++++ drivers/accel/qda/Makefile | 10 ++++++ drivers/accel/qda/qda_drv.c | 71 ++++++++++++++++++++++++++++++++++++++ drivers/accel/qda/qda_drv.h | 61 +++++++++++++++++++++++++++++++++ drivers/accel/qda/qda_rpmsg.c | 79 +++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 253 insertions(+)
diff --git a/drivers/accel/Kconfig b/drivers/accel/Kconfig index bdf48ccafcf2..74ac0f71bc9d 100644 --- a/drivers/accel/Kconfig +++ b/drivers/accel/Kconfig @@ -29,6 +29,7 @@ source "drivers/accel/ethosu/Kconfig" source "drivers/accel/habanalabs/Kconfig" source "drivers/accel/ivpu/Kconfig" source "drivers/accel/qaic/Kconfig" +source "drivers/accel/qda/Kconfig" source "drivers/accel/rocket/Kconfig" endif diff --git a/drivers/accel/Makefile b/drivers/accel/Makefile index 1d3a7251b950..58c08dd5f389 100644 --- a/drivers/accel/Makefile +++ b/drivers/accel/Makefile @@ -5,4 +5,5 @@ obj-$(CONFIG_DRM_ACCEL_ARM_ETHOSU) += ethosu/ obj-$(CONFIG_DRM_ACCEL_HABANALABS) += habanalabs/ obj-$(CONFIG_DRM_ACCEL_IVPU) += ivpu/ obj-$(CONFIG_DRM_ACCEL_QAIC) += qaic/ +obj-$(CONFIG_DRM_ACCEL_QDA) += qda/ obj-$(CONFIG_DRM_ACCEL_ROCKET) += rocket/ \ No newline at end of file
You have trivial patch errors.
newline problem was already there, wasn't introduced as part of this patch series, so I wasn't sure to fix it here. I can fix this in v3.>
...
+}
+static const struct of_device_id qda_rpmsg_id_table[] = {
- { .compatible = "qcom,fastrpc" },
- {},
Device node with this compatible is already populated, so this looks simply wrong or you are adding a duplicated driver.
That's a no-go, you are supposed to work with existing drivers and grow them.
I'll bring the discussion again here, there was a discussion to move the driver to accel subsystem if we want to support new features/uAPI changes. Please read [1],[2] threads. The intention is to replace fastrpc driver with QDA eventually.
None of them address the problem. You want to grow fastrpc into user of dmabuf? So you move it from misc to here.
It's not as easy and nice, so I think in this case it's better to repeat
I disagree. The existing fastrpc driver is not that complicated. It's actually moderate amount of code, much less than Venus was (~7 times less).
It easily can grow to support two interfaces and the only difficulty is how to manage these two interfaces simultaneously or exclusively, e.g. opening first one disables the second.
what we did for the venus/iris migration or what happened already several times in the kernel history (for example the AIC7xxx SCSI host drivers were migrated by introducing the second driver and then removing the first one after the grace period). The backwards compatibility is a separate topic, but it will be addressed before the driver can be
Backwards compatibility should be one of the first things explained in cover letter in one of the first paragraphs.
And if you make it backwards compatible, then just remove old driver, because there is no point to keep it there. Again, this should be one of the first things explained in cover letter.
Best regards, Krzysztof