[alsa-devel] user space control app driver interface for sound soc

[Takashi Iwai]

At Fri, 1 Oct 2010 00:12:34 -0700,
Mark Brown wrote:
> 
> On Fri, Oct 01, 2010 at 08:56:25AM +0200, Clemens Ladisch wrote:
> 
> > If the firmware isn't needed when initialzing the device, you can add
> > some ioctl that makes the driver call request_firmware() (this basically
> > assumes that the data is stored in a file with a known name), or just
> > add some device that allows userspace to write data to the device (use
> > this for dynamic data).
> 
> This does rather depend on what the firmware does and why it needs to be
> reloaded - it is very rare that one can just blindly reload the firmware
> and frequently changing the firmware will affect the set of user tunable
> features that can be offered to the application layer.  Joining
> everything up in a way that avoids fragility typically means that the
> driver will end up initiating all the requests based on higher level
> requests from audio applications.

Such a thing wasn't so uncommon in the past, even ISA days; they
weren't called as "firmware" at that time, though.
The implementation really depends on the driver, i.e. how complex and
how influential to the whole operation, as Mark repeatedly wrote :)

FWIW, if it's an EQ band coef data or such small and more-or-less safe
data, you can create even a dedicated ALSA control element to
read/write the byte array.  For example, SPDIF status bits are
transferred in that way between the driver and the user-space.


Takashi