dcr stuff.

[Benjamin Herrenschmidt]

On Sun, 2008-03-23 at 21:34 -0700, Stephen Neuendorffer wrote:
> 
> Certainly, if it ain't broke don't fix it.  What I'm really trying to
> do is figure out how to clean up alot of non-mainline drivers.
> At the moment, several cores use DCR, but the drivers for those cores
> have internal code for DCR, their own ifdefs, etc.  This *is* broken.
> I'm looking at the available documentation to figure out the best way
> of approaching the problem.
> 
> It might be nice if there was an extra layer of indirection which was
> only enabled if DCR_NATIVE and DCR_MMIO, and which was no cost
> otherwise,
> but the bigger problem I see in the short term is that we'll likely
> have to support ARCH ppc for at least some time into the future, and
> it would be
> nice if we used the same driver code to do it: it doesn't seem obvious
> how to achieve this.

It's not too hard to have the DCR code be common, it's harder to deal
with the lack of device-tree in arch/ppc tho.

As for enabling support for both native and MMIO, that's certainly
possible, patches welcome :-) You could make the dcr host structure
contain the type or even function pointers, as you see fit. But make is
so that when only native is enabled, it turns back into the inlines we
have now.

Cheers,
Ben.