Re: CONFIG_HIGHMEM on PPC
From: Dan Malek <hidden>
Date: 2001-01-25 17:08:34
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/