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.
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).
And now we have
sound/soc/codecs/wm5102.c, around line 1093:
@@ -1092,7 +1094,6 @@ SND_SOC_DAPM_SUPPLY("ASYNCOPCLK", ARIZONA_OUTPUT_ASYNC_CLOCK, SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD2", 0, 0), SND_SOC_DAPM_REGULATOR_SUPPLY("DBVDD3", 0, 0), SND_SOC_DAPM_REGULATOR_SUPPLY("CPVDD", 20, 0), -SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0, SND_SOC_DAPM_REGULATOR_BYPASS), SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDL", 0, 0), SND_SOC_DAPM_REGULATOR_SUPPLY("SPKVDDR", 0, 0),
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.
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.
to be on something like the same page here, at the very least I need you to talk about what code you're looking at and what you don't understand so I can try to help you follow it but right now I'm just not sure where to start, it feels like you're trying to treat a lot of the code as a black box without following the abstractions it provides which makes things very hard.
Well, the code is pretty close to the black box for me :-(.
How far have you got in trying to follow the code, what specific areas are confusing you?
Ok, good. I don't understand how the things are expected to fit together. See above. I believe SND_SOC_ macros should have another argument "device", or maybe regulator names should have "device" name embedded in them.
Regulator names *do* have a device. This is the whole point with namespacing by client device.