Re: i2c-gpio performance issue w/MPC8xx @ 50 MHz

[Ben Dooks <ben-i2c-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>]

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-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org, http://www.fluff.org/ben/

Large Hadron Colada: A large Pina Colada that makes the universe disappear.