On Sun, May 01, 2011 at 03:04:21PM -0700, Håvard Skinnemoen wrote: > Hi Eran, > > Hmm. i2c-gpio overrides the udelay specified by the platform? That > shouldn't happen. It does try to come up with some reasonable defaults > if the platform doesn't specify any though. [snip] > You can probably create a minimal i2c-platform driver which just > passes the platform-specific callbacks to i2c-algo-bit. I think it > should be a new bus driver though...passing those callbacks to > i2c-gpio would basically eliminate the very small amount of > functionality this driver provides while making it more complex. > > i2c-gpio currently has 225 lines of code. I think it should be > possible to write a i2c-platform driver in less than 100 lines. > Probably worthwhile for 3x performance, although probably not if the > GPIO hardware has concurrency issues. I suppose this would work, but is it worth the additional code for what may not be much of a win? > > That being said, if you use GPIOs, it would certainly be better to find > > out whether the extra delay you've been observing could be removed. > > Properly requesting the GPIOs you need is definitely cleaner than > > accessing the I/O port (or whatever) directly. Direct access can be > > unreliable if other code is using GPIOs nearby. > > If your hardware allows you to control individual pins without > affecting others, it's probably ok to bypass the GPIO layer (although > you should probably still request the pins to prevent others from > using them). If not, you should expect a lot of trouble. yeuck. -- Ben Dooks, ben@xxxxxxxxx, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
