On Mon, Sep 19, 2016 at 03:11:00AM +0000, Oder Chiou wrote: > > On Tue, Aug 23, 2016 at 01:33:43PM +0800, Oder Chiou wrote: > > > +- realtek,use-ldo2 > > This would more normally be done by making LDO2 a regulator via the > > normal regulator framework - look at how the arizona drivers handle > > DCVDD for an example, it provides a default supply mapping which makes > > things really easy for users. Right now it's not clear to me looking at > > the code that the driver works for systems that don't use an internal > > LDO as there's nothing that enables MICVDD. > The LDO2 is not a regulator, and it is an internal LDO of codec that > controlled by register setting. Normally, the MICVDD is connected to 3.3V It's an internal regulator in the CODEC. > VDD directly, and it isn't controlled by regulator. The option > "realtek,use-ldo2" is depend on the customer that can decide that the MICVDD > is provided by external 3.3V VDD or internal LDO2 for it. If they used the > internal LDO2, the pin of MICVDD can be floated. Sure, that's exactly what it looks like so my comments above apply. > > We do a reset when we unregister at the CODEC level - that'll overwrite > > these settings won't it? > We have done it in the function "rt5660_remove". Right, and if the user removes and reloads the driver then the reset will happen.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
