On Thu, 8 Sep 2011 13:52:06 -0400 "jonsmirl@gmail.com" jonsmirl@gmail.com wrote:
On Thu, Sep 8, 2011 at 10:32 AM, David Jander david.jander@protonic.nl wrote:
Dear Jon,
On Thu, 8 Sep 2011 06:55:56 -0400 "jonsmirl@gmail.com" jonsmirl@gmail.com wrote:
On Thu, Sep 8, 2011 at 6:45 AM, David Jander david.jander@protonic.nl wrote:
Dear Jon,
Thanks for replying so quickly.
On Thu, 8 Sep 2011 06:28:02 -0400 "jonsmirl@gmail.com" jonsmirl@gmail.com wrote:
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...
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/b...
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 haven't booted a mpc5200 in over a year so I don't know. Grant probably has better info. He'll answer this thread sooner or later.
Ok. Thanks.
I have been investigating the history os soc-core.c. Specially how the probe function evolved, and one thing I can tell from it, is that the probe order always has been:
1. machine 2. cpu_dai 3. codec 4. platform
Only in recent versions, there seems to be a possibility to change the order by using the "probe_order" field in "struct snd_soc_dai_driver". No idea how the specify it yet...
Nevertheless, the mpc5200 audio driver seems to rely on the platform part being probed _before_ the cpu_dai part. Does it work by shear luck or am I missing something?
Best regards,