On Wed, 2011-10-05 at 18:43 +0300, Mark Brown wrote: > On Tue, Oct 04, 2011 at 02:30:17PM +0300, Tanu Kaskinen wrote: > > > I'm not sure that would work in this case. The mixer element is an > > enumeration with states "Off", "Rx" and "Tx". I've been told that it > > controls whether the FM radio is powered on (and whether it's in the > > reception or transmission mode). Of course, the logic could also include > > a rule that if one of the options for an enumeration is "Off", that will > > be used unless something else is specified. > > It should only be powered if someone routes audio to it. Is that the > case? I don't think so. I have now asked from the driver writer (Matti Aaltonen) why the driver doesn't power off the radio automatically, and the answer was the following (I'll also quote the question): On Wed, 2011-10-05 at 13:16 +0300, Matti J. Aaltonen wrote: > >>> And still one thing: what's the reason for not powering off the fm radio > >>> automatically when nobody's using the device, but requiring userspace to > >>> set the "Mode" mixer element to "Off" manually? See also this thread: > >>> http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/11283 > > Any comments to this? Pulseaudio upstream doesn't want features that are > > only used to work around kernel bugs, and there's some concern that this > > case is a kernel bug. > > Is it a bug or a feature? That's the question.... Off hand I don't > remember seeing such a requirement for the driver. And how do you define > when the radio is not off? It also offers analog audio. > > Anyway, there was/is a reason for not turning the radio off > unnecessarily: the firmware patch needs to be uploaded to the chip every > time it gets turned on. However, it should be rather simple to change > the on/off behavior of the driver once the conditions have been agreed upon. > > Cheers, > Matti Matti, do you have anything to add? I didn't fully understand how offering analog audio is a problem here - is the driver unable to detect whether someone is using the analog output or not? ...I actually already have Matti's answer, since I handled this discussion in a bit "funny" way... Here's Matti's reply, and my reply to that: On Thu, 2011-10-06 at 09:56 +0300, Matti J. Aaltonen wrote: > Yeah the driver is unable to detect directly if someone wants to use > the analog signal. But that's not a big problem, there still could > exist the facility for explicitly turning the radio on and off. It's > also possible to imagine a use case where only RDS data is of > interest. Sorry, I have some difficulty understanding this paragraph. Are you arguing for or against turning off the radio automatically? What do you mean by "that's not a big problem"? (That's the sentence that causes my confusion.) If the driver doesn't know if someone is using the analog output (or RDS), isn't that a showstopper, if the goal is to turn off the radio automatically without any explicit request? > Above, in the earlier message, I just tried to explain how "we" ended > up with the current design. At the moment I don't (in principle) see > reason why this new feature of controlling the radio state (on/off) > from the audio codec couldn't be implemented, it's just that all use > cases need to be considered. > > By the way have you noticed that the driver in the n950 tree and the > one in the official kernel are quite different? Nope, I don't follow kernel development. By "the official kernel", do you mean the upstream mainline kernel? If they are very different, does it mean that the mainline kernel doesn't (and won't?) support this chip very well? -- Tanu
