From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
To: Sergej Sawazki <ce3a@gmx.de>
Cc: alsa-devel@alsa-project.org, broonie@kernel.org,
lgirdwood@gmail.com, patches@opensource.wolfsonmicro.com
Subject: Re: [PATCH] ASoC: wm8741: Remove unneeded startup() callback
Date: Tue, 31 Jan 2017 09:49:31 +0000 [thread overview]
Message-ID: <20170131094931.GG1754@localhost.localdomain> (raw)
In-Reply-To: <1c9d48c3-770b-3048-23d2-afc22f221077@gmx.de>
On Mon, Jan 30, 2017 at 11:56:52PM +0100, Sergej Sawazki wrote:
> On Mon, 30 Jan 2017 09:22:59 +0000, Charles Keepax wrote:
> > On Sat, Jan 28, 2017 at 12:35:45AM +0100, Sergej Sawazki wrote:
> >> Do not apply rate constraints in the startup() callback. The machine driver
> >> can change the sysclk and hence the supported frame rates in its hw_params().
> >> This callback is unneeded since commit e369bd006fd6 ("ASoC: wm8741: Allow
> >> master clock switching").
>
> > This function should not be removed it is performing a useful
> > function. If a sysclk has already been configured by the machine
> > driver then we should inform user-space of the rates we can
> > support from that clock. Without this that information is not
> > available to user-space, so instead of user-space being able to
> > resample appropriately it would just error out from hw_params.
> >
> > Are you perhaps missing a call to clear the sysclk from your
> > machine driver? Usually a dai_set_sysclk call with a rate of
> > zero, also I find if it is a machine driver supporting multiple
> > rates you are best to use ignore_pmdown_time on the DAI link,
> > assuming the devices don't have long bring up times.
>
> After clearing the sysclk, the codec should 'pretend' to support all
> rates, right? (no sysclk -> no rate constrains)
>
Indeed yes, so a normal pattern would often be setting a sysclk
rate in set_bias_level(on the way up)/hw_params and clearing it in
set_bias_level(on the way down). That way whilst the device is
powered up it is fixed at a certain rate so as not to disrupt any
running audio but whilst powered down you are free to start it up
at any rate.
> After applying rate constraints using snd_pcm_hw_constraint_list(...),
> what would be a clean way to remove the constraints from the rates
> parameter?
>
I am not sure I fully follow here, normally one would close the
stream and open a new one at the new rate. Hence no need to clear
the constraits as its a new stream. Are you intending to keep the
stream open but reconfigure it for new rates?
Thanks,
Charles
next prev parent reply other threads:[~2017-01-31 9:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-27 23:35 [PATCH] ASoC: wm8741: Remove unneeded startup() callback Sergej Sawazki
2017-01-30 9:22 ` Charles Keepax
2017-01-30 22:56 ` Sergej Sawazki
2017-01-31 9:49 ` Charles Keepax [this message]
2017-01-31 20:38 ` Sergej Sawazki
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=20170131094931.GG1754@localhost.localdomain \
--to=ckeepax@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=ce3a@gmx.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 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).