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

Jean Delvare khali at linux-fr.org
Wed Apr 15 23:52:36 EST 2009


On Wed, 15 Apr 2009 15:18:10 +0200, Johannes Berg wrote:
> On Wed, 2009-04-15 at 15:06 +0200, Jean Delvare wrote:
> > Yes, i2c core or even driver core. I'll see if I can reproduce it.
> 
> Alright.

Hmm, couldn't reproduce it. Maybe it is fixed in rc2. I don't have too
much time to spend on this, so if we don't hit it again I consider it
solved.

> > (...)
> > What I had in mind was not so complex. Simply, we could move the
> > i2c_new_device() calls into layout_found_codec(). That way we can
> > decide to instantiate the I2C device if and only if check_codec() is
> > successful. This is more efficient that creating the device, letting
> > the driver attach to it, with probing eventually failing, and then
> > removing the device if it wasn't the right one.
> > 
> > That is, the i2c client would be a mere helper on top of struct
> > aoa_codec, rather than the other way around.
> 
> Ah. That would probably work, but right now I have little motivation to
> work on it -- I hardly use the G5 desktop machine any more.

OK, no problem. I don't want to force anyone to spend time on this. But
if anyone ever does and need my help for the i2c part, just drop me a
line!

> > Wow. One I2C device which can be reached through 2 different I2C buses?
> > First time I hear about something like this. Very odd. I can't see the
> > point of doing this.
> 
> Hmm. How do you know it's on different buses?

2-0046 fails and 3-0046 succeeds. The second number is the hexadecimal
I2C address, the first number is the I2C bus number. So, unless
i2c-powermac was told to register the same I2C bus twice (which would
be dangerous), the device can be accessed through 2 different buses.

> I don't really know
> anything -- all I know is that the DT is buggered and lists the codec
> twice. Since we can talk to both, then I'm sure it's just one chip, they
> wouldn't put the chip in twice when you can use only one of them :)

There's probably little point in trying to guess anything further, the
only thing that would help are the detailed schematics of that part of
the board.

-- 
Jean Delvare



More information about the Linuxppc-dev mailing list