From: Dan Malek <dan@mvista•com>
To: Roman Zippel <zippel@fh-brandenburg•de>
Cc: mgreer@mvista•com, linuxppc-dev@lists•linuxppc.org
Subject: Re: CONFIG_HIGHMEM on PPC
Date: Thu, 25 Jan 2001 12:08:34 -0500 [thread overview]
Message-ID: <3A705D92.682A6FEF@mvista.com> (raw)
In-Reply-To: Pine.GSO.4.10.10101251016230.20829-100000@zeus.fh-brandenburg.de
Roman Zippel wrote:
> And they don't have to.
So, why do we have so damn many ways and hacks to do stuff like
this? If a page or I/O is mapped into the VM space, there should
be a set of common functions to manage this space, and exactly one
function to do the virt_to_phys.
> .... If you have a highmem page, use kmap to get
> temporary virtual mapping. On the other hand most of the drivers should
> never see a highmem page.
On the other hand, if highmem was designed properly the kernel
should just fault in the needed pages and virt_to_phys and friends
should just work in this space, too. Yet another set of functions
to use and restrictions just because a physical page exists beyond
some arbitrary boundary? Geeze, I thought we learned from Mush-DOS
back in the mid-80's this was not a good design........
> I do currently.
I removed the #ifdef APUS in the virt_to_phys and friends macros
and made everyone call iopa which is going to move to a new file
called arch/ppc/mm/ioremap.c (like other architectures do). I
don't think the mm_ptov() function works on anything because the
kmap_chunks is gone (at least in the linuxppc_2_5 I am using).
Perhaps I'm just missing some updates from you. I'll delete
these functions from apus_setup.c since they are common to everyone
now. I'm almost done with this first phase of IBM4xx merge, which
I will probably start checking in later today. I'm just testing
on as many other platforms as I can to ensure I didn't break other
stuff.
Thanks.
-- Dan
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-01-25 17:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-01-24 0:31 CONFIG_HIGHMEM on PPC Mark A. Greer
2001-01-25 6:04 ` Dan Malek
2001-01-25 6:44 ` HTTP daemon required Srinivas Rao.M
2001-01-25 9:25 ` CONFIG_HIGHMEM on PPC Roman Zippel
2001-01-25 17:08 ` Dan Malek [this message]
2001-01-25 18:37 ` Roman Zippel
2001-01-25 19:47 ` Dan Malek
2001-01-25 19:59 ` David Edelsohn
2001-01-25 21:36 ` Roman Zippel
2001-01-25 21:51 ` Gabriel Paubert
2001-01-25 22:35 ` Roman Zippel
2001-01-25 22:39 ` David Edelsohn
2001-01-26 3:05 ` Frank Rowand
2001-01-25 19:28 ` Gabriel Paubert
2001-01-25 20:07 ` Dan Malek
2001-01-25 21:40 ` Gabriel Paubert
2001-01-25 21:46 ` David Edelsohn
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=3A705D92.682A6FEF@mvista.com \
--to=dan@mvista$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
--cc=mgreer@mvista$(echo .)com \
--cc=zippel@fh-brandenburg$(echo .)de \
/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