Re: [EXTERNAL] Re: [PATCH 1/2] ASoC: cs35l36: Add support for Cirrus CS35L36 Amplifier

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 14, 2018 at 06:54:02PM +0000, Schulman, James wrote:
> On Tue, 13 Nov 2018, Mark Brown wrote:
> > On Tue, Nov 13, 2018 at 12:49:16PM -0600, James Schulman wrote:

> >> +static const struct snd_kcontrol_new cs35l36_boost_mux[] = {
> >> +    SOC_DAPM_ENUM("Boost Enable", boost_enum),
> >> +};

> > Simple on/off conttrols should be _SINGLE controls with Switch at the
> > end of their name.  It's not super clear why this is in DAPM as a widget
> > at all, the routing around it is:

> > +       {"BOOST Mux", "On", "Channel Mux"},
> > +       {"CLASS H", NULL, "BOOST Mux"},

> > which is a bit perplexing.  Possibly this should be handled in the event
> > for the main amplifier?

> We used _ENUM instead of _SINGLE because we wanted the default value to be
> "On" instead of "Off". We don't want the default assumption to have boost
> turned off. However, we're happy to change this if you would rather have
> consitency with the _SINGLE controls.

I don't follow this at all.  Setting a default value for a control is
not related to the type of the control.

> >> +    /*
> >> +     * Rev B0 has 2 versions
> >> +     * L36 is 10V
> >> +     * L37 is 12V

> > \o/

> Yes we had 2 silicon spins for this revision >_< is there anything about
> this comment you want us to change?

You could more explicitly explain what happened here, revisions and
spins are generally synonymous so it's confusing.

> >> +    }
> >> +
> >> +    return IRQ_HANDLED;

> > This unconditionally reports that it handled the interrupt, even if it
> > didn't.  This will stop the interrupt core handling for faulty interrupt
> > lines working and will disrupt any support that gets added for handling
> > shared threaded interrupts.

> Earlier in the handler, we have a check to see if any unmasked bits are
> set. If not we return IRQ_NONE. I figured this would be enough to ensure
> we don't unconditionally report IRQ_HANDLED.

What if something you didn't expect got unmasked by some bug?

> I think we will add an err_disable_regs jump statement to ensure we don't
> try to use the uninitialized reset_gpio handle. Once we do that, I think
> this will handle -EPROBE_DEFER cleanly?

Yes.

Attachment: signature.asc
Description: PGP signature

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

[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux