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

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.061 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site