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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20151113215812.GA19020@amd>
Date:	Fri, 13 Nov 2015 22:58:12 +0100
From:	Pavel Machek <pavel@....cz>
To:	Mark Brown <broonie@...nel.org>
Cc:	Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>,
	lgirdwood@...il.com, perex@...ex.cz, tiwai@...e.de,
	patches@...nsource.wolfsonmicro.com, alsa-devel@...a-project.org,
	linux-kernel@...r.kernel.org
Subject: Re: multi-codec support for arizona-ldo1 was Re: System with
 multiple arizona (wm5102) codecs

On Tue 2015-10-13 12:53:55, Mark Brown wrote:
> On Mon, Oct 12, 2015 at 10:11:38PM +0200, Pavel Machek wrote:
> > On Mon 2015-10-12 16:47:15, Mark Brown wrote:
> > > On Mon, Oct 12, 2015 at 11:00:45AM +0200, Pavel Machek wrote:
> 
> > > >  static const struct regulator_desc arizona_ldo1_hc = {
> > > > -	.name = "LDO1",
> 
> > > No, you definitely shouldn't be doing this - the regulator names should
> > > reflect the names the device has in the datasheet to aid people in going
> > > from software to the hardware and back again.  They shouldn't be
> > > dynamically generated at runtime.  If you need to namespace by
> > device
> 
> > They already are, see wm831x-ldo.c .
> 
> No, that's a different case where we actually have a repeatable IP we
> can enumerate multiple instances of on a single piece of silicon which
> has multiple variants available.  This is a single device with a single
> regulator on it.

Ok. But I'd still like to get it working.

Now... I got up-to v4.2 kernel, and it seems that it has support for
multiple sources with same name (but on different chips):

[    1.125485] Adding alias for supply MICVDD,(null) -> MICVDD,spi32766.1
[    1.285470] Adding alias for supply MICVDD,(null) -> MICVDD,spi32766.2

...but it does not look like I can use those aliases from the ALSA side:

[    2.734198] wm5102-codec.1 supply MICVDD,spi32766.1 not found, using dummy regulator
[    3.170912] wm5102-codec.2 supply MICVDD,spi32766.2 not found, using dummy regulator

I tried to do this:

SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD,spi32766.1", 0, SND_SOC_DAPM_REGULATOR_BYPASS),

Any idea what I did wrong, or what needs to be fixed?

> > > provide an interface which explicitly namespaces by device rather than
> > > hacking it into another interface, the usual thing is to use the struct
> > > device as the context.
> 
> > I'll need some more help here. I need to use it from ALSA, so I don't
> > think I can influence that interface easily.
> 
> Sorry?  If this is going into the userspace ABI there's something
> seriously wrong...

It is exposed to the ALSA. If ALSA exposes it to userspace, I'm not sure. 

> > What is currently in tree _does not work_, as there are two arizona
> > chips, and two "LDO1" regulators. (Doable) suggestions how to fix that
> > are welcome.
> 
> To repeat what I said above, provide an interface which namespaces by
> device (as we normally do when we need to distinguish between multiple
> instances of the same device).  Given that everything is part of the
> same device it's very easy to discover which device so it's clearly no
> problem when mapping the supplies.

I'm afraid I don't know how to do this. See above.

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/