[alsa-devel] SoC sound support for imx27
Hi,
I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S. I found the imx21 already in the repository (may it will help for my job). Is anybody else working on i.MX27 support (to avoid to reinvention everything)?
Regards Juergen
On Wed, 2008-04-23 at 16:54 +0200, Juergen Beisert wrote:
Hi,
I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S. I found the imx21 already in the repository (may it will help for my job). Is anybody else working on i.MX27 support (to avoid to reinvention everything)?
It's not fully supported atm. However I've had interest from a few folks who are interested in completing support.
Currently working :-
o i.MX2x SSI is complete (same as i.MX3)
Todo:
o i.MX2x DMA is not completed. There is a half ASoC ported OSS based implementation in git atm, although it's not complete due to my only remaining i.MX21 board dying. Should be only about 1 weeks effort to complete this.
Liam
On Wednesday 23 April 2008 17:36, Liam Girdwood wrote:
On Wed, 2008-04-23 at 16:54 +0200, Juergen Beisert wrote:
Hi,
I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S. I found the imx21 already in the repository (may it will help for my job). Is anybody else working on i.MX27 support (to avoid to reinvention everything)?
It's not fully supported atm. However I've had interest from a few folks who are interested in completing support.
Currently working :-
o i.MX2x SSI is complete (same as i.MX3)
But why there are different files for different CPUs when their hardware "on chip" is the same?
Todo:
o i.MX2x DMA is not completed. There is a half ASoC ported OSS based implementation in git atm, although it's not complete due to my only remaining i.MX21 board dying. Should be only about 1 weeks effort to complete this.
I have an i.MX27 and i.MX31 board here. Question is, what kind of CPU/architecture support you are using for i.MX21? The one from arch/arm/imx? Or something from arch/arm/mxc3, arch/arm/plat-mxc?
So now we have a few (nearly working) implementations. What should be used? The implementations from soc/imx or from soc/fsl?
Juergen
On Thu, 2008-04-24 at 13:19 +0200, Juergen Beisert wrote:
On Wednesday 23 April 2008 17:36, Liam Girdwood wrote:
On Wed, 2008-04-23 at 16:54 +0200, Juergen Beisert wrote:
Hi,
I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S. I found the imx21 already in the repository (may it will help for my job). Is anybody else working on i.MX27 support (to avoid to reinvention everything)?
It's not fully supported atm. However I've had interest from a few folks who are interested in completing support.
Currently working :-
o i.MX2x SSI is complete (same as i.MX3)
But why there are different files for different CPUs when their hardware "on chip" is the same?
Not sure what you mean. The only different files we have here is for the DMA :-
http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-asoc.git;a...
Todo:
o i.MX2x DMA is not completed. There is a half ASoC ported OSS based implementation in git atm, although it's not complete due to my only remaining i.MX21 board dying. Should be only about 1 weeks effort to complete this.
I have an i.MX27 and i.MX31 board here. Question is, what kind of CPU/architecture support you are using for i.MX21? The one from arch/arm/imx? Or something from arch/arm/mxc3, arch/arm/plat-mxc?
I was using an old 2.4 oss kernel (iirc from mv) for the i.MX21 work until the board died. All the new i.MX work is based on the FSL kernel i.e. arch/arm/mxc, arch/arm/plat-mxc
So now we have a few (nearly working) implementations. What should be used? The implementations from soc/imx or from soc/fsl?
imx for ARM, fsl for PPC.
Liam
Liam Girdwood wrote:
So now we have a few (nearly working) implementations. What should be used? The implementations from soc/imx or from soc/fsl?
imx for ARM, fsl for PPC.
Whatever driver is in fsl/ should be for PPC and ARM. The drivers in there should be updated to support i.MX. Who's going to make that change? Well, I can help, but I don't know enough about i.MX to do it all.
On Wednesday 23 April 2008 17:36, Liam Girdwood wrote:
On Wed, 2008-04-23 at 16:54 +0200, Juergen Beisert wrote:
Hi,
I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S. I found the imx21 already in the repository (may it will help for my job). Is anybody else working on i.MX27 support (to avoid to reinvention everything)?
It's not fully supported atm. However I've had interest from a few folks who are interested in completing support.
Currently working :- [...]
Working in what tree? In the git repository I did not found a "struct dma_channel_params" for imx. I'm confused.
Juergen
On Thu, 2008-04-24 at 16:11 +0200, Juergen Beisert wrote:
On Wednesday 23 April 2008 17:36, Liam Girdwood wrote:
On Wed, 2008-04-23 at 16:54 +0200, Juergen Beisert wrote:
Hi,
I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S. I found the imx21 already in the repository (may it will help for my job). Is anybody else working on i.MX27 support (to avoid to reinvention everything)?
It's not fully supported atm. However I've had interest from a few folks who are interested in completing support.
Currently working :- [...]
Working in what tree? In the git repository I did not found a "struct dma_channel_params" for imx. I'm confused.
http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-asoc.git;a...
(dev branch)
It's currently based on the 2.6.22 Freescale kernel (i.e. arch/arm/mxc) from their i.MX31ADS board's BSP.
Fwiw, I will be updating stuff as more i.MX code goes upstream, it's just a matter of time.
Liam
On Thursday 24 April 2008 16:30, Liam Girdwood wrote:
On Thu, 2008-04-24 at 16:11 +0200, Juergen Beisert wrote:
On Wednesday 23 April 2008 17:36, Liam Girdwood wrote:
On Wed, 2008-04-23 at 16:54 +0200, Juergen Beisert wrote:
Hi,
I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S. I found the imx21 already in the repository (may it will help for my job). Is anybody else working on i.MX27 support (to avoid to reinvention everything)?
It's not fully supported atm. However I've had interest from a few folks who are interested in completing support.
Currently working :- [...]
Working in what tree? In the git repository I did not found a "struct dma_channel_params" for imx. I'm confused.
http://opensource.wolfsonmicro.com/cgi-bin/gitweb.cgi?p=linux-2.6-asoc.git; a=summary
(dev branch)
It's currently based on the 2.6.22 Freescale kernel (i.e. arch/arm/mxc) from their i.MX31ADS board's BSP.
Fwiw, I will be updating stuff as more i.MX code goes upstream, it's just a matter of time.
Hmm, I did a deeper look into this code. Why - for example - does the file mx31ads-wm8753.c does the job of the BSP file? Why it registers devices? For my board I want to register platform_devices only in arc/arm/mach-mx2/pcm038.c. Nowhere else. If there is some glue required to bring components together, IMHO also arc/arm/mach-mx2/pcm038.c is the correct place to do so. Why you did it in sound/ ? If you do it in sound/ , you always need two locations to maintain. On in the arch/, one in sound/ .
Juergen
On Mon, May 05, 2008 at 12:56:37PM +0200, Juergen Beisert wrote:
Hmm, I did a deeper look into this code. Why - for example - does the file mx31ads-wm8753.c does the job of the BSP file? Why it registers devices? For my board I want to register platform_devices only in arc/arm/mach-mx2/pcm038.c. Nowhere else. If there is some glue required to bring components together, IMHO also arc/arm/mach-mx2/pcm038.c is the correct place to do so. Why you did it in sound/ ? If you do it in sound/ , you always need two locations to maintain. On in the arch/, one in sound/ .
The model which the existing ASoC platform code is using is that the sound subsystem of the device is frequently involved enough to justify thinking of it as a discrete "sound card", even if physically it is part of the same board. This is partly inherited from ASoC v1 where the way things are registered is less than ideal (it doesn't use the device model) and partly due to the fact that some machine definitions can get fairly large, especially with more complex board designs.
That said, you don't need to do things this way, especially with ASoC v2 where even if you do separate out the machine driver you can still register everything in your architecture code including a platform device for the machine driver.
On Monday 05 May 2008 14:42, Mark Brown wrote:
On Mon, May 05, 2008 at 12:56:37PM +0200, Juergen Beisert wrote:
Hmm, I did a deeper look into this code. Why - for example - does the file mx31ads-wm8753.c does the job of the BSP file? Why it registers devices? For my board I want to register platform_devices only in arc/arm/mach-mx2/pcm038.c. Nowhere else. If there is some glue required to bring components together, IMHO also arc/arm/mach-mx2/pcm038.c is the correct place to do so. Why you did it in sound/ ? If you do it in sound/ , you always need two locations to maintain. On in the arch/, one in sound/ .
The model which the existing ASoC platform code is using is that the sound subsystem of the device is frequently involved enough to justify thinking of it as a discrete "sound card", even if physically it is part of the same board. This is partly inherited from ASoC v1 where the way things are registered is less than ideal (it doesn't use the device model) and partly due to the fact that some machine definitions can get fairly large, especially with more complex board designs.
That said, you don't need to do things this way, especially with ASoC v2 where even if you do separate out the machine driver you can still register everything in your architecture code including a platform device for the machine driver.
Hmm, how far away is ASoC v2 from mainline? When I start to develop the driver right now, what version I should use?
Juergen
On Mon, May 05, 2008 at 02:55:04PM +0200, Juergen Beisert wrote:
Hmm, how far away is ASoC v2 from mainline? When I start to develop the driver right now, what version I should use?
Depends on how quickly you want to get it into the mainline. Developing for v1 would be the most conservative choice and let you get stuff in as soon as possible without being held up by v2 but it would mean that you'd be working with the ASoC v1 interfaces and that someone will have to convert to v2 at some point.
The idea is that ASoC v2 itself should be starting to make its way into mainline during 2.6.27 but there's no guarantees that it'll make it then.
On Monday 05 May 2008 14:42, Mark Brown wrote:
On Mon, May 05, 2008 at 12:56:37PM +0200, Juergen Beisert wrote:
Hmm, I did a deeper look into this code. Why - for example - does the file mx31ads-wm8753.c does the job of the BSP file? Why it registers devices? For my board I want to register platform_devices only in arc/arm/mach-mx2/pcm038.c. Nowhere else. If there is some glue required to bring components together, IMHO also arc/arm/mach-mx2/pcm038.c is the correct place to do so. Why you did it in sound/ ? If you do it in sound/ , you always need two locations to maintain. On in the arch/, one in sound/ .
That said, you don't need to do things this way, especially with ASoC v2 where even if you do separate out the machine driver you can still register everything in your architecture code including a platform device for the machine driver.
It seems the documentation in the "asoc-v2-dev" (Documentation/sound/alsa/soc/) is still v1, isn't it?
I'm confused how to link the pcm-layer and the transmission layer together. pxa2xx-i2s.c registers a codec-dai (line 346), while the imx-ssi.c registers (line 864) a platform-dai (internally called a cpu_dai. BTW: why a different name?). I _believe_ the CPU DAI tries to connect the CPU-pcm to the transmission interface like ssi or i2s on the same chip. But both implementations are using the same layering (pcm-dma and ssi/i2s), but registering different DAIs.
Now I have an ssi driver for my CPU (to be more precise: Two instances of it, when I registering two ssi devices in my BSP file). But how to tell the CPU pcm-layer which one it should use (and for what purpose, play, capture)? And only the ssi driver itself knows how to interact with the DMA controller. But this information is needed in the CPU pcm-layer as it setup the DMA.
Does a list exists, where I can store driver's private data in each layer (mapped iomem addresses for example)? And how to access it, when I only get a "struct snd_pcm_substream" as a parameter?
Regards Juergen
On Thu, May 08, 2008 at 09:54:28AM +0200, Juergen Beisert wrote:
It seems the documentation in the "asoc-v2-dev" (Documentation/sound/alsa/soc/) is still v1, isn't it?
Yes.
I'm confused how to link the pcm-layer and the transmission layer together. pxa2xx-i2s.c registers a codec-dai (line 346), while the imx-ssi.c registers (line 864) a platform-dai (internally called a cpu_dai. BTW: why a different name?). I _believe_ the CPU DAI tries to connect the CPU-pcm to the transmission interface like ssi or i2s on the same chip. But both implementations are using the same layering (pcm-dma and ssi/i2s), but registering different DAIs.
The i.MX code is correct here.
The PXA I2S code isn't a good example to use - it doesn't compile at the minute due to changes in the underlying PXA platform code - and has only been translated mechanically for ASoC v2. If you're looking for examples then the most heavily tested in-tree configurations for ASoC v2 are:
- i.MX31 I2S with WM8350 - PXA3xx AC97 with WM9713
Now I have an ssi driver for my CPU (to be more precise: Two instances of it, when I registering two ssi devices in my BSP file). But how to tell the CPU pcm-layer which one it should use (and for what purpose, play, capture)? And only the ssi driver itself knows how to interact with the DMA controller. But this information is needed in the CPU pcm-layer as it setup the DMA.
The CPU DAI has a dma_data member intended for this purpose - it can set up information the DMA driver will need in there for the DMA driver to pick up when it needs it. The PXA code sets this up in hw_params since the DMA configuration depends on if the stream is mono or stereo but there's no need to set it up that late if you don't have a similar requirement.
Does a list exists, where I can store driver's private data in each layer (mapped iomem addresses for example)? And how to access it, when I only get a "struct snd_pcm_substream" as a parameter?
Yes. ASoC sets the private_data of snd_pcm_substream to point to the struct snd_soc_pcm_runtime for the substream. That in turn contains pointers to the platform, codec and CPU DAIs. Each of those has a private_data member which you can use.
Hi all, I see the background of ASOC states that it supports some mechanism for events from plugging/unplugging headphone. But I don't see this support in any of the drivers/alsa-lib or is this feature is yet to come in ASOC core.
Rgrds srinivas.kandagatla
On Thu, May 08, 2008 at 03:57:04PM +0530, Srinivas.Kandagatla wrote:
I see the background of ASOC states that it supports some mechanism for events from plugging/unplugging headphone. But I don't see this support in any of the drivers/alsa-lib or is this feature is yet to come in ASOC core.
There is currently no core support for this. The machine driver needs to listen for headphone insert events using whatever mechanism the board supports and call snd_soc_dapm_set_endpoint() to enable and disable the relevant jacks when the headphones are connected and disconnected.
On Thu, 2008-05-08 at 09:54 +0200, Juergen Beisert wrote:
I'm confused how to link the pcm-layer and the transmission layer together. pxa2xx-i2s.c registers a codec-dai (line 346), while the imx-ssi.c registers (line 864) a platform-dai (internally called a cpu_dai. BTW: why a different name?). I _believe_ the CPU DAI tries to connect the CPU-pcm to the transmission interface like ssi or i2s on the same chip. But both implementations are using the same layering (pcm-dma and ssi/i2s), but registering different DAIs.
Now I have an ssi driver for my CPU (to be more precise: Two instances of it, when I registering two ssi devices in my BSP file). But how to tell the CPU pcm-layer which one it should use (and for what purpose, play, capture)? And only the ssi driver itself knows how to interact with the DMA controller. But this information is needed in the CPU pcm-layer as it setup the DMA.
Does a list exists, where I can store driver's private data in each layer (mapped iomem addresses for example)? And how to access it, when I only get a "struct snd_pcm_substream" as a parameter?
You shouldn't need to write an I2S driver for the i.MX2x SSI port as the i.MX3x SSI is very similar (maybe identical). Please try imx-ssi.c first, although it may need some changes if the register defs are different and will need changes for DMA config.
Fwiw, I've attached an older 2.4 OSS driver for the i.MX21. This may help with the DMA.
Liam
Juergen Beisert wrote:
Hi,
I'm going to adapt Freescale's i.MX27 CPU to the SoC sound support via I2S.
Are you talking about the SSI device? There already is an FSL SSI driver in sound/soc/fsl, but it's for PowerPC, not i.MX. I'd be happy to work with you in making it cross-platform.
participants (5)
-
Juergen Beisert -
Liam Girdwood -
Mark Brown -
Srinivas.Kandagatla -
Timur Tabi