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/b...

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.