Hi Mark, On Tue, Dec 2, 2014 at 4:49 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > On Tue, Dec 02, 2014 at 10:05:48AM +0000, Harini Katakam wrote: >> From: Vishnu Motghare <vishnum@xxxxxxxxxx> >> >> This patch adds "defeature-repeated-start" property in i2c-cadence.txt. >> >> Signed-off-by: Vishnu Motghare <vishnum@xxxxxxxxxx> >> Signed-off-by: Harini Katakam <harinik@xxxxxxxxxx> >> --- >> .../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? > 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. 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
