On 31-08-2026 20:28, Ekansh Gupta wrote: > On 20-08-2026 19:01, Krzysztof Kozlowski wrote: >> On 20/08/2026 12:07, Dmitry Baryshkov wrote: >>> On Thu, Aug 20, 2026 at 11:07:45AM +0200, Krzysztof Kozlowski wrote: >>>>>>>> >>>>>>>> Device node with this compatible is already populated, so this looks >>>>>>>> simply wrong or you are adding a duplicated driver. >>>>>>>> >>>>>>>> That's a no-go, you are supposed to work with existing drivers and grow >>>>>>>> them. >>>>>>> I'll bring the discussion again here, there was a discussion to move the >>>>>>> driver to accel subsystem if we want to support new features/uAPI >>>>>>> changes. Please read [1],[2] threads. The intention is to replace >>>>>>> fastrpc driver with QDA eventually. >>>>>> >>>>>> None of them address the problem. You want to grow fastrpc into user of >>>>>> dmabuf? So you move it from misc to here. >>>>> >>>>> It's not as easy and nice, so I think in this case it's better to repeat >>>> >>>> I disagree. The existing fastrpc driver is not that complicated. It's >>>> actually moderate amount of code, much less than Venus was (~7 times less). >>>> >>>> It easily can grow to support two interfaces and the only difficulty is >>>> how to manage these two interfaces simultaneously or exclusively, e.g. >>>> opening first one disables the second. >>> >>> I see the point here. >>> >>> Would it be acceptable if we add QDA support only on the new platforms >>> (e.g. via the SoC-specific compat), provide QDA for those platforms, >>> and, once it reaches complete API and feature parity, we remove the old >>> fastrpc driver, migrati old platforms. >> >> The problem with this approach is that we have no guarantees that it >> will reach feature parity in respect of old interface, thus old driver >> might stay forever. If we agree for duplicated driver, contributors have >> no incentives to support old approach. > That's a fair concern. Let me lay out the sequence we have in mind and > then the concrete reasons parity is not optional for us. > > The plan is staged. QDA is enabled first on new platforms, where there > is no existing userspace to migrate and the new UAPI can be exercised > properly. In parallel we close the remaining feature gaps against > fastrpc. Once parity is reached we migrate the older platforms onto QDA > and remove drivers/misc/fastrpc.c. The end state is one driver, not two. > > On why parity will actually happen: the DSP firmware is not changing. > Both drivers implement the same base protocol against the same firmware > image, so the feature set is defined by that firmware interface, not by > what we feel like implementing. For QDA to support a feature at all it > has to implement the same protocol operations fastrpc already does. > Parity is a property of the interface rather than of contributor enthusiasm. > > Other than the base protocol, there are some features(daemons, > capability, session sharing) that exist in fastrpc for performance etc. > but are not yet part of QDA. We want to implement them properly rather > than port them across as they stand. > > The remaining question is how fastrpc can actually be removed once > parity exists, without breaking existing userspace. That needs a > compatibility path, and it is a deliverable we are committed to rather > than an afterthought. For that, we need to settle is whether that path > is a userspace shim in the library, an in-kernel translation layer > exposing the legacy device nodes, or a hybrid. We evaluated an in-kernel > shim during v1 and hit constraints around constructing per-client > drm_file contexts from outside the DRM core, so the approach is still > open. I'll come back with a concrete proposal, and it will land before > fastrpc is removed rather than after. > >> >> Much better is to refine the old driver, gradually adding new features >> while maintaining old stuff. This is the only way we can force >> contributors to actively work on minimizing duplicate parts. >> > I believe you are suggesting we bring the new features we are developing > with DRM core utilities into the fastrpc driver. I don't think the two > interfaces can share one driver, though, and it isn't a question of code > size. > > fastrpc is a miscdevice: it accepts raw DMA-BUF fds as arguments and > tracks buffers in its own per-file lists, with the fd itself being the > buffer identity visible to the DSP. QDA is a drm_driver whose buffers > are GEM objects in a per-drm_file handle namespace, with PRIME used for > import and the GEM handle being the identity. These are two different > buffer ownership models, and neither can be expressed on the other's > file type. > > Supporting both from one driver therefore means carrying both models > simultaneously: two IOCTL surfaces, two buffer lifetimes, two teardown > paths, and a memory manager that has to serve both. That is two drivers > sharing a directory rather than one driver with two interfaces, and I > think it would be harder to review, and harder to eventually untangle, > than a separate driver with a stated removal plan. > > There is also a positive reason for being in the accel subsystem rather > than misc. We can build on existing DRM infrastructure instead of > reimplementing it: GEM for buffer management, the device and file > lifecycle, and the debug infrastructure. It also positions us for work > we have planned around scheduling, drm_gpuvm, etc. Over time this should > mean less driver-specific code, not more. > > I'll restructure the cover letter so the staged rollout, the > compatibility path and the eventual removal of drivers/misc/fastrpc.c > are stated properly. > > If after this you still want to add or change anything, please let me know. > > Thanks, > Ekansh> Best regards,
Gentle ping on this thread. Wanted to check if there's any update on the compatible string and coexistence question above, since it's currently blocking respin. Thanks, Ekansh >> Krzysztof >
