[alsa-devel] ASoC MPC5xxx PSC AC97 audio driver
david.jander at protonic.nl
Fri Sep 9 08:28:44 CEST 2011
On Thu, 8 Sep 2011 20:44:41 +0200
torbenh <torbenh at 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 at gmail.com" <jonsmirl at gmail.com> wrote:
> > > On Thu, Sep 8, 2011 at 6:45 AM, David Jander <david.jander at protonic.nl>
> > > wrote:
> > > >
> > > > Dear Jon,
> > > >
> > > > Thanks for replying so quickly.
> > > >
> > > > On Thu, 8 Sep 2011 06:28:02 -0400
> > > > "jonsmirl at gmail.com" <jonsmirl at gmail.com> wrote:
> > > >> On Thu, Sep 8, 2011 at 6:16 AM, David Jander
> > > >> <david.jander at 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.
More information about the Alsa-devel