[alsa-devel] [PATCH v6 05/10] ASoC: Intel: mrfld: add DSP core controls

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140917/203a81cc/attachment.sig>