RE: [alsa-devel] [PATCH] ASoC: da7219: check SRM lock in trigger callback

[Adam Thomson]

On 11 February 2020 21:49, Pierre-Louis Bossart wrote:

> -----Original Message-----
> From: Pierre-Louis Bossart <pierre-louis.bossart@xxxxxxxxxxxxxxx>
> Sent: 11 February 2020 21:49
> To: Sridharan, Ranjani <ranjani.sridharan@xxxxxxxxx>
> Cc: alsa-devel@xxxxxxxxxxxxxxxx; Support Opensource
> <Support.Opensource@xxxxxxxxxxx>; Takashi Iwai <tiwai@xxxxxxxx>; Liam
> Girdwood <lgirdwood@xxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; Chiang, Mac
> <mac.chiang@xxxxxxxxx>; Mark Brown <broonie@xxxxxxxxxx>; Ranjani Sridharan
> <ranjani.sridharan@xxxxxxxxxxxxxxx>; Adam Thomson
> <Adam.Thomson.Opensource@xxxxxxxxxxx>; Lu, Brent <brent.lu@xxxxxxxxx>;
> cychiang@xxxxxxxxxx
> Subject: Re: [alsa-devel] [PATCH] ASoC: da7219: check SRM lock in trigger callback
> Importance: High
> 
> 
> 
> >>> Are you talking about the change in this commit acbf27746ecfa96b
> >>> "ASoC: pcm: update FE/BE trigger order based on the command"?
> >>>
> >>> We made this change to handle xruns during pause/release particularly on
> >>> the Intel HDA platforms.
> >>
> >> this change was just to mirror the behavior between start/stop, I
> >> thought there was a patch where we moved to TRIGGER_POST by default?
> >>
> >> What I am trying to figure out if whether using TRIGGER_PRE is ok or not
> >> for the SOF firmware.
> >>
> >
> > Ahh yes, it was part of the same series as this one. fd274c2b7267b  "ASoC:
> > SOF: topology: set trigger order for FE DAI link"
> >
> > TRIGGER_PRE won't really work in the case of SOF. We need the BE DAI to be
> > triggered before the FE DAI during start to prevent the xruns during
> > pause/release.
> 
> Thanks Ranjani. That information closes the door on the idea of playing
> with the trigger order suggested earlier in the thread, so my guess is
> that we really need to expose the MCLK/BCLK with the clk API and turn
> them on/off from the machine driver as needed. I hope is that we don't
> need the FSYNC as well, that would be rather painful to implement.

Am not going to make myself popular here. It's MCLK and FSYNC (or WCLK as it's
termed for our device) that is required for SRM to lock in the PLL.

So far I've not found a way in the codec driver to be able to get around this.
I spent a very long time with Sathya in the early days (Apollo Lake) looking at
options but nothing would fit which is why I have the solution that's in place
right now. We could probably reduce the number of rechecks before timeout in the
driver but that's really just papering over the crack and there's still the
possibility of noise later when SRM finally does lock.