linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Tom Rini <trini@kernel.crashing.org>
To: Dan Malek <dan@embeddededge.com>,
	Eugene Surovegin <ebs@innocent.com>,
	linuxppc-embedded@lists.linuxppc.org
Subject: Re: [PATCH] pci_alloc_consistent in an interrupt context
Date: Fri, 14 Jun 2002 07:59:30 -0700	[thread overview]
Message-ID: <20020614145930.GI13541@opus.bloom.county> (raw)
In-Reply-To: <20020614051450.GM26146@zax>


On Fri, Jun 14, 2002 at 03:14:50PM +1000, David Gibson wrote:
> On Thu, Jun 13, 2002 at 05:51:56PM -0700, Tom Rini wrote:
> >
> > On Fri, Jun 14, 2002 at 10:45:39AM +1000, David Gibson wrote:
> > > On Thu, Jun 13, 2002 at 05:38:07PM -0700, Tom Rini wrote:
> > [snip]
> > > > Er, the problem of setting dma_handle twice?
> > >
> > > Well, it fixes that and as a bonus gets rid of the ifdefs in
> > > pci_{alloc,free}_consistent() and means that if we ever port a driver
> > > using consistent_{alloc,free}() to a processor that *is* cache
> > > coherent it will Just Work.
> >
> > In theory at that point OCP would either have its API fully flushed out
> > or be applied nicely on top of the generic driver work in 2.5 and it
> > would just work anyhow :)
>
> Well at the moment OCP drivers call consistent_alloc() directly which
> would always fail on cache-coherent processors.

Yes.  And at the moment OCP is still a work in progress too.  As I said
before, by the time that pops up, OCP will either have it's API finished
(and look alot like PCI so drivers shouldn't be calling
consistent_alloc() themselves) or be worked in nicely with the generic
driver work in 2.5, which again will be copying pci_alloc_consistent()
to driver_alloc_consistent().

> > > > My only concern is that are things still consistent on non consistent
> > > > procs?
> > >
> > > Absolutely - no change to the code path at all on non cache coherent
> > > processors.
> >
> > So kmalloc/kfree are equivilent to __get_free_pages/free_pages ?
>
> Read that again: on *non* cache coherent processors the code path is
> the same.  kmalloc() vs. __get_free_pages() is a problem for
> processors which *are* cache coherent.

Yes.  And there's 2 things here which I'm wondering about:
(a) Why do we call __get_fre_pages/free_pages now on coherent procs?
Can we really just call something else and have it work?
(b) Is it really a good idea to have a function called
'consistent_alloc()' which doesn't actually do that, for the sake of
removing 2 ifdefs?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

  reply	other threads:[~2002-06-14 14:59 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-13 19:28 [PATCH] pci_alloc_consistent in an interrupt context Eugene Surovegin
2002-06-13 20:58 ` Tom Rini
2002-06-13 21:47   ` Dan Malek
2002-06-13 21:56     ` Tom Rini
2002-06-14  0:24       ` David Gibson
2002-06-14  0:38         ` Tom Rini
2002-06-14  0:45           ` David Gibson
2002-06-14  0:51             ` Tom Rini
2002-06-14  5:14               ` David Gibson
2002-06-14 14:59                 ` Tom Rini [this message]
2002-06-15  6:40                   ` David Gibson
2002-06-14  1:25         ` Eugene Surovegin
2002-06-14  1:33           ` David Gibson
2002-06-14  1:57             ` Eugene Surovegin
2002-06-14  2:06               ` David Gibson
2002-06-14  2:15                 ` Tom Rini
2002-06-14  3:58                   ` David Gibson
2002-06-14  4:42                     ` Tom Rini
2002-06-14  2:08             ` Dan Malek
2002-06-14  1:57       ` Dan Malek
2002-06-13 22:23     ` Eugene Surovegin
2002-06-13 23:34       ` Paul Mackerras
2002-06-14  2:17         ` Dan Malek
2002-06-14  2:29         ` Eugene Surovegin
2002-06-13 23:37       ` Paul Mackerras
2002-06-14  2:15       ` Dan Malek
2002-06-14  2:21         ` Eugene Surovegin
2002-06-13 23:07     ` [PATCH] pci_alloc_consistent in an interrupt context, part 2 Eugene Surovegin

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=20020614145930.GI13541@opus.bloom.county \
    --to=trini@kernel.crashing.org \
    --cc=dan@embeddededge.com \
    --cc=ebs@innocent.com \
    --cc=linuxppc-embedded@lists.linuxppc.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).