From: Pantelis Antoniou <panto@intracom.gr>
To: joakim.tjernlund@lumentis.se
Cc: acurtis@directvinternet.com, Tom Rini <trini@kernel.crashing.org>,
Dan Malek <dan@embeddededge.com>,
Paul Mackerras <paulus@au1.ibm.com>, Matt Porter <porter@cox.net>,
linuxppc-embedded@lists.linuxppc.org
Subject: Re: Regarding consistent_alloc
Date: Wed, 11 Dec 2002 11:58:45 +0200 [thread overview]
Message-ID: <3DF70C55.3010709@intracom.gr> (raw)
In-Reply-To: <IGEFJKJNHJDCBKALBJLLAELIFIAA.joakim.tjernlund@lumentis.se>
Joakim Tjernlund wrote:
>>
>>>>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?
>>>>
>
>It would be great if the new fucntions could work with micropatch.c as well.
>If the microcode is loaded, then those microcode area should be reserved and
>not used by 8xx_cpm_dpalloc.
>
As a matter of fact, this is another patch that I can submit
that take into account the area left by the micropatches so that the
dpalloc functions can utilize every last byte of the DPRAM.
At the moment I'm swamped with work, so it will take a couple of
days to clean things up and submit them.
>
>>><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>
>>>
>>m8xx_cpm_hostalloc(), if it is anything like the 8260 version, enables you
>>to allocation memory from dual-port RAM. (which could be handy and/or
>>required for certain CPM related operations) _va() and _pa() only work for
>>main memory addresses. For all other address ranges the iopa() function must
>>be used. (I hope this is helpful)
>>
>
>_va() and _pa() used to work for m8xx_cpm_hostalloc() and I like that better. _pa()
>is much cheaper than iopa() and there is no iova()(I think).
>
>Why was m8xx_cpm_hostalloc() changed to use consistent_alloc()? alloc_bootmem_pages()
>should still work(I am guessing)
>
>BTW, m8xx_setup_arch() still calls alloc_bootmem_pages() and
>the new m8xx_cpm_reset() does not take a ptr argument, but m8xx_setup_arch()
>still calls m8xx_cpm_reset() with cpm_page as argument.
>
I think it's safe to assume that there is large amount of confussion at
this subject.
FWIW I dislike the use of iopa(), and I would be forced to duplicate the
code of
consistent_alloc() class of functions in my tree.
Could we at least have a m8xx_cpm_hostalloc that works as expected?
How about the following approach:
Each platform which is based on 8xx defines the amount of uncached
memory that is expected
to be used by it's drivers. It's not hard to make a rough estimation
since most people
that use the 8xx have very tight control of the hardware.
We organize then the memory in a heap, which is able to do allocations and
deallocations properly. That allows drivers that are loaded as modules
to operate
correctly and does not fragment (much) the memory.
How about it?
>
> Jocke
>
>
>
>
P.S. I have posted by QMC driver to the list, but there has been no
response.
Please if anyone is interested in the QMC, give me some kind of feedback.
Even negative feedback is OK.
Thanks
--
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-11 9:58 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 [this message]
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=3DF70C55.3010709@intracom.gr \
--to=panto@intracom.gr \
--cc=acurtis@directvinternet.com \
--cc=dan@embeddededge.com \
--cc=joakim.tjernlund@lumentis.se \
--cc=linuxppc-embedded@lists.linuxppc.org \
--cc=paulus@au1.ibm.com \
--cc=porter@cox.net \
--cc=trini@kernel.crashing.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 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.