On Fri, Jan 09, 2009 at 01:43:38PM +0100, Robert Jarzmik wrote:
Would it be accepted a generic API in sound/soc/soc-scenario.c, which more or less the same construction as with mio_mixes_t, get_scenario and set_scenario, and a possible callback before and after scenario changes ?
I could propose an API if it is agreed that the API will be eventually accepted, after technical discussion in this ML.
Yes, I think that's a good approach. Perhaps if you sketch out the interface before delving into the actual implementation?
If the system is overheating that's something that it's worth preventing in kernel space. Do you know what they did to make that happen - is it a case of enabling more outputs than can comfortably be driven, for example?
IIRC, the guy was playing music on the amplified speaker which is connected to HPL and OUT3 on the wm9713. He tried to increase the volume, but instead of touching HPL+OUT3, he changed SPKL+SPKR.
So the two speakers can't safely be run simultaneously, then?
Actually, looking at your driver are there any pins that are not connected and never touched by the scenario stuff? By default pins will be enabled unless otherwise stated.
And then, if we had to go that way, why not provide a generic pxa2xx-ac97 + wm9713 codec couple, without board code, drop board code, and let the sound daemon handle the problems. Personnaly, with my experience on smartphones, I
That's a perfectly sensible approach if there are classes of system which are generic enough to make the code reuse meanigful - if they just slightly different sets of pins marked as not connected, for example. There are some examples already, such as the spitz machine which handles three different platforms with two options for a GPIO. At a certain point there will be enough special cases or something fiddly enough to make it worth splitting off to make multiple machine drivers.
For really straightfoward systems then the standard ALSA AC97 driver may be all people need.
feel very reluctant to it. I think sound on a phone is a critical enough issue to be handled in kernel space.
The sound also has to agree with things like the GSM chipset and what the user is trying to do.
+#define ARRAY_AND_SIZE(x) (x), ARRAY_SIZE(x)
You're right, it was NACKed. I don't remember the "strongly", would you please provide me your source. From what I read, there was bickering about the naming, and
Google isn't turning up anything particularly strong so I guess I'm misremembering.
arch/arm/mach-pxa/generic.h, which is not easily reachable, hence the definition.
#include <mach/generic.h>? (not tested at all)
Wouldn't that point to arch/arm/mach-pxa/include/mach instead of arch/arm/mach-pxa ?
Yes, it would - misread what you wrote there.
<nitpick>mixers and muxes</nitpick>
Mixers is more "frogish", isn't it ? :)
You had "muxers".
The comment are all in mixes_gsm_call_headset. You have the full path. I can move them in the header if you wish, or try some ascii art of the wm9713 connection on the mioa701 board.
What you've got is fine, it's just that that wouldn't cover non-DAPM things like a connection to the voice PCM (that should appear in the DAIs).
Ah, exactly my case. I wonder why dapm can't "guess" that path ... The pins are activated, the audio pathes are known ... Can I take some debug info that could help to understand the problem ?
#define DEBUG at the top of soc-dapm.c - it'll be *very* verbose about the power decisions it's making.