Problem with unstable i2c communication with i810 bus driver

Problem with unstable i2c communication with i810 bus driver

[Wilken Haase]

Hi People,
i own a Samsung TV settopbox which is nice to use with linux, even while
its manufacturer samsung ships it with another operating system. The box
consists of a intel i815 chipset with integrated graphics, connected to
a focus enhancements fs454 scan converter which is controlled by i2c
commands and which must be setup correctly to produce a useable picture.

In the current state it kinda works. If i do a dump of the registers of
the fs454 I always get some bogus values back, even while most registers
are read out correctly. There is no visible pattern in what registers
give back wrong values, it differs from dump to dump. As another fact
writing to the chip is unstable, too. I often need to rewrite the values
2 or 3 times to get them in place.

I did test some different kernel versions up to the current 2.6.25 and i
saw a nice little increase in reliability but still its a piece off from
perfect.

Failures in writing are producing the following messages in syslog:

May 20 02:33:13 smt i2c-adapter i2c-1: sendbytes: NAK bailout.

Identified busses derived from the output of i2cdump are:

i2c-0    i2c           I810-DDC
i2c-1    i2c           I810-I2C
i2c-2    i2c           I810-GPIOC
i2c-3    smbus         SMBus I801 adapter at 1810
i2c-4    i2c           cx88[0]

The fs454 scan converter is located on I810-I2C.

I tried some different values for delays in i2c-i810.c like here:

/* delays */
#define CYCLE_DELAY             100
#define TIMEOUT                 100

But this didn't seem to offer advantages.

What else can i do ?
Any suggestions ?
If more information is needed feel free to drop me a mail, i will offer
any information as needed.

Thanks a lot !
Wilken Haase



_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Problem with unstable i2c communication with i810 bus driver

[Jean Delvare]

Hi Wilken,

On Tue, 20 May 2008 02:48:25 +0200, Wilken Haase wrote:
> Hi People,
> i own a Samsung TV settopbox which is nice to use with linux, even while
> its manufacturer samsung ships it with another operating system. The box
> consists of a intel i815 chipset with integrated graphics, connected to
> a focus enhancements fs454 scan converter which is controlled by i2c
> commands and which must be setup correctly to produce a useable picture.
> 
> In the current state it kinda works. If i do a dump of the registers of
> the fs454 I always get some bogus values back, even while most registers
> are read out correctly. There is no visible pattern in what registers
> give back wrong values, it differs from dump to dump. As another fact
> writing to the chip is unstable, too. I often need to rewrite the values
> 2 or 3 times to get them in place.
> 
> I did test some different kernel versions up to the current 2.6.25 and i
> saw a nice little increase in reliability but still its a piece off from
> perfect.
> 
> Failures in writing are producing the following messages in syslog:
> 
> May 20 02:33:13 smt i2c-adapter i2c-1: sendbytes: NAK bailout.
> 
> Identified busses derived from the output of i2cdump are:
> 
> i2c-0    i2c           I810-DDC
> i2c-1    i2c           I810-I2C
> i2c-2    i2c           I810-GPIOC
> i2c-3    smbus         SMBus I801 adapter at 1810
> i2c-4    i2c           cx88[0]
> 
> The fs454 scan converter is located on I810-I2C.
> 
> I tried some different values for delays in i2c-i810.c like here:
> 
> /* delays */
> #define CYCLE_DELAY             100
> #define TIMEOUT                 100
> 
> But this didn't seem to offer advantages.

I think that you are not modifying the right file. Apparently you
modified the delay values in drivers/i2c/busses/i2c-i810.c? While bus
I810-I2C is created by driver i810fb. So if you want to change the
timings, you should edit chan->algo.udelay and chan->algo.timeout in
drivers/video/i810/i810-i2c.c.

Note that the i2c-i810 driver is deprecated and will be removed in
kernel 2.6.27, this should help clear the confusion.

> What else can i do ?
> Any suggestions ?
> If more information is needed feel free to drop me a mail, i will offer
> any information as needed.

Are there other I2C devices connected to the i810? It would be
interesting to know whether the problem happens only with the FS454 or
also with other devices. If all I2C devices are affected then the
problem is probably hardware noise, maybe you have a defective part,
and there's not much we can do. If only the FS454 is affected, maybe
this specific device is not able of clock stretching and does support
only very slow I2C transactions (in which case increasing
chan->algo.udelay should help). But the current speed isn't very high
(50 kHz) so I'd be surprised.

Or maybe the FS454 simply needs a delay between reads and writes, I've
seen other I2C devices like this before. It is common for the device to
simply nack the transactions (as you see in your logs) while it is
busy. In this case the fix is to add delays in the fs454 driver (or
user-space tool accessing the device over i2c-dev) between transactions.

If you have access to the FS454 datasheet, it should tell whether the
device can stretch the clock and whether it needs a delay between the
transactions.

As an additional note, I seem to remember that i2c-algo-bit (which
I810-I2C uses) doesn't properly support bus arbitration. So, if you
have a multi-master bus, that could explain your problems, too. You'd
need to know the exact I2C bus topology of your system to rule out this
possibility.

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Problem with unstable i2c communication with i810 bus driver

[Wilken Haase]

Hi Jean, Hi List,

Jean Delvare wrote:
> Hi Wilken,
>
> On Tue, 20 May 2008 02:48:25 +0200, Wilken Haase wrote:
>   
>> Hi People,
>> i own a Samsung TV settopbox which is nice to use with linux, even while
>> its manufacturer samsung ships it with another operating system. The box
>> consists of a intel i815 chipset with integrated graphics, connected to
>> a focus enhancements fs454 scan converter which is controlled by i2c
>> commands and which must be setup correctly to produce a useable picture.
>>
>> In the current state it kinda works. If i do a dump of the registers of
>> the fs454 I always get some bogus values back, even while most registers
>> are read out correctly. There is no visible pattern in what registers
>> give back wrong values, it differs from dump to dump. As another fact
>> writing to the chip is unstable, too. I often need to rewrite the values
>> 2 or 3 times to get them in place.
>>
>> I did test some different kernel versions up to the current 2.6.25 and i
>> saw a nice little increase in reliability but still its a piece off from
>> perfect.
>>
>> Failures in writing are producing the following messages in syslog:
>>
>> May 20 02:33:13 smt i2c-adapter i2c-1: sendbytes: NAK bailout.
>>
>> Identified busses derived from the output of i2cdump are:
>>
>> i2c-0    i2c           I810-DDC
>> i2c-1    i2c           I810-I2C
>> i2c-2    i2c           I810-GPIOC
>> i2c-3    smbus         SMBus I801 adapter at 1810
>> i2c-4    i2c           cx88[0]
>>
>> The fs454 scan converter is located on I810-I2C.
>>
>> I tried some different values for delays in i2c-i810.c like here:
>>
>> /* delays */
>> #define CYCLE_DELAY             100
>> #define TIMEOUT                 100
>>
>> But this didn't seem to offer advantages.
>>     
>
> I think that you are not modifying the right file. Apparently you
> modified the delay values in drivers/i2c/busses/i2c-i810.c? While bus
> I810-I2C is created by driver i810fb. So if you want to change the
> timings, you should edit chan->algo.udelay and chan->algo.timeout in
> drivers/video/i810/i810-i2c.c.
>
> Note that the i2c-i810 driver is deprecated and will be removed in
> kernel 2.6.27, this should help clear the confusion.
>
>   
You seem to be right, i modified the wrong file. Thanks for that hint !

>> What else can i do ?
>> Any suggestions ?
>> If more information is needed feel free to drop me a mail, i will offer
>> any information as needed.
>>     
>
> Are there other I2C devices connected to the i810? It would be
> interesting to know whether the problem happens only with the FS454 or
> also with other devices. If all I2C devices are affected then the
> problem is probably hardware noise, maybe you have a defective part,
> and there's not much we can do. If only the FS454 is affected, maybe
> this specific device is not able of clock stretching and does support
> only very slow I2C transactions (in which case increasing
> chan->algo.udelay should help). But the current speed isn't very high
> (50 kHz) so I'd be surprised.
>
>   
Badly I don't know of anymore devices connected to this bus.
> Or maybe the FS454 simply needs a delay between reads and writes, I've
> seen other I2C devices like this before. It is common for the device to
> simply nack the transactions (as you see in your logs) while it is
> busy. In this case the fix is to add delays in the fs454 driver (or
> user-space tool accessing the device over i2c-dev) between transactions.
>
> If you have access to the FS454 datasheet, it should tell whether the
> device can stretch the clock and whether it needs a delay between the
> transactions.
>
>   
I do have the datasheets and read them multiple times just to be sure.
The data sheet talks of needed delays.
> As an additional note, I seem to remember that i2c-algo-bit (which
> I810-I2C uses) doesn't properly support bus arbitration. So, if you
> have a multi-master bus, that could explain your problems, too. You'd
> need to know the exact I2C bus topology of your system to rule out this
> possibility.
>
>   
I tried experimenting with udelay values at the right file and did slow
the bus
down, both values up to 150. But while dumping the chip slowed noticeably
down i still got some bogus values back. Think that's maybe not the
right idea.
On another sidenote: I own another settopbox which is partly similar and
also uses
a fs454 scan konverter, but controlled by an intel i830 chipset. The
fs454 is
accessible without any problems there with the stock kernel driver.
I really don't think the bus is multi mastered. Maybe this is a
termination problem.
If i can try anything else i would appreciate all your people thoughts.

Thanks Jean !
Thanks anyone else !

Greetings
Wilken Haase
 


_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Problem with unstable i2c communication with i810 bus driver

[Jean Delvare]

Hi Wilken,

On Tue, 20 May 2008 14:15:04 +0200, Wilken Haase wrote:
> Badly I don't know of anymore devices connected to this bus.

You could probe the bus using i2cdetect. Just testing if i2cdetect works
will be a good test already.

> I do have the datasheets and read them multiple times just to be sure.
> The data sheet talks of needed delays.

What does it say exactly?

> I tried experimenting with udelay values at the right file and did slow
> the bus down, both values up to 150.

Note: values above 50 are not compatible with SMBus.

> But while dumping the chip slowed noticeably
> down i still got some bogus values back. Think that's maybe not the
> right idea.
> On another sidenote: I own another settopbox which is partly similar and
> also uses a fs454 scan konverter, but controlled by an intel i830 chipset.
> The fs454 is accessible without any problems there with the stock kernel
> driver. I really don't think the bus is multi mastered. Maybe this is a
> termination problem.

If the other system works OK with basically the same type of hardware,
then I indeed suspect a hardware defect on the failing box. Maybe try
to find out someone else with exactly the same box which is failing for
you, and see if it also fails for him/her?

-- 
Jean Delvare

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Problem with unstable i2c communication with i810 bus driver

[Wilken Haase]

Jean Delvare wrote:
> Hi Wilken,
>
> On Tue, 20 May 2008 14:15:04 +0200, Wilken Haase wrote:
>   
>> Badly I don't know of anymore devices connected to this bus.
>>     
>
> You could probe the bus using i2cdetect. Just testing if i2cdetect works
> will be a good test already.
>
>   
I am able to probe the bus. The only discovered device on the bus is the
fs454 at 0x6a and the master at 0x00.
>> I do have the datasheets and read them multiple times just to be sure.
>> The data sheet talks of needed delays.
>>     
>
> What does it say exactly?
>   
"The FS453 registers are accessed through a serial input/output bus (SIO) which is I2C*-compatible and SMBus-compatible. These registers can be read or written at any time the part is receiving a reference clock at XTAL_IN and not being held in reset via the RESET_L pin."

see Hardware Datasheet, Page 8 at:
http://ingeninge.homelinux.net/ingmar/zenega/Datenbl%E4tter/FS453-4___FS455-6_HW_v31.pdf
,page 8

you can find the Software Reference there too if you need more
information, but id not find anything related there:
http://ingeninge.homelinux.net/ingmar/zenega/Datenbl%E4tter/FS453-4___FS455-6_SW_v31.pdf

>> I tried experimenting with udelay values at the right file and did slow
>> the bus down, both values up to 150.
>>     
>
> Note: values above 50 are not compatible with SMBus.
>
>   
Isn't this true i2c here ?
>> But while dumping the chip slowed noticeably
>> down i still got some bogus values back. Think that's maybe not the
>> right idea.
>> On another sidenote: I own another settopbox which is partly similar and
>> also uses a fs454 scan konverter, but controlled by an intel i830 chipset.
>> The fs454 is accessible without any problems there with the stock kernel
>> driver. I really don't think the bus is multi mastered. Maybe this is a
>> termination problem.
>>     
>
> If the other system works OK with basically the same type of hardware,
> then I indeed suspect a hardware defect on the failing box. Maybe try
> to find out someone else with exactly the same box which is failing for
> you, and see if it also fails for him/her?
>
>   

A hardware defect is not the problem here. There is a growing community
on these settopboxes in Germany
and I do talk to many of the owners actively. All the Samsung SMT-7020S
share the same problem when used with Linux. This is no single defect. 
On a sidenote: I never saw the Original WindowsCE Operating System or
the Intel IEGD Driver fail on setting up the fs454 once, but those both
are dead end solutions. The IEGD Drivers for older chipsets don't work
with newer software like Linux Kernel >2.6.15, the original Operating
System is really plagued by obscure Bugs and missing functionality...

Greetings
Wilken Haase


_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Problem with unstable i2c communication with i810 bus driver

[Jean Delvare]

On Wed, 21 May 2008 00:38:34 +0200, Wilken Haase wrote:
> I am able to probe the bus. The only discovered device on the bus is the
> fs454 at 0x6a and the master at 0x00.

0x00 is actually the broadcast address. I've never seed used so far,
but apparently the FS454 supports broadcast messages.

BTW, you must be using an old version of i2cdetect. Newer versions
don't probe address 0 by default.

What about the DDC channel? If there is a screen connected with an EDID
EEPROM you should see it on the DDC channel, and then you could test if
it has transaction errors as well.

> "The FS453 registers are accessed through a serial input/output bus (SIO)
> which is I2C*-compatible and SMBus-compatible. These registers can be
> read or written at any time the part is receiving a reference clock at
> XTAL_IN and not being held in reset via the RESET_L pin."

OK, this doesn't sound like any delay is required between accesses then.

> Isn't this true i2c here ?

As the FS454 is advertised as compatible with I2C, yes.

> A hardware defect is not the problem here. There is a growing community
> on these settopboxes in Germany
> and I do talk to many of the owners actively. All the Samsung SMT-7020S
> share the same problem when used with Linux. This is no single defect. 

OK.

> On a sidenote: I never saw the Original WindowsCE Operating System or
> the Intel IEGD Driver fail on setting up the fs454 once, but those both
> are dead end solutions. The IEGD Drivers for older chipsets don't work
> with newer software like Linux Kernel >2.6.15, the original Operating
> System is really plagued by obscure Bugs and missing functionality...

Maybe the i810fb driver is missing an initialization which your system
needs. You might want to discuss your problem with the i810fb driver
maintainer (Antonino Daplas).

You could try the old i2c-i810 driver temporarily and see if it does a
better job, but I wouldn't hold my breath. Both drivers use the same
helper driver (i2c-algo-bit) for the actual work. 

I don't have any more ideas, sorry.

-- 
Jean Delvare


_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: Problem with unstable i2c communication with i810 bus driver

[Wilken Haase]

Hi People,
a while ago i asked for help on this list concerning unreliable i2c 
communication in a pc based settopbox i own.

Short explanation of the problem:
Basically there is a scan converter on the mainboard which converts 
video signals from the intel i815 graphics chip to tv compatible analog 
signaling at the video outputs of the box. This converter is configured 
via i2c. I2c communication works sort of, but is unreliable.
While reading i always get some bogus values back, writing has often to 
be done twice to work.

The scan konverter is the only device on the bus.

As there is quite a big community with these boxes a defect in my box 
can be ruled out. There is noone without these problems. Another fact: 
Intel IEGD Drivers for Windows and Linux work without any failure, but 
these are a dead end because they only support very old xfree and kernel 
versions.

After this description some new stuff. I've found someone to do some i2c 
oscilloscope dumps while accessing the chips. There seem to be problems 
while ACK'ing. You can see the pictures here:

Dump of bios initializing the chip:
http://beeker.campuspoint.de/pool/smt/bios_i2c_start.jpg

Dump of writing a 32bit value to the chip via console i2cset:
http://beeker.campuspoint.de/pool/smt/i2cset_0x6a_0xc4_0x9842.jpg

More details, same command, first 16bits:
http://beeker.campuspoint.de/pool/smt/i2cset_0x6a_0xc4_0x9842_16bits.jpg

Even more details:
http://beeker.campuspoint.de/pool/smt/i2cset_0x6a_0xc4_0x9842_ACK_error.jpg

Any idea what might go wrong here is appreciated. This should definately 
be some issue in software.
If any more infos are needed just ask, i will supply them.

Greets
Wilken Haase


Jean Delvare schrieb:
> On Wed, 21 May 2008 00:38:34 +0200, Wilken Haase wrote:
>   
>> I am able to probe the bus. The only discovered device on the bus is the
>> fs454 at 0x6a and the master at 0x00.
>>     
>
> 0x00 is actually the broadcast address. I've never seed used so far,
> but apparently the FS454 supports broadcast messages.
>
> BTW, you must be using an old version of i2cdetect. Newer versions
> don't probe address 0 by default.
>
> What about the DDC channel? If there is a screen connected with an EDID
> EEPROM you should see it on the DDC channel, and then you could test if
> it has transaction errors as well.
>
>   
>> "The FS453 registers are accessed through a serial input/output bus (SIO)
>> which is I2C*-compatible and SMBus-compatible. These registers can be
>> read or written at any time the part is receiving a reference clock at
>> XTAL_IN and not being held in reset via the RESET_L pin."
>>     
>
> OK, this doesn't sound like any delay is required between accesses then.
>
>   
>> Isn't this true i2c here ?
>>     
>
> As the FS454 is advertised as compatible with I2C, yes.
>
>   
>> A hardware defect is not the problem here. There is a growing community
>> on these settopboxes in Germany
>> and I do talk to many of the owners actively. All the Samsung SMT-7020S
>> share the same problem when used with Linux. This is no single defect. 
>>     
>
> OK.
>
>   
>> On a sidenote: I never saw the Original WindowsCE Operating System or
>> the Intel IEGD Driver fail on setting up the fs454 once, but those both
>> are dead end solutions. The IEGD Drivers for older chipsets don't work
>> with newer software like Linux Kernel >2.6.15, the original Operating
>> System is really plagued by obscure Bugs and missing functionality...
>>     
>
> Maybe the i810fb driver is missing an initialization which your system
> needs. You might want to discuss your problem with the i810fb driver
> maintainer (Antonino Daplas).
>
> You could try the old i2c-i810 driver temporarily and see if it does a
> better job, but I wouldn't hold my breath. Both drivers use the same
> helper driver (i2c-algo-bit) for the actual work. 
>
> I don't have any more ideas, sorry.
>
>   


_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c