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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
