From: Pantelis Antoniou <panto@intracom•gr>
To: Dan Malek <dan@embeddededge•com>
Cc: Tom Rini <trini@kernel•crashing.org>,
joakim.tjernlund@lumentis•se, acurtis@directvinternet•com,
Paul Mackerras <paulus@au1•ibm.com>, Matt Porter <porter@cox•net>,
linuxppc-embedded@lists•linuxppc.org
Subject: Re: Regarding consistent_alloc
Date: Thu, 12 Dec 2002 10:00:10 +0200 [thread overview]
Message-ID: <3DF8420A.4040409@intracom.gr> (raw)
In-Reply-To: <3DF8057D.3040106@embeddededge.com>
Dan Malek wrote:
> Pantelis Antoniou wrote:
>
>> Perhaps the best way to proceed is just to fix the
>> xxx_cpm_hostalloc() and
>> xxx_cpm_dpalloc() routines to work more intelligently, and to
>> forget about consistent_alloc entirely...
>
>
> You are totally missing the proper use of these functions. The 'cpm'
> functions are used specifically to assist the management of memory
> for the CPM peripherals on the 8xx and 82xx processor. There are often
> unique attributes of mapping these spaces that must be considered. The
> only thing to "fix" in these functions is to make a resource free (and
> smarter resource management) that works for loadable modules.
>
> The purpose of consistent_alloc() functions is to provide a method of
> allocating DMA consistent (i.e. non-cached in our case) memory spaces
> for _any_ purpose. These are functions you will find in other processor
> architectures and have become standard part of many Linux processor
> ports.
>
> The 'cpm' and PCI (and other non-PCI functions like USB OHCI) functions
> will rely on the consistent_alloc() functions to provide consistent
> spaces when necessary. There are some memory mapping assumptions made
> about the way consistent memory is allocated for the purposes of
> portabilty
> and performance.
>
> All of these functions are required and work reasonably well as currently
> implemented when they are used properly.
>
> Thanks.
>
>
> -- Dan
>
>
>
Fine,
I see now.
Since what I'm doing regards the CPM the proper thing to do
is to actually use the 8xx routines.
They only reason that I considered the consistent() routines was
that the 8xx routines are unsuitable for use in modules.
I will prepare a patch that deals with the inefficiencies
of the 8xx routines.
I believe you are the person that is assigned for maintaining
the 8xx series. Can you audit them after I post them
to the list?
Regards
--
Pantelis Antoniou
INTRACOM S.A. Greece
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-12-12 8:00 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
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 [this message]
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=3DF8420A.4040409@intracom.gr \
--to=panto@intracom$(echo .)gr \
--cc=acurtis@directvinternet$(echo .)com \
--cc=dan@embeddededge$(echo .)com \
--cc=joakim.tjernlund@lumentis$(echo .)se \
--cc=linuxppc-embedded@lists$(echo .)linuxppc.org \
--cc=paulus@au1$(echo .)ibm.com \
--cc=porter@cox$(echo .)net \
--cc=trini@kernel$(echo .)crashing.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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