From: Mark Brown <broonie@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
patches@opensource.wolfsonmicro.com, alsa-devel@alsa-project.org,
lgirdwood@gmail.com
Subject: Re: [PATCH] ASoC: arizona: Check clocking during hw_params rather than startup
Date: Fri, 24 Jan 2014 17:37:54 +0000 [thread overview]
Message-ID: <20140124173754.GD11727@sirena.org.uk> (raw)
In-Reply-To: <52E2A1F2.6070707@metafoo.de>
[-- Attachment #1.1: Type: text/plain, Size: 1301 bytes --]
On Fri, Jan 24, 2014 at 06:25:06PM +0100, Lars-Peter Clausen wrote:
> The problem with this approach is that if the sysclk is fixed instead to
> e.g. falling back to rate conversion you'll get an error instead when
> calling hw_params. The typical idiom here is to only apply the rate
> constraints in the CODEC driver if the sysclk is non zero. This driver
> already seems to do this. The problem that you probably see is that if the
> machine driver changes the sysclk value in hw_params the constraints that
Thanks, that's about what I was going to write. The current theory is
that setting the sysclk to zero is the equivalent of a dynamic SYSCLK
flag - with the extensive use of charge pumps and so on in modern
devices on the fly reclocking is normally difficult to do safely so the
idea is that if the machine driver is in a position to reclock it should
set the clock to zero.
> are setup are still setup with the previous sysclk in mind. I think instead
> of removing the constraints support altogether from the driver a better
> solution is to introduce a dynamic_sysclk or similar attribute to the DAI
> link and not constrain the supported rates if this attribute is set to true.
It would be useful to have this more in the core rather than open coded,
as with the sample size stuff.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2014-01-24 17:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-24 16:59 [PATCH] ASoC: arizona: Check clocking during hw_params rather than startup Charles Keepax
2014-01-24 17:25 ` Lars-Peter Clausen
2014-01-24 17:37 ` Mark Brown [this message]
2014-01-27 7:17 ` Lars-Peter Clausen
2014-01-27 10:55 ` Mark Brown
2014-01-27 11:25 ` 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=20140124173754.GD11727@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=ckeepax@opensource.wolfsonmicro.com \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=patches@opensource.wolfsonmicro.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.