Problem with unstable i2c communication with i810 bus driver

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.

Hi Wilken,

Quoted 32 lines · 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.

Quoted 8 lines

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.

Quoted 5 lines

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.

Badly I don't know of anymore devices connected to this bus.

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

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.

Hi Wilken,

Quoted 2 lines · Wilken Haase

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.

Quoted 3 lines

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?

Quoted 3 lines

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.

Quoted 9 lines

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?

I am able to probe the bus. The only discovered device on the bus is the fs454 at 0x6a and the master at 0x00.

"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."

Isn't this true i2c here ?

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...

Quoted 3 lines · Wilken Haase

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.

Quoted 5 lines

"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.

Quoted 2 lines

Isn't this true i2c here ?

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

Quoted 5 lines

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.

Quoted 6 lines

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.