On Thu, Aug 20, 2026 at 11:07:45AM +0200, Krzysztof Kozlowski wrote: > 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 <[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. > > > > 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.
I see the point here. Would it be acceptable if we add QDA support only on the new platforms (e.g. via the SoC-specific compat), provide QDA for those platforms, and, once it reaches complete API and feature parity, we remove the old fastrpc driver, migrati old platforms. > > > 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. That's the plan. > Again, this should be one of > the first things explained in cover letter. -- With best wishes Dmitry
