On 19/08/2026 16:49, Rob Clark wrote: > On Wed, Aug 19, 2026 at 7:43 AM Krzysztof Kozlowski <[email protected]> wrote: >> >> On 19/08/2026 16:38, Rob Clark wrote: >>> On Wed, Aug 19, 2026 at 7:21 AM Krzysztof Kozlowski <[email protected]> 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/[email protected]/ >>>> >>>> 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
