All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Lindgren <tony@atomide.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: alsa-devel@alsa-project.org,
	Linux OMAP List <linux-omap@vger.kernel.org>,
	Matt Ranostay <matt@ranostay.consulting>
Subject: Re: [PATCH v3] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches
Date: Mon, 5 Dec 2016 07:30:29 -0800	[thread overview]
Message-ID: <20161205153028.GK4705@atomide.com> (raw)
In-Reply-To: <730ed491-ebe7-86c1-b131-5d9441ae2b7c@ti.com>

* Peter Ujfalusi <peter.ujfalusi@ti.com> [161205 01:35]:
> On 12/04/2016 03:33 AM, Matt Ranostay wrote:
> >>> + *
> >>> + * Also setting of the QoS latency for the FIFO which varies upon the buffer
> >>> + * size. Approximately 2.3 milliseconds per FIFO location.
> >>>   */
> >>>  void omap_mcbsp_start(struct omap_mcbsp *mcbsp, int tx, int rx)
> >>>  {
> >>>       int enable_srg = 0;
> >>> +     int latency = mcbsp->pdata->buffer_size * 23;
> >>
> >> I think this is not correct.
> >> The McBSP FIFO time depends on the sample rate and on the number of
> >> channels the audio is using. With 8KHz mono you have 12 times more time
> >> per FIFO element compared to 48KHz stereo.
> >>
> >> As it has been discussed with Tony we should calculate the QoS latency
> >> in hw_params:
> >>
> > 
> > Ok yeah missed that part of the thread but it makes sense. Just one
> > question should the latency value be only based on the TX FIFO
> > threshold? I assume capture and transmit have two different settings.
> 
> Yes, I believe we should apply the lowest QoS when both direction is
> active. If the second stream needs lower QoS, we should switch to use
> that, if it would need longer, we should keep the QoS placed for the
> first stream.

Sounds good to me.

Regards,

Tony

      reply	other threads:[~2016-12-05 15:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1480555145-8300-1-git-send-email-matt@ranostay.consulting>
2016-12-02  8:23 ` [PATCH v3] ASoC: omap-mcbsp: Add PM QoS support for McBSP to prevent glitches Peter Ujfalusi
2016-12-02  8:26   ` Peter Ujfalusi
2016-12-04  1:33   ` Matt Ranostay
2016-12-05  9:35     ` Peter Ujfalusi
2016-12-05 15:30       ` Tony Lindgren [this message]

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=20161205153028.GK4705@atomide.com \
    --to=tony@atomide.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=matt@ranostay.consulting \
    --cc=peter.ujfalusi@ti.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.