Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1224051 > unrolled thread

System with multiple arizona (wm5102) codecs

Back to article view | Back to linux.kernel

Contents

  System with multiple arizona (wm5102) codecs Pavel Machek <pavel@ucw.cz> - 2015-09-14 14:00 +0200
    Re: System with multiple arizona (wm5102) codecs Charles Keepax <ckeepax@opensource.wolfsonmicro.com> - 2015-09-14 14:20 +0200
      Re: System with multiple arizona (wm5102) codecs Charles Keepax <ckeepax@opensource.wolfsonmicro.com> - 2015-09-14 16:00 +0200
      Re: System with multiple arizona (wm5102) codecs Pavel Machek <pavel@ucw.cz> - 2015-09-14 22:20 +0200
      Re: System with multiple arizona (wm5102) codecs Pavel Machek <pavel@ucw.cz> - 2015-09-15 08:20 +0200
        Re: System with multiple arizona (wm5102) codecs Charles Keepax <ckeepax@opensource.wolfsonmicro.com> - 2015-09-15 10:40 +0200
          Re: System with multiple arizona (wm5102) codecs Pavel Machek <pavel@ucw.cz> - 2015-09-15 10:40 +0200
            Re: [alsa-devel] System with multiple arizona (wm5102) codecs Caleb Crome <caleb@crome.org> - 2015-09-15 16:00 +0200
              Re: [alsa-devel] System with multiple arizona (wm5102) codecs Mark Brown <broonie@kernel.org> - 2015-09-15 16:20 +0200
                Re: [alsa-devel] System with multiple arizona (wm5102) codecs Caleb Crome <caleb@crome.org> - 2015-09-15 17:30 +0200
                  Re: [alsa-devel] System with multiple arizona (wm5102) codecs Mark Brown <broonie@kernel.org> - 2015-09-20 02:40 +0200
              Re: [alsa-devel] System with multiple arizona (wm5102) codecs Pavel Machek <pavel@ucw.cz> - 2015-09-21 14:40 +0200

#1224051 — System with multiple arizona (wm5102) codecs

Hi!

I've got an embedded system with two arizona / wm5102 codecs.

Unfortunately, kernel does not seem to be ready for that
configuration.

In particular, drivers/regulator/arizona-ldo1.c and
drivers/regulator/arizona-micsupp.c register system-wide "MICVDD" and
"LDO1" regulators, but with two codecs in the system, we really have
wm5102-codec.1.MICVDD, wm5102-codec.2.MICVDD, wm5102-codec.1.LDO1 and
wm5102-codec.2.LDO1.

That got me second codec working in two-codec configuration, but first
one still stops working as soon as two codecs are enabled.

If you have idea what else needs fixing, let me know.

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1224062

On Mon, Sep 14, 2015 at 01:54:39PM +0200, Pavel Machek wrote:
> Hi!
> 
> I've got an embedded system with two arizona / wm5102 codecs.
> 
> Unfortunately, kernel does not seem to be ready for that
> configuration.
> 
> In particular, drivers/regulator/arizona-ldo1.c and
> drivers/regulator/arizona-micsupp.c register system-wide "MICVDD" and
> "LDO1" regulators, but with two codecs in the system, we really have
> wm5102-codec.1.MICVDD, wm5102-codec.2.MICVDD, wm5102-codec.1.LDO1 and
> wm5102-codec.2.LDO1.
> 
> That got me second codec working in two-codec configuration, but first
> one still stops working as soon as two codecs are enabled.
> 
> If you have idea what else needs fixing, let me know.
> 
> Best regards,
> 								Pavel

I must confess I haven't ever tested a system with two Arizona
CODECs connected. Yes it seems you would get clashes on the
regulator names, I guess that would need to be fixed up. If you
were doing so wm831x-ldo.c would probably make a reasonable
example.

I guess you would need to be careful with the machine driver as
well, you will need to use a snd_soc_codec_conf structure for at
least one (although I would do both) of the CODECs to give  a
prefix for all the widget/control names, otherwise those will
clash and everything will probably behave very strangely. See
sound/soc/samsung/bells.c for an example doing this for wm9081.

Those are the only two things that spring to mind at the moment
but keep me informed on how you are getting on and I will let you
know if I can come up with any other traps.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224173

On Mon, Sep 14, 2015 at 12:52:55PM +0100, Charles Keepax wrote:
> On Mon, Sep 14, 2015 at 01:54:39PM +0200, Pavel Machek wrote:
> > Hi!
> > 
> > I've got an embedded system with two arizona / wm5102 codecs.
> > 
> > Unfortunately, kernel does not seem to be ready for that
> > configuration.
> > 
> > In particular, drivers/regulator/arizona-ldo1.c and
> > drivers/regulator/arizona-micsupp.c register system-wide "MICVDD" and
> > "LDO1" regulators, but with two codecs in the system, we really have
> > wm5102-codec.1.MICVDD, wm5102-codec.2.MICVDD, wm5102-codec.1.LDO1 and
> > wm5102-codec.2.LDO1.
> > 
> > That got me second codec working in two-codec configuration, but first
> > one still stops working as soon as two codecs are enabled.
> > 
> > If you have idea what else needs fixing, let me know.
> > 
> > Best regards,
> > 								Pavel
> 
> I must confess I haven't ever tested a system with two Arizona
> CODECs connected. Yes it seems you would get clashes on the
> regulator names, I guess that would need to be fixed up. If you
> were doing so wm831x-ldo.c would probably make a reasonable
> example.
> 
> I guess you would need to be careful with the machine driver as
> well, you will need to use a snd_soc_codec_conf structure for at
> least one (although I would do both) of the CODECs to give  a
> prefix for all the widget/control names, otherwise those will
> clash and everything will probably behave very strangely. See
> sound/soc/samsung/bells.c for an example doing this for wm9081.
> 
> Those are the only two things that spring to mind at the moment
> but keep me informed on how you are getting on and I will let you
> know if I can come up with any other traps.

Oh and one more all the calls to mfd_add_devices in
arizona-core.c use PLATFORM_DEVID_NONE at the moment, which I
suspect will also cause problems at some point.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224438

Hi!

> > I've got an embedded system with two arizona / wm5102 codecs.
> > 
> > Unfortunately, kernel does not seem to be ready for that
> > configuration.
> > 
> > In particular, drivers/regulator/arizona-ldo1.c and
> > drivers/regulator/arizona-micsupp.c register system-wide "MICVDD" and
> > "LDO1" regulators, but with two codecs in the system, we really have
> > wm5102-codec.1.MICVDD, wm5102-codec.2.MICVDD, wm5102-codec.1.LDO1 and
> > wm5102-codec.2.LDO1.
> > 
> > That got me second codec working in two-codec configuration, but first
> > one still stops working as soon as two codecs are enabled.
> > 
> > If you have idea what else needs fixing, let me know.
> > 
> > Best regards,
> 
> I must confess I haven't ever tested a system with two Arizona
> CODECs connected. Yes it seems you would get clashes on the
> regulator names, I guess that would need to be fixed up. If you
> were doing so wm831x-ldo.c would probably make a reasonable
> example.
> 
> I guess you would need to be careful with the machine driver as
> well, you will need to use a snd_soc_codec_conf structure for at
> least one (although I would do both) of the CODECs to give  a
> prefix for all the widget/control names, otherwise those will
> clash and everything will probably behave very strangely. See
> sound/soc/samsung/bells.c for an example doing this for wm9081.

Thanks a lot for pointers. I did split wm5102_dapm_widgets into two
structures, and modified them by hand (but probably did not get all
the right fields)... and thought that there must be better way.

> Those are the only two things that spring to mind at the moment
> but keep me informed on how you are getting on and I will let you
> know if I can come up with any other traps.

I guess I'll have to undo my horrible hacks, first.

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224659

Hi!

> > I've got an embedded system with two arizona / wm5102 codecs.
> > 
> > Unfortunately, kernel does not seem to be ready for that
> > configuration.
> > 
> > In particular, drivers/regulator/arizona-ldo1.c and
> > drivers/regulator/arizona-micsupp.c register system-wide "MICVDD" and
> > "LDO1" regulators, but with two codecs in the system, we really have
> > wm5102-codec.1.MICVDD, wm5102-codec.2.MICVDD, wm5102-codec.1.LDO1 and
> > wm5102-codec.2.LDO1.
> > 
> > That got me second codec working in two-codec configuration, but first
> > one still stops working as soon as two codecs are enabled.
> > 
> > If you have idea what else needs fixing, let me know.
> > 
> > Best regards,
> > 								Pavel
> 
> I must confess I haven't ever tested a system with two Arizona
> CODECs connected. Yes it seems you would get clashes on the
> regulator names, I guess that would need to be fixed up. If you
> were doing so wm831x-ldo.c would probably make a reasonable
> example.
> 
> I guess you would need to be careful with the machine driver as
> well, you will need to use a snd_soc_codec_conf structure for at
> least one (although I would do both) of the CODECs to give  a
> prefix for all the widget/control names, otherwise those will
> clash and everything will probably behave very strangely. See
> sound/soc/samsung/bells.c for an example doing this for wm9081.
> 
> Those are the only two things that spring to mind at the moment
> but keep me informed on how you are getting on and I will let you
> know if I can come up with any other traps.

It seems that davinci-evm takes data from device tree, but then uses
statically-allocated evm_soc_card, which would lead to problems in
dual-codec config....?

Thanks,
								Pavel

Signed-off-by: Pavel Machek <pavel@ucw.cz>

commit 977baecbcdb362bdc92096e7c454c379af319f8a
Author: Pavel <pavel@ucw.cz>
Date:   Tue Sep 15 08:16:02 2015 +0200

    Split card allocation in davinci-evm.c

diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 3296116..de277ca 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -885,8 +899,12 @@ static int davinci_evm_probe(struct platform_device *pdev)
 	struct snd_soc_card_drvdata_davinci *drvdata = NULL;
 	struct clk *mclk;
 	int ret = 0;
+	struct snd_soc_card *card = devm_kzalloc(&pdev->dev, sizeof(struct snd_soc_card), GFP_KERNEL);
+
+	*card = evm_soc_card;
 
-	evm_soc_card.dai_link = dai;
+	printk("bluebox / davinci_evm_probe: probing!\n");
+	card->dai_link = dai;
 
 	dai->codec_of_node = of_parse_phandle(np, "ti,audio-codec", 0);
 	if (!dai->codec_of_node)
@@ -900,8 +918,9 @@ static int davinci_evm_probe(struct platform_device *pdev)
 	if (!dai->platform_name)
 		dai->platform_of_node = dai->cpu_of_node;
 
-	evm_soc_card.dev = &pdev->dev;
-	ret = snd_soc_of_parse_card_name(&evm_soc_card, "ti,model");
+	card->codec_conf = rx51_codec_conf_2;
+	card->dev = &pdev->dev;
+	ret = snd_soc_of_parse_card_name(card, "ti,model");
 	if (ret)
 		return ret;
 
@@ -938,8 +957,8 @@ static int davinci_evm_probe(struct platform_device *pdev)
 				 requestd_rate, drvdata->sysclk);
 	}
 
-	snd_soc_card_set_drvdata(&evm_soc_card, drvdata);
-	ret = snd_soc_register_card(&evm_soc_card);
+	snd_soc_card_set_drvdata(card, drvdata);
+	ret = snd_soc_register_card(card);
 
 	if (ret)
 		dev_err(&pdev->dev, "snd_soc_register_card failed (%d)\n", ret);


-- 
(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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224758

On Tue, Sep 15, 2015 at 08:18:32AM +0200, Pavel Machek wrote:
> Hi!
> 
> > > I've got an embedded system with two arizona / wm5102 codecs.
> > > 
> > > Unfortunately, kernel does not seem to be ready for that
> > > configuration.
> > > 
> > > In particular, drivers/regulator/arizona-ldo1.c and
> > > drivers/regulator/arizona-micsupp.c register system-wide "MICVDD" and
> > > "LDO1" regulators, but with two codecs in the system, we really have
> > > wm5102-codec.1.MICVDD, wm5102-codec.2.MICVDD, wm5102-codec.1.LDO1 and
> > > wm5102-codec.2.LDO1.
> > > 
> > > That got me second codec working in two-codec configuration, but first
> > > one still stops working as soon as two codecs are enabled.
> > > 
> > > If you have idea what else needs fixing, let me know.
> > > 
> > > Best regards,
> > > 								Pavel
> > 
> > I must confess I haven't ever tested a system with two Arizona
> > CODECs connected. Yes it seems you would get clashes on the
> > regulator names, I guess that would need to be fixed up. If you
> > were doing so wm831x-ldo.c would probably make a reasonable
> > example.
> > 
> > I guess you would need to be careful with the machine driver as
> > well, you will need to use a snd_soc_codec_conf structure for at
> > least one (although I would do both) of the CODECs to give  a
> > prefix for all the widget/control names, otherwise those will
> > clash and everything will probably behave very strangely. See
> > sound/soc/samsung/bells.c for an example doing this for wm9081.
> > 
> > Those are the only two things that spring to mind at the moment
> > but keep me informed on how you are getting on and I will let you
> > know if I can come up with any other traps.
> 
> It seems that davinci-evm takes data from device tree, but then uses
> statically-allocated evm_soc_card, which would lead to problems in
> dual-codec config....?

That somewhat depends on how you plan on doing things. I had
assumed you would be having a single machine driver with both
CODECs connected to it, in which case the statically allocated
snd_soc_card wouldn't be a problem. However, if you wanted to
have two seperate machine drivers with a single CODEC connected
to each then you would have an issue.

I guess either approach is reasonable and probably just depends
on what your end goal is.

Thanks,
Charles
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1224762

Hi!

> > > I must confess I haven't ever tested a system with two Arizona
> > > CODECs connected. Yes it seems you would get clashes on the
> > > regulator names, I guess that would need to be fixed up. If you
> > > were doing so wm831x-ldo.c would probably make a reasonable
> > > example.
> > > 
> > > I guess you would need to be careful with the machine driver as
> > > well, you will need to use a snd_soc_codec_conf structure for at
> > > least one (although I would do both) of the CODECs to give  a
> > > prefix for all the widget/control names, otherwise those will
> > > clash and everything will probably behave very strangely. See
> > > sound/soc/samsung/bells.c for an example doing this for wm9081.
> > > 
> > > Those are the only two things that spring to mind at the moment
> > > but keep me informed on how you are getting on and I will let you
> > > know if I can come up with any other traps.
> > 
> > It seems that davinci-evm takes data from device tree, but then uses
> > statically-allocated evm_soc_card, which would lead to problems in
> > dual-codec config....?
> 
> That somewhat depends on how you plan on doing things. I had
> assumed you would be having a single machine driver with both
> CODECs connected to it, in which case the statically allocated
> snd_soc_card wouldn't be a problem. However, if you wanted to
> have two seperate machine drivers with a single CODEC connected
> to each then you would have an issue.
> 
> I guess either approach is reasonable and probably just depends
> on what your end goal is.

The way dts is set up in my case, I ended up with two
snd_soc_cards. It seems to work for me now (on old kernel and with
some rather extreme hacks).

I'll most likely clean it up and get into mainline-ready form, but it
will take some time. If you want to see the ugly patches, let me know.

Thanks and 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225126 — Re: [alsa-devel] System with multiple arizona (wm5102) codecs

Hi Pavel,
   I'd love to see the patches :-)  I've been trying to figure out the
*right* way to add multiple codecs to a single card (and single CPU
DAI) for some days now.  Any help would be greatly appreciated.

Thanks,
 -Caleb


On Tue, Sep 15, 2015 at 1:35 AM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> > > I must confess I haven't ever tested a system with two Arizona
>> > > CODECs connected. Yes it seems you would get clashes on the
>> > > regulator names, I guess that would need to be fixed up. If you
>> > > were doing so wm831x-ldo.c would probably make a reasonable
>> > > example.
>> > >
>> > > I guess you would need to be careful with the machine driver as
>> > > well, you will need to use a snd_soc_codec_conf structure for at
>> > > least one (although I would do both) of the CODECs to give  a
>> > > prefix for all the widget/control names, otherwise those will
>> > > clash and everything will probably behave very strangely. See
>> > > sound/soc/samsung/bells.c for an example doing this for wm9081.
>> > >
>> > > Those are the only two things that spring to mind at the moment
>> > > but keep me informed on how you are getting on and I will let you
>> > > know if I can come up with any other traps.
>> >
>> > It seems that davinci-evm takes data from device tree, but then uses
>> > statically-allocated evm_soc_card, which would lead to problems in
>> > dual-codec config....?
>>
>> That somewhat depends on how you plan on doing things. I had
>> assumed you would be having a single machine driver with both
>> CODECs connected to it, in which case the statically allocated
>> snd_soc_card wouldn't be a problem. However, if you wanted to
>> have two seperate machine drivers with a single CODEC connected
>> to each then you would have an issue.
>>
>> I guess either approach is reasonable and probably just depends
>> on what your end goal is.
>
> The way dts is set up in my case, I ended up with two
> snd_soc_cards. It seems to work for me now (on old kernel and with
> some rather extreme hacks).
>
> I'll most likely clean it up and get into mainline-ready form, but it
> will take some time. If you want to see the ugly patches, let me know.
>
> Thanks and best regards,
>                                                                         Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1225164 — Re: [alsa-devel] System with multiple arizona (wm5102) codecs

[Multipart message — attachments visible in raw view] — view raw

On Tue, Sep 15, 2015 at 06:56:39AM -0700, Caleb Crome wrote:

>    I'd love to see the patches :-)  I've been trying to figure out the
> *right* way to add multiple codecs to a single card (and single CPU
> DAI) for some days now.  Any help would be greatly appreciated.

Like Charles said earlier the Bells machine in mainline has multiple
CODECs hooked up.  Speyside too.  To hook up multiple CODECs to a single
DAI link see 88bd870f02dff5c94 (ASoC: core: Add initial support for DAI
multicodec), sadly I don't think Benoit ever got round to submitting a
machine.

[toc] | [prev] | [next] | [standalone]

#1225315 — Re: [alsa-devel] System with multiple arizona (wm5102) codecs

>
> Like Charles said earlier the Bells machine in mainline has multiple
> CODECs hooked up.  Speyside too.  To hook up multiple CODECs to a single
> DAI link see 88bd870f02dff5c94 (ASoC: core: Add initial support for DAI
> multicodec), sadly I don't think Benoit ever got round to submitting a
> machine.

Thanks Mark.

I've been staring at that diff for a a day or two, and I still can't
quite figure out how to use it.

I think I'm getting close:  all codecs are registered, the DAPM stuff
seems to be connected (all with prefixed names), but the card won't
open more than a 2 channel interface.

For example, when I do aplay -l, I get this:
**** List of PLAYBACK Hardware Devices ****
card 0: PUPPYAUDIO [PUPPY-AUDIO], device 0: AIC3X tlv320aic3x-hifi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PUPPYAUDIO [PUPPY-AUDIO], device 1: AIC3X tlv320aic3x-hifi-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PUPPYAUDIO [PUPPY-AUDIO], device 2: AIC3X tlv320aic3x-hifi-2 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: PUPPYAUDIO [PUPPY-AUDIO], device 3: AIC3X tlv320aic3x-hifi-3 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Each device is a 2 channel codec, so I thought I should get 8
channels. but when I try to run jackd with 8 channels, I get the
following:
# jackd  -d alsa -D -i 8 -o 8 -S -r16000
...
ALSA: cannot set channel count to 8 for capture
ALSA: cannot configure capture channel
...


So, here are the relevent bits of my patch.  Any chance you could
point out the error in my ways?

Basically, what I did was add a snd_soc_dai_link and a
snd_soc_codec_conf for each codec, and set num_links and num_configs
to the number of codecs.

Thanks

-Caleb

diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index 731fb0d..d2e7049 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -23,10 +23,11 @@

 #include <asm/dma.h>
 #include <asm/mach-types.h>
-
 struct snd_soc_card_drvdata_davinci {
     struct clk *mclk;
     unsigned sysclk;
+        int controls_added_already;
 };

@@ -118,11 +122,18 @@ static int evm_aic3x_init(struct snd_soc_pcm_runtime *rtd)
 {
     struct snd_soc_card *card = rtd->card;
     struct device_node *np = card->dev->of_node;
+
+    struct snd_soc_card_drvdata_davinci *drvdata =
+        snd_soc_card_get_drvdata(card);
     int ret;

     /* Add davinci-evm specific widgets */
-    snd_soc_dapm_new_controls(&card->dapm, aic3x_dapm_widgets,
-                  ARRAY_SIZE(aic3x_dapm_widgets));
+    if (!drvdata->controls_added_already) {
+        snd_soc_dapm_new_controls(&card->dapm, aic3x_dapm_widgets,
+                      ARRAY_SIZE(aic3x_dapm_widgets));
+        drvdata->controls_added_already = 1;
+    }

     if (np) {
         ret = snd_soc_of_parse_audio_routing(card, "ti,audio-routing");
@@ -330,14 +342,71 @@ static struct snd_soc_card da850_snd_soc_card = {
  * The struct is used as place holder. It will be completely
  * filled with data from dt node.
  */
-static struct snd_soc_dai_link evm_dai_tlv320aic3x = {
-    .name        = "TLV320AIC3X",
+static struct snd_soc_dai_link evm_dai_tlv320aic3x[] = {
+    {
+    .name        = "TLV320AIC3X a",
     .stream_name    = "AIC3X",
     .codec_dai_name    = "tlv320aic3x-hifi",
     .ops            = &evm_ops,
     .init           = evm_aic3x_init,
-    .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
-           SND_SOC_DAIFMT_IB_NF,
+    .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
SND_SOC_DAIFMT_IB_NF,
+    },
+    {
+    .name        = "TLV320AIC3X b",
+    .stream_name    = "AIC3X",
+    .codec_dai_name    = "tlv320aic3x-hifi",
+    .ops            = &evm_ops,
+    .init           = evm_aic3x_init,
+    .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
SND_SOC_DAIFMT_IB_NF,
+    },
+    {
+    .name        = "TLV320AIC3X c",
+    .stream_name    = "AIC3X",
+    .codec_dai_name    = "tlv320aic3x-hifi",
+    .ops            = &evm_ops,
+    .init           = evm_aic3x_init,
+    .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
SND_SOC_DAIFMT_IB_NF,
+    },
+    {
+    .name        = "TLV320AIC3X d",
+    .stream_name    = "AIC3X",
+    .codec_dai_name    = "tlv320aic3x-hifi",
+    .ops            = &evm_ops,
+    .init           = evm_aic3x_init,
+    .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
SND_SOC_DAIFMT_IB_NF,
+    },
+    {
+    .name        = "TLV320AIC3X e",
+    .stream_name    = "AIC3X",
+    .codec_dai_name    = "tlv320aic3x-hifi",
+    .ops            = &evm_ops,
+    .init           = evm_aic3x_init,
+    .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
SND_SOC_DAIFMT_IB_NF,
+    },
+    {
+    .name        = "TLV320AIC3X f",
+    .stream_name    = "AIC3X",
+    .codec_dai_name    = "tlv320aic3x-hifi",
+    .ops            = &evm_ops,
+    .init           = evm_aic3x_init,
+    .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
SND_SOC_DAIFMT_IB_NF,
+    },
+    {
+    .name        = "TLV320AIC3X g",
+    .stream_name    = "AIC3X",
+    .codec_dai_name    = "tlv320aic3x-hifi",
+    .ops            = &evm_ops,
+    .init           = evm_aic3x_init,
+    .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
SND_SOC_DAIFMT_IB_NF,
+    },
+    {
+    .name        = "TLV320AIC3X h",
+    .stream_name    = "AIC3X",
+    .codec_dai_name    = "tlv320aic3x-hifi",
+    .ops            = &evm_ops,
+    .init           = evm_aic3x_init,
+    .dai_fmt = SND_SOC_DAIFMT_DSP_B | SND_SOC_DAIFMT_CBM_CFM |
SND_SOC_DAIFMT_IB_NF,
+    },
 };

 static const struct of_device_id davinci_evm_dt_ids[] = {
@@ -355,6 +424,8 @@ static struct snd_soc_card evm_soc_card = {
     .num_links = 1,
 };

+static struct snd_soc_codec_conf evm_codec_confs[16];
+
 static int davinci_evm_probe(struct platform_device *pdev)
 {
     struct device_node *np = pdev->dev.of_node;
@@ -364,18 +435,36 @@ static int davinci_evm_probe(struct platform_device *pdev)
     struct snd_soc_card_drvdata_davinci *drvdata = NULL;
     struct clk *mclk;
     int ret = 0;
+    int i;

     evm_soc_card.dai_link = dai;
-
-    dai->codec_of_node = of_parse_phandle(np, "ti,audio-codec", 0);
-    if (!dai->codec_of_node)
+
+    evm_soc_card.codec_conf = evm_codec_confs;
+
+    for (i = 0;
+         (of_parse_phandle(np, "ti,audio-codec", i) != NULL) &&
+         (i < ARRAY_SIZE(evm_dai_tlv320aic3x)-1);
+         i++) {
+        char *name_prefix = kzalloc(4, GFP_KERNEL);
+
+        dai[i].codec_of_node = of_parse_phandle(np, "ti,audio-codec", i);
+
+        if (!dai[i].codec_of_node)
         return -EINVAL;

-    dai->cpu_of_node = of_parse_phandle(np, "ti,mcasp-controller", 0);
-    if (!dai->cpu_of_node)
+        evm_codec_confs[i].of_node = dai[i].codec_of_node;
+        snprintf(name_prefix, 4, "%c", 'a'+i);
+        evm_codec_confs[i].name_prefix = name_prefix;
+
+        dai[i].cpu_of_node = of_parse_phandle(np, "ti,mcasp-controller", 0);
+        if (!dai[i].cpu_of_node)
         return -EINVAL;

-    dai->platform_of_node = dai->cpu_of_node;
+        dai[i].platform_of_node = dai[i].cpu_of_node;
+    }
+    evm_soc_card.num_configs=i;
+    evm_soc_card.num_links  =i;
+

     evm_soc_card.dev = &pdev->dev;
     ret = snd_soc_of_parse_card_name(&evm_soc_card, "ti,model");
diff --git a/arch/arm/boot/dts/am335x-boneblack.dts
b/arch/arm/boot/dts/am335x-boneblack.dts
index 6335072..19af41f 100644
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
+&i2c1 {
+    clock-frequency = <100000>;
+    status = "okay";
+    pinctrl-names = "default";
+    pinctrl-0 = <&i2c1_pins_default>;
+    status="okay";
+
+    tlv320aic3x_a: tlv320aic3x@18 {
+        compatible = "ti,tlv320aic3x";
+        reg = <0x18>;
+        tdm-offset = <0>;
+        status = "okay";
+    };
+
+    tlv320aic3x_b: tlv320aic3x@19 {
+        compatible = "ti,tlv320aic3x";
+        reg = <0x19>;
+        tdm-offset = <32>;
+        status = "okay";
+    };
+
+    tlv320aic3x_c: tlv320aic3x@1a {
+        compatible = "ti,tlv320aic3x";
+        reg = <0x1a>;
+        tdm-offset = <64>;
+        status = "okay";
+    };
+
+    tlv320aic3x_d: tlv320aic3x@1b {
+        compatible = "ti,tlv320aic3x";
+        reg = <0x1b>;
+        tdm-offset = <96>;
+        status = "okay";
+    };
+
+};
+
+&mcasp0 {
+    pinctrl-names = "default";
+    pinctrl-0 = <&mcasp_0_pins_default>;
+    status = "okay";
+
+    op-mode = <0>;          /* MCASP_IIS_MODE */
+    tdm-slots = <16>;
+    num-serializer = <16>;
+    serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
+        0 0 1 2
+        0 0 0 0
+        0 0 0 0
+        0 0 0 0
+    >;
+    tx-num-evt = <1>;
+    rx-num-evt = <1>;
 };

+
 / {
+    sound {
+        compatible = "ti,da830-evm-audio";
+        ti,model = "PUPPY-AUDIO";
+        ti,audio-codec = <
+                   &tlv320aic3x_a
+                   &tlv320aic3x_b
+                   &tlv320aic3x_c
+                   &tlv320aic3x_d
+                   >;
+        ti,mcasp-controller = <&mcasp0>;
+        ti,codec-clock-rate = <12288000>;
+        ti,audio-routing =
+            "Headphone Jack",       "a HPLOUT",
+            "Headphone Jack",       "a HPROUT",
+            "a LINE1L",               "Line In",
+            "a LINE1R",               "Line In";
+        status="okay";
+    };
 };

 &rtc {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1228800 — Re: [alsa-devel] System with multiple arizona (wm5102) codecs

[Multipart message — attachments visible in raw view] — view raw

On Tue, Sep 15, 2015 at 08:26:36AM -0700, Caleb Crome wrote:

> > Like Charles said earlier the Bells machine in mainline has multiple
> > CODECs hooked up.  Speyside too.  To hook up multiple CODECs to a single
> > DAI link see 88bd870f02dff5c94 (ASoC: core: Add initial support for DAI
> > multicodec), sadly I don't think Benoit ever got round to submitting a
> > machine.

> Thanks Mark.

> I've been staring at that diff for a a day or two, and I still can't
> quite figure out how to use it.

> I think I'm getting close:  all codecs are registered, the DAPM stuff
> seems to be connected (all with prefixed names), but the card won't
> open more than a 2 channel interface.

> For example, when I do aplay -l, I get this:
> **** List of PLAYBACK Hardware Devices ****
> card 0: PUPPYAUDIO [PUPPY-AUDIO], device 0: AIC3X tlv320aic3x-hifi-0 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: PUPPYAUDIO [PUPPY-AUDIO], device 1: AIC3X tlv320aic3x-hifi-1 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: PUPPYAUDIO [PUPPY-AUDIO], device 2: AIC3X tlv320aic3x-hifi-2 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0
> card 0: PUPPYAUDIO [PUPPY-AUDIO], device 3: AIC3X tlv320aic3x-hifi-3 []
>   Subdevices: 1/1
>   Subdevice #0: subdevice #0

That doesn't look entirely like what I'd expect...  I'd epect to see one
DAI presented to userspace.  Indeed looking through your diff I don't
see any usage of struct snd_soc_dai_link_component as described in the
changelog for the change I pointed you at.  I'd expect to see one DAI
link with a bunch of those hanging off it giving a single DAI to aplay.

OTOH I'm not sure it's going to work as I'm not immediately seeing how
we handle the ability to have more capabilities than an individual
device (based on the changelog I suspect the original use case may have
been two mono I2S devices which have stereo interfaces even if they only
pay attention to one channel on themm).  But let's at least get
everything appearing as one DAI first before we move on to worrying
about that, I didn't check thoroughly yet.

[toc] | [prev] | [next] | [standalone]

#1229259 — Re: [alsa-devel] System with multiple arizona (wm5102) codecs

Hi!

>    I'd love to see the patches :-)  I've been trying to figure out the
> *right* way to add multiple codecs to a single card (and single CPU
> DAI) for some days now.  Any help would be greatly appreciated.

I eventually got it to work, but I'm really sure that what I've done
can't be considered "right" :-).
								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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web