Re: [PATCH] qcom: apr: Make apr callbacks in non-atomic context

[Bjorn Andersson <bjorn.andersson@linaro.org>]

On Thu 31 Jan 09:33 PST 2019, Srinivas Kandagatla wrote:

> On 31/01/2019 16:05, Bjorn Andersson wrote:
> > Sure, but we want the design to allow for that still, either in future
> > upstream or by additional downstream code.
> > 
> Yes, I agree, I don't have solution for this ATM.
> It will be interesting to see how Intel handles this kind of usecase on
> there DSP.
> 
> The whole issue is the APR messaging is not really atomic in nature, it is
> basically request->response but the fact in existing code is that smd/glink
> callbacks run in interrupt context.
> 
> Trying to pretend that APR is atomic in nature is problem with audio.
> 
> As audio (dai-links) can be marked as atomic or non-atomic depending on
> which bus it links with, for example when it has to work with other buses
> like slimbus, soundwire, i2c whose transactions can sleep we mark the audio
> dai-link as non-atomic which means that the functions can sleep.
> In the above case, invoking any audio functions as part of the rpmsg
> callback is an issue.
> 
> The only solution I found to address this is handle the callbacks in
> workqueue.
> 

Okay, I think we should merge this and once we have the means of doing
low latency playback we can measure and worst case revisit this
decision.

Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>

Regards,
Bjorn

> > > Also it depends on definition of "latency", is the latency referring to
> > > "filling the data" or "latency between DSP command and response".
> > > 
> > I'm referring to the latency between the message from the DSP until we
> > give it a new buffer.
> > 
> > > For former case as long as we have more samples in our ring buffer there
> > > should be no latency in filling the data.
> > > For later case it should not really matter as long as former case is taken
> > > care off.
> > > 
> > > Low latency audio involves smaller sample sizes and no or minimal
> > > preprocessing in DSP so am guessing that we should be okay with responses in
> > > workqueue as long as we have good size ring buffer.
> > > 
> > Relying on more buffered data will increase the latency of the audio,
> > preventing you from doing really low-latency things.
> My bad!.. Yes, in low latency case we would have very less buffers!
> 
> srini
>