On 30. 04. 24 16:46, Mark Brown wrote:
So instead of hammering a driver into the wrong destination, I would
suggest bundling our forces and implementing a general memory-to-memory
framework that both the media and the audio subsystem can use, that
addresses the current shortcomings of the implementation and allows you
to upload the driver where it is supposed to be.
That doesn't sound like an immediate solution to maintainer overload
issues... if something like this is going to happen the DRM solution
does seem more general but I'm not sure the amount of stop energy is
proportionate.
The "do what you want" ALSA's hwdep device / interface can be used to transfer
data in/out from SRC using custom read/write/ioctl/mmap syscalls. The question
is, if the changes cannot be more simpler for the first implementation keeping
the hardware enumeration in one subsystem where is the driver code placed. I
also see the benefit to reuse the already existing framework (but is v4l2 the
right one?).
Jaroslav
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
