lkml.org 
[lkml]   [2005]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-07-29 19:11    [W:0.037 / U:1.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site