On Mon, 2019-09-30 at 16:11 +0100, Mark Brown wrote:
>
> 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.
Ok, got it. Looking at `_regulator_get` I can see that a dummy
regulator is provided, when `NORMAL_GET` is used, even if one was not
given. So I think I get now the usage of
`devm_regulator_get_optional`. As you said, supply voltages are not
optional, the optional _get_ should be used for things that are really
optional like some parts that can use external vs internal vref.
> > 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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
