From: Tom Rini <trini@kernel.crashing.org>
To: Pantelis Antoniou <panto@intracom.gr>
Cc: Dan Malek <dan@embeddededge.com>,
Paul Mackerras <paulus@au1.ibm.com>,
joakim.tjernlund@lumentis.se, Matt Porter <porter@cox.net>,
linuxppc-embedded@lists.linuxppc.org
Subject: Re: Regarding consistent_alloc
Date: Tue, 10 Dec 2002 10:49:11 -0700 [thread overview]
Message-ID: <20021210174911.GB14786@opus.bloom.county> (raw)
In-Reply-To: <3DF45D05.5030003@intracom.gr>
On Mon, Dec 09, 2002 at 11:06:13AM +0200, Pantelis Antoniou wrote:
[snip]
> Since I'm the one that started this thread let me make a few points.
>
> 1. The comment that consistent_alloc is tied to the PCI bus is valid,
> since the dma_handle is returned by a call to virt_to_bus(), with
> the virt_to_bus() being:
>
> /*
> * The PCI bus is inherently Little-Endian. The PowerPC is being
> * run Big-Endian. Thus all values which cross the [PCI] barrier
> * must be endian-adjusted. Also, the local DRAM has a different
> * address from the PCI point of view, thus buffer addresses also
> * have to be modified [mapped] appropriately.
> */
> extern inline unsigned long virt_to_bus(volatile void * address)
> {
> #ifndef CONFIG_APUS
> if (address == (void *)0)
> return 0;
> return (unsigned long)address - KERNELBASE + PCI_DRAM_OFFSET;
> #else
> return iopa ((unsigned long) address);
> #endif
> }
This is typically used by PCI, but look at the code for the !CONFIG_APUS
(ie just about every machine, including all 8xx) case. This is the
iopa, that if classes haven't made me even more incoherent, that has
been mentioned throught the thread.
> Also the consistent_sync() takes as a direction argument values like
> PCI_DMA_FROMDEVICE.
This is unfortunate, but 'expected' for now. These constants really
have nothing to do with PCI DMA, but DMA in general. There was a hope
of fixing that in 2.5, but I don't recall if it happened (it might
have) yet.
> It has something obviously to do with a PCI bus. My board, and I believe
> most of the boards with a 8xx do not have a PCI bus.
>
> Is it possible to modify consistent_alloc to be something more
> generic?
It is already generic, it's just not obvious :(
> 2. I have a requirement to have my drivers loaded as modules.
> m8xx_cpm_hostalloc has a very simplistic implementation, which
> makes it unsuitable for something like that. I have some patches
> that fix both m8xx_cpm_hostalloc and 8xx_cpm_dpalloc by implementing
> a proper heap, with free space management and coalescing.
> What is the proper way to push them, and to whom?
<buck passing mode=on>Dan Malek still knows the most about the
8xx-specific portions of the kernel, so he should really speak up here
when he gets a moment</buck passing>
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-12-10 17:49 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-12-06 13:18 Regarding consistent_alloc Pantelis Antoniou
2002-12-06 13:23 ` Pantelis Antoniou
2002-12-06 14:25 ` Joakim Tjernlund
2002-12-06 15:59 ` Matt Porter
2002-12-06 16:08 ` Joakim Tjernlund
2002-12-06 18:30 ` Matt Porter
2002-12-06 18:15 ` Joakim Tjernlund
2002-12-06 18:52 ` Matt Porter
2002-12-06 19:59 ` Dan Malek
2002-12-06 22:11 ` Joakim Tjernlund
2002-12-07 0:16 ` Paul Mackerras
2002-12-07 12:53 ` Joakim Tjernlund
2002-12-07 16:53 ` Dan Malek
2002-12-09 9:06 ` Pantelis Antoniou
2002-12-10 17:49 ` Tom Rini [this message]
2002-12-11 3:52 ` acurtis
2002-12-11 8:57 ` Joakim Tjernlund
2002-12-11 9:58 ` Pantelis Antoniou
2002-12-11 14:41 ` acurtis
2002-12-11 15:01 ` Pantelis Antoniou
2002-12-11 15:36 ` acurtis
2002-12-12 3:32 ` Dan Malek
2002-12-11 14:56 ` Tom Rini
2002-12-11 15:07 ` Pantelis Antoniou
2002-12-12 3:41 ` Dan Malek
2002-12-12 8:00 ` Pantelis Antoniou
2002-12-12 8:18 ` Wolfgang Denk
2002-12-12 8:37 ` Pantelis Antoniou
2002-12-12 12:56 ` Is the preemptive kernel patch unsafe for 8xx/PPC? Joakim Tjernlund
2002-12-12 18:28 ` Eugene Surovegin
2002-12-12 20:35 ` Joakim Tjernlund
2002-12-13 4:12 ` acurtis
2002-12-13 6:09 ` Eugene Surovegin
2002-12-13 7:47 ` Joakim Tjernlund
2002-12-16 14:41 ` acurtis
2002-12-13 4:08 ` acurtis
2002-12-12 16:53 ` "Missing" patches (Was: Re: Regarding consistent_alloc) Tom Rini
2002-12-06 16:56 ` Regarding consistent_alloc Dan Malek
2002-12-06 18:29 ` Matt Porter
2002-12-06 19:45 ` Dan Malek
2002-12-07 0:25 ` Paul Mackerras
2002-12-06 15:54 ` Matt Porter
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=20021210174911.GB14786@opus.bloom.county \
--to=trini@kernel.crashing.org \
--cc=dan@embeddededge.com \
--cc=joakim.tjernlund@lumentis.se \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=panto@intracom.gr \
--cc=paulus@au1.ibm.com \
--cc=porter@cox.net \
/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