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

[Peter Hsiang]

On Fri, Oct 01, 2010, Takashi Iwai wrote:
> 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).

Thanks Clemens, Takashi and Mark for the good comments.
Does ALSA use ioctl to implement its ALSA control elements?
To add an ioctl entry, would one expand on an existing list of ioctls
in ALSA, or would it be a fresh set of open/read/write/ioctl 
implemented in the codec driver?

> >
> > 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 :)

I agree too that it depends on a number of factors.
If it's dynamic, can't be computed ahead of time, and the combination 
is too large to be stored statically in a limited amount of RAM, 
then there is a valid need.
A build-in mechanism in the driver to handle dynamic info will also
enable the driver itself to function as part of the runtime solution
that produces the dynamic data, and also saves them to disk file, 
for example.

> 
> 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.

Thanks this is good to know.
> 
> 
> Takashi