My solution works with the recommended pullups.
hmm, ok, but... that's nothing new.
My solution is according to the bus protocol recommendations and works reliable even with long cables. I was lucky and it even works without pullups (but I would not count on that!).
wait, you're implying that the 4-wire-version does not meet the I2C specs? what is wrong about the pullup-resistors and the transistors to pull down the line?
concerning wire length: we have not made any tests, but i doubt there's much difference.
(by the way - the 4-wire-version is of course not desirable, but it's fancy: you don't have to remove the LEDs and get a nice i2c activity light. )
As explained above: if you actively drive an I2C line, you will only be able to read back the value you are driving onto that line.
i was talking about the outputs of the broadcom-chip. there are registers for... data, input/output-functionality, "control" and "enabled"... right? i don't remember what "enabled" was supposed to be, but looking at your driver code, i guess "enable" means the line is driven actively, is that right?
so, you put a line to "output", "disabled" and "0", the pullup raises the level to "1", and (if no slave device pulls the line down) that can be read from the registers without setting the line to input?
This is perfectly fine with the I2C bus protocol. The protocol implementation knows this and will only read from a line when it is not actively driving it.
so you have to know when to drive the line to 1 and when to only "let it float" to 1, right?
(because IIRC there are situations, when the slave MUST be able to pull down a line even though the master "wants" it to be high.)
i am really surprised at this this, because i remember writing myself a bit table with all possible register states and tried to pull a line down... and the line had to be set to input... hmm... then there was this "control" register... - i must have forgotten to remove some interferring parts. or maybe the old WRTs are just different from your router.
The idea behind this is called "wired and/or" and this is why there should be pullups.
hmm, do you have a link explaining this "wired and/or" thing? i would like to read about that but couldn't find anything with g**gle.
I got some inspiration from nekmech as well so that is why there are credits...
you wrote "nekmech aka datenritter", but we're two different persons.
looking at your driver... maybe i oversaw something, but it looks like a bit oldfashioned to me:
1. what are those static addresses doing there:
static volatile uint32 *gpioaddr_input = (uint32 *)0xb8000060; (...) ?
we removed the static addresses for a reason. the driver is supposed to make use of the sb_gpio interface.
2. you should also do some (software-)cleanup so the router can safely be rebooted. what if the user overrides the GPIO-lines and uses the reset-line as SDA or SCL? you have to make sure, reset is high on reboot, otherwise you will wipe the nvram. (also - what about older routers with an external ADMTEK switch..?)
hmm, i think it is better to change the driver posted in http://forum.openwrt.org/viewtopic.php?id=7949 back to two-wire logic, instead of re-implementing the old mistakes.