On Fri, 2013-09-13 at 13:20 +0530, Arun Raghavan wrote: > On Fri, 2013-08-30 at 15:11 +0200, David Henningsson wrote: > > On 08/30/2013 09:28 AM, Tanu Kaskinen wrote: > > > On Fri, 2013-08-30 at 08:16 +0200, David Henningsson wrote: > > >> On 08/29/2013 04:36 PM, Tanu Kaskinen wrote: > > >>> Sometimes it would be nice to disable module-suspend-on-idle for > > >>> specific devices. For me the use case is to keep a HDMI sink running > > >>> all the time to avoid loss of audio when starting to play a stream to > > >>> the device (the HDMI receiver eats a bit from the beginning of the > > >>> stream when the device is opened). This is arguably a hacky solution > > >>> to the problem, but on the other hand, I think it's very sensible to > > >>> interpret negative timeout in the module-suspend-on-idle.timeout > > >>> property as disabling the suspending altogher. This is also how the > > >>> exit-idle-time configuration option behaves (negative value disables > > >>> automatic exiting). > > >> > > >> Didn't Arun have another solution for a similar problem? Like a sink > > >> ALWAYS_RUNNING flag or something. > > > > > > Yes, he did. That patch was not merged, and I don't know if Arun plans > > > to still work on it. > > > > > > Regardless of Arun's solution, I think it makes sense to support > > > negative value for the module-suspend-on-idle.timeout property to be > > > consistent with other timeout parameters. > > > > > > > Hmm, it looks like there already is a module-suspend-on-idle.timeout > > property and you're just improving its functionality. Then I would > > typically prefer this over a new sink flag. > > > > Even better if the module-suspend-on-idle.timeout was documented though... > > > > Arun, would this solve your problem as well? Would it be possible for > > the two of you to synchronise your efforts? > > Tanu and I discussed this on IRC. I don't think we should use this > property to do what I was trying to with ALWAYS_RUNNING - the module > parameters is mechanism, and the always-running-ness is policy. Don't > want to mix the two. > > That said, I've no objection to what the patch is trying to do, per se > (i.e. extend/standardise the semantics of a device property that we > already support). OK, patch pushed. For the record, I agree with Arun in that this property shouldn't be used in the hardware description files (UCM or alsa-mixer files). I didn't quite understand Arun's explanation about mechanism vs. policy. My reason for disliking the property is that it's specific to module-suspend-on-idle, while "idle suspending not recommended" is a hardware property that shouldn't be tied to any particular module. -- Tanu
