Am 28.11.2011 08:48, schrieb David Jander: > > Hi Micheal, > > On Fri, 25 Nov 2011 11:27:44 +0100 > Michael Lawnick <ml.lawnick@xxxxxx> wrote: >> Am 24.11.2011 12:02, schrieb David Jander: >>> For many peripherals in order to support this, a special function would be >>> needed, that reconfigures the SDA/SCL pins as GPIO and manually toggles >>> SCL a few times. This would probably need to be implemented in >>> board-support-/platform code...? >> >> Needs to be part of recover function which in turn is part of driver code. > > In the case of the i.MX I2C peripheral, and probably in the case of a few > others, there is no way of doing this, except for switching I2C i/o pins to > GPIO via the iomux and toggling the GPIO pin that corresponds to SCL "by > hand", while watching the GPIO pin that corresponds to SDA. So only one problem up to here: may the i2c adapter code have reserved access to iomux? If its the only user -> move control into adpater driver, reserve the H/W-access and you are done. If not, then you have a shared device -> make a driver for iomux registers that serializes access, possibly with reservation functions, export them and reference from adapter code. >>> In my specific situation, there was no way of recovering other than >>> power-cycling the device, which is completely unacceptable, specially for >>> an industrial control system. A temporary bus-lockup with automatic >>> recovery via a proper I2C bus reset OTOH, wouldn't have any significant >>> impact even if occurring sporadically. >>> Individually resetting I2C slaves is also not a real solution because it >>> may not be possible to determine which is the I2C slave that misbehaved. >> >> Most I2C slaves haven't got any reset line. > > Even worse.... that means the bus will never come back, even if you reset the > machine!!! Only a power-cycle would save you. > Correct. >>> Any idea on how to solve this problem? >>> Should each driver implement support for it and implement optional callback >>> functions in platform-data? >> >> IMHO this typically is adapter driver's job. It strongly depends on >> particular H/W whether controller can return information on busy/blocked >> bus and whether it is able to manually toggle the clock line. On single >> master systems, the driver code should automatically try to recover when >> not being able to send start flag. On multi master systems the situation >> is more complex. > > I agree. There might be a few platforms where there is no solution to this, > other than hardwiring a separate GPIO line to SCL... or by wiring Vcc of unresetable I2C devices to a controllable on-board power supply/relays. -- KR Michael -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
