Re: Memory mapped IO vs Port IO

[John Bradford]

> > My claim is basically:
> > 
> > Change everybody who currently does
> > 
> > #ifdef CONFIG_MMIO
> >         writel(... )
> >         readl(...)
> > #else
> >         outl( ... ) 
> >         inl ( ...) 
> > #endif
> > 
> > to 
> >         if (dev->mmio) { 
> >                 writel(); 
> >                 real();
> >         } else { 
> >                 outl();
> >                 inl();
> >         } 
> > 
> > and you will have a hard time to benchmark the difference on any non
> > ancient system
> > in actual driver operation.

Or an embedded system, maybe?

At the end of the day, it still means loosing a tiny amount of
performance just to make it easier for distributions to have one
generic kernel.  There is nothing wrong with that, but why force it on
systems that are not running a generic kernel?

What's wrong with:

#ifdef CONFIG_MMIO
	writel(... );
        readl(... );
#endif
#ifdef CONFIG_NO_MMIO
	outl(... );
	inl(...);
#endif
#ifdef CONFIG_DONT_CARE_MMIO
	if (dev->mmio) {	
		writel(... );
		readl(... );
	} else {
		outl(... );
		inl(... );
	}
#endif

Although I'm dubious of having a global switch for MMIO anyway.

> Wouldn't it be better if we set the IN and OUT function pointers to the
> right functions during driver init. based on the setting of dev->mmio.
> And throughout the driver, we just call the IN and OUT functions by
> their pointers.  Then we don't have to do if (dev->mmio) every time.
> It's similar to the concept of virtual member function in C++.

It's neater, but still means bloat, however small.

I know we're talking a few bytes here and there, but embedded systems
really care about them.

John.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/