On Mon, 7 Mar 2011 14:59:31 +0000 Mark Brown broonie@opensource.wolfsonmicro.com wrote:
On Mon, Mar 07, 2011 at 07:29:12AM -0500, Mike Frysinger wrote:
On Mon, Mar 7, 2011 at 07:15, Mark Brown wrote:
[...]
Right, and this isn't a particularly unusual requirement especially if the driver isn't going to have any ability to interact with the DSP (at which point it's just coefficient data, the fact that it's a DSP program is uninteresting). The problem is that this isn't a great interface for doing that.
i dont see suggestions of a better interface anywhere ...
It currently isn't and I'd encourage you to contribute to the discussion that's been going on on this, or even better help out with code. There was some discussion on the list recently (in the past month IIRC).
Whatever we do is going to require some additional APIs in alsa-lib, I'd expect. The key requirements I'm aware of are that we be able to support:
- Discoverable userspace interface.
- Very large data sizes (megabytes have been mentioned).
- Adding and removing parameter sets at runtime (for in system callibration).
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?
wrt pm, that's a trivial programming issue that would be resolved in the driver. userspace need not care.
That's the ideal, I mentioned this as several of my other review comments concerned issues with power management in the driver - addressing those will probably require that the integration occur.
wrt stream flows, all the customers we've talked to are fine with this -- having stream control be an application issue. their application is driving the codec directly and knows when it needs to change the firmware, so it pauses its alsa flow, loads the new firmware, and moves on.
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)?
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) to cause something in alsa core to stop/pause/mute playback or capture and restart everything after the firmware has been loaded is all that's necessary. That is, userspace triggers the firmware loading. 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 would leave userspace no longer able to explicitly trigger a reload, but leave the driver smart enough to ensure that when a new firmware is available, it will be loaded once it is safe to do so (a break in userspace codec usage).