[PATCH 2/2] ASoC: codec: tlv320adc3xxx: New codec driver

Ricard Wanderlof ricardw at axis.com
Mon Oct 25 18:01:04 CEST 2021


On Mon, 4 Oct 2021, Mark Brown wrote:

> > > > +static const char * const micbias_voltage[] = { "off", "2V", "2.5V", 
> > > > "AVDD" };
> 
> > > This should be configured in the DT, it's going to be a property of the
> > > electrical design of the system.
> 
> > I can very well imagine that this something that should be runtime 
> > userspace configurable. In fact where I work we have had products where 
> > the bias voltage (for an externally connected microphone) could be 
> > configured by the end user, (although not for this specific driver quite 
> > honestly, we have had the need for hardware engineers to change it runtime 
> > during circuit verification though).
> 
> > Would it be ok to have this configurable both in the DT as well as using a 
> > control? Or should it be implemented in another way, such as a number of 
> > pre set voltages that are selected between using a control?
> 
> It seems like a lot less work to just not have the runtime control and
> let someone who needs it figure out how to represent it to userspace.
> Something that's basically a backdoor for validation doesn't seem
> persuasive, validation often wants to do things we actively wish to
> prevent at runtime.

I'll add it to the DT configuration, but I can't really see why the having 
an additional runtime control would be a lot of extra work.

In a completely embedded system where the microphone is part of the 
internal design it makes sense not to have it controllable of course, but 
in a system where the microphone is an external component (i.e. plugged 
into a microphone connector), the system design might need for it to be 
user configurable.

/Ricard
-- 
Ricard Wolf Wanderlof                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30


More information about the Alsa-devel mailing list