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. Best regards, Krzysztof
