On Tue, Dec 02, 2014 at 10:05:48AM +0000, Harini Katakam wrote: > From: Vishnu Motghare <[email protected]> > > This patch adds "defeature-repeated-start" property in i2c-cadence.txt. > > Signed-off-by: Vishnu Motghare <[email protected]> > Signed-off-by: Harini Katakam <[email protected]> > --- > .../devicetree/bindings/i2c/i2c-cadence.txt | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/Documentation/devicetree/bindings/i2c/i2c-cadence.txt > b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt > index 7cb0b56..9d417a7 100644 > --- a/Documentation/devicetree/bindings/i2c/i2c-cadence.txt > +++ b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt > @@ -11,6 +11,17 @@ Required properties: > Optional properties: > - clock-frequency: Desired operating frequency, in Hz, of the bus. > - clock-names: Input clock name, should be 'pclk'. > + - 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? Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
