Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: "Sa, Nuno" <Nuno.Sa@analog.com>
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>,
	"tiwai@suse.com" <tiwai@suse.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>
Subject: Re: [alsa-devel] [PATCH 1/2] ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driver
Date: Mon, 30 Sep 2019 16:11:32 +0100	[thread overview]
Message-ID: <20190930151132.GA4265@sirena.co.uk> (raw)
In-Reply-To: <6245f99f37c10dcec0a52344bab4b980f08e07da.camel@analog.com>


[-- Attachment #1.1: Type: text/plain, Size: 2767 bytes --]

On Mon, Sep 30, 2019 at 09:44:00AM +0000, Sa, Nuno wrote:
> On Thu, 2019-09-26 at 11:43 -0700, Mark Brown wrote:

> > > +	case SND_SOC_DAIFMT_RIGHT_J:
> > > +		st->right_j = true;
> > > +		break;

> > Don't we need to set any register values here?

> The register set is done in adau7118_hw_params(). For right
> justification the device can delay bclck by 8, 12 or 16. So, We need to
> know the data_width to check if we can apply the configuration.

OK.

> > > +	case SND_SOC_BIAS_STANDBY:
> > > +		if (snd_soc_component_get_bias_level(component) ==
> > > +							SND_SOC_BIAS_OF
> > > F) {
> > > +			if (!st->iovdd)
> > > +				return 0;

> > This is broken, the device will always require power so it should
> > always control the regulators.

> The reason why I made this optional was to let the user assume that, in
> some cases, the supply can be always present (and not controlled by the
> kernel) and, in those cases, he would not have to care about giving
> regulators nodes in devicetree. Furthermore, the driver would not have

Have you tried doing that?  Notice how the regulator API subtitutes in a
dummy regulator for you and the driver works fine without custom code.

> to care about enabling/disabling  regulators. Is this not a valid
> scenario? Or is it that, for this kind of devices it does not really

It's not a valid scenario in driver code - the driver shouldn't be
randomly ignoring errors and hoping the errors were deliberate rather
than indiciations of real problems.

> > > +static int adau7118_resume(struct snd_soc_component *component)
> > > +{
> > > +	return snd_soc_component_force_bias_level(component,
> > > +						  SND_SOC_BIAS_STANDBY)
> > > ;
> > > +}

> > Let DAPM do this for you, there's no substantial delays on power
> > on so you're probably best just setting idle_bias_off.

> So, this means dropping resume/suspend and to not set idle_bias_on,
> right?

Right.  Like I say it looks like your power up path is fast enough for
this.

> > > +static int adau7118_regulator_setup(struct adau7118_data *st)
> > > +{
> > > +	int ret = 0;
> > > +
> > > +	st->iovdd = devm_regulator_get_optional(st->dev, "IOVDD");
> > > +	if (!IS_ERR(st->iovdd)) {

> > Unless the device can operate with supplies physically absent it
> > should not be requesting regulators as optional, this breaks your
> > error handling especially with probe deferral which is a fairly
> > common case.

> Just for my understanding (most likely I'm missing something obvious),
> why would I have issues with the error handling in probe deferral?

Actually it does look like you handle this correctly further down, the
normal pattern would have been to have the error handling inside the if
here and not indent the rest of the success path so I misread it.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 161 bytes --]

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

  reply	other threads:[~2019-09-30 15:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-26  7:17 [alsa-devel] [PATCH 1/2] ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driver Nuno Sá
2019-09-26  7:17 ` [alsa-devel] [PATCH 2/2] dt-bindings: asoc: Add ADAU7118 documentation Nuno Sá
2019-09-26 18:44   ` Mark Brown
2019-09-26 15:07 ` [alsa-devel] [PATCH 1/2] ASOC: Add ADAU7118 8 Channel PDM-to-I2S/TDM Converter driver Mark Brown
2019-09-26 15:21   ` Sa, Nuno
2019-09-26 18:43 ` Mark Brown
2019-09-30  9:44   ` Sa, Nuno
2019-09-30 15:11     ` Mark Brown [this message]
2019-10-02  8:09       ` 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=20190930151132.GA4265@sirena.co.uk \
    --to=broonie@kernel.org \
    --cc=Nuno.Sa@analog.com \
    --cc=alsa-devel@alsa-project.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox