All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sa, Nuno" <Nuno.Sa@analog.com>
To: "broonie@kernel.org" <broonie@kernel.org>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"lars@metafoo.de" <lars@metafoo.de>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: Re: [PATCH v3 1/2] ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driver
Date: Fri, 11 Oct 2019 07:03:15 +0000	[thread overview]
Message-ID: <944157fe22c59a997e86287ff9cd686be91ac0df.camel@analog.com> (raw)
In-Reply-To: <20191010153623.GD4741@sirena.org.uk>

On Thu, 2019-10-10 at 16:36 +0100, Mark Brown wrote:
> 
> On Thu, Oct 10, 2019 at 03:05:24PM +0000, Sa, Nuno wrote:
> > On Thu, 2019-10-10 at 15:05 +0100, Mark Brown wrote:
> > > You could use regulator_bulk_enable() here (and similarly on
> > > disable) but it doesn't fundamentally matter - they do guarantee
> > > that they'll do things in sequence, though they don't wait for
> > > the ramp to complete before kicking off the next enable in the
> > > sequence which can be an issue for some hardware.
> > Yes, regulator_bulk_enable() could fit. The only thing that worries
> > me
> > is that we only check for errors returned from regulator_enable()
> > after
> > all async work is done (which is probably what you mean by "they
> > don't
> > wait for the ramp to complete before kicking off the next
> > enable...")
> > which could leave us with DVDD applied without IOVDD for a short
> > amount
> > of time. I'm not sure this would be a really issue and that would
> > damage the HW, but from what I can tell from the datasheet, It's
> > not
> > advised to apply DVDD without IOVDD.
> 
> Yeah, exactly.  OTOH things like that (especially for brief time
> periods) are much more likely to result in the chip being in some
> weird state on init which won't matter if we immediately power
> off than anything else.  Like I say it's not a requirement to use
> bulk operations.

Yeah, that's probably right. I can also do some internal querying to
understand if this could really damage the part. If not and since I
have to prepare a v4 either way (for dt bindings), I will use
regulator_bulk_enable().

Nuno Sá
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Sa, Nuno" <Nuno.Sa@analog.com>
To: "broonie@kernel.org" <broonie@kernel.org>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"lars@metafoo.de" <lars@metafoo.de>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: Re: [alsa-devel] [PATCH v3 1/2] ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driver
Date: Fri, 11 Oct 2019 07:03:15 +0000	[thread overview]
Message-ID: <944157fe22c59a997e86287ff9cd686be91ac0df.camel@analog.com> (raw)
In-Reply-To: <20191010153623.GD4741@sirena.org.uk>

On Thu, 2019-10-10 at 16:36 +0100, Mark Brown wrote:
> 
> On Thu, Oct 10, 2019 at 03:05:24PM +0000, Sa, Nuno wrote:
> > On Thu, 2019-10-10 at 15:05 +0100, Mark Brown wrote:
> > > You could use regulator_bulk_enable() here (and similarly on
> > > disable) but it doesn't fundamentally matter - they do guarantee
> > > that they'll do things in sequence, though they don't wait for
> > > the ramp to complete before kicking off the next enable in the
> > > sequence which can be an issue for some hardware.
> > Yes, regulator_bulk_enable() could fit. The only thing that worries
> > me
> > is that we only check for errors returned from regulator_enable()
> > after
> > all async work is done (which is probably what you mean by "they
> > don't
> > wait for the ramp to complete before kicking off the next
> > enable...")
> > which could leave us with DVDD applied without IOVDD for a short
> > amount
> > of time. I'm not sure this would be a really issue and that would
> > damage the HW, but from what I can tell from the datasheet, It's
> > not
> > advised to apply DVDD without IOVDD.
> 
> Yeah, exactly.  OTOH things like that (especially for brief time
> periods) are much more likely to result in the chip being in some
> weird state on init which won't matter if we immediately power
> off than anything else.  Like I say it's not a requirement to use
> bulk operations.

Yeah, that's probably right. I can also do some internal querying to
understand if this could really damage the part. If not and since I
have to prepare a v4 either way (for dt bindings), I will use
regulator_bulk_enable().

Nuno Sá
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel

  reply	other threads:[~2019-10-11  7:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-10  7:42 [PATCH v3 1/2] ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driver Nuno Sá
2019-10-10  7:42 ` [alsa-devel] " Nuno Sá
2019-10-10  7:42 ` [PATCH v3 2/2] dt-bindings: asoc: Add ADAU7118 documentation Nuno Sá
2019-10-10  7:42   ` [alsa-devel] " Nuno Sá
2019-10-10 21:08   ` Rob Herring
2019-10-10 21:08     ` [alsa-devel] " Rob Herring
2019-10-11 19:01     ` Rob Herring
2019-10-11 19:01       ` [alsa-devel] " Rob Herring
2019-10-10 14:05 ` [PATCH v3 1/2] ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driver Mark Brown
2019-10-10 14:05   ` [alsa-devel] " Mark Brown
2019-10-10 15:05   ` Sa, Nuno
2019-10-10 15:05     ` [alsa-devel] " Sa, Nuno
2019-10-10 15:36     ` Mark Brown
2019-10-10 15:36       ` [alsa-devel] " Mark Brown
2019-10-11  7:03       ` Sa, Nuno [this message]
2019-10-11  7:03         ` Sa, Nuno

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=944157fe22c59a997e86287ff9cd686be91ac0df.camel@analog.com \
    --to=nuno.sa@analog.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lars@metafoo.de \
    --cc=lgirdwood@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=tiwai@suse.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.