-----Original Message----- From: Josh Boyer [mailto:[EMAIL PROTECTED] Sent: Fri 3/21/2008 6:17 PM To: Stephen Neuendorffer Cc: linuxppc-dev@ozlabs.org; git-dev Subject: Re: dcr stuff. On Fri, 21 Mar 2008 12:05:40 -0700 "Stephen Neuendorffer" <[EMAIL PROTECTED]> wrote: > > Is there a plan here? (In particular, in FPGA designs, its possible to > > have crazy things like multiple independent dcr busses, some using > > native access, some using mmio. Or even if there is one bus, many of > > the existing non-linux drivers we have assume native or mmio access. > > I'd like to clean this up, obviously.. :) > Clean it up how? I'd hate to add bloat to boards with native DCR > access just because a few require oddities. > > If it ain't broke, don't fix it. > > josh 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. Steve
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
