[PATCH] AOA: Convert onyx and tas codecs to new-style i2c drivers

[Johannes Berg]

Hi,

> > Because the device-tree is broken -- there are two nodes for the same
> > device, and only one of them can be used. Then the fabric rejects the
> > first instantiation from the broken node. Here's how it looks normally:
> > 
> > ...
> > [   10.398296] snd-aoa-codec-onyx: found pcm3052
> > [   10.398472] PM: Adding info for i2c:2-0046
> > [   10.412189] snd-aoa-fabric-layout: platform-onyx-codec-ref doesn't match!
> > [   10.462593] snd-aoa: fabric didn't like codec onyx
> > [   10.468030] PM: Removing info for i2c:2-0046
> > [   10.473892] snd-aoa-codec-onyx: found pcm3052
> > [   10.479317] PM: Adding info for i2c:3-0046
> > [   10.485631] snd-aoa-fabric-layout: can use this codec
> > ...
> 
> OK, I understand better what is going on now. I do not understand the
> crash at the end though, but I suspect it isn't a bug in my code but
> simply a faulty error path which had never been taken before.

That would be weird -- the error path _has_ to be taken always in onyx.
Unless you're talking about something in the i2c core or whatever?

> Now, the fact that there are two nodes, one right and one wrong, is
> quite a problem. My code expected the device tree to be trustworthy.

No such luck.

> The new i2c binding model cleanly separates the instantiation of
> devices and their binding to a driver. The codec check which fails,
> will cause the i2c device to not bind to its driver, but it will still
> be present, while there is no underlying physical I2C device if I
> understand properly. In the new i2c model, you have to ensure that an
> i2c device exists _before_ you instantiate it.

Oh, no, there _is_ an underlying i2c device, the same one. The DT
accidentally has two almost identical nodes for the same chip, but we
can only use the one with the correct reference.

> Well, there is a dirty workaround, which I will apply for now, but...
> ideally the layout factory should be revisited so that the codec check
> happens earlier. Is this something you could help with?

That's not really possible unless the factory post-processes the entire
device-tree -- very ugly.

> That's something which isn't too clear to me: is there a physical
> device at 2-0046 and 3-0046? The onyx codec is accepted for the latter,
> however it seems that the test of a device presence at 2-0046 succeeds
> as well...

It's the _same_ physical device.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090415/3a054e83/attachment.pgp>