i2c-i810.c

i2c-i810.c

[Detlef Conradin]

Hello

The drivers for the I2C and DCC Busses don't work (at least on my
Computer).

With ver 2.7.0 nothing worked and no devices were detected by
i2cdetect. But i2c-algo-bit's bit_test succeded.

With ver 2.8.0 my Chrontel TV encoder was detected, but
communication did not work and i2c-algo-bit's bit_test failed.
(SDA stuck high). The driver got the first ACK (after sending the DAB),
but never got the second one after sending the RAB.

Using the attached patch everything works.

My Chipset (from lspci):
00:01.0 Class 0300: 8086:7121 (rev 02)

00:01.0 VGA compatible controller: Intel Corp. 82810 CGC [Chipset Graphics
Controller] (rev 02) (prog-if 00 [VGA])
        Subsystem: Intel Corp. 82810 CGC [Chipset Graphics Controller]
        Flags: bus master, 66Mhz, medium devsel, latency 0, IRQ 11
        Memory at d0000000 (32-bit, prefetchable) [sizedM]
        Memory at d6000000 (32-bit, non-prefetchable) [sizeQ2K]
        Capabilities: <available only to root>

Detlef Conradin
-------------- next part --------------
diff -ur lm_sensors-2.8.0/kernel/busses/i2c-i810.c lm_sensors-2.8.0p/kernel/busses/i2c-i810.c
--- lm_sensors-2.8.0/kernel/busses/i2c-i810.c	2003-07-03 03:30:13.000000000 +0200
+++ lm_sensors-2.8.0p/kernel/busses/i2c-i810.c	2003-07-18 16:05:04.000000000 +0200
@@ -95,18 +95,39 @@
 /* The i810 GPIO registers have individual masks for each bit
    so we never have to read before writing. Nice. */
 
+/* The masks defined at the beginning of the file are wrong.
+   They seem to be according to the documentation,
+   but at least for me they don't work. I think
+   the documentation is incorrect.
+
+   D. Conradin <skyline@despammed.com>, 18.7.03 */
+ 
 static void bit_i810i2c_setscl(void *data, int val)
 {
-	outlong((val ? SCL_VAL_OUT : 0) | SCL_DIR | SCL_DIR_MASK | SCL_VAL_MASK,
-	     I810_GPIOB);
-	readlong(I810_GPIOB);	/* flush posted write */
+//	outlong((val ? SCL_VAL_OUT : 0) | SCL_DIR | SCL_DIR_MASK | SCL_VAL_MASK,
+//	     I810_GPIOB);
+//	readlong(I810_GPIOB);	/* flush posted write */
+	if (val) {
+		outlong(0x5, I810_GPIOB);
+		outlong(0x4, I810_GPIOB);
+	} else {
+		outlong(0x7, I810_GPIOB);
+		outlong(0x6, I810_GPIOB);
+	}
 }
 
 static void bit_i810i2c_setsda(void *data, int val)
 {
- 	outlong((val ? SDA_VAL_OUT : 0) | SDA_DIR | SDA_DIR_MASK | SDA_VAL_MASK,
-	     I810_GPIOB);
-	readlong(I810_GPIOB);	/* flush posted write */
+// 	outlong((val ? SDA_VAL_OUT : 0) | SDA_DIR | SDA_DIR_MASK | SDA_VAL_MASK,
+//	     I810_GPIOB);
+//	readlong(I810_GPIOB);	/* flush posted write */
+	if (val) {
+		outlong(0x500, I810_GPIOB);
+		outlong(0x400, I810_GPIOB);
+	} else {
+		outlong(0x700, I810_GPIOB);
+		outlong(0x600, I810_GPIOB);
+	}
 }
 
 /* The GPIO pins are open drain, so the pins could always remain outputs.
@@ -121,42 +142,56 @@
 
 static int bit_i810i2c_getscl(void *data)
 {
-	outlong(SCL_DIR_MASK, I810_GPIOB);
+//	outlong(SCL_DIR_MASK, I810_GPIOB);
 	outlong(0, I810_GPIOB);
 	return (0 != (readlong(I810_GPIOB) & SCL_VAL_IN));
 }
 
 static int bit_i810i2c_getsda(void *data)
 {
-	outlong(SDA_DIR_MASK, I810_GPIOB);
+//	outlong(SDA_DIR_MASK, I810_GPIOB);
 	outlong(0, I810_GPIOB);
 	return (0 != (readlong(I810_GPIOB) & SDA_VAL_IN));
 }
 
 static void bit_i810ddc_setscl(void *data, int val)
 {
-	outlong((val ? SCL_VAL_OUT : 0) | SCL_DIR | SCL_DIR_MASK | SCL_VAL_MASK,
-	     I810_GPIOA);
-	readlong(I810_GPIOA);	/* flush posted write */
+//	outlong((val ? SCL_VAL_OUT : 0) | SCL_DIR | SCL_DIR_MASK | SCL_VAL_MASK,
+//	     I810_GPIOA);
+//	readlong(I810_GPIOA);	/* flush posted write */
+	if (val) {
+		outlong(0x5, I810_GPIOA);
+		outlong(0x4, I810_GPIOA);
+	} else {
+		outlong(0x7, I810_GPIOA);
+		outlong(0x6, I810_GPIOA);
+	}
 }
 
 static void bit_i810ddc_setsda(void *data, int val)
 {
- 	outlong((val ? SDA_VAL_OUT : 0) | SDA_DIR | SDA_DIR_MASK | SDA_VAL_MASK,
-	     I810_GPIOA);
-	readlong(I810_GPIOA);	/* flush posted write */
+// 	outlong((val ? SDA_VAL_OUT : 0) | SDA_DIR | SDA_DIR_MASK | SDA_VAL_MASK,
+//	     I810_GPIOA);
+//	readlong(I810_GPIOA);	/* flush posted write */
+	if (val) {
+		outlong(0x500, I810_GPIOA);
+		outlong(0x400, I810_GPIOA);
+	} else {
+		outlong(0x700, I810_GPIOA);
+		outlong(0x600, I810_GPIOA);
+	}
 }
 
 static int bit_i810ddc_getscl(void *data)
 {
-	outlong(SCL_DIR_MASK, I810_GPIOA);
+//	outlong(SCL_DIR_MASK, I810_GPIOA);
 	outlong(0, I810_GPIOA);
 	return (0 != (readlong(I810_GPIOA) & SCL_VAL_IN));
 }
 
 static int bit_i810ddc_getsda(void *data)
 {
-	outlong(SDA_DIR_MASK, I810_GPIOA);
+//	outlong(SDA_DIR_MASK, I810_GPIOA);
 	outlong(0, I810_GPIOA);
 	return (0 != (readlong(I810_GPIOA) & SDA_VAL_IN));
 }

i2c-i810.c

[Jean Delvare]

> The drivers for the I2C and DCC Busses don't work (at least on my
> Computer).
>
> With ver 2.7.0 nothing worked and no devices were detected by
> i2cdetect. But i2c-algo-bit's bit_test succeded.

How can you say it succeeded if you were not able to load any bus
driver?

> With ver 2.8.0 my Chrontel TV encoder was detected, but
> communication did not work and i2c-algo-bit's bit_test failed.
> (SDA stuck high). The driver got the first ACK (after sending the
> DAB), but never got the second one after sending the RAB.
> 
> Using the attached patch everything works.

Could you tell us how you did come to the values you are using? We can't
apply a patch unless we fully understand what it does. The set family is
the same in 2.7.0 and 2.8.0. Only the get family was changed. Please
take a look at the attached patch and tell us if reverting this part is
enough to get the driver to work again for you.

Also, could you tell us which chip driver is used for your tv encoder?
And is your monitor DDC capable or not?

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
-------------- next part --------------
--- i2c-i810.c	24 Nov 2002 05:45:28 -0000	1.10
+++ i2c-i810.c	3 Jul 2003 01:30:13 -0000	1.17
@@ -140,22 +109,26 @@
 	readlong(I810_GPIOB);	/* flush posted write */
 }
 
-/* The GPIO pins are open drain, so the pins always remain outputs.
+/* The GPIO pins are open drain, so the pins could always remain outputs.
+   However, some chip versions don't latch the inputs unless they
+   are set as inputs.
    We rely on the i2c-algo-bit routines to set the pins high before
    reading the input from other chips. Following guidance in the 815
    prog. ref. guide, we do a "dummy write" of 0 to the register before
    reading which forces the input value to be latched. We presume this
-   applies to the 810 as well. This is necessary to get
+   applies to the 810 as well; shouldn't hurt anyway. This is necessary to get
    i2c_algo_bit bit_test=1 to pass. */
 
 static int bit_i810i2c_getscl(void *data)
 {
+	outlong(SCL_DIR_MASK, I810_GPIOB);
 	outlong(0, I810_GPIOB);
 	return (0 != (readlong(I810_GPIOB) & SCL_VAL_IN));
 }
 
 static int bit_i810i2c_getsda(void *data)
 {
+	outlong(SDA_DIR_MASK, I810_GPIOB);
 	outlong(0, I810_GPIOB);
 	return (0 != (readlong(I810_GPIOB) & SDA_VAL_IN));
 }
@@ -176,12 +149,14 @@
 
 static int bit_i810ddc_getscl(void *data)
 {
+	outlong(SCL_DIR_MASK, I810_GPIOA);
 	outlong(0, I810_GPIOA);
 	return (0 != (readlong(I810_GPIOA) & SCL_VAL_IN));
 }
 
 static int bit_i810ddc_getsda(void *data)
 {
+	outlong(SDA_DIR_MASK, I810_GPIOA);
 	outlong(0, I810_GPIOA);
 	return (0 != (readlong(I810_GPIOA) & SDA_VAL_IN));
 }

i2c-i810.c

[Detlef Conradin]

On Fri, 18 Jul 2003, Jean Delvare wrote:

> > The drivers for the I2C and DCC Busses don't work (at least on my
> > Computer).
> >
> > With ver 2.7.0 nothing worked and no devices were detected by
> > i2cdetect. But i2c-algo-bit's bit_test succeded.
> 
> How can you say it succeeded if you were not able to load any bus
> driver?
Well, 'nothing' is not very clear, my mistake....
I didn't mean that I was unable to load it. I wanted to say that the
driver didn't work. 

> > With ver 2.8.0 my Chrontel TV encoder was detected, but
> > communication did not work and i2c-algo-bit's bit_test failed.
> > (SDA stuck high). The driver got the first ACK (after sending the
> > DAB), but never got the second one after sending the RAB.
> > 
> > Using the attached patch everything works.
> Could you tell us how you did come to the values you are using? We can't
> apply a patch unless we fully understand what it does. The set family is
Yes I know... :-)
I found these values by disassembling the programm mentioned here:
http://www.maersk-moller.net/projects/familynet/TV-Out.html
So I have no idea about the meaning of the individual bits.
The values as defined at the moment are not working on my computer, thats
way I guess they're wrong.

> the same in 2.7.0 and 2.8.0. Only the get family was changed. Please
> take a look at the attached patch and tell us if reverting this part is
> enough to get the driver to work again for you.
???
Then I will have 2.7.0 again... And this version doesn't work, as
stated in my first message.

> Also, could you tell us which chip driver is used for your tv encoder?
> And is your monitor DDC capable or not?
No my monitor is not DDC capable. But i810 has two busses. It tested this
modification only on the I2C bus. But I really hope the behaviour is the
same for the DDC Channel. There is no chip driver for the TV Encoder. But
there is a userspace programm: http://tumult.textalk.se/chp3258.html
BTW: The patch you can download there didn't work for me.

Maybe you could just put this patch in a contrib directory, for further
evalution... I don't know....
I just thought I sould send it to you, because it took me a lot of time
to get it working....

i2c-i810.c

[Detlef Conradin]

On Fri, 18 Jul 2003, Jean Delvare wrote:

I found another programm (Open Source!) that uses the same values as
I found: http://sourceforge.net/projects/nv-tv-out
So I guess they are correct. Maybe you could contact the author of
that programm for explanations.
I have attached you the interesting file.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tv_i810.c
Type: text/x-csrc
Size: 21497 bytes
Desc: 
Url : http://lists.lm-sensors.org/pipermail/lm-sensors/attachments/20030719/b833667e/tv_i810.bin

i2c-i810.c

[Jean Delvare]

> > the same in 2.7.0 and 2.8.0. Only the get family was changed. Please
> > take a look at the attached patch and tell us if reverting this part
> > is enough to get the driver to work again for you.
> ???
> Then I will have 2.7.0 again... And this version doesn't work, as
> stated in my first message.

No, no. There have been a *lot* of changes between 2.7.0 and 2.8.0. What
I want you to do is revert a very small portion of these changes on your
2.8.0 version, and see what happens. If it is enough to make it work
(which means it is functionally equivalent to the changes you proposed),
it would give us a point to start from.

> > Also, could you tell us which chip driver is used for your tv
> > encoder? And is your monitor DDC capable or not?
> No my monitor is not DDC capable.

i2c-algo-bit's bit_test failing is normal in this case, this is even the
wanted behavior. Or what would this parameter be useful for?

> There is no chip driver for the TV
> Encoder. But there is a userspace programm:
> http://tumult.textalk.se/chp3258.html
> BTW: The patch you can download there didn't work for me.

