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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 31 Jan 2019 08:05:51 -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 02:44 PST 2019, Srinivas Kandagatla wrote:

> 
> 
> On 31/01/2019 01:16, Bjorn Andersson wrote:
> > On Thu 15 Nov 10:49 PST 2018, Srinivas Kandagatla wrote:
> > 
> > > APR communication with DSP is not atomic in nature.
> > > Its request-response type. Trying to pretend that these are atomic
> > > and invoking apr client callbacks directly under atomic/irq context has
> > > endless issues with soundcard. It makes more sense to convert these
> > > to nonatomic calls. This also coverts all the dais to be nonatomic.
> > > 
> > Hi Srinivas,
> > 
> > Sorry for not looking at this before.
> > 
> NP, thanks for the review!
> 
> > Are you sure that you're meeting the latency requirements of low-latency
> > audio with this change?
> 
> Low and Ultra Low Latency audio is not supported in the exiting upstream
> qdsp drivers.
> 

Sure, but we want the design to allow for that still, either in future
upstream or by additional downstream code.

> 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.

Regards,
Bjorn