Hello Wolfram, On Wed, Jun 19, 2013 at 05:20:59PM +0200, Wolfram Sang wrote: > [...] > > > > > - It should not be encoded in the devicetree, since the flaw is implicit > > > to the device, so only the driver needs to know about it. I wonder > > > about something like this in the i2c slave driver: > > > > > > ret = i2c_request_sda_hold_time(client); > > > > > > The core then can collect the requests and forward them to the host > > > driver. This driver then can set up the hardware or return -EOPNOTSUPP > > > and we can even warn the user that there might be problems ahead. > > > > This might be a solution but given that many I2C drivers are written as > > an afterthought by device manufacturers and are released under more or > > less open terms of licensing into the wild I doubt this would work very > > well in practise. > > Hrmgl, the design looks much better to me, though. Once a driver is > identified to need this, the core is able to report this requirement to > a user who might even be unaware of the issue. The dt property has a bit > of "try this if things don't work, you may be lucky" taste to it. Need > to think about it. If PCB design also has an influence, then my idea > won't work, though. I agree with that in theory. We would need to define more constraints in this case, however: Both min and max setup and hold times would be required for data and start/stop conditions. We have seen cases in which the hold time we configured was too big for some devices on the bus which in turn seemed to get confused between data and start/stop conditions. I don't remember the exact values causing this issue but it was definitely less than the max of 650ns I have grepped out yesterday. Addressing this issue properly would mean implementing some simple form of STA. Not sure if an operating system kernel is the right place for this, though (and pretty sure that individual device drivers aren't). These questions are probably better addressed at the PCB design stage. > [...] > > > > > > In the case of the Designware block, the parameter both changes SDA and > > > > START hold times, however, and you'll find lots of data sheets for > > > > hardware with START hold time requirements on the net, e.g. > > > > http://ww1.microchip.com/downloads/en/DeviceDoc/21805B.pdf > > > > > > What I couldn't find is a reference manual for a designware IP that > > > supports sda hold time? I found some spear SoC which do not have that > > > register, so that should surely be reflected in the patchset, too. > > > > If you have access to DesignWare documentation, check out the > > "DesignWare DW_apb_i2c Databook" Version 1.17a from March 2012. > > I don't have, and I do have a hard time finding information about it > otherwise :( > > > Unluckily, I clearly don't have the right to share this document with > > you. Do you know the version of the blocks in the spear SoC which do not > > support this register? > > ST Spear300 and 600 have 0x3130352a in the version reg according to the > refman. Hrmmm... Going through the release notes it looks like this feature was added with module version 1.11a, released in 2010 (the initial version of the IP was released in 2003). > > > > The empirical solution in the function i2c_dw_scl_hcnt does not seem to > > > > work in all cases: Our lab guys confirmed that we have several PCB > > > > designs which do not work without adjusting the sda-hold-time parameter > > > > to an appropriate value. The value seems to be different for different > > > > PCBs. > > > > > > I'd hope that 300ns is a safe value for all PCBs? > > > > Not according to our PCB guys. The highest value I have found in a quick > > check of our device trees is 650ns with others being just slightly above > > 300ns. > > Thanks for sharing your results \o/ This helps me a lot. Can you find > out/guess if this value is solely dependend on a slave or is it also > dependend on PCB layout? In the simplest form of STA, timings are generally considered a function of three factors: . Drive strength . Bus load (Fan out) . Internal timings of all devices on the bus (setup/hold times etc.) This applies to ASIC internal timing. My PCB experience is quite limited and I'm not sure if this can be applied as such. That said, the I2C specification does define all three of these factors and I deduce they all have their importance. We know that the specified internal device timings are sometimes buggy, I don't know about the other two. Greetings, Christian -- Christian Ruppert , <christian.ruppert@xxxxxxxxxx> /| Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri _// | bilis Systems CH-1228 Plan-les-Ouates
Attachment:
pgp2lDKnJd0gz.pgp
Description: PGP signature
