Re: [PATCH v2 03/15] accel/qda: Add initial QDA DRM accelerator driver

[Krzysztof Kozlowski]

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@xxxxxxxxxxxxxxxx>
>>> ---
>>> 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