All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org,
	Linux-ALSA <alsa-devel@alsa-project.org>,
	Lars-Peter Clausen <lars@metafoo.de>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Marco Felsch <m.felsch@pengutronix.de>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	Sascha Hauer <kernel@pengutronix.de>
Subject: Re: [PATCH] ASoC: ssm2602: Fix ADC powerup sequencing
Date: Wed, 23 May 2018 11:53:52 -0500	[thread overview]
Message-ID: <20180523165352.GA6187@rob-hp-laptop> (raw)
In-Reply-To: <1526640409.3948.5.camel@pengutronix.de>

On Fri, May 18, 2018 at 12:46:49PM +0200, Philipp Zabel wrote:
> Hi Rob,
> 
> On Thu, 2018-05-17 at 11:14 -0500, Rob Herring wrote:
> > On Thu, May 17, 2018 at 8:30 AM, Marco Felsch <m.felsch@pengutronix.de> wrote:
> > > From: Philipp Zabel <p.zabel@pengutronix.de>
> > > 
> > > According to the ssm2603 data sheet (control register sequencing), the
> > > digital core should be activated only after all necessary bits in the
> > > power register are enabled, and a delay determined by the decoupling
> > > capacitor on the VMID pin has passed. If the digital core is activated
> > > too early, or even before the ADC is powered up, audible artifacts
> > > appear at the beginning of the recorded signal.
> > > 
> > > The digital core is also needed for playback, so when recording starts
> > > it may already be enabled. This means we cannot get the power sequence
> > > correct when we want to be able to start recording after playback.
> > > 
> > > As a workaround put the MIC mute switch into the DAPM routes. This
> > > way we can keep the recording disabled until the MIC Bias has settled
> > > and thus get rid of audible artifacts.
> > > 
> > > The delay we have to wait depends on a board specific capacitor
> > > connected to the VMID pins, so make the delay configurable in the device
> > > tree.
> > > 
> > > Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
> > > ---
> > >  .../devicetree/bindings/sound/adi,ssm2602.txt |  7 +++++
> > >  sound/soc/codecs/ssm2602.c                    | 30 +++++++++++++++++--
> > >  2 files changed, 35 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/sound/adi,ssm2602.txt b/Documentation/devicetree/bindings/sound/adi,ssm2602.txt
> > > index 3b3302fe399b..9334d48c0462 100644
> > > --- a/Documentation/devicetree/bindings/sound/adi,ssm2602.txt
> > > +++ b/Documentation/devicetree/bindings/sound/adi,ssm2602.txt
> > > @@ -11,9 +11,16 @@ Required properties:
> > >    - reg : the I2C address of the device for I2C, the chip select
> > >            number for SPI.
> > > 
> > > +Optional properties:
> > > +
> > > +  - startup-delay-us : delay between powering on and activating the digital
> > > +                       core, determined by the decoupling capacitor C on the
> > > +                      VMID pin: delay [µs] = C [µF] * 25000 / 3.5
> > > +
> > 
> > We already have similarly defined property. Please reuse that. See mmc
> > pwrseq binding.
> 
> Do you mean 'post-power-on-delay-ms' from 'mmc-pwseq-simple'?
> It is documented as:
> 
> - post-power-on-delay-ms : Delay in ms after powering the card and
>         de-asserting the reset-gpios (if any)
> 
> The startup delay here is not after powering the whole IC or deasserting
> resets and before it can be used, but after powering up a specific part
> of the codec (the ADC) and before unmuting the MIC input to the digital
> core during start of decoding. With this in mind, do you still think the
> property should be called the same as the mmc full-chip poweron delay?
> If so, would it be acceptable to use post-power-on-delay-us to keep the
> microsecond resolution?

Okay, then I'd suggest something a bit more specific. Perhaps 
"pre-unmute-delay-us" and document in a common location.

Rob

  reply	other threads:[~2018-05-23 16:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 13:30 [PATCH] ASoC: ssm2602: Fix ADC powerup sequencing Marco Felsch
2018-05-17 16:14 ` Rob Herring
2018-05-18 10:46   ` Philipp Zabel
2018-05-23 16:53     ` Rob Herring [this message]
2018-05-25  9:47       ` Marco Felsch
2018-05-25 10:26         ` Mark Brown
2018-05-25 11:42           ` Marco Felsch
2018-05-25 14:52             ` Mark Brown
2018-05-25 15:18               ` Philipp Zabel
2018-05-25 17:24                 ` Mark Brown
2018-06-05  9:58                   ` Philipp Zabel
2018-06-05 16:06                     ` Mark Brown
2018-05-25 15:42         ` Rob Herring

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=20180523165352.GA6187@rob-hp-laptop \
    --to=robh@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=m.felsch@pengutronix.de \
    --cc=mark.rutland@arm.com \
    --cc=p.zabel@pengutronix.de \
    --cc=s.hauer@pengutronix.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 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.