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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
