Re: radeonfb blanks my monitor

[Jean Delvare]

Hi Frédéric, hi Benjamin,

> Mar  2 15:16:45 darkstar kernel: radeonfb: Reference=27.00 MHz 
> (RefDiv=12) Memory=325.00 Mhz, System=200.00 MHz
> Mar  2 15:16:45 darkstar kernel: radeonfb: PLL min 20000 max 40000
> Mar  2 15:16:45 darkstar kernel: i2c-algo-bit.o: monid seems to be busy.
> Mar  2 15:16:45 darkstar kernel: radeonfb 0000:01:00.0: Failed to 
> register I2C bus monid.
> Mar  2 15:16:45 darkstar kernel: i2c-algo-bit.o: crt2 seems to be busy.
> Mar  2 15:16:46 darkstar kernel: radeonfb 0000:01:00.0: Failed to 
> register I2C bus crt2.
> Mar  2 15:16:46 darkstar kernel: Console: switching to colour frame 
> buffer device 90x25
> Mar  2 15:16:46 darkstar kernel: radeonfb (0000:01:00.0): ATI Radeon AP
>
> Do the "seems to be busy." and/or "Failed to register I2C bus" indicate 
> a problem ?

The i2c-algo-bit driver has an optional bus check function. It can be 
used to detect stalled, disconnected or improperly configured busses. 
The check seems to be enabled in your case, which is kind of strange 
since it isn't by default.

Frédéric, can you check in /etc/modprobe.conf if you have a line like:
options i2c-algo-bit bit_test=1
If you do, please comment it out and see if it changes anything.

Benjamin, i2c-algo-bit with bit_test=1 may cause I2C bus creation to 
fail. As far as I can see, it is even the only way the bus creation 
function can return a negative value (which I consider a bug because 
there are other possible failure causes). I will test the effect of 
bit_test=1 on my two radeon systems this evening and see what happens. I 
will also work on a patch fixing the return value if it needs to be.

What I wanted to underline is the fact that it might be the first time 
bus registration ever fails, and although it looks like the radeonfb 
code handles the case, that code path had certainly not received much 
testing so far.

--
Jean Delvare

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/