All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc: broonie@kernel.org, perex@perex.cz, tiwai@suse.com,
	krzysztof.kozlowski@linaro.org, linux-sound@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	dmitry.baryshkov@linaro.org, johan+linaro@kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH v5 2/5] ASoC: q6apm: add q6apm_get_hw_pointer helper
Date: Thu, 10 Apr 2025 09:16:56 +0200	[thread overview]
Message-ID: <Z_dwaEMoavqsGOEw@hovoldconsulting.com> (raw)
In-Reply-To: <7222bbbd-51f7-43b6-9755-29808833cf5f@linaro.org>

On Tue, Apr 08, 2025 at 09:07:27AM +0100, Srinivas Kandagatla wrote:
> On 07/04/2025 12:25, Johan Hovold wrote:
> > On Fri, Mar 14, 2025 at 05:47:57PM +0000, Srinivas Kandagatla wrote:
> >> From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> >>
> >> Implement an helper function in q6apm to be able to read the current
> >> hardware pointer for both read and write buffers.
> >>
> >> This should help q6apm-dai to get the hardware pointer consistently
> >> without it doing manual calculation, which could go wrong in some race
> >> conditions.

> >> @@ -553,6 +567,8 @@ static int graph_callback(struct gpr_resp_pkt *data, void *priv, int op)
> >>   		rd_done = data->payload;
> >>   		phys = graph->tx_data.buf[hdr->token].phys;
> >>   		mutex_unlock(&graph->lock);
> >> +		/* token numbering starts at 0 */
> >> +		atomic_set(&graph->tx_data.hw_ptr, hdr->token + 1);
> >>   
> >>   		if (upper_32_bits(phys) == rd_done->buf_addr_msw &&
> >>   		    lower_32_bits(phys) == rd_done->buf_addr_lsw) {
> > 
> > 			graph->result.opcode = hdr->opcode;
> >                          graph->result.status = rd_done->status;
> >                          if (graph->cb)
> >                                  graph->cb(client_event, hdr->token, data->payload, graph->priv);
> >                  } else {
> >                          dev_err(dev, "RD BUFF Unexpected addr %08x-%08x\n", rd_done->buf_addr_lsw,
> >                                  rd_done->buf_addr_msw);
> >                  }
> > 
> > I just hit the following error on the T14s with 6.15-rc1 that I've never
> > seen before and which looks like it could be related to this series:

> Its unlikely, but the timings have changed here.
> I have not seen it either, but I will try to reproduce this with 6.15-rc1.
> > 
> > 	q6apm-dai 6800000.remoteproc:glink-edge:gpr:service@1:dais: RD BUFF Unexpected addr ffe0d200-00000001
> > 
> > Any ideas about what may be causing this?

> How easy is this to reproduce?

I've only noticed this error once on the first boot of 6.15-rc1, and it
does not seem to show up again now.

I did a fair bit of testing with this series on 6.14-rcs, but did not
check the logs while doing so (and there's nothing in the logs I still
have).

Johan

  reply	other threads:[~2025-04-10  7:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-14 17:47 [PATCH v5 0/5] ASoC: q6apm: fix under runs and fragment sizes srinivas.kandagatla
2025-03-14 17:47 ` [PATCH v5 1/5] ASoC: q6apm-dai: schedule all available frames to avoid dsp under-runs srinivas.kandagatla
2025-03-14 17:47 ` [PATCH v5 2/5] ASoC: q6apm: add q6apm_get_hw_pointer helper srinivas.kandagatla
2025-04-07 11:25   ` Johan Hovold
2025-04-08  8:07     ` Srinivas Kandagatla
2025-04-10  7:16       ` Johan Hovold [this message]
2025-03-14 17:47 ` [PATCH v5 3/5] ASoC: q6apm-dai: make use of q6apm_get_hw_pointer srinivas.kandagatla
2025-03-31 12:32   ` Mark Brown
2025-03-31 13:22     ` Johan Hovold
2025-03-31 14:00       ` Mark Brown
2025-03-31 15:35   ` Christopher Obbard
2025-03-14 17:47 ` [PATCH v5 4/5] ASoC: qdsp6: q6apm-dai: set 10 ms period and buffer alignment srinivas.kandagatla
2025-03-14 17:48 ` [PATCH v5 5/5] ASoC: qdsp6: q6apm-dai: fix capture pipeline overruns srinivas.kandagatla
2025-03-31 18:23 ` [PATCH v5 0/5] ASoC: q6apm: fix under runs and fragment sizes Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z_dwaEMoavqsGOEw@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=broonie@kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=johan+linaro@kernel.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=srinivas.kandagatla@linaro.org \
    --cc=stable@vger.kernel.org \
    --cc=tiwai@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.