Nouveau - Jan 2012 - Bisect: i2c regression in 63daa9589cb88617d9cc8a0b0282564682a975b7

Hi.

Updating nouveau module to a newer git revision, I noticed I lost hwmon.

I ran a bisect, which identified 63daa9589cb88617d9cc8a0b0282564682a975b7 as 
being the first bad commit.

Adding printk traces, I saw that probing i2c bus 3 for sensors always failed 
with -EIO (no ack from slave). After reading the code, remembering how i2c 
works and reading sample code on wikipedia, I couldn't identify any 
algorythmic problem.

So I gave a try at changing delays. I doubled T_RISEFALL and T_HOLD, and the 
adt7473 chip could be detected & used again. I haven't tested other 
combination, nor tried to link those delays with any datasheet.

My card is a GTX 280.

Regards,
-- 
Vincent Pelletier

On Sun, 2012-01-01 at 22:38 +0100, Vincent Pelletier
wrote:
> Hi.
Hey,
> 
> Updating nouveau module to a newer git revision, I noticed I lost hwmon.
> 
> I ran a bisect, which identified 63daa9589cb88617d9cc8a0b0282564682a975b7
as
> being the first bad commit.
> 
> Adding printk traces, I saw that probing i2c bus 3 for sensors always
failed
> with -EIO (no ack from slave). After reading the code, remembering how i2c 
> works and reading sample code on wikipedia, I couldn't identify any 
> algorythmic problem.
> 
> So I gave a try at changing delays. I doubled T_RISEFALL and T_HOLD, and
the
> adt7473 chip could be detected & used again. I haven't tested other
> combination, nor tried to link those delays with any datasheet.
Apologies for the breakage, and thanks for looking into the cause!
Could you identify whether both timeouts needed doubling, or just one of
them?

Thanks,
Ben.
> 
> My card is a GTX 280.
> 
> Regards,