linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Stephen Neuendorffer <stephen.neuendorffer@xilinx.com>
Cc: linuxppc-dev@ozlabs.org, git-dev <git-dev@xilinx.com>
Subject: RE: dcr stuff.
Date: Tue, 25 Mar 2008 08:59:33 +1100	[thread overview]
Message-ID: <1206395973.7197.50.camel@pasglop> (raw)
In-Reply-To: <20080324043416.3634316E007A@mail15-dub.bigfish.com>


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.

  reply	other threads:[~2008-03-24 22:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-21 19:05 dcr stuff Stephen Neuendorffer
2008-03-21 21:24 ` Benjamin Herrenschmidt
2008-03-22  1:17 ` Josh Boyer
2008-03-24  4:34   ` Stephen Neuendorffer
2008-03-24 21:59     ` Benjamin Herrenschmidt [this message]
2008-03-24 22:18       ` Stephen Neuendorffer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1206395973.7197.50.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=git-dev@xilinx.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=stephen.neuendorffer@xilinx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).