* Re: ASoC MPC5xxx PSC AC97 audio driver [not found] <20110908121600.267dee07@archvile> @ 2011-09-08 10:28 ` jonsmirl [not found] ` <20110908124529.520c1388@archvile> 0 siblings, 1 reply; 17+ messages in thread From: jonsmirl @ 2011-09-08 10:28 UTC (permalink / raw) To: David Jander; +Cc: Grant Likely, alsa-devel On Thu, Sep 8, 2011 at 6:16 AM, David Jander <david.jander@protonic.nl> wrote: > > Dear Jon, Here's the device tree... http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/dspeak01.dts;h=50cc247b4da0eb2bc4deb315b1b5348af87e5979;hb=9166a4a4141ab7c8d7a7b97fa5b726e11a8d0ca4 Grant can comment on the current bindings. We switched onto ARM based hardware a couple of years ago. We're looking the the iMX502 for a current design. > > I am busy writing an AC97 ASoC driver for the MPC5121e processor from > Freescale, and was using your MPC5200 driver as a starting point. I would > really like to make the driver as unified as possible, but I was encountering > some problems that make me think that maybe your driver as included in current > mainline linux (3.1-rc2 for me atm) is not working anymore. Do you know if it > is still working? > Unfortunately I have little experience with ALSA drivers, so I might not > be doing things entirely in the correct way. Nevertheless I was unable to get > the driver/device binding working the way you did, and I don't have a MPC5200 > platform with AC97 codec to try out your code :-( > > Here's what I don't quite get: > > mpc5200_dma.c seems to be the proper PCM driver, which has an OF compatible > string of "fsl,mpc5200-pcm", but I can't find any DTS which declares such a > node. Apparently the driver is somehow bound by ALSA via the platform name > "mpc5200-pcm-audio" via the specific fabric drivers, but that seems to happen > in the opposite order than it is supposed to: In my case, first the AC97 driver > is probed (i.e. mpc5200_psc_ac97.c), which expects the driver data to be > already initialized by the dma part, which it isn't, so the kernel oopses in > line 288 of mpc5200_psc_ac97.c: > > static int __devinit psc_ac97_of_probe(struct platform_device *op) > { > ... > 287 psc_dma = dev_get_drvdata(&op->dev); > 288 regs = psc_dma->psc_regs; > 289 ac97.private_data = psc_dma; > ... > > Am I doing something wrong or has this indeed changed in recent versions of > the kernel? > > I do have the driver working now, but I had to turn things around and kzalloc() > the drvdata struct "psc_dma" in the AC97 part of the driver. Of course this > makes unifying the driver quite an ugly job. > > Also, currently, my driver is not using DMA, but a work-queue to keep the FIFO > filled ;-) > > To get DMA working, I still need to extend the existing DMA driver which can > only do memory->memory transfers right now. Unfortunately this part is totally > different from the MPC5200B, which uses a bestcomm DMA controller, so I would > like to end up creating a new file "mpc5121_dma.c" and extending > "mpc5200_psc_ac97.c" so it does the mpc5121e-specific cold-reset. The rest is > basically the same.... except for the fact that I get the oops mentioned above > unless I do the PSC register setup and drvdata allocation in > psc_ac97_of_probe()! Is this also broken for the MPC5200B and do I need to fix > it for both? > > Also, I'd like to work towards generic fabric code for all the cases of > "generic AC97 codec connected to a PSC". Maybe this can be OF-ified somehow? > > Thanks a lot for any hint. > > Best regards, > > -- > David Jander > Protonic Holland. > -- Jon Smirl jonsmirl@gmail.com ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <20110908124529.520c1388@archvile>]
* Re: ASoC MPC5xxx PSC AC97 audio driver [not found] ` <20110908124529.520c1388@archvile> @ 2011-09-08 10:55 ` jonsmirl 2011-09-08 14:32 ` David Jander 0 siblings, 1 reply; 17+ messages in thread From: jonsmirl @ 2011-09-08 10:55 UTC (permalink / raw) To: David Jander; +Cc: Grant Likely, alsa-devel On Thu, Sep 8, 2011 at 6:45 AM, David Jander <david.jander@protonic.nl> wrote: > > Dear Jon, > > Thanks for replying so quickly. > > On Thu, 8 Sep 2011 06:28:02 -0400 > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: >> On Thu, Sep 8, 2011 at 6:16 AM, David Jander <david.jander@protonic.nl> >> wrote: >> > >> > Dear Jon, >> >> Here's the device tree... >> http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/dspeak01.dts;h=50cc247b4da0eb2bc4deb315b1b5348af87e5979;hb=9166a4a4141ab7c8d7a7b97fa5b726e11a8d0ca4 > > Thanks... but it uses I2S, not AC97 :-( > It doesn't have a "fsl,mpc5200-pcm" node either, btw. > In the case of I2C, this makes some sense, since the Codec is usually > connected to two different interfaces at the same time (I2S and I2C for > control), so you have 2 device nodes. AC97 OTOH has just one interface. It is > connected to a AC97 bus (a PSC in this case). AFAICS there are no OF bindings > yet for an AC97 bus, so the actual codec doesn't figure and thus still needs > this ugly fabric driver thing. Try the pcm030 device tree... http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/pcm030.dts;h=30bfdc04c6dfacd88a9c6e325e873d75a633bdf5;hb=HEAD I think it is checked into the kernel. > >> Grant can comment on the current bindings. > > Ok. > > Best regards, > > -- > David Jander > Protonic Holland. > -- Jon Smirl jonsmirl@gmail.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-08 10:55 ` jonsmirl @ 2011-09-08 14:32 ` David Jander 2011-09-08 17:52 ` jonsmirl 2011-09-08 18:44 ` torbenh 0 siblings, 2 replies; 17+ messages in thread From: David Jander @ 2011-09-08 14:32 UTC (permalink / raw) To: jonsmirl; +Cc: Grant Likely, alsa-devel Dear Jon, On Thu, 8 Sep 2011 06:55:56 -0400 "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > On Thu, Sep 8, 2011 at 6:45 AM, David Jander <david.jander@protonic.nl> > wrote: > > > > Dear Jon, > > > > Thanks for replying so quickly. > > > > On Thu, 8 Sep 2011 06:28:02 -0400 > > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > >> On Thu, Sep 8, 2011 at 6:16 AM, David Jander <david.jander@protonic.nl> > >> wrote: > >> > > >> > Dear Jon, > >> > >> Here's the device tree... > >> http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/dspeak01.dts;h=50cc247b4da0eb2bc4deb315b1b5348af87e5979;hb=9166a4a4141ab7c8d7a7b97fa5b726e11a8d0ca4 > > > > Thanks... but it uses I2S, not AC97 :-( > > It doesn't have a "fsl,mpc5200-pcm" node either, btw. > > In the case of I2C, this makes some sense, since the Codec is usually > > connected to two different interfaces at the same time (I2S and I2C for > > control), so you have 2 device nodes. AC97 OTOH has just one interface. It > > is connected to a AC97 bus (a PSC in this case). AFAICS there are no OF > > bindings yet for an AC97 bus, so the actual codec doesn't figure and thus > > still needs this ugly fabric driver thing. > > Try the pcm030 device tree... > > http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/pcm030.dts;h=30bfdc04c6dfacd88a9c6e325e873d75a633bdf5;hb=HEAD I had also looked at that one.... still no "fsl,mpc5200-pcm" node. I would not expect one either, given the way the fabric driver works. But what is the reason for this OF compatible string then? Most important question: Does the mpc5200_dma.c/mpc5200_psc_ac97.c combination in current mainline still work correctly? I am unable (by inference) to say for sure that mpc5200_hpcd_probe() will always be called before psc_ac97_of_probe(). If it is not, the latter will OOPS. In fact, when I try to mimic the same on a MPC5121e, it does get called in the opposite order! My theory is that this order may have changed in recent versions of kernel/ALSA, and that since that moment this driver has been broken and nobody noticed yet. I need to know, because I intend to enhance mpc5200_psc_ac97.c, to also support MPC512x, but this is not working the way it is written now. If I knew for sure that mpc5200 still works this way, I would need to find a bug in my code. In the other case, I'd just go and fix the driver for MPC5200 also, but I have no hardware to try it out myself. Best regards, -- David Jander Protonic Holland. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-08 14:32 ` David Jander @ 2011-09-08 17:52 ` jonsmirl 2011-09-09 6:48 ` David Jander 2011-09-08 18:44 ` torbenh 1 sibling, 1 reply; 17+ messages in thread From: jonsmirl @ 2011-09-08 17:52 UTC (permalink / raw) To: David Jander; +Cc: Grant Likely, alsa-devel On Thu, Sep 8, 2011 at 10:32 AM, David Jander <david.jander@protonic.nl> wrote: > > Dear Jon, > > On Thu, 8 Sep 2011 06:55:56 -0400 > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > >> On Thu, Sep 8, 2011 at 6:45 AM, David Jander <david.jander@protonic.nl> >> wrote: >> > >> > Dear Jon, >> > >> > Thanks for replying so quickly. >> > >> > On Thu, 8 Sep 2011 06:28:02 -0400 >> > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: >> >> On Thu, Sep 8, 2011 at 6:16 AM, David Jander <david.jander@protonic.nl> >> >> wrote: >> >> > >> >> > Dear Jon, >> >> >> >> Here's the device tree... >> >> http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/dspeak01.dts;h=50cc247b4da0eb2bc4deb315b1b5348af87e5979;hb=9166a4a4141ab7c8d7a7b97fa5b726e11a8d0ca4 >> > >> > Thanks... but it uses I2S, not AC97 :-( >> > It doesn't have a "fsl,mpc5200-pcm" node either, btw. >> > In the case of I2C, this makes some sense, since the Codec is usually >> > connected to two different interfaces at the same time (I2S and I2C for >> > control), so you have 2 device nodes. AC97 OTOH has just one interface. It >> > is connected to a AC97 bus (a PSC in this case). AFAICS there are no OF >> > bindings yet for an AC97 bus, so the actual codec doesn't figure and thus >> > still needs this ugly fabric driver thing. >> >> Try the pcm030 device tree... >> >> http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/pcm030.dts;h=30bfdc04c6dfacd88a9c6e325e873d75a633bdf5;hb=HEAD > > I had also looked at that one.... still no "fsl,mpc5200-pcm" node. I would not > expect one either, given the way the fabric driver works. But what is the > reason for this OF compatible string then? > > Most important question: Does the mpc5200_dma.c/mpc5200_psc_ac97.c combination > in current mainline still work correctly? I haven't booted a mpc5200 in over a year so I don't know. Grant probably has better info. He'll answer this thread sooner or later. > > I am unable (by inference) to say for sure that mpc5200_hpcd_probe() will > always be called before psc_ac97_of_probe(). If it is not, the latter will > OOPS. > In fact, when I try to mimic the same on a MPC5121e, it does get called in the > opposite order! My theory is that this order may have changed in recent > versions of kernel/ALSA, and that since that moment this driver has been > broken and nobody noticed yet. I need to know, because I intend to enhance > mpc5200_psc_ac97.c, to also support MPC512x, but this is not working the way it > is written now. If I knew for sure that mpc5200 still works this way, I would > need to find a bug in my code. In the other case, I'd just go and fix the > driver for MPC5200 also, but I have no hardware to try it out myself. > > Best regards, > > -- > David Jander > Protonic Holland. > -- Jon Smirl jonsmirl@gmail.com ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-08 17:52 ` jonsmirl @ 2011-09-09 6:48 ` David Jander 0 siblings, 0 replies; 17+ messages in thread From: David Jander @ 2011-09-09 6:48 UTC (permalink / raw) To: jonsmirl; +Cc: Grant Likely, alsa-devel On Thu, 8 Sep 2011 13:52:06 -0400 "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > On Thu, Sep 8, 2011 at 10:32 AM, David Jander <david.jander@protonic.nl> > wrote: > > > > Dear Jon, > > > > On Thu, 8 Sep 2011 06:55:56 -0400 > > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > > > >> On Thu, Sep 8, 2011 at 6:45 AM, David Jander <david.jander@protonic.nl> > >> wrote: > >> > > >> > Dear Jon, > >> > > >> > Thanks for replying so quickly. > >> > > >> > On Thu, 8 Sep 2011 06:28:02 -0400 > >> > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > >> >> On Thu, Sep 8, 2011 at 6:16 AM, David Jander <david.jander@protonic.nl> > >> >> wrote: > >> >> > > >> >> > Dear Jon, > >> >> > >> >> Here's the device tree... > >> >> http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/dspeak01.dts;h=50cc247b4da0eb2bc4deb315b1b5348af87e5979;hb=9166a4a4141ab7c8d7a7b97fa5b726e11a8d0ca4 > >> > > >> > Thanks... but it uses I2S, not AC97 :-( > >> > It doesn't have a "fsl,mpc5200-pcm" node either, btw. > >> > In the case of I2C, this makes some sense, since the Codec is usually > >> > connected to two different interfaces at the same time (I2S and I2C for > >> > control), so you have 2 device nodes. AC97 OTOH has just one interface. > >> > It is connected to a AC97 bus (a PSC in this case). AFAICS there are no > >> > OF bindings yet for an AC97 bus, so the actual codec doesn't figure and > >> > thus still needs this ugly fabric driver thing. > >> > >> Try the pcm030 device tree... > >> > >> http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/pcm030.dts;h=30bfdc04c6dfacd88a9c6e325e873d75a633bdf5;hb=HEAD > > > > I had also looked at that one.... still no "fsl,mpc5200-pcm" node. I would > > not expect one either, given the way the fabric driver works. But what is > > the reason for this OF compatible string then? > > > > Most important question: Does the mpc5200_dma.c/mpc5200_psc_ac97.c > > combination in current mainline still work correctly? > > I haven't booted a mpc5200 in over a year so I don't know. Grant > probably has better info. He'll answer this thread sooner or later. Ok. Thanks. I have been investigating the history os soc-core.c. Specially how the probe function evolved, and one thing I can tell from it, is that the probe order always has been: 1. machine 2. cpu_dai 3. codec 4. platform Only in recent versions, there seems to be a possibility to change the order by using the "probe_order" field in "struct snd_soc_dai_driver". No idea how the specify it yet... Nevertheless, the mpc5200 audio driver seems to rely on the platform part being probed _before_ the cpu_dai part. Does it work by shear luck or am I missing something? Best regards, -- David Jander Protonic Holland. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-08 14:32 ` David Jander 2011-09-08 17:52 ` jonsmirl @ 2011-09-08 18:44 ` torbenh 2011-09-09 6:28 ` David Jander 1 sibling, 1 reply; 17+ messages in thread From: torbenh @ 2011-09-08 18:44 UTC (permalink / raw) To: David Jander; +Cc: Grant Likely, alsa-devel On Thu, Sep 08, 2011 at 04:32:31PM +0200, David Jander wrote: > > Dear Jon, > > On Thu, 8 Sep 2011 06:55:56 -0400 > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > > > On Thu, Sep 8, 2011 at 6:45 AM, David Jander <david.jander@protonic.nl> > > wrote: > > > > > > Dear Jon, > > > > > > Thanks for replying so quickly. > > > > > > On Thu, 8 Sep 2011 06:28:02 -0400 > > > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > > >> On Thu, Sep 8, 2011 at 6:16 AM, David Jander <david.jander@protonic.nl> > > >> wrote: > > >> > > > >> > Dear Jon, > > >> > > >> Here's the device tree... > > >> http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/dspeak01.dts;h=50cc247b4da0eb2bc4deb315b1b5348af87e5979;hb=9166a4a4141ab7c8d7a7b97fa5b726e11a8d0ca4 > > > > > > Thanks... but it uses I2S, not AC97 :-( > > > It doesn't have a "fsl,mpc5200-pcm" node either, btw. > > > In the case of I2C, this makes some sense, since the Codec is usually > > > connected to two different interfaces at the same time (I2S and I2C for > > > control), so you have 2 device nodes. AC97 OTOH has just one interface. It > > > is connected to a AC97 bus (a PSC in this case). AFAICS there are no OF > > > bindings yet for an AC97 bus, so the actual codec doesn't figure and thus > > > still needs this ugly fabric driver thing. > > > > Try the pcm030 device tree... > > > > http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/pcm030.dts;h=30bfdc04c6dfacd88a9c6e325e873d75a633bdf5;hb=HEAD > > I had also looked at that one.... still no "fsl,mpc5200-pcm" node. I would not > expect one either, given the way the fabric driver works. But what is the > reason for this OF compatible string then? > > Most important question: Does the mpc5200_dma.c/mpc5200_psc_ac97.c combination > in current mainline still work correctly? > > I am unable (by inference) to say for sure that mpc5200_hpcd_probe() will > always be called before psc_ac97_of_probe(). If it is not, the latter will > OOPS. > In fact, when I try to mimic the same on a MPC5121e, it does get called in the > opposite order! My theory is that this order may have changed in recent > versions of kernel/ALSA, and that since that moment this driver has been > broken and nobody noticed yet. I need to know, because I intend to enhance > mpc5200_psc_ac97.c, to also support MPC512x, but this is not working the way it > is written now. If I knew for sure that mpc5200 still works this way, I would > need to find a bug in my code. In the other case, I'd just go and fix the > driver for MPC5200 also, but I have no hardware to try it out myself. i am working on mpc5125 right now. i dont have hardware with an audio codec yet, but will get that soon. I already have extended drivers/dma/mpc512x_dma.c to support slave dma to the sdhc. (only got it working today, so its still a bit sketchy) i am also interested in a proper fabric example. > > Best regards, > > -- > David Jander > Protonic Holland. > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- torben Hohn ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-08 18:44 ` torbenh @ 2011-09-09 6:28 ` David Jander 2011-09-09 10:02 ` ASoC audio fabric OF bindings RFC. was: " David Jander 0 siblings, 1 reply; 17+ messages in thread From: David Jander @ 2011-09-09 6:28 UTC (permalink / raw) To: torbenh; +Cc: Grant Likely, alsa-devel Hi Torben, On Thu, 8 Sep 2011 20:44:41 +0200 torbenh <torbenh@gmx.de> wrote: > On Thu, Sep 08, 2011 at 04:32:31PM +0200, David Jander wrote: > > > > Dear Jon, > > > > On Thu, 8 Sep 2011 06:55:56 -0400 > > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > > > > > On Thu, Sep 8, 2011 at 6:45 AM, David Jander <david.jander@protonic.nl> > > > wrote: > > > > > > > > Dear Jon, > > > > > > > > Thanks for replying so quickly. > > > > > > > > On Thu, 8 Sep 2011 06:28:02 -0400 > > > > "jonsmirl@gmail.com" <jonsmirl@gmail.com> wrote: > > > >> On Thu, Sep 8, 2011 at 6:16 AM, David Jander > > > >> <david.jander@protonic.nl> wrote: > > > >> > > > > >> > Dear Jon, > > > >> > > > >> Here's the device tree... > > > >> http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/dspeak01.dts;h=50cc247b4da0eb2bc4deb315b1b5348af87e5979;hb=9166a4a4141ab7c8d7a7b97fa5b726e11a8d0ca4 > > > > > > > > Thanks... but it uses I2S, not AC97 :-( > > > > It doesn't have a "fsl,mpc5200-pcm" node either, btw. > > > > In the case of I2C, this makes some sense, since the Codec is usually > > > > connected to two different interfaces at the same time (I2S and I2C for > > > > control), so you have 2 device nodes. AC97 OTOH has just one > > > > interface. It is connected to a AC97 bus (a PSC in this case). AFAICS > > > > there are no OF bindings yet for an AC97 bus, so the actual codec > > > > doesn't figure and thus still needs this ugly fabric driver thing. > > > > > > Try the pcm030 device tree... > > > > > > http://git.digispeaker.com/?p=digispeaker-kernel.git;a=blob;f=arch/powerpc/boot/dts/pcm030.dts;h=30bfdc04c6dfacd88a9c6e325e873d75a633bdf5;hb=HEAD > > > > I had also looked at that one.... still no "fsl,mpc5200-pcm" node. I would > > not expect one either, given the way the fabric driver works. But what is > > the reason for this OF compatible string then? > > > > Most important question: Does the mpc5200_dma.c/mpc5200_psc_ac97.c > > combination in current mainline still work correctly? > > > > I am unable (by inference) to say for sure that mpc5200_hpcd_probe() will > > always be called before psc_ac97_of_probe(). If it is not, the latter will > > OOPS. > > In fact, when I try to mimic the same on a MPC5121e, it does get called in > > the opposite order! My theory is that this order may have changed in recent > > versions of kernel/ALSA, and that since that moment this driver has been > > broken and nobody noticed yet. I need to know, because I intend to enhance > > mpc5200_psc_ac97.c, to also support MPC512x, but this is not working the > > way it is written now. If I knew for sure that mpc5200 still works this > > way, I would need to find a bug in my code. In the other case, I'd just go > > and fix the driver for MPC5200 also, but I have no hardware to try it out > > myself. > > i am working on mpc5125 right now. My respects. Nobody I know dared to touch that alien yet (at least not for use with linux) ;-) May I ask how you solved the nasty incompatibilities in the PSC (and other) drivers? I couldn't come up with an acceptable solution.... > i dont have hardware with an audio codec yet, but will get that soon. > I already have extended drivers/dma/mpc512x_dma.c to support slave dma > to the sdhc. (only got it working today, so its still a bit sketchy) Great. I was planning to add slave DMA myself for audio, but decided to first try out a simple work_queue to see if I can produce some sound. Do you mind sharing your DMA patch? I'd really like to have a look at it. > i am also interested in a proper fabric example. What do you think about creating device-tree bindings for that? I tend to like the idea of not needing any special board support code besides the DT, and the audio fabric driver part is the only obstacle for that. Best regards, -- David Jander Protonic Holland. ^ permalink raw reply [flat|nested] 17+ messages in thread
* ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-09 6:28 ` David Jander @ 2011-09-09 10:02 ` David Jander 2011-09-09 16:37 ` Mark Brown 0 siblings, 1 reply; 17+ messages in thread From: David Jander @ 2011-09-09 10:02 UTC (permalink / raw) To: torbenh; +Cc: Grant Likely, alsa-devel, devicetree-discuss On Fri, 9 Sep 2011 08:28:44 +0200 David Jander <david.jander@protonic.nl> wrote: >[...] > > i am also interested in a proper fabric example. > > What do you think about creating device-tree bindings for that? I tend to > like the idea of not needing any special board support code besides the DT, > and the audio fabric driver part is the only obstacle for that. Ok, I actually spent a while thinking about this. What about the following idea: Given the following devicetree: ... // PSC11 in ac97 mode ac97@11b00 { /* 1 */ compatible = "fsl,mpc5121-psc-ac97", "fsl,mpc5121-psc", "alsa,cpu-dai"; cell-index = <11>; reg = <0x11b00 0x100>; interrupts = <40 0x8>; fsl,mode = "ac97-slave"; fsl,rx-fifo-size = <384>; fsl,tx-fifo-size = <384>; #address-cells = <1>; #size-cells = <0>; /* 2 */ codec0: psc-ac97-analog@0 { /* 3 */ compatible = "national,lm4550", "ac97-codec"; /* 4 */ alsa,codec-dai-name = "ac97-hifi"; }; }; Consider the following pseudo-code in sound/soc/soc-of.c: static struct snd_soc_card card; static struct snd_soc_dai_link *of_dai; static __init int of_fabric_init(void) { of_for_each_compatible_node("alsa,cpu-dai") do { count++; } of_dai = kzalloc(count * (sizeof struct snd_soc_dai_link)); of_for_each_compatible_node("alsa,cpu-dai") as parent do { of_for_each_child(parent) as node { of_dai[i].name = of_get_name(parent); /* "ac97" */ of_dai[i].stream_name = of_fabric_dai[i].name + str(i); of_dai[i].cpu_dai_name = of_get_name(node); /* "psc-ac97-analog" */ of_dai[i].codec_dai_name = of_get_property(node, "alsa,codec_dai_name"); /* 5 */ of_dai[i].codec_name = match_of_compatible_with_registered_codec_list(node); of_dai[i].platform_name = of_soc_name + "-pcm-audio"; i++; } } card.name = "of-audio"; card.dai_link = of_dai; card.num_links = i; pdev = platform_device_alloc("soc-audio", 1); platform_set_drvdata(pdev, &card); platform_device_add(pdev); } Notes in the pseudo-source above: 1: By adding compatible = "alsa,cpu-dai", this DAI is marked for binding. 2: Child nodes list all CPU DAI's and their conected codecs. Child node name is name of the CPU DAI. 3: Many ac97 codecs are compatible with the generic codec driver "ac97-codec". 4: Don't know if this is the right way to work the codec DAI name in. See the next note: 5: The pseudo-function match_of_compatible_with_registered_codec_list() will search through the list of registered ALSA codecs and match the compatible strings of this codec with one in the list. If one is found, the name is used for of_dai[i].codec_name, otherwise the current node is discarded (no matching codec driver registered). Maybe the corresponding "codec-dai-name" can be extracted from the codec database? That would eliminate line /* 4 */. Unfortunately, this way we will probably need to get back the Kconfig option to choose which codecs should be built. Apparently this option existed before, but was removed. All comments are welcome. Best regards, -- David Jander Protonic Holland. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-09 10:02 ` ASoC audio fabric OF bindings RFC. was: " David Jander @ 2011-09-09 16:37 ` Mark Brown 2011-09-12 6:31 ` David Jander 0 siblings, 1 reply; 17+ messages in thread From: Mark Brown @ 2011-09-09 16:37 UTC (permalink / raw) To: David Jander; +Cc: Grant Likely, alsa-devel, lrg, devicetree-discuss, torbenh On Fri, Sep 09, 2011 at 12:02:16PM +0200, David Jander wrote: > Ok, I actually spent a while thinking about this. What about the following > idea: *Always* CC maintainers. > 1: By adding compatible = "alsa,cpu-dai", this DAI is marked for binding. This isn't really something that should go into device tree, ALSA is a Linux specific concept. > 3: Many ac97 codecs are compatible with the generic codec driver "ac97-codec". All should be. The only reason for specific drivers is to enable additional non-standard functionality. > 4: Don't know if this is the right way to work the codec DAI name in. See the > next note: What we should really be doing here is to autodiscover by reading the ID registers in the device. That needs generic AC'97 bus work which we don't have right now. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-09 16:37 ` Mark Brown @ 2011-09-12 6:31 ` David Jander 2011-09-12 11:09 ` Mark Brown 0 siblings, 1 reply; 17+ messages in thread From: David Jander @ 2011-09-12 6:31 UTC (permalink / raw) To: Mark Brown; +Cc: Grant Likely, alsa-devel, lrg, devicetree-discuss, torbenh On Fri, 9 Sep 2011 17:37:14 +0100 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Fri, Sep 09, 2011 at 12:02:16PM +0200, David Jander wrote: > > > Ok, I actually spent a while thinking about this. What about the following > > idea: > > *Always* CC maintainers. Sorry ;-) > > 1: By adding compatible = "alsa,cpu-dai", this DAI is marked for binding. > > This isn't really something that should go into device tree, ALSA is a > Linux specific concept. There are many Linux-specific details in Linux's implementation of Open Firmware Device Trees. Right now, thanks to Linux, Open-Firmware device trees are used for much more hardware platforms than just Oracle hardware that probably isn't manufactured anymore and IBM Power servers. For embedded systems for example, DT's have been used on all PowerPC platforms and is being introduced in arch/arm right now. On all these platforms, its sole existence is purely for running Linux with minimal board support code in the kernel. So, why not add a few more Linux-specific bits to it, if it helps get rid of the last bit of board-specific code? The platforms that will use those bindings, will never have Open-Firmware bioses in the first place, and their DT sources will be part of the kernel source tree anyway. > > 3: Many ac97 codecs are compatible with the generic codec driver > > "ac97-codec". > > All should be. The only reason for specific drivers is to enable > additional non-standard functionality. I was being careful. > > 4: Don't know if this is the right way to work the codec DAI name in. See > > the next note: > > What we should really be doing here is to autodiscover by reading the ID > registers in the device. That needs generic AC'97 bus work which we > don't have right now. Seems reasonable, but is correct autodiscovery really possible for all configurations and all DAI-codec combinations? Best regards, -- David Jander Protonic Holland. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-12 6:31 ` David Jander @ 2011-09-12 11:09 ` Mark Brown 2011-09-12 12:55 ` David Jander 0 siblings, 1 reply; 17+ messages in thread From: Mark Brown @ 2011-09-12 11:09 UTC (permalink / raw) To: David Jander; +Cc: Grant Likely, alsa-devel, lrg, devicetree-discuss, torbenh On Mon, Sep 12, 2011 at 08:31:58AM +0200, David Jander wrote: > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > > This isn't really something that should go into device tree, ALSA is a > > Linux specific concept. > There are many Linux-specific details in Linux's implementation of Open > Firmware Device Trees. Right now, thanks to Linux, Open-Firmware device trees This is generally considered a bug in the bindings, the bindings are for cross-platform usage and should not be specific to any OS. > introduced in arch/arm right now. On all these platforms, its sole existence > is purely for running Linux with minimal board support code in the kernel. Other OSs are actively using device tree. > So, why not add a few more Linux-specific bits to it, if it helps get rid of > the last bit of board-specific code? Eliminating board specific code for audio is not a realistic goal, the configuration of modern audio subsystems is too complex and dynamic. It is realistic to make machine drivers which cover broad classes of devices with similar hardware. > The platforms that will use those bindings, will never have > Open-Firmware bioses in the first place, and their DT sources will be part of > the kernel source tree anyway. The plan is to push the device trees out of the kernel into a separate repository. > > What we should really be doing here is to autodiscover by reading the ID > > registers in the device. That needs generic AC'97 bus work which we > > don't have right now. > Seems reasonable, but is correct autodiscovery really possible for all > configurations and all DAI-codec combinations? Yes, it's a very basic part of AC'97. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-12 11:09 ` Mark Brown @ 2011-09-12 12:55 ` David Jander 2011-09-12 13:19 ` Mark Brown 0 siblings, 1 reply; 17+ messages in thread From: David Jander @ 2011-09-12 12:55 UTC (permalink / raw) To: Mark Brown; +Cc: Grant Likely, alsa-devel, lrg, devicetree-discuss, torbenh On Mon, 12 Sep 2011 12:09:50 +0100 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Mon, Sep 12, 2011 at 08:31:58AM +0200, David Jander wrote: > > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > > > > This isn't really something that should go into device tree, ALSA is a > > > Linux specific concept. > > > There are many Linux-specific details in Linux's implementation of Open > > Firmware Device Trees. Right now, thanks to Linux, Open-Firmware device > > trees > > This is generally considered a bug in the bindings, the bindings are for > cross-platform usage and should not be specific to any OS. Ok. I get your point. > > introduced in arch/arm right now. On all these platforms, its sole > > existence is purely for running Linux with minimal board support code in > > the kernel. > > Other OSs are actively using device tree. Interesting. I wasn't aware of "actively using". Sure, there's MacOS-X-ppc, IBM AIX, Oracle Solaris.... and I just discovered that Free-/OpenBSD also use them. > > So, why not add a few more Linux-specific bits to it, if it helps get rid > > of the last bit of board-specific code? > > Eliminating board specific code for audio is not a realistic goal, the > configuration of modern audio subsystems is too complex and dynamic. Why not? How complex could it be in order to not be able to describe it in a Device-Tree in some OS-agnostic way? > It > is realistic to make machine drivers which cover broad classes of > devices with similar hardware. Ok. That was my original plan... it just occurred to me that describing the audio fabric in OF-DT would be a better idea :-( > > The platforms that will use those bindings, will never have > > Open-Firmware bioses in the first place, and their DT sources will be part > > of the kernel source tree anyway. > > The plan is to push the device trees out of the kernel into a separate > repository. Good idea.... but where should such a repository be hosted? > > > What we should really be doing here is to autodiscover by reading the ID > > > registers in the device. That needs generic AC'97 bus work which we > > > don't have right now. > > > Seems reasonable, but is correct autodiscovery really possible for all > > configurations and all DAI-codec combinations? > > Yes, it's a very basic part of AC'97. Thanks for pointing out. I suspected that already, but since everyone seems to just go ahead and write his own piece of fabric-code, I started wondering about the reason. I wouldn't consider a second about just blindfolded duplicating what several others already did before me without seriously thinking about a universal "fits almost all" solution instead. And I still refuse to just copy-cat audio fabric code for our board! Best regards, -- David Jander Protonic Holland. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-12 12:55 ` David Jander @ 2011-09-12 13:19 ` Mark Brown 2011-09-12 13:59 ` David Jander 0 siblings, 1 reply; 17+ messages in thread From: Mark Brown @ 2011-09-12 13:19 UTC (permalink / raw) To: David Jander; +Cc: Grant Likely, alsa-devel, lrg, devicetree-discuss, torbenh On Mon, Sep 12, 2011 at 02:55:07PM +0200, David Jander wrote: > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > > Other OSs are actively using device tree. > Interesting. I wasn't aware of "actively using". Sure, there's MacOS-X-ppc, > IBM AIX, Oracle Solaris.... and I just discovered that Free-/OpenBSD also use > them. *BSD are the main ones to consider here. > > Eliminating board specific code for audio is not a realistic goal, the > > configuration of modern audio subsystems is too complex and dynamic. > Why not? How complex could it be in order to not be able to describe it in a > Device-Tree in some OS-agnostic way? Note the "dynamic" bit - the configuration changes at runtime. Describing the hardware for something like a modern smartphone isn't particularly useful due to the flexibility, there are too many different ways of configuring the system and we need code to acutally take those decision. > > The plan is to push the device trees out of the kernel into a separate > > repository. > Good idea.... but where should such a repository be hosted? Still an open issue. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-12 13:19 ` Mark Brown @ 2011-09-12 13:59 ` David Jander 2011-09-12 14:52 ` Mark Brown 0 siblings, 1 reply; 17+ messages in thread From: David Jander @ 2011-09-12 13:59 UTC (permalink / raw) To: Mark Brown; +Cc: Grant Likely, alsa-devel, lrg, devicetree-discuss, torbenh On Mon, 12 Sep 2011 14:19:24 +0100 Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > On Mon, Sep 12, 2011 at 02:55:07PM +0200, David Jander wrote: > > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > > > > Other OSs are actively using device tree. > > > Interesting. I wasn't aware of "actively using". Sure, there's MacOS-X-ppc, > > IBM AIX, Oracle Solaris.... and I just discovered that Free-/OpenBSD also > > use them. > > *BSD are the main ones to consider here. > > > > Eliminating board specific code for audio is not a realistic goal, the > > > configuration of modern audio subsystems is too complex and dynamic. > > > Why not? How complex could it be in order to not be able to describe it in > > a Device-Tree in some OS-agnostic way? > > Note the "dynamic" bit - the configuration changes at runtime. > Describing the hardware for something like a modern smartphone isn't > particularly useful due to the flexibility, there are too many different > ways of configuring the system and we need code to acutally take those > decision. Ok, but you could still describe the hardwired part of it (Audio muxes, codecs, busses and physical interfaces). Isn't that what OF is all about? In our case, its just a simple AC97 codec connected to a simple AC97 bus. Sounds like total overkill having to write a "fabric driver" for this.... while there are already quite a few that are all 99% the same! > > > The plan is to push the device trees out of the kernel into a separate > > > repository. > > > Good idea.... but where should such a repository be hosted? > > Still an open issue. Seems like its hard to find a vendor- and OS-neutral entity to host this? OpenBIOS maybe? Best regards, -- David Jander Protonic Holland. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-12 13:59 ` David Jander @ 2011-09-12 14:52 ` Mark Brown 2011-09-12 19:48 ` Grant Likely 0 siblings, 1 reply; 17+ messages in thread From: Mark Brown @ 2011-09-12 14:52 UTC (permalink / raw) To: David Jander; +Cc: Grant Likely, alsa-devel, lrg, devicetree-discuss, torbenh On Mon, Sep 12, 2011 at 03:59:05PM +0200, David Jander wrote: > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > > Note the "dynamic" bit - the configuration changes at runtime. > > Describing the hardware for something like a modern smartphone isn't > > particularly useful due to the flexibility, there are too many different > > ways of configuring the system and we need code to acutally take those > > decision. > Ok, but you could still describe the hardwired part of it (Audio muxes, > codecs, busses and physical interfaces). Isn't that what OF is all about? > In our case, its just a simple AC97 codec connected to a simple AC97 bus. > Sounds like total overkill having to write a "fabric driver" for this.... > while there are already quite a few that are all 99% the same! I'm not sure I understand what you are talking about. As I've already said at least once having a *machine* driver which covers multiple machines is absolutely OK. We already have several such drivers in kernel. *Please* look at the existing code and read what I'm saying, and ideally also read the prior discussions on this topic. Please also try to avoid inventing your own techncial terms. It's enormously repetitive and not terribly useful to have to go through all this stuff from square one every single time someone looks at this stuff. > > > > The plan is to push the device trees out of the kernel into a separate > > > > repository. > > > Good idea.... but where should such a repository be hosted? > > Still an open issue. > Seems like its hard to find a vendor- and OS-neutral entity to host this? > OpenBIOS maybe? More a problem of deciding which of the many available options to choose. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-12 14:52 ` Mark Brown @ 2011-09-12 19:48 ` Grant Likely 2011-09-13 6:31 ` David Jander 0 siblings, 1 reply; 17+ messages in thread From: Grant Likely @ 2011-09-12 19:48 UTC (permalink / raw) To: Mark Brown; +Cc: alsa-devel, lrg, David Jander, devicetree-discuss, torbenh On Mon, Sep 12, 2011 at 03:52:14PM +0100, Mark Brown wrote: > On Mon, Sep 12, 2011 at 03:59:05PM +0200, David Jander wrote: > > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > > > > Note the "dynamic" bit - the configuration changes at runtime. > > > Describing the hardware for something like a modern smartphone isn't > > > particularly useful due to the flexibility, there are too many different > > > ways of configuring the system and we need code to acutally take those > > > decision. > > > Ok, but you could still describe the hardwired part of it (Audio muxes, > > codecs, busses and physical interfaces). Isn't that what OF is all about? > > In our case, its just a simple AC97 codec connected to a simple AC97 bus. > > Sounds like total overkill having to write a "fabric driver" for this.... > > while there are already quite a few that are all 99% the same! > > I'm not sure I understand what you are talking about. As I've already > said at least once having a *machine* driver which covers multiple > machines is absolutely OK. We already have several such drivers in > kernel. Yes, a machine driver is quite a sane way to manage the huge range of variability of a machine's audio complex. If it turns out that an SoC only ever has one machine driver that handles all possible configurations, it still isn't really more complex. If, however, the permutations are sufficiently different to warrant separate driver then the groundwork is already established to support it sanely. BTW, this isn't a question about "what OF is all about". It makes perfect sense in the OF context to have a node describing how multiple devices are aggregated into a single logically composite device. Do a machine driver. It's the right thing to do. g. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: ASoC audio fabric OF bindings RFC. was: Re: ASoC MPC5xxx PSC AC97 audio driver 2011-09-12 19:48 ` Grant Likely @ 2011-09-13 6:31 ` David Jander 0 siblings, 0 replies; 17+ messages in thread From: David Jander @ 2011-09-13 6:31 UTC (permalink / raw) To: Grant Likely; +Cc: lrg, alsa-devel, Mark Brown, devicetree-discuss, torbenh On Mon, 12 Sep 2011 13:48:50 -0600 Grant Likely <grant.likely@secretlab.ca> wrote: > On Mon, Sep 12, 2011 at 03:52:14PM +0100, Mark Brown wrote: > > On Mon, Sep 12, 2011 at 03:59:05PM +0200, David Jander wrote: > > > Mark Brown <broonie@opensource.wolfsonmicro.com> wrote: > > > > > > Note the "dynamic" bit - the configuration changes at runtime. > > > > Describing the hardware for something like a modern smartphone isn't > > > > particularly useful due to the flexibility, there are too many > > > > different ways of configuring the system and we need code to acutally > > > > take those decision. > > > > > Ok, but you could still describe the hardwired part of it (Audio muxes, > > > codecs, busses and physical interfaces). Isn't that what OF is all about? > > > In our case, its just a simple AC97 codec connected to a simple AC97 bus. > > > Sounds like total overkill having to write a "fabric driver" for this.... > > > while there are already quite a few that are all 99% the same! > > > > I'm not sure I understand what you are talking about. As I've already > > said at least once having a *machine* driver which covers multiple > > machines is absolutely OK. We already have several such drivers in > > kernel. > > Yes, a machine driver is quite a sane way to manage the huge range of > variability of a machine's audio complex. If it turns out that an SoC > only ever has one machine driver that handles all possible > configurations, it still isn't really more complex. If, however, the > permutations are sufficiently different to warrant separate driver > then the groundwork is already established to support it sanely. > > BTW, this isn't a question about "what OF is all about". It makes > perfect sense in the OF context to have a node describing how multiple > devices are aggregated into a single logically composite device. > > Do a machine driver. It's the right thing to do. Ok, thanks. Best regards, -- David Jander Protonic Holland. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2011-09-13 6:31 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20110908121600.267dee07@archvile> 2011-09-08 10:28 ` ASoC MPC5xxx PSC AC97 audio driver jonsmirl [not found] ` <20110908124529.520c1388@archvile> 2011-09-08 10:55 ` jonsmirl 2011-09-08 14:32 ` David Jander 2011-09-08 17:52 ` jonsmirl 2011-09-09 6:48 ` David Jander 2011-09-08 18:44 ` torbenh 2011-09-09 6:28 ` David Jander 2011-09-09 10:02 ` ASoC audio fabric OF bindings RFC. was: " David Jander 2011-09-09 16:37 ` Mark Brown 2011-09-12 6:31 ` David Jander 2011-09-12 11:09 ` Mark Brown 2011-09-12 12:55 ` David Jander 2011-09-12 13:19 ` Mark Brown 2011-09-12 13:59 ` David Jander 2011-09-12 14:52 ` Mark Brown 2011-09-12 19:48 ` Grant Likely 2011-09-13 6:31 ` David Jander
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.