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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 5 Feb 2019 10:35:49 -0800
From:   Bjorn Andersson <bjorn.andersson@...aro.org>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     andy.gross@...aro.org, david.brown@...aro.org,
        linux-arm-msm@...r.kernel.org, linux-soc@...r.kernel.org,
        linux-kernel@...r.kernel.org, bgoswami@...eaurora.org,
        rohitkr@...eaurora.org
Subject: Re: [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@...aro.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
>