Re: ASoC MPC5xxx PSC AC97 audio driver

* 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