Re: multi-codec support for arizona-ldo1 was Re: System with multiple arizona (wm5102) codecs

From: Pavel Machek
Date: Sat Nov 14 2015 - 16:17:09 EST

HiOn Sat 2015-11-14 18:49:40, Mark Brown wrote:
> On Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> > Well, mfd_core.c seems to call regulator_bulk_register_supply_alias()
> > with device that does not have dev_name initialized.
> OK, that'll be the problem then - we're not mapping the supply into the
> individual child device but rather system wide, probably because that
> mapping is being done too early, before we've actually created the
> device.

Take a look at mfd_add_device(). Yes, we do
regulator_bulk_register_supply_alias() before doing

> > regulator_bulk_register_supply_alias() results in "Adding alias"
> > stuff, and then drivers/regulator/arizona-micsupp.c tries to register
> > another "MICVDD".
> That's fine because all supplies should be namespaced with a device.
> The goal is to say "Supply X on device Y" (we do support exceptions for
> the few cases where there are not yet any devices involved but this
> clearly isn't one of them).

Well, clearly someone should tell that to wm5102
maintainers. Hmm. It looks like driver is marked supported but there
are no names attached?

L: patches@xxxxxxxxxxxxxxxxxxxxxxxxxxx
T: git git://
T: git git://
S: Supported

I guess Charles Keepax should be listed there?

> > And now we have
> > sound/soc/codecs/wm5102.c, around line 1093:
> > @@ -1092,7 +1094,6 @@ SND_SOC_DAPM_SUPPLY("ASYNCOPCLK",
> > That is the regulator<->alsa interface I'm talking about. But as you
> So if you look at this just templates out some boilerplate regulator API
> client code which calls regulator_get() like any other client and then
> hooks that regulator into the audio power management.

Ok, so SND_SOC_DAPM_REGULATOR_SUPPLY() does not work, because I have
two regulators, right? Is there similar macro I can use?

Do you have an example (filename, linenumber) of sound driver that
gets this right?

> > may recall, I have 2 arizona chips here, so two wm5102.c instances,
> > and I believe this means that "MICVDD" is not suitable here, and we
> > want something like "MICVDD,spi32766.2" here.
> > But a) code does not seem to be quite ready for that, and b) you said
> > you disliked that approach.
> Please go and look at how regulator clients request their supplies and
> how those get resolved into actual supplies - it's exactly the same
> struct device based namespacing that we use for clocks, PWMs and other
> resources. It's not that I dislike this approach, it's that this
> approach does not make sense in the model we use for requesting supplies
> and is not supported in any way by the code.
> I'm not sure how I can be any clearer that supply names are namespaced
> by client device and that as a result fiddling around with the supply
> name is not going to help anything.

Well, you are saying that pretty clearly, but sound driver I seen
assumes names are global, and /sys interface assumed the names are
global. Give me an example I can look at and I should be able to
figure it out... You are clear, but the kernel code seems to disagree
with you.

Best regards,

(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at