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