From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Rutland Subject: Re: [PATCH 3/4] devicetree: bindings: Add defeature-repeated-start property for Cadence I2C Date: Tue, 2 Dec 2014 11:19:07 +0000 Message-ID: <20141202111907.GC23671@leverpostej> References: <1417514749-24319-1-git-send-email-harinik@xilinx.com> <1417514749-24319-4-git-send-email-harinik@xilinx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <1417514749-24319-4-git-send-email-harinik@xilinx.com> Sender: linux-kernel-owner@vger.kernel.org To: Harini Katakam Cc: "wsa@the-dreams.de" , "grant.likely@linaro.org" , "robh+dt@kernel.org" , Pawel Moll , "ijc+devicetree@hellion.org.uk" , "galak@codeaurora.org" , "michal.simek@xilinx.com" , "soren.brinkmann@xilinx.com" , "linux-arm-kernel@lists.infradead.org" , "linux-i2c@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "devicetree@vger.kernel.org" , "vishnum@xilinx.com" List-Id: devicetree@vger.kernel.org On Tue, Dec 02, 2014 at 10:05:48AM +0000, Harini Katakam wrote: > From: Vishnu Motghare > > This patch adds "defeature-repeated-start" property in i2c-cadence.txt. > > Signed-off-by: Vishnu Motghare > Signed-off-by: Harini Katakam > --- > .../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.