On 2/23/26 7:08 PM, Ekansh Gupta wrote: Thanks Ekansh for this this one out.
Key Features
- Standard DRM accelerator interface via /dev/accel/accelN> * GEM-based buffer management with DMA-BUF import/export support
- IOMMU-based memory isolation using per-process context banks
- FastRPC protocol implementation for DSP communication
- RPMsg transport layer for reliable message passing
- Support for all DSP domains (ADSP, CDSP, SDSP, GDSP)
To what extent is this support expected ?
- Comprehensive IOCTL interface for DSP operations
High-Level Architecture Differences with Existing FastRPC Driver
The QDA driver represents a significant architectural departure from the existing FastRPC driver (drivers/misc/fastrpc.c), addressing several key limitations while maintaining protocol compatibility:
IOMMU Context Bank Management
UAPI Design
- FastRPC: Custom IOCTL interface
- QDA: DRM-style IOCTLs with proper versioning support
- Benefit: Follows DRM conventions, easier userspace integration
Can you elaborate this.
Are we really getting leverage from any of the standard libraries that are available for drm accel?
In general I would like to understand how standardization of this kernel driver is helping userspace side of things.
Does this mean that there will be no libfastrpc requirements in future?
If that is not the case then I see no point.
Open Items
The following items are identified as open items:
- Privilege Level Management
- Currently, daemon processes and user processes have the same access level as both use the same accel device node. This needs to be addressed as daemons attach to privileged DSP PDs and require higher privilege levels for system-level operations
- Seeking guidance on the best approach: separate device nodes, capability-based checks, or DRM master/authentication mechanisms
- UAPI Compatibility Layer
Simple rule! you can not break anything that is already working with existing UAPI.
- Add UAPI compat layer to facilitate migration of client applications from existing FastRPC UAPI to the new QDA accel driver UAPI, ensuring smooth transition for existing userspace code
What will happen to long term supported devices?
- Seeking guidance on implementation approach: in-kernel translation layer, userspace wrapper library, or hybrid solution
- Documentation Improvements
- Add detailed IOCTL usage examples
- Document DSP firmware interface requirements
- Create migration guide from existing FastRPC
- Per-Domain Memory Allocation
- Develop new userspace API to support memory allocation on a per domain basis, enabling domain-specific memory management and optimization
- Audio and Sensors PD Support
- The current patch series does not handle Audio PD and Sensors PD functionalities. These specialized protection domains require additional support for real-time constraints and power management
Please elaborate, fastrpc support is incomplete without audiopd support.
--srini