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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
