From: Marco Felsch <m.felsch@pengutronix.de>
To: Rob Herring <robh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Linux-ALSA <alsa-devel@alsa-project.org>,
Lars-Peter Clausen <lars@metafoo.de>,
kernel@pengutronix.de, Sascha Hauer <s.hauer@pengutronix.de>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>
Subject: Re: [PATCH] ASoC: ssm2602: Fix ADC powerup sequencing
Date: Fri, 25 May 2018 11:47:24 +0200 [thread overview]
Message-ID: <20180525094724.3f4edofopk52i3v6@pengutronix.de> (raw)
In-Reply-To: <20180523165352.GA6187@rob-hp-laptop>
Hi Rob,
On 18-05-23 11:53, Rob Herring wrote:
> 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
The delay is not just for the line-in/mic path it is also for the out
path. More technical, it is needed to charge the decouple capacity which
provides the voltage bias for the analog input/output frontends.
I found the: "ti,charge-period (sound/ti,tas5086.txt)" binding which
represents nearly the same but it is not common. One opportunity would be to
introduce a common "charge-period-us" binding and change the ti binding the
common binding later.
Would that be okay?
Marco
next prev parent reply other threads:[~2018-05-25 9:47 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
2018-05-25 9:47 ` Marco Felsch [this message]
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=20180525094724.3f4edofopk52i3v6@pengutronix.de \
--to=m.felsch@pengutronix.de \
--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=mark.rutland@arm.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--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 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).