lkml.org 
[lkml]   [2019]   [Feb]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] qcom: apr: Make apr callbacks in non-atomic context
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
>

\
 
 \ /
  Last update: 2019-02-05 19:36    [W:0.205 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site