[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151116140547.GD18889@ck-lbox>
Date: Mon, 16 Nov 2015 14:05:47 +0000
From: Charles Keepax <ckeepax@...nsource.wolfsonmicro.com>
To: Pavel Machek <pavel@....cz>
CC: Mark Brown <broonie@...nel.org>, <sameo@...ux.intel.com>,
<lee.jones@...aro.org>, <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 Sat, Nov 14, 2015 at 06:59:16PM +0100, Pavel Machek wrote:
> Hi!
>
> > If you're asking about the regulator API or embedded ALSA both of those
> > are me but there are other things in here - the driver you're working
> > with and the MFD core at least. At the minute I'm not convinced that
> > the problem here isn't just that the MFD and/or MFD core hasn't set up
> > the mappings to the child devices properly.
>
> 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.
Effectively the device is passed it is just implicit. If you look
where the regulator is actually registered in soc-dapm.c
case snd_soc_dapm_regulator_supply:
w->regulator = devm_regulator_get(dapm->dev, w->name);
if (IS_ERR(w->regulator)) {
You see we are requesting the regulator with the dapm device,
which will correspond to the CODEC.
Thanks,
Charles
--
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/
Powered by blists - more mailing lists