From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Kuninori Morimoto <morimoto.kuninori@renesas.com>,
alsa-devel@alsa-project.org, linux-sh@vger.kernel.org,
Magnus Damm <damm@opensource.se>,
Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH 1/4 v4] ASoC: add a WM8978 codec driver
Date: Mon, 1 Feb 2010 14:31:20 +0000 [thread overview]
Message-ID: <20100201143120.GA26011@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <Pine.LNX.4.64.1001291452110.4613@axis700.grange>
On Fri, Jan 29, 2010 at 02:57:34PM +0100, Guennadi Liakhovetski wrote:
> On Wed, 27 Jan 2010, Mark Brown wrote:
> > I'm fairly sure this and the similar logic for SYSCLK can be squashed
> > together with some suitable local variables. Might be more legible
> > since this requires some staring at. I didn't actually go so far as to
> > work out what the relevant code is, though.
> Well, not really. In one case f_PLLOUT can be derived directly, because
> OPCLKDIV covers the whole its value range 1-4, whereas MCLKDIV takes
> values 1, 3/2, 2, 3, 4, 6, 8, 12, so, you have to apply an iterative
> process to select the best match. I've just sent a patch, that improves
I don't follow your logic there at all, I'm afraid. Both options have a
table of possible values for the divider (and hence the PLL output
frequencies they can use) which they need to additionally constrain
based on the PLL operating conditions.
Looking at the code I think half the issue here is that all the
constraints that are shared from the PLL and its input path aren't
factored out but are in per-output conditional cases, making those more
complex than they need to be. The magic number heaviness of the code
and comments accentuates the issue.
next prev parent reply other threads:[~2010-02-01 14:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-27 17:56 [PATCH 1/4 v4] ASoC: add a WM8978 codec driver Guennadi Liakhovetski
2010-01-27 20:17 ` Mark Brown
2010-01-28 8:24 ` Guennadi Liakhovetski
2010-01-28 19:01 ` Dan Williams
2010-01-29 13:57 ` Guennadi Liakhovetski
2010-02-01 14:31 ` Mark Brown [this message]
2010-02-01 20:01 ` Guennadi Liakhovetski
2010-02-03 10:34 ` 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=20100201143120.GA26011@rakim.wolfsonmicro.main \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=damm@opensource.se \
--cc=g.liakhovetski@gmx.de \
--cc=linux-sh@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=morimoto.kuninori@renesas.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).