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 <[email protected]> >>> --- >>> 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. Again: you have one driver. > > Do you suggest adding a different compatible, say "qcom,qda" for this > driver? How would that even work? How much (or many?) hardware do you have in your SoC? > > Let me know if you have a better suggestion to proceed here. > > [1] https://lkml.org/lkml/2024/6/24/479 > [2] https://lkml.org/lkml/2024/6/21/1252> Please do not ever reference lkml.org, it's long time deprecated and barely working. Use lore. Best regards, Krzysztof
