dcr stuff.

[Stephen Neuendorffer]

> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh at kernel.crashing.org]
> Sent: Monday, March 24, 2008 3:00 PM
> To: Stephen Neuendorffer
> Cc: Josh Boyer; linuxppc-dev at ozlabs.org; git-dev
> Subject: RE: dcr stuff.
> 
> 
> 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.

My thoughts at the moment are to punt on map and unmap and at least
provide support for dcr_host_t and dcr_read and dcr_write.  Any driver
code that wants to use this without a device tree will just have to do
the work itself.  This will at least support the use cases we have
today: If people want something better, then they should switch to ARCH
powerpc.. :)
 
> 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.

Working on it.. :)

Steve