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