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

[Mark Brown]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20151114/89949ca3/attachment-0001.sig>