lkml.org 
[lkml]   [2020]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] ASoC: da7219: check SRM lock in trigger callback
Date
> 
> Could ensure? This change seems specific to Intel DSP based systems, at
> least from the description. Having looked through the core, the trigger code
> for a codec is seemingly always called before the trigger for the CPU. How will
> this work for other platforms, assuming their clocks are enabled in the CPU
> DAI trigger function by default?
>
> Can we always guarantee the CPU side isn't going to send anything other
> than 0s until after SRM has locked?
>

I think the patch is for those systems which enable I2S clocks in pcm_start instead
of pcm_prepare. It has no effect on systems already be able to turn on clocks in
supply widgets or set_bias_level() function.

If the trigger type in the DAI link is TRIGGER_PRE, then the trigger function of FE port
(component or CPU DAI) will be called before codec driver's trigger function. In this
case we will be able to turn on the clock in time. However, if the trigger type is
TRIGGER_POST, then the patch does not help because just like what you said, codec
driver's trigger function is called first.

In my experiment with the patch, the SRM is locked in the second read and cost
50ms to wait.

>
> I was under the impression that 'trigger()' was atomic? We'd have to have
> some kind of workqueue to do all of this, which means we'd almost certainly
> lose some PCM data at the start of a stream.
>


\
 
 \ /
  Last update: 2020-02-11 11:08    [W:0.102 / U:1.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site