[PATCH v15 00/16] Add audio support in v4l2 framework

Jaroslav Kysela perex at perex.cz
Wed May 1 01:03:28 AEST 2024


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 at perex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.



More information about the Linuxppc-dev mailing list