Hi Guenter, > I didn't (want to) say that. I am perfectly happy with driver specific > code, and I would personally still very much prefer it. I only wanted to > suggest that _if_ a generic solution is implemented, it should cover all > existing use cases and not just this one. But, really, I'd rather leave > that alone and not risk introducing regressions to existing drivers. Okay, seems we are aligned again :) > I don't know about this device, but in general the problem is that the > devices need some delay between some or all transfers or otherwise react > badly in one way or another. The problem is not always the same. Ok, that again doesn't speak for a generic solution IMO. > Lower bus frequencies don't help, at least not for the devices where > I have seen to problem myself. The issue is not bus speed, but time between > transfers. Typically the underlying problem is that there is some > microcontroller on the affected chips, and the microcode is less than > perfect. For example, the microcode may not poll its I2C interface > while it is busy writing into the chip's internal EEPROM or while it is > updating some internal parameters as result of a previous I2C transfer. I see. Well, as you probably know, EEPROMs not reacting because they are busy with an erase cycle is well-known in the I2C world. The bus driver reports that the transfer couldn't get through, and then the EEPROM driver knows the details and does something apropriate, probably waiting a while. This assumes that the EEPROM can still play well on the I2C bus. If a faulty device will lock up a bus because of bad microcode while it is busy, then it surely needs handling of that :( And this convinces me just more that it should be in the driver... > The latter. I never bothered trying to write up a list. Typically the behavior > is not documented and needs to be tweaked a couple of times, and it may be > different across chips supported by the same driver, or even across chip > revisions. Any list trying to keep track of the various details would > be difficult to maintain and notoriously be outdated. ... especially because of that. If there is really some repeating pattern for some of the devices, we could introduce helper functions for the drivers to use maybe. But the I2C core functions are not the place to handle it. All the best, Wolfram
Attachment:
signature.asc
Description: PGP signature
