headers
Peter Hsiang | 1 Oct 2010 03:56
Favicon

Re: user space control app driver interface for sound soc

On Thu, Sep 30, 2010, Mark Brown wrote:
> On Thu, Sep 30, 2010 at 04:10:15PM -0700, Peter Hsiang wrote:
> > On Thu, Sep 30, 2010, Mark Brown wrote:
> 
> > > For these it depends; frequently these are (like your existing EQ
> > > configuration) included in platform data but it really depends on how
> > > they are generated and if they are custom to a particular system (eg,
> > > dependant on plastics or particular speakers).
> 
> > In addition to the platform data, I would like in the future be
> > able to load in data values that are stored in or generated from the
> > user space.  Would I use the ALSA interface for this, or would it
> > need to be a separate interface?
> 
> This would not be idiomatic for ALSA.  The particular interface to use
> would depend on the volume of data being configured and the format it is
> provided in.  If this is just for test and development purposes then
> adding something to debugfs would be the normal thing.

This will be intended for normal operation.
The volume of data would be both small amounts (say 20 bytes or so)
for custom parameters, and also larger amounts (order of kilo bytes) 
for firmware image.
Seems like ALSA does not have build-in interfaces that can be 
directly used for these use cases right?
Will it be better to extend on ALSA or setup a separate path?

> > > > binary code image that goes into the chip's memory.
> 
> > > For this use request_firmware() and associated interfaces.
(Continue reading)

Permalink | Reply |
headers
Mark Brown | 1 Oct 2010 04:37
Favicon
Gravatar

Re: user space control app driver interface for sound soc

On Thu, Sep 30, 2010 at 06:56:58PM -0700, Peter Hsiang wrote:
> On Thu, Sep 30, 2010, Mark Brown wrote:

> > This would not be idiomatic for ALSA.  The particular interface to use
> > would depend on the volume of data being configured and the format it is
> > provided in.  If this is just for test and development purposes then
> > adding something to debugfs would be the normal thing.

> This will be intended for normal operation.
> The volume of data would be both small amounts (say 20 bytes or so)

That's still not really answering the questions about how and when the
values will be generated which are important here.

> for custom parameters, and also larger amounts (order of kilo bytes) 
> for firmware image.

For firmware there's request_firmware().

> Seems like ALSA does not have build-in interfaces that can be 
> directly used for these use cases right?
> Will it be better to extend on ALSA or setup a separate path?

It seems likely that the behaviour should have some sort of higher level
interface wrapped around it - for example, firmwares will add certain
features to the chip, coefficients will set the chip into a given mode.
Presenting these things uninterpreted to userspace would be really bad
for usability since they're not likely to be things that make sense to
users directly.
(Continue reading)

Permalink | Reply |
headers
Clemens Ladisch | 1 Oct 2010 08:56
Picon
Gravatar

Re: user space control app driver interface for sound soc

Mark Brown wrote:
> On Thu, Sep 30, 2010 at 06:56:58PM -0700, Peter Hsiang wrote:
> > On Thu, Sep 30, 2010, Mark Brown wrote:
> > > Have you looked at request_firmware()?  It is the established mechanism
> > > for doing this and supports both firmware images built into the kernel
> > > and firmware loaded from userspace, though firmware in userspace is the
> > > more common approach.
> > 
> > Thanks, yes I see that it's a kernel space only feature, regardless
> > of where the firmware image is located.
> > Would it be ok for a user space app to handle the image file directly
> > and send down the file content for the driver to process?
> 
> With request_firmware() to userspace the firmware is loaded into the
> kernel by a userspace application.

request_firmware() is used to get the firmware data into the driver, but
it assumes that the driver decides when to ask for it.

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

Regards,
Clemens
Permalink | Reply |
headers
Mark Brown | 1 Oct 2010 09:12
Favicon
Gravatar

Re: user space control app driver interface for sound soc

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.
Permalink | Reply |
headers
Takashi Iwai | 1 Oct 2010 15:42
Picon

Re: user space control app driver interface for sound soc

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
(Continue reading)

Permalink | Reply |
headers
Mark Brown | 1 Oct 2010 19:35
Favicon
Gravatar

Re: user space control app driver interface for sound soc

On Fri, Oct 01, 2010 at 03:42:55PM +0200, Takashi Iwai 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.

Though in the embedded case platform data often ends up being idomatic
since many of the typical uses revolve around tuning things for physical
properties of the platform.
Permalink | Reply |
headers
Peter Hsiang | 1 Oct 2010 23:57
Favicon

Re: user space control app driver interface for sound soc

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 :)
(Continue reading)

Permalink | Reply |
headers
Takashi Iwai | 3 Oct 2010 11:09
Picon

Re: user space control app driver interface for sound soc

At Fri, 1 Oct 2010 14:57:28 -0700,
Peter Hsiang wrote:
> 
> 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?

Yes, but you can't add your own ioctl for control API.  The API
already provides the (small fixed-size) byte array communication.

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

If you need own syscalls, implement freely using other method, such
as ALSA hwdep device or whatever you like.  But, of course, it will be
unportable since you define a new API set there.

Takashi
(Continue reading)

Permalink | Reply |

Gmane