rivafb / DDC/CI problem

[Nicolas Boichat <nicolas@boichat.ch>]

Hello,

I have a problem with this patch :
rivafb-directcolor-mode-and-miscellaneous-fixes.patch

It has been included in 2.6.8.1-mm1, and in 2.6.9-rc1.

The following part of the patch breaks DDC/CI implementation (monitor
control by software, see http://sourceforge.net/projects/ddccontrol/),
as bits are sent too fast to the monitor on the I2C bus:

diff -puN
drivers/video/riva/rivafb-i2c.c~rivafb-directcolor-mode-and-miscellaneous-fixes drivers/video/riva/rivafb-i2c.c
--- 25/drivers/video/riva/rivafb-i2c.c~rivafb-directcolor-mode-and-miscellaneous-fixes	2004-08-21 13:47:37.761874856 -0700
+++ 25-akpm/drivers/video/riva/rivafb-i2c.c	2004-08-21 13:47:37.774872880 -0700
@@ -105,8 +105,9 @@ static int riva_setup_i2c_bus(struct riv
 	chan->algo.setscl		= riva_gpio_setscl;
 	chan->algo.getsda		= riva_gpio_getsda;
 	chan->algo.getscl		= riva_gpio_getscl;
-	chan->algo.udelay		= 40;
-	chan->algo.timeout		= 20;
+	chan->algo.udelay		= 5;
+	chan->algo.mdelay               = 5;
+	chan->algo.timeout		= 10;
 	chan->algo.data 		= chan;
 
 	i2c_set_adapdata(&chan->adapter, chan);

Antonino, could you explain why you changed these values, as both works for EDID reading?
(atyfb use 40 as udelay, and 20 as timeout, the original values)

Is it possible to remove this part of the patch from the current kernel version?

Best regards,

Nicolas Boichat



-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m