On 2/25/2026 11:40 AM, Dmitry Baryshkov wrote: > On Wed, Feb 25, 2026 at 11:16:26AM -0800, Trilok Soni wrote: >> On 2/25/2026 7:12 AM, Bjorn Andersson wrote: >>> On Wed, Feb 25, 2026 at 07:47:08PM +0530, Ekansh Gupta wrote: >>>> >>>> >>>> On 2/24/2026 9:03 AM, Trilok Soni wrote: >>>>> On 2/23/2026 11:08 AM, Ekansh Gupta wrote: >>>>>> Add initial documentation for the Qualcomm DSP Accelerator (QDA) driver >>>>>> integrated in the DRM accel subsystem. >>>>>> >>>>>> The new docs introduce QDA as a DRM/accel-based implementation of >>>>>> Hexagon DSP offload that is intended as a modern alternative to the >>>>>> legacy FastRPC driver in drivers/misc. The text describes the driver >>>>>> motivation, high-level architecture and interaction with IOMMU context >>>>>> banks, GEM-based buffer management and the RPMsg transport. >>>>>> >>>>>> The user-space facing section documents the main QDA IOCTLs used to >>>>>> establish DSP sessions, manage GEM buffer objects and invoke remote >>>>>> procedures using the FastRPC protocol, along with a typical lifecycle >>>>>> example for applications. >>>>>> >>>>>> Finally, the driver is wired into the Compute Accelerators >>>>>> documentation index under Documentation/accel, and a brief debugging >>>>>> section shows how to enable dynamic debug for the QDA implementation. >>>>> So existing applications written over character device UAPI needs to be >>>>> rewritten over new UAPI and it will be broken once this driver gets >>>>> merged? Are we going to keep both the drivers in the Linux kernel >>>>> and not deprecate the /char device one? >>>>> >>>>> Is Qualcomm going to provide the wrapper library in the userspace >>>>> so that existing applications by our customers and developers >>>>> keep working w/ the newer kernel if the char interface based >>>>> driver gets deprecated? It is not clear from your text above. >>>> Thanks for raising this, Trilok. >>>> >>>> This is one of the open items that I have. I'm not exactly sure what would >>>> be the >>>> acceptable way for this. >>>> >>>> As you mentioned, applications that rely on /dev/fastrpc* might not work >>>> on QDA >>>> without modification. >>>> >>>> I was thinking in the same lines as you have mentioned and having some >>>> shim/compat >>>> driver to translate FastRPC UAPI to QDA. The compat driver would expose >>>> the existing >>>> character devices and route the calls to QDA. The compat driver could be >>>> built via Kconfig. >>>> >>> >>> This is a fundamental requirement, you need to address this in order for >>> this to move forward. >>> >>> Which makes me wonder if it would be possible to reach an accel driver >>> through incremental transition of the current driver, instead of just >>> dropping in a few thousand lines of new code/design. >>> >>>> However, I haven’t encountered an example of such a UAPI‑translation >>>> driver in the kernel >>>> before, so I would want guidance from maintainers on whether this is an >>>> acceptable >>>> model or not. >>>> >>>> Regarding your question about library, all the APIs exposed by >>>> github/fastrpc library are kept >>>> unchanged in terms of definitions and expectation. The same project can be >>>> build for both >>>> FastRPC and QDA based on configure options. So, the applications using >>>> github/fastrpc should >>>> not face any problem if the libs is built with proper configure options. >>>> >>> >>> You're assuming that the kernel and userspace are a unified piece of >>> software, they are not. It must be possible for me to install a new >>> kernel package without having to replace the userspace libraries. >> >> Thank you Bjorn for providing the inputs. >> >> I also foresee that we will be stop adding (or already happened) new features >> into the existing fastrpc driver, so calling the new driver as an alternative >> is in oversold category. >> >> You are pretty much began the deprecating the existing fastrpc driver, so >> let's >> just mention it if that is the case and provide migration/shim path so that >> existing binaries doesn't break. > > I agree that we need a migration path, but I'd really focus on it after > getting at least basic parts of the QDA reviewed and agreed upon. > Otherwise the shim layer will be reworked again and again with no > immediate added benefit. >
I am fine with the review to be continued, this is RFC series anyway. We should also decide the design of the shim layer here as well. I prefer to not have multiple RFC revisions here if we don't agree on the basic requirements which leads to acceptance of this new driver. ---Trilok Soni
