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 and the existing driver to old? Ie. have both drivers but only one binds on a given platform? BR, -R