I don't remember this guy sending that patch to us. I *hate* it when
people use our modules, modify them and don't even take the time to tell
us about their changes. Don't they understand how free software works,
or what? :(

> Maybe you could just put this patch in a contrib directory, for
> further evalution... I don't know....

We don't really have such a directory, but we still can give the patch
to anyone contacting us with the same problem as you have.

> I just thought I sould send it to you, because it took me a lot of
> time to get it working....

Yeah of course, I understand. It's always great to solve that kind of
problem and you are very welcome to share your experience with us. All I
meant is that we can't apply patches just because one use says it works
for him/her. We need to know why it works, especially if the change does
not match the specs, as it seem to be the case here.

Anyway, I am not the one who will handle that, I don't know enough about
bus drivers to do so. Philip Edelbrock and Mark D. Studebaker will
probably be more helpful than me.

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

i2c-i810.c

[Detlef Conradin]

> > > the same in 2.7.0 and 2.8.0. Only the get family was changed. Please
> > > take a look at the attached patch and tell us if reverting this part
> > > is enough to get the driver to work again for you.
> > Then I will have 2.7.0 again... And this version doesn't work, as
> > stated in my first message.
> No, no. There have been a *lot* of changes between 2.7.0 and 2.8.0. What
> I want you to do is revert a very small portion of these changes on your
> 2.8.0 version, and see what happens. If it is enough to make it work
> (which means it is functionally equivalent to the changes you proposed),
> it would give us a point to start from.
Of course... But i'm sure the problem is in getsda, setsda, getscl or 
setscl. Since 2.7.0 didn't work at all, although the bit_test passed.
It makes IMHO no senso to check this patch....

> > > Also, could you tell us which chip driver is used for your tv
> > > encoder? And is your monitor DDC capable or not?
> > No my monitor is not DDC capable.
> i2c-algo-bit's bit_test failing is normal in this case, this is even the
> wanted behavior. Or what would this parameter be useful for?
1. i2c-algo-bit's bit_test failed for both busses.
2. I don't think that this is the normal case. The bit test just checks
   wether it is possible setting the clock and data line to high or
   low. This should also work without any connected device if the
   manufacturer didn't force the line to be high (or low) by some 
   electrical circuit. But then the bus would not be usable anymore.
3. i2c-algo-bit's bit_test succeds with my patch on both busses.

> We don't really have such a directory, but we still can give the patch
> to anyone contacting us with the same problem as you have.
Would be a possibility....

> Yeah of course, I understand. It's always great to solve that kind of
> problem and you are very welcome to share your experience with us. All I
> meant is that we can't apply patches just because one use says it works
> for him/her. We need to know why it works, especially if the change does
> not match the specs, as it seem to be the case here.
Okay ......

i2c-i810.c

[Mark D. Studebaker]

Thanks for the info.
I wrote the 810 driver.
I agree 100% w/ Jean that we can't apply the patch without getting info on
why it works. If somebody took our code, fixed a bug, and didn't feed
it back to us that's pretty rude.
I think I have an 810 board somewhere, if I get a chance I will see
if our code still works. But I'm not inclined to try and
figure out from the patch what it's supposed to "fix"
(and on what version of the 810 chip).
As far as having your patch available to others, it's in our mailing list archive.
mds

Detlef Conradin wrote:
>>>>the same in 2.7.0 and 2.8.0. Only the get family was changed. Please
>>>>take a look at the attached patch and tell us if reverting this part
>>>>is enough to get the driver to work again for you.
>>>
>>>Then I will have 2.7.0 again... And this version doesn't work, as
>>>stated in my first message.
>>
>>No, no. There have been a *lot* of changes between 2.7.0 and 2.8.0. What
>>I want you to do is revert a very small portion of these changes on your
>>2.8.0 version, and see what happens. If it is enough to make it work
>>(which means it is functionally equivalent to the changes you proposed),
>>it would give us a point to start from.
> 
> Of course... But i'm sure the problem is in getsda, setsda, getscl or 
> setscl. Since 2.7.0 didn't work at all, although the bit_test passed.
> It makes IMHO no senso to check this patch....
> 
> 
>>>>Also, could you tell us which chip driver is used for your tv
>>>>encoder? And is your monitor DDC capable or not?
>>>
>>>No my monitor is not DDC capable.
>>
>>i2c-algo-bit's bit_test failing is normal in this case, this is even the
>>wanted behavior. Or what would this parameter be useful for?
> 
> 1. i2c-algo-bit's bit_test failed for both busses.
> 2. I don't think that this is the normal case. The bit test just checks
>    wether it is possible setting the clock and data line to high or
>    low. This should also work without any connected device if the
>    manufacturer didn't force the line to be high (or low) by some 
>    electrical circuit. But then the bus would not be usable anymore.
> 3. i2c-algo-bit's bit_test succeds with my patch on both busses.
> 
> 
>>We don't really have such a directory, but we still can give the patch
>>to anyone contacting us with the same problem as you have.
> 
> Would be a possibility....
> 
> 
>>Yeah of course, I understand. It's always great to solve that kind of
>>problem and you are very welcome to share your experience with us. All I
>>meant is that we can't apply patches just because one use says it works
>>for him/her. We need to know why it works, especially if the change does
>>not match the specs, as it seem to be the case here.
> 
> Okay ......
> 
> 
> 

i2c-i810.c

[Detlef Conradin]

On Sat, 19 Jul 2003, Mark D. Studebaker  wrote:

> I wrote the 810 driver.
Thanks!
> I agree 100% w/ Jean that we can't apply the patch without getting info on
> why it works. 
I understand you position.

Have you seen this project: 
http://sourceforge.net/projects/nv-tv-out
They use the same values as I found. Maybe it would be 
a good idea to contact the respective authors.

> If somebody took our code, fixed a bug, and didn't feed
> it back to us that's pretty rude.
Well, this project looks rather experimential. And at least for me the
patch didn't work anyway....

> I think I have an 810 board somewhere, if I get a chance I will see
> if our code still works. But I'm not inclined to try and
Yes! Would be a good idea to do that.