From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Christoph Hellwig <hch@lst.de>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH/RFC] powerpc: Refactor 64 bits DMA operations
Date: Sun, 05 Nov 2006 08:52:08 +1100 [thread overview]
Message-ID: <1162677128.28571.40.camel@localhost.localdomain> (raw)
In-Reply-To: <20061104132101.GA8704@lst.de>
On Sat, 2006-11-04 at 14:21 +0100, Christoph Hellwig wrote:
> On Sat, Nov 04, 2006 at 08:21:34AM +1100, Benjamin Herrenschmidt wrote:
> > This is also something I'll need in 2.6.20. Right now posted only for
> > comments though. It's known to "miss" fixup of at least pasemi and maybe
> > a few other things and I've not tested if I break 32 bits build yet :)
> >
> > This patch completely refactors DMA operations for 64 bits powerpc. 32 bits
> > is untouched for now.
>
> Can we please make 32bit use the same scheme for consistancy? It would
> just plug in a set of dummy direct mapped ops, quite similar to what we
> do in Cell (just without setting the magic bit)
dma_64.c has a set of generic direct ops that could be used for 32 bits
as well. It's just that in addition to fairly different PCI code, 32
bits code use a wider variety of bus types and platform devices and does
DMA from them. All those would need to be updated to get the device
extension with the dma ops pointers.
That's why right now, I prefer leaving 32 bits alone. I do plan to
converge 32 and 64 bits PCI code, don't worry about that :-) At which
point I'll also tackle that issue.
Right now, 64 bits DMA is different, I'm not making it more or less
different, just differently different :-). Merging 32 bits here is just
not something I can do for 2.6.20 timeframe.
Ben
prev parent reply other threads:[~2006-11-04 21:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-03 21:21 [PATCH/RFC] powerpc: Refactor 64 bits DMA operations Benjamin Herrenschmidt
2006-11-04 13:21 ` Christoph Hellwig
2006-11-04 21:52 ` Benjamin Herrenschmidt [this message]
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=1162677128.28571.40.camel@localhost.localdomain \
--to=benh@kernel.crashing.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).