Re: [PATCH v2 03/15] accel/qda: Add initial QDA DRM accelerator driver

[Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>]

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
>