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

[Vinod Koul]

On Sat, Jun 21, 2014 at 08:56:42AM +0200, Lars-Peter Clausen wrote:
> 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.

Do you mean autodisable bit? Btw this seems to be used only in kcontrol creation
and not in runtime. Actually I wont find using this feature if we have it :)

-- 
~Vinod