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