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

[Vinod Koul]

On Wed, Sep 17, 2014 at 12:37:06PM -0700, Mark Brown wrote:
> 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?

Since this is specfic to BE (SSP) port, the DSP FW doesnt allow us to reconfigure
the slots when it is active. These will take effect next time the BE
restarts.

Yes not ideal but thats something we have to live with!

Thanks

-- 
~Vinod
> 
> > 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: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140918/7428a7ae/attachment.sig>