Re: RFC: 64-bit resources and changes to pci, ioremap, ...

From: Deepak Saxena
Date: Fri Jul 29 2005 - 12:09:10 EST

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 Saxena - dsaxena@xxxxxxxxxxx -

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at