On Wed, Sep 17, 2014 at 04:25:57PM +0530, Subhransu S. Prusty wrote:
On Tue, Sep 16, 2014 at 12:30:53PM -0700, Mark Brown wrote:
This is returning with the lock still held AFAICT. I'm a bit surprised that we don't need to interact with the hardware if we've disabled everything, shouldn't this have some effect on the hardware?
Also the coding style thing with the comments again.
Will fix the locking and comment.
Regarding interaction with the driver, the slot map is cached and sent in sst_set_be_modules event. This is sent only when that particular BE is active, otherwise driver will happily cache these values. This is the reason why we don't see trigger to DSP when usermode fiddles around.
In our model only when a particular FE/BE/Mixer/Pipe is active we forward the settings and parameters, rest we keep the values in driver and forward when DAPM enables them.
I think we can add this explanation here at top of this file to help.
This doesn't really answer my concern - what happens if we're already active and making a change?
Power ops in SST takes care of the PM handling. Following comment is already added in the code which explains. "Send the command only if this call is the first enable or last disable"
Let us know if it is not clear enough.
No, that comment is orthogonal to the interaction with the DSP which is what is confusing.