linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Christoph Hellwig <hch@lst.de>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	"cbe-oss-dev@ozlabs.org" <cbe-oss-dev@ozlabs.org>
Subject: Re: [PATCH] powerpc: New DCR access methods
Date: Mon, 16 Oct 2006 18:21:52 +1000	[thread overview]
Message-ID: <1160986912.22522.79.camel@localhost.localdomain> (raw)
In-Reply-To: <20061016081748.GA11677@lst.de>


> > +#ifdef CONFIG_PPC_DCR_NATIVE
> > +#include <asm/dcr-native.h>
> > +#else
> > +#include <asm/dcr-mmio.h>
> > +#endif
> 
> Having this as a compile-time switch seems broken.  I thought the plan was
> to support all different 64bit kernels with a single kernel binary?

"native" DCRs only exist in 32 bits 4xx / BookE processors as of today.

Basically, those processors have mtdcr and mfdcr instructions to access
those special "registers". They are in fact connected to a bus to
control various IOs. On AXON (and possibly other future chips), since
the host processor doesn't have those instructions, they are memory
mapped.

There is currently no way you can have both in the same kernel. If that
ever happens, then the "mmio" version could easily be tweaked to deal
with both. However, the "native only" implementation is useful for
embedded 4xx etc... as it resolves directly to mfdcr/mtdcr instructions,
dcr_map is an empty macro, etc... thus there is 0 overhead of switching
4xx code to the new dcr accessors.

Ben.

  reply	other threads:[~2006-10-16  8:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-16  7:44 [PATCH] powerpc: New DCR access methods Benjamin Herrenschmidt
2006-10-16  8:17 ` Christoph Hellwig
2006-10-16  8:21   ` Benjamin Herrenschmidt [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-10-11  5:42 Benjamin Herrenschmidt

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=1160986912.22522.79.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=hch@lst.de \
    --cc=linuxppc-dev@ozlabs.org \
    /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).