[alsa-devel] [PATCH 10/19] ASoC: Intel: add mrfld DSP registers

[Lars-Peter Clausen]

On 06/21/2014 08:22 AM, Vinod Koul wrote:
> On Fri, Jun 20, 2014 at 02:33:19PM +0200, Lars-Peter Clausen wrote:
>> On 06/20/2014 01:32 PM, Vinod Koul wrote:
>>> On Fri, Jun 20, 2014 at 10:22:30AM +0200, Lars-Peter Clausen wrote:
>>>> On 06/13/2014 02:33 PM, Vinod Koul wrote:
>>>>> +unsigned int sst_soc_read(struct snd_soc_platform *platform,
>>>>> +			unsigned int reg)
>>>>> +{
>>>>> +	struct sst_data *drv = snd_soc_platform_get_drvdata(platform);
>>>>> +
>>>>> +	pr_debug("%s: reg[%d] = %#x\n", __func__, reg, drv->widget[reg]);
>>>>> +	BUG_ON(reg > (SST_NUM_WIDGETS - 1));
>>>>> +	return drv->widget[reg];
>>>>> +}
>>>>> +
>>>>> +int sst_soc_write(struct snd_soc_platform *platform,
>>>>> +		  unsigned int reg, unsigned int val)
>>>>> +{
>>>>> +	struct sst_data *drv = snd_soc_platform_get_drvdata(platform);
>>>>> +
>>>>> +	pr_debug("%s: reg[%d] = %#x\n", __func__, reg, val);
>>>>> +	BUG_ON(reg > (SST_NUM_WIDGETS - 1));
>>>>> +	drv->widget[reg] = val;
>>>>> +	return 0;
>>>>> +}
>>>>
>>>> These seem to be purely virtual registers, what is this about? The
>>>> DAPM core is able to handle widgets and controls without any
>>>> register backing just fine. There is no need to emulate virtual
>>>> registers.
>>> But we need to store the mixer configuration for sending IPCs to DSP. So virtual
>>> register file is very much required
>>
>> Hm, ok. But how does this work, when is the IPC triggered and why
>> can't the IPC be done from within the write function?
> Write can come at any time, even when DSP is inactive. Also we want to tell DSP
> about the paths which are active
>
> So most of IPCs are sent from DAPM widget handlers with exception of controls
> which are active. For those we send IPC during get/put handlers.

This sounds very similar to the auto-mute controls that are supported by the 
ASoC core. Auto-mute controls will update the value in the put handler, but 
only if the widget it is attached to is powered up. If the widget is not 
powered up the value is stored and will be written once the widget powers 
up. Try to see if you can adopt the auto-mute controls for your usecase. I 
think this should allow to remove some of the parts from the driver that 
peek into core internal data structures.

- Lars