All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Malek <dan@mvista.com>
To: Peter Desnoyers <pdesnoyers@chinook.com>
Cc: "Justin (Gus) Hurwitz" <ghurwitz@dyndns.com>,
	Daris A Nevil <dnevil@snmc.com>,
	linuxppc-embedded@lists.linuxppc.org
Subject: Re: Non-cacheable memory
Date: Tue, 14 Aug 2001 17:26:41 -0400	[thread overview]
Message-ID: <3B799791.2CEAFCC0@mvista.com> (raw)
In-Reply-To: 3B77F684.415638E8@chinook.com


Peter Desnoyers wrote:

> This seems like another case of either too little abstraction, or too
> much.  An embedded PPC system with PCI basically has two buses, with
> different DMA addressing, and there's no way to tell consistent_alloc(),
> etc. about that.

Well, if you are using PCI devices, you should be calling the pci_*
versions of these functions.  Those include a pci_dev structure, so
you can get the information you need to do this correctly, and seems
like the solution (more discussion later in the message).

> If you wouldn't mind, could you give me a pointer to the discussion of
> this phase-out?

I hear it from other folks on ppc-dev or something.  There are too many
lists for me to read and find this information first hand :-).


> I wonder if the proper thing to do is to enhance consistent_alloc to
> take an argument indicating the bus type?

Yep.  Like I said above, you should be using the pci_* versions of
these functions.  We can extract information from the pci_dev and pass
it along to consistent_alloc.  The local, internal peripherals can just
pass a NULL or zero or something, whatever this parameter is supposed to
mean.  Or, perhaps the pci_* functions fix up the information returned
from consistent_alloc.

> ....  There are more elegant ways
> of doing things, but this wouldn't involve changes to a lot of code.

This seems elegant enough to me :-).


	-- Dan

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

      reply	other threads:[~2001-08-14 21:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-07 18:49 Non-cacheable memory Justin (Gus) Hurwitz
2001-08-07 15:59 ` Tom Roberts
2001-08-07 18:34   ` Daris A Nevil
2001-08-09 22:49     ` Justin (Gus) Hurwitz
2001-08-09 19:27       ` Peter Desnoyers
2001-08-11  3:47         ` Dan Malek
2001-08-13 15:47           ` Peter Desnoyers
2001-08-14 21:26             ` Dan Malek [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=3B799791.2CEAFCC0@mvista.com \
    --to=dan@mvista.com \
    --cc=dnevil@snmc.com \
    --cc=ghurwitz@dyndns.com \
    --cc=linuxppc-embedded@lists.linuxppc.org \
    --cc=pdesnoyers@chinook.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.