On 09-09-2026 13:32, Srinivas Kandagatla wrote: > On 9/9/26 8:53 AM, Ekansh Gupta wrote: >>> This is the actual problem! >>> >>> We have existing user space that depends on the ioctl interface exposed >>> by the current misc driver. You must not break these. >>> >>> Hardware cutoff is not a viable solution, because that's just a >>> declaration that we'll let the old platforms rotten - or alternatively >>> you commit to maintain two drivers to the very same feature and quality >>> level. >>> >>> So the only reasonable solution is #2; from there it's a valid question >>> if you reach that point my stepwise migrating the current misc driver >>> that solution, or if you present a new driver with the fully backwards >>> compatible interface, alongside the new ABI. >>> >>> >>> But this does bring to a question which the cover letter should explain >>> - but doesn't: what problem does this patch series actually solve? >>> >>> Regards, >>> Bjorn >> Agreed. I'll target #2: QDA implementing the existing fastrpc UABI >> alongside the new one, rather than a driver split by platform. >> >> On how to get there: the blocker we hit in v1 was that legacy fastrpc >> buffer semantics appeared to need a drm_file, and there's no exported >> way to construct one outside the DRM core. I want to re-examine that >> constraint rather than treat it as final, since the legacy interface's >> own buffer model (a dma_buf fd as the buffer identity, no GEM >> involved) is not inherently tied to drm_file, that's how the existing >> misc driver implements it today. I don't have a concrete design yet >> and would rather work through it here than commit to one prematurely. >> If anyone has thoughts on how the legacy UABI could be served without >> requiring a drm_file per session or if I can somehow bind drm_file with >> chardev by exposing some APIs from DRM core, I'd welcome them. >> >> On the cover letter: fair point, and I'll fix it. The problem this >> series solves is that a miscdevice interface requires us to hand-roll >> what the accel/DRM subsystem already provides as common >> infrastructure: GEM for buffer lifecycle and reference counting, >> PRIME for cross-driver import/export, per-file (per-open) context and >> handle-namespace isolation, and the existing debug and lifecycle >> tooling the DRM core already ships. Every accelerator driver added to >> drivers/accel (habanalabs, ivpu, qaic, rocket) has taken this path for >> the same reason, rather than each maintaining its own equivalent >> inside drivers/misc. Building QDA directly on this shared >> infrastructure, instead of extending fastrpc's own ad hoc buffer and >> session tracking to cover the same ground, avoids that duplication > Am sure you must have already tried this, but Can you not migrate > existing fastrpc driver to this shared infrastructure under the hood? > > Can you elaborate on what are the blockers you hit in doing so? > > This will ensure that UAPI is retained and still get benefit of QDA. >
QDA's session model is built around drm_file, and fastrpc's chardev has no drm_file associated with it. I'm still checking whether that dependency is unavoidable for fastrpc's case, or whether there's a way to use the underlying buffer-management infrastructure without it. Please correct me if you are asking/suggesting a different approach? > --srini >> going forward. >
