Messages in this thread | | | Date | Fri, 29 Jul 2005 10:02:18 -0700 | From | Deepak Saxena <> | Subject | Re: RFC: 64-bit resources and changes to pci, ioremap, ... |
| |
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 - dsaxena@plexity.net - 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |