Hi, On Tue, Dec 2, 2014 at 6:22 PM, Wolfram Sang <wsa@xxxxxxxxxxxxx> wrote: >> >> + - defeature-repeated-start: Include this property to defeature repeated start >> >> + This defeature is due to a few bugs in the >> >> + I2C controller. >> >> + Completion interrupt after a read/receive >> >> + operation is NOT obtained if HOLD bit is set >> >> + at that time. Because of this bug, repeated start >> >> + will only work if there are no transfers following >> >> + a read/receive transfer. >> >> + If HOLD is held for long without a transfer, >> >> + invalid read transactions are generated by the >> >> + controller due to a HW timeout related bug. >> > >> > I'm not keen on the name; it sounds like we're disabling a feature >> > rather than describing the problem (and "defeature" is not a common >> > term in this sense, "disable" would be better). >> > >> > It sounds like there are two issues with staying in the HOLD state? Lost >> > completion IRQs and a separate HW timeout bug? Or are the two related? >> > >> >> Yes, there are two issues here and they are not related. >> But a combination of both is leading to not using repeated start. >> The intention was to defeature except that it works in some scenarios >> (such as a typical write+read in that order with repeated start) >> and there are people who already use the driver with slaves that need this. > > That should not be handled using a binding. If you get a transfer (at > runtime) with criteria you don't support, return with -EOPNOTSUPP from > the master xfer routine. > I put a check in place for one failure condition that we know (will change the error code returned). But given the bugs, it will be useful to just disable it if the system doesn't require repeated start. If you think DT entry is not the way to go, do you think a CONFIG option or something better will work? We chose a DT property because there is a good chance the user has multiple cadence I2C controllers - one connected to a slave that needs repeated start (like a power controller) and another that doesn't care. Regards, Harini -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
