mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Nicolin Chen <Guangyu.Chen@freescale.com>
Cc: lgirdwood@gmail.com, alsa-devel@alsa-project.org, tiwai@suse.de,
	perex@perex.cz, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3] ASoC: fsl: imx-wm8962: Grant hw_params/free() permission to control FLL
Date: Wed, 18 Dec 2013 11:57:03 +0000	[thread overview]
Message-ID: <20131218115703.GL28455@sirena.org.uk> (raw)
In-Reply-To: <20131218051334.GA7648@MrMyself>

[-- Attachment #1: Type: text/plain, Size: 1288 bytes --]

On Wed, Dec 18, 2013 at 01:13:36PM +0800, Nicolin Chen wrote:
> On Tue, Dec 17, 2013 at 10:50:02PM +0000, Mark Brown wrote:

> > I do think refcounting from both here and the bias level changes is
> > going to be the most robust thing, that'd also avoid the need to peer
> > into the CODEC register map.

> I've tried count reference way to handle FLL enabler/disabler here before
> I sent this version. But the result shows the FLL would be never disabled
> in hw_free() because the refcount is accumulated to 2, one from hw_params()
> and the other from set_bias_level(PREPARE), which just made this patch
> meaningless to me.

Well, it gets the clocking configured early which was part of the goal I
thought to ensure smoother startup.

> So the reclocking with bypass checking seems to be the last resort I can
> figure out right here as the playback flow for 'aplay -Dhw:0 44k16bit.wav
> 48k24bit.wav' does need to reprogram the FLL during CODEC active.

That's the other bit.  It should be possible for the machine driver to
disable all outputs prior to reprogramming the FLL, though this will
obviously glitch bypass paths.  One way of doing it would be to have
something that does the reprogramming but only if there is actually a
change - that way the common case is unaffected.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

      reply	other threads:[~2013-12-18 11:57 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-12  9:59 Nicolin Chen
2013-12-17 22:50 ` Mark Brown
2013-12-18  5:13   ` Nicolin Chen
2013-12-18 11:57     ` Mark Brown [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=20131218115703.GL28455@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Guangyu.Chen@freescale.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=perex@perex.cz \
    --cc=tiwai@suse.de \
    /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

all inboxes | Powered by JetHome®