linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Dan Malek <dan@embeddededge.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: consistent_alloc() revisited
Date: Tue, 16 Jul 2002 10:09:03 -0400	[thread overview]
Message-ID: <3D3428FF.5090401@embeddededge.com> (raw)
In-Reply-To: 20020716021313.GQ22786@zax


David Gibson wrote:

> In addition, the following seem to me like desirable (to a greater or
> lesser extent) properties for consistent_alloc():
> 	a. one of the return values can be used as a single "handle"
> so that consistent_free() only needs one parameter.

We want the implementation API to be identical across all architectures.
Until there is a consistent way of handling devices that are on local
processor busses, platforms with these types of devices may call these
functions directly.    This is particularly true of some host USB controllers
on embedded systems that don't have PCI busses.

> 	b. works on both cache coherent and non cache coherent
> machines

The original purpose of the consistent_* functions was to provide support
for processors that aren't cache coherent.  The pci_* (and any other functions)
can call these if appropriate, but I still believe the decision should  be
made at a higher level.  Obviously, these consistent_* functions will
be implemented differently on non- or cache coherent processors, and across
different architectures.  The PCI functions (or others) should still do their
thing as they always have, and call these consistent_* functions when
appropriate.


> 	c. be able to use highmem pages

You think there will be non-coherent processors with this much memory? :-)


> -	if (in_interrupt())
> -		BUG();
> +	BUG_ON(in_interrupt());

We should be able to call these functions from interrupt, let's push
the remainder of the changes though get_free_pages() to make this happen.


Thanks.


	-- Dan


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

  reply	other threads:[~2002-07-16 14:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-16  2:13 consistent_alloc() revisited David Gibson
2002-07-16 14:09 ` Dan Malek [this message]
2002-07-16 14:58   ` Tom Rini
2002-07-16 15:23   ` Matt Porter
2002-07-16 15:27   ` Matt Porter
2002-07-17  1:24   ` David Gibson
2002-07-20 15:28     ` Benjamin Herrenschmidt
2002-07-21 13:26       ` David Gibson
2002-07-20 15:22 ` Benjamin Herrenschmidt
2002-07-21 13:23   ` David Gibson
  -- strict thread matches above, loose matches on Subject: below --
2002-07-16 16:14 Ralph Blach

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=3D3428FF.5090401@embeddededge.com \
    --to=dan@embeddededge.com \
    --cc=david@gibson.dropbear.id.au \
    --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).