On Jul 29 2005, at 10:53, Kumar Gala was caught saying:
> The main issue that I'm starting to see is that the concept of a
> physical address from the processors point of view needs to be
> consistent throughout all subsystems of the kernel. Currently the
> major usage of struct resource is with the PCI subsystem and PCI
> drivers. The following are some questions that I was hoping to get
> answers to and discussion around:
>
> * How many 32-bit systems support larger than 32-bit physical
> addresses (I know newer PPCs do)?
Intel's new XSC3 ARM core supports up to 36-bit addressing and
they have several CPUs based on this that are already out or will
be released in the next year. I can currently get around 64-bit
resources by playing ugly tricks with the memory map and trapping
ioremap() calls to a certain unused 32-bit physical range and fixing
it up to 64-bit (like PPC440?? does) but that may not work on future
CPUs that don't have holes in the memmap.
> * How many 32-bit systems support a 64-bit PCI address space?
This is a fairly common thing on some of the Intel XScale I/O and
network processors. Some of the Intel CPUs provide a window in
32-bit CPU that translates to 64-bit PCI space.
> * Should ioremap and variants start taking 64-bit physical addresses?
If we are to use 64 bit resources, then yes. Or pfns...
Do a google for my real opinion on this. I think ioremap() should take
a device and resource describing the address of the resources in the
address space of the device (the bus it is one). The whole resource
and I/O subwystem currently assumes that physical and PCI bus address
spaces are one and the same, but I have HW that breaks this assumption
by allowing up to 2 GB of RAM and 3GB of PCI devices. Whenever this
has been brought up though, Linus has shot it down. What we need is
a real concept of per-bus address spaces and resources. But that is
far more complicated change.
> * Do we make this an arch option and wrap start and end in a typedef
> similar to pte_t and provide accessor macros to ensure proper use?
Probably the best thing to do b/c on really small systems that
don't have 64-bit needs, we'll just be wasting memory with the
extra data structure size. We need to scale down to PCI systems
with just 8MB of RAM.
~Deepak
--
Deepak Saxena - [email protected] - http://www.plexity.net
Even a stopped clock gives the right time twice a day.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |