On 19/08/2026 16:49, Rob Clark wrote:
On Wed, Aug 19, 2026 at 7:43 AM Krzysztof Kozlowski krzk@kernel.org wrote:
On 19/08/2026 16:38, Rob Clark wrote:
On Wed, Aug 19, 2026 at 7:21 AM Krzysztof Kozlowski krzk@kernel.org wrote:
On 19/08/2026 15:26, Ekansh Gupta wrote:
On 19-08-2026 00:43, Krzysztof Kozlowski wrote:
On 17/08/2026 06:47, Ekansh Gupta wrote: > This patch series introduces the Qualcomm DSP Accelerator (QDA) driver, > a DRM-based accelerator driver for Qualcomm DSPs. The driver provides a > standardized interface for offloading computational tasks to DSPs found > on Qualcomm SoCs, supporting all DSP domains. > > The QDA driver implements the FastRPC protocol over the DRM accel > subsystem. It uses the same device-tree node structure as the existing > fastrpc driver in drivers/misc/. The approach for binding the QDA driver > to device-tree nodes while coexisting with the fastrpc driver is an open > item described below.
No. Grow/replace/improve existing driver instead of coming with a duplicate.
That's a standard upstream requirement, basically given on every upstreaming guide.
Please watch old talk from Greg - "I Don’t Want Your Code!".
Posted discussion threads here[1]. Would seek comments from Dmitry, Srini as well.
[1] https://lore.kernel.org/all/3476b5c3-7983-4994-a901-3d7d8bd75255@oss.qualcom...
The rest of the comments is still valid even if you did not acknowledge them.
Anyway, regarding above - again, watch the talk from Greg.
You have ONE driver. Not two.
Long term, moving to the common driver framework (which did not exist when fastrpc was first created) seems like a good thing. But does that not allow for some transition period? How can we get from here to there without otherwise breaking userspace? Is there some other precedent elsewhere in other driver subsystems?
Yes, Iris and Venus where we agreed for an exception (two drivers) as long as new driver supports old hardware / features.
This is not the case here, right?
I suppose drm exposing legacy fbdev on top of drm drivers is _sort of_ a precedent if you squint a bit? I'm not really familiar enough to say if that would be reasonable/possible in this case.
Growing old driver does not look complicated itself. The only a bit tricky thing is to present somehow exclusive interface to user-space, like usage of one disables the second etc. Depending on actual differences in that interface.
But having a duplicated driver is a clear no go and it is well known upstream requirement. Nothing new here.
Would it be acceptable as a first step to, by default (ie. when no cmdline override/etc) for the new driver to bind to new compatibles
You have one compatible.
and the existing driver to old? Ie. have both drivers but only one binds on a given platform?
I don't see how is it possible to write such DTS, because - repeating my question - how many hardware blocks is there? I believe only one per given DSP, so how could you have two device nodes?
Best regards, Krzysztof