On Mon, Apr 18, 2011 at 05:15:05PM -0700, Andres Salomon wrote:
Mark Brown broonie@opensource.wolfsonmicro.com wrote:
Given the number of people looking at this from various angles I'd expect to see some sort of progress this year (probably in the next quater or so), but obviously no guarantees.
Out of curiosity, has any progress been made on this?
No, it's only been a month.
What would actually cause the firmware to change? Would the userspace application that's currently driving the codec know that it needs to load a new firmware, or will there be multiple applications potentially interacting with the codec (with only one driving it, and another deciding that the firmware should change)?
Clearly something in userspace will need to be able to do this.
One can imagine two different types of APIs depending upon the answers to those questions. If the application driving the codec is also changing the firmware, a simple 'echo new_firmware_name.bin > /sys/.../filter_coeff' (or equivalent ALSA function)
Using sysfs isn't going to fly for all the reasons discussed upthread - it's not enumerable and it's not going to cope with large coefficient sets.
However, if multiple applications are going to be interacting with the codec, I'd imagine we'd need something more complex; perhaps a hook in snd_soc_dai_ops that's called anytime stream state changes? That
Using the ops isn't going to work as there's no reason a coefficient set has to be associated with a DAI.