I'm looking into write a ASoC v2 driver for the Efika. Efika uses a Freescale MPC5200B and a STAC9766. This is a practice driver before writing one for our target hardware (which doesn't work yet, same CPU but different codec).
I've brought the changes from wolfson/asoc-v2-dev into my powerpc tree and got a couple of config errors with ARCH=powerpc.
sound/soc/pxa/Kconfig:23:warning: 'select' used by config symbol 'SND_PXA2XX_SOC_SSP' refers to undefined symbol 'PXA_SSP' sound/soc/au1x/Kconfig:35:warning: 'select' used by config symbol 'SND_SOC_EXM1200_SSI' refers to undefined symbol 'SND_SOC_CS4251X'
Suggestions on the best way to start? Target hardware also has a WM8804 on it.
On Thu, 2007-10-04 at 13:12 -0400, Jon Smirl wrote:
I'm looking into write a ASoC v2 driver for the Efika. Efika uses a Freescale MPC5200B and a STAC9766. This is a practice driver before writing one for our target hardware (which doesn't work yet, same CPU but different codec).
I've brought the changes from wolfson/asoc-v2-dev into my powerpc tree and got a couple of config errors with ARCH=powerpc.
sound/soc/pxa/Kconfig:23:warning: 'select' used by config symbol 'SND_PXA2XX_SOC_SSP' refers to undefined symbol 'PXA_SSP' sound/soc/au1x/Kconfig:35:warning: 'select' used by config symbol 'SND_SOC_EXM1200_SSI' refers to undefined symbol 'SND_SOC_CS4251X'
Thanks, I'll fix this.
Suggestions on the best way to start? Target hardware also has a WM8804 on it.
A good place to start would be looking at the other supported architectures and codecs and see what fits in best with your target SoC CPU. Fwiw, Timur Tabi has some working PPC code, although I'm not sure if it will work on Efika.
I usually start with the I2S driver and the codec in slave mode. Then move onto the DMA when I see the I2S bits toggling correctly. After the DMA is up and running I can complete the codec and I2S drivers.
Liam
On 10/5/07, Liam Girdwood lg@opensource.wolfsonmicro.com wrote:
A good place to start would be looking at the other supported architectures and codecs and see what fits in best with your target SoC CPU. Fwiw, Timur Tabi has some working PPC code, although I'm not sure if it will work on Efika.
Efika is STAC9766, ac97 with no i2c control. I dug into the imx ac97 driver and discovered that it isn't finished.
Timur, we may need to get some Bestcomm tasks written. I haven't explored this yet but I've been told that no one can get anything except the general DMA task working for audio. This mean all audio input has to be 32b. Isn't Bestcomm capable of expanding 16/24 bit data? Our target hardware is i2s, not ac97, so I need to get i2s running too.
I usually start with the I2S driver and the codec in slave mode. Then move onto the DMA when I see the I2S bits toggling correctly. After the DMA is up and running I can complete the codec and I2S drivers.
Sounds like a good plan. I already have a working driver for the Efika so this shouldn't be two bad. It just need to be rearranged.
Jon Smirl wrote:
On 10/5/07, Liam Girdwood lg@opensource.wolfsonmicro.com wrote:
A good place to start would be looking at the other supported architectures and codecs and see what fits in best with your target SoC CPU. Fwiw, Timur Tabi has some working PPC code, although I'm not sure if it will work on Efika.
Efika is STAC9766, ac97 with no i2c control. I dug into the imx ac97 driver and discovered that it isn't finished.
A lot of the i.MX code just sits in BSPs and is never forwarded to the main repositories.
Timur, we may need to get some Bestcomm tasks written. I haven't explored this yet but I've been told that no one can get anything except the general DMA task working for audio. This mean all audio input has to be 32b. Isn't Bestcomm capable of expanding 16/24 bit data? Our target hardware is i2s, not ac97, so I need to get i2s running too.
I'm working on an audio driver for the 8610, but I'm going to target ASoC V1 first, just so that I can get a better feel for how V2 is different (a sort of "trial by fire").
I don't know much about Bestcomm, but the DMA engine on the the 8610 is much simpler, from what I've heard. I only work on 83xx, 85xx, and 86xx, so I really can't answer any Bestcomm questions.
As for requiring all audio to be 32b, that's not such a bad thing. Any application that uses the standard ALSA interface will have format-conversion plug-ins automatically invoked. The overhead will be minor, since it has to do a byte-copy anyway.
On 10/5/07, Timur Tabi timur@freescale.com wrote:
Jon Smirl wrote:
On 10/5/07, Liam Girdwood lg@opensource.wolfsonmicro.com wrote:
A good place to start would be looking at the other supported architectures and codecs and see what fits in best with your target SoC CPU. Fwiw, Timur Tabi has some working PPC code, although I'm not sure if it will work on Efika.
Efika is STAC9766, ac97 with no i2c control. I dug into the imx ac97 driver and discovered that it isn't finished.
A lot of the i.MX code just sits in BSPs and is never forwarded to the main repositories.
Aren't you fixing that?
Timur, we may need to get some Bestcomm tasks written. I haven't explored this yet but I've been told that no one can get anything except the general DMA task working for audio. This mean all audio input has to be 32b. Isn't Bestcomm capable of expanding 16/24 bit data? Our target hardware is i2s, not ac97, so I need to get i2s running too.
I'm working on an audio driver for the 8610, but I'm going to target ASoC V1 first, just so that I can get a better feel for how V2 is different (a sort of "trial by fire").
I started looking at v2 because of the posts about modularizing it and using open firmware to identify and load the codecs. There doesn't seem to be that much difference.
I don't know much about Bestcomm, but the DMA engine on the the 8610 is much simpler, from what I've heard. I only work on 83xx, 85xx, and 86xx, so I really can't answer any Bestcomm questions.
We are on 5200 because it is cheaper and 5200 has all the peripherals we need. Now that I am writing code for it I see that BestComm adds a lot of complexity. Hopefully I can get i2s working on it, I'd hate to switch CPUs after doing all this work.
As for requiring all audio to be 32b, that's not such a bad thing. Any application that uses the standard ALSA interface will have format-conversion plug-ins automatically invoked. The overhead will be minor, since it has to do a byte-copy anyway.
-- Timur Tabi Linux Kernel Developer @ Freescale
Jon Smirl wrote:
A lot of the i.MX code just sits in BSPs and is never forwarded to the main repositories.
Aren't you fixing that?
No, I work on PowerPC only, and only some 8xxx chips. The i.MX stuff is a completely different group, and I only know one person who works on it, and she's in India.
I started looking at v2 because of the posts about modularizing it and using open firmware to identify and load the codecs. There doesn't seem to be that much difference.
My brain can only handle so much at one time. :-)
We are on 5200 because it is cheaper and 5200 has all the peripherals we need. Now that I am writing code for it I see that BestComm adds a lot of complexity. Hopefully I can get i2s working on it, I'd hate to switch CPUs after doing all this work.
You might want to direct some questions to the linuxppc-dev@ozlabs.org. Also, if you have an IRC client, you can find a bunch of us on irc.freenode.net, channel #mklinux.
participants (3)
-
Jon Smirl -
Liam Girdwood -
Timur Tabi