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