From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Thu, 25 Jul 2013 10:40:53 -0700 Subject: [U-Boot] [Ac100] [PATCH 3/3] ARM: tegra: paz00: enable nveckeyboardsupport In-Reply-To: <2212981.62UMKmQoca@ax5200p> References: <1374223663-8576-1-git-send-email-danindrey@mail.ru> <3316781.OqtWDWHhXR@fb07-iapwap2.physik.uni-giessen.de> <51EEA3FA.2010804@wwwdotorg.org> <2212981.62UMKmQoca@ax5200p> Message-ID: <51F16325.3050009@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 07/24/2013 10:52 AM, Marc Dietrich wrote: > On Tuesday 23 July 2013 08:40:42 Stephen Warren wrote: >> On 07/22/2013 01:09 AM, Marc Dietrich wrote: > > [ snip the stuff we agreed upon ] > >>> The nvec still needs to tell the slave driver which protocol to use, but >>> that can be hard coded. >> >> I'm not sure what that means. At the controller/HW level, aren't I2C and >> SMBUS the same; it's just the data within the transactions that may be >> more defined by one or the other? > > at this level yes, but we need to handle the underlying protocol in the ISR, > which means that depending on the protocol (smbus or I2C), we need a different > interrupt service routine. Currently we are doing most of the smbus protocol > in the ISR because of timing reasons and I'm not sure if we can change this. > We are already suffering from nvec timeouts and I fear that splitting the > protocol out of the ISR would make things even worse. I assume that the I2C slave driver's ISR would simply directly/immediately call a function in the "protocol driver". That should allow sufficient separation of the layers while still maintaining minimal latency, assuming a good design of the callback's function prototype and/or the list of I2C slave controller functions that the callback is allowed to call into.