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 [email protected] http://lists.lm-sensors.org/mailman/listinfo/i2c
