From: Mark Brown <broonie@kernel.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: sameo@linux.intel.com, lee.jones@linaro.org,
Charles Keepax <ckeepax@opensource.wolfsonmicro.com>,
lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.de,
patches@opensource.wolfsonmicro.com, alsa-devel@alsa-project.org,
linux-kernel@vger.kernel.org
Subject: Re: multi-codec support for arizona-ldo1 was Re: System with multiple arizona (wm5102) codecs
Date: Sat, 14 Nov 2015 18:49:40 +0000 [thread overview]
Message-ID: <20151114184940.GY12392@sirena.org.uk> (raw)
In-Reply-To: <20151114175915.GA20429@amd>
[-- Attachment #1: Type: text/plain, Size: 3309 bytes --]
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-11-14 18:50 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-14 11:54 System with multiple arizona (wm5102) codecs Pavel Machek
2015-09-14 11:52 ` Charles Keepax
2015-09-14 11:52 ` Charles Keepax
2015-09-14 13:31 ` Charles Keepax
2015-09-14 13:31 ` Charles Keepax
2015-09-14 20:11 ` Pavel Machek
2015-09-15 6:18 ` Pavel Machek
2015-09-15 8:06 ` Charles Keepax
2015-09-15 8:06 ` Charles Keepax
2015-09-15 8:35 ` Pavel Machek
2015-09-15 13:56 ` [alsa-devel] " Caleb Crome
2015-09-15 13:56 ` Caleb Crome
2015-09-15 14:09 ` [alsa-devel] " Mark Brown
2015-09-15 14:09 ` Mark Brown
2015-09-15 15:26 ` [alsa-devel] " Caleb Crome
2015-09-19 18:21 ` Mark Brown
2015-09-21 12:36 ` Pavel Machek
2015-10-12 9:00 ` multi-codec support for arizona-ldo1 was " Pavel Machek
2015-10-12 11:37 ` Charles Keepax
2015-10-12 11:37 ` Charles Keepax
2015-11-30 11:33 ` multi-card support for davinci-evm Pavel Machek
2015-11-30 11:37 ` multi-card support for arizona-core Pavel Machek
2015-11-30 11:37 ` Pavel Machek
2015-11-30 11:54 ` Mark Brown
2015-10-12 15:47 ` multi-codec support for arizona-ldo1 was Re: System with multiple arizona (wm5102) codecs Mark Brown
2015-10-12 20:11 ` Pavel Machek
2015-10-13 11:53 ` Mark Brown
2015-10-13 11:53 ` Mark Brown
2015-11-13 21:58 ` Pavel Machek
2015-11-13 22:53 ` Mark Brown
2015-11-14 7:44 ` Pavel Machek
2015-11-14 7:44 ` Pavel Machek
2015-11-14 12:39 ` Mark Brown
2015-11-14 17:59 ` Pavel Machek
2015-11-14 17:59 ` Pavel Machek
2015-11-14 18:49 ` Mark Brown [this message]
2015-11-14 21:16 ` Pavel Machek
2015-11-14 21:16 ` Pavel Machek
2015-11-15 0:14 ` Mark Brown
2015-11-15 0:14 ` Mark Brown
2015-11-16 7:45 ` Pavel Machek
2015-11-16 10:50 ` Mark Brown
2015-11-16 12:29 ` Pavel Machek
2015-11-16 12:29 ` Pavel Machek
2015-11-16 13:57 ` Charles Keepax
2015-11-16 13:57 ` Charles Keepax
2015-11-16 14:28 ` Charles Keepax
2015-11-16 14:28 ` Charles Keepax
2015-11-16 17:33 ` Mark Brown
2015-11-16 14:11 ` Charles Keepax
2015-11-16 14:11 ` Charles Keepax
2015-11-22 6:51 ` Pavel Machek
2015-11-22 6:51 ` Pavel Machek
2015-11-23 8:18 ` Lee Jones
2015-11-23 8:18 ` Lee Jones
2015-11-23 10:11 ` Pavel Machek
2015-11-23 10:25 ` Richard Fitzgerald
2015-11-23 10:25 ` Richard Fitzgerald
2015-11-23 11:30 ` Mark Brown
2015-11-23 11:46 ` Charles Keepax
2015-11-23 11:46 ` Charles Keepax
2015-11-23 14:31 ` Lee Jones
2015-11-23 15:00 ` Pavel Machek
2015-11-16 14:05 ` Charles Keepax
2015-11-16 14:05 ` Charles Keepax
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151114184940.GY12392@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=ckeepax@opensource.wolfsonmicro.com \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@opensource.wolfsonmicro.com \
--cc=pavel@ucw.cz \
--cc=perex@perex.cz \
--cc=sameo@linux.intel.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.