All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: Daniel Baluta <daniel.baluta@nxp.com>,
	<alsa-devel@alsa-project.org>, <shengjiu.wang@freescale.com>,
	<patches@opensource.wolfsonmicro.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Mark Brown <broonie@kernel.org>, <viorel.suman@nxp.com>,
	<mihai.serban@nxp.com>, Takashi Iwai <tiwai@suse.com>
Subject: Re: [alsa-devel] [PATCH v2 2/2] ASoC: codec: wm8960: Relax bit clock computation
Date: Tue, 21 Mar 2017 14:31:17 +0000	[thread overview]
Message-ID: <20170321143117.GZ6986@localhost.localdomain> (raw)
In-Reply-To: <CAEnQRZC1d5M_Sh5Q7k3FHn-634_7psR-8XZp9-tfhEcyNM26tw@mail.gmail.com>

On Tue, Mar 21, 2017 at 04:25:40PM +0200, Daniel Baluta wrote:
> On Tue, Mar 21, 2017 at 4:20 PM, Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com> wrote:
> > On Tue, Mar 21, 2017 at 04:05:15PM +0200, Daniel Baluta wrote:
> >> On Tue, Mar 21, 2017 at 2:52 PM, Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com> wrote:
> >> > On Tue, Mar 21, 2017 at 12:09:36PM +0200, Daniel Baluta wrote:
> >> >>       * use a marker to check if a match is found
> >> >>       * didn't removed PLL as Charles suggested because there is
> >> >>       a special PLL mode which explictly uses PLL. We could start
> >> >>       a discussion on not using PLL when deriving bitclk, but this
> >> >>       is to be done in another patch.
> >> >>
> >> >
> >> > Could you elaborate on this a little more am I not sure I follow
> >> > 100%? There is a mode which explictly requires the PLL to be used
> >> > (WM8960_SYSCLK_PLL) but in that case your wm8960_configure_sysclk
> >> > code will not be called so I don't see what is causing that to have
> >> > an effect on this patch?
> >>
> >> My doubt is, what happens if wm8960_configure_clocking is called with
> >> wm8960->clk_id = WM8960_SYSCLK_PLL and we remove the PLL
> >> as suggested.
> >
> > I wasn't suggesting removing the PLL just that if we find a
> > "relaxed match" we don't need to then check the PLL for a better
> > match, as I suspect that a slightly higher than needed bit clock
> > has less power/performance impact than firing up the PLL.
> >
> > Which removes the need to differenciate between a relaxed and
> > bang on match in wm8960_configure_sysclk and means you don't have
> > to do the caching the values across the PLL code that you do now.
> 
> Oh, I see. So we still use the PLL when no exact or relaxed match
> is found.

Yeah exactly or in the case that it is requested directly.

Thanks,
Charles

WARNING: multiple messages have this Message-ID (diff)
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: alsa-devel@alsa-project.org, shengjiu.wang@freescale.com,
	patches@opensource.wolfsonmicro.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	viorel.suman@nxp.com, mihai.serban@nxp.com,
	Takashi Iwai <tiwai@suse.com>,
	Daniel Baluta <daniel.baluta@nxp.com>
Subject: Re: [PATCH v2 2/2] ASoC: codec: wm8960: Relax bit clock computation
Date: Tue, 21 Mar 2017 14:31:17 +0000	[thread overview]
Message-ID: <20170321143117.GZ6986@localhost.localdomain> (raw)
In-Reply-To: <CAEnQRZC1d5M_Sh5Q7k3FHn-634_7psR-8XZp9-tfhEcyNM26tw@mail.gmail.com>

On Tue, Mar 21, 2017 at 04:25:40PM +0200, Daniel Baluta wrote:
> On Tue, Mar 21, 2017 at 4:20 PM, Charles Keepax
> <ckeepax@opensource.wolfsonmicro.com> wrote:
> > On Tue, Mar 21, 2017 at 04:05:15PM +0200, Daniel Baluta wrote:
> >> On Tue, Mar 21, 2017 at 2:52 PM, Charles Keepax
> >> <ckeepax@opensource.wolfsonmicro.com> wrote:
> >> > On Tue, Mar 21, 2017 at 12:09:36PM +0200, Daniel Baluta wrote:
> >> >>       * use a marker to check if a match is found
> >> >>       * didn't removed PLL as Charles suggested because there is
> >> >>       a special PLL mode which explictly uses PLL. We could start
> >> >>       a discussion on not using PLL when deriving bitclk, but this
> >> >>       is to be done in another patch.
> >> >>
> >> >
> >> > Could you elaborate on this a little more am I not sure I follow
> >> > 100%? There is a mode which explictly requires the PLL to be used
> >> > (WM8960_SYSCLK_PLL) but in that case your wm8960_configure_sysclk
> >> > code will not be called so I don't see what is causing that to have
> >> > an effect on this patch?
> >>
> >> My doubt is, what happens if wm8960_configure_clocking is called with
> >> wm8960->clk_id = WM8960_SYSCLK_PLL and we remove the PLL
> >> as suggested.
> >
> > I wasn't suggesting removing the PLL just that if we find a
> > "relaxed match" we don't need to then check the PLL for a better
> > match, as I suspect that a slightly higher than needed bit clock
> > has less power/performance impact than firing up the PLL.
> >
> > Which removes the need to differenciate between a relaxed and
> > bang on match in wm8960_configure_sysclk and means you don't have
> > to do the caching the values across the PLL code that you do now.
> 
> Oh, I see. So we still use the PLL when no exact or relaxed match
> is found.

Yeah exactly or in the case that it is requested directly.

Thanks,
Charles

  reply	other threads:[~2017-03-21 14:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-21 10:09 [PATCH v2 0/2] wm8960: Relax bit clock computation Daniel Baluta
2017-03-21 10:09 ` Daniel Baluta
2017-03-21 10:09 ` [PATCH v2 1/2] ASoC: codec: wm8960: Refactor sysclk freq search Daniel Baluta
2017-03-21 10:09   ` Daniel Baluta
2017-03-21 12:43   ` Charles Keepax
2017-03-21 12:43     ` Charles Keepax
2017-03-24 19:16   ` Applied "ASoC: codec: wm8960: Refactor sysclk freq search" to the asoc tree Mark Brown
2017-03-24 19:16     ` Mark Brown
2017-03-21 10:09 ` [PATCH v2 2/2] ASoC: codec: wm8960: Relax bit clock computation Daniel Baluta
2017-03-21 10:09   ` Daniel Baluta
2017-03-21 12:52   ` Charles Keepax
2017-03-21 12:52     ` Charles Keepax
2017-03-21 14:05     ` [alsa-devel] " Daniel Baluta
2017-03-21 14:05       ` Daniel Baluta
2017-03-21 14:20       ` [alsa-devel] " Charles Keepax
2017-03-21 14:20         ` Charles Keepax
2017-03-21 14:25         ` [alsa-devel] " Daniel Baluta
2017-03-21 14:25           ` Daniel Baluta
2017-03-21 14:31           ` Charles Keepax [this message]
2017-03-21 14:31             ` Charles Keepax

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=20170321143117.GZ6986@localhost.localdomain \
    --to=ckeepax@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=daniel.baluta@gmail.com \
    --cc=daniel.baluta@nxp.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mihai.serban@nxp.com \
    --cc=patches@opensource.wolfsonmicro.com \
    --cc=shengjiu.wang@freescale.com \
    --cc=tiwai@suse.com \
    --cc=viorel.suman@nxp.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.