Messages in this thread | | | Date | Sun, 15 Nov 1998 10:23:44 +0100 (MET) | From | Gerard Roudier <> | Subject | Re: Accessing MMIO PCI space - crossplatform |
| |
On Sat, 14 Nov 1998, David S. Miller wrote:
> Date: Fri, 13 Nov 1998 20:41:48 +0100 (MET) > From: Gerard Roudier <groudier@club-internet.fr> > > I dislike the PCI addressing implementation in SPARC64 because it does > not use the FLAT model. This is pain in the ass since BUS addresses are > different from the CPU and from devices that are on the BUS, and PCI > base registers are to be converted to/from CPU, etc..., etc... > > Was it really not possible to make things clean for PCI on SPARC (i.e. is > it a constraint of SUN's implementation of PCI) ? > > BTW, it is a question, not a flame. > > Well, let me put it this way, how would you implement the capability > to put 100 PCI busses on a system? This is what the Sun method is > trying to do.
I heard of a 133 MHz PCI BUS project. In 64 bit mode, the total bandwidth will be 53.2 GB/sec. Perhaps future Java Systems would need such a memory bandwidth ;-). The SUN method to enhance computing seems worse than Intel/M$$ one to me in some aspects.
> PCI base registers only need to be converted because when you want to > speak of "raw PCI MEM I/O address from devices point of view" you must > account for the fact that the CPU sees each PCI bus in a different > part of the physical address space. Consider the fact that we put > actual cpu view address into base register a side effect of the fact > that it is the simplest way to encode "PCI bus instance" into such a > value.
The present is 64 bit addressing or at least 36 or 40 bit addressing. Let each thing that is connected to the address bus claim accesses based on memory address comparators and window size and all the addressing mechanism can be unified without losing significant address space for BUSES.
MMIO is the simplest IO method that have been ever invented. With SUN's approach we may need address translations as:
virt_to_bus_from_memory() phys_on_bus1_I_have_to_provide_bus2() bus1_address_as_seen_from_cpu_to_devices_on_bus2_address(....)
Are you able propose a clean abstraction for that ?
> So please propose a PCI addressing implementation that allows more > than 1 PCI bus in the system and does not have the "problems" you see > in sparc64 method :-) BTW, Alpha has something similar on multi-PCI > bus machines and last I checked they were going to make it work the > same way we did on sparc64.
Only a unified addressing scheme is acceptable in my opinion. Other schemes make things a lot too complex to deal with. BTW, I know we have to deal with existing architectures. I just want to say how much I dislike some IO sub-systems design. That's all.
Thanks for having responded.
Gerard.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |