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 15 Nov 1998, Jes Sorensen wrote:

> >>>>> "Gerard" == Gerard Roudier <groudier@club-internet.fr> writes:
>
> Gerard> On Sun, 15 Nov 1998, Jakub Jelinek wrote:
>
> Gerard> My concern was an unified address mapping to be the only
> Gerard> acceptable solution since other scheme leads to kind of
> Gerard> complexity I donnot want to deal with from software. You may
> Gerard> love SUN stuff for personnal reasons but I donnot like their
> Gerard> BUSes addressing model for software technical reasons.
>
> Add a bus-key to the virt/phys conversion functions and you are all

I donnot want to add complexity but to remove some. :-)

> set. In fact it would solve a lot of problems for the m68k port (and
> possibly others) if they inb/outb macros people tend to use in lotsa
> drivers required a bus-key or a base offset (which could be the same
> thing) as some systems use mmap'ed I/O for both ISA and PCI busses'
> I/O space in the same machine, but without having them at the same
> address.

Suppose that I want a device on a BUS to directly transfer data to another
device on the same BUS or to another one without CPU intervention. How
many keys must I pass to any BUS abstraction layer to provide me the
appropriate address values I need?

> Gerard> BTW, it is the PCI BUS architecture that won the approbation
> Gerard> of most manufacturers and not the SUN approach for BUSes. You
> Gerard> seem to forget that a good standard must also allow to make
> Gerard> superior goods for a minimal cost.
>
> PCI bus won because it was far better than what was available in PC's
> before. However, PCI is SLOW and we are beginning to suffer from this
> now.

PCI specs allows 64 bit / 66 MHz transfers = 512 MB/sec.
We haven't yet it because, IMO:
1 - It is significantly more expensive than 32 bit PCI.
2 - It isn't worth it because 64 bit machines are not yet common due to
lack of software taking advantage of them.
A 133 MHz PCI is also possible => 1 GB/s

> Intel chose to create this ridiculous AGP crap instead of putting
> real PCI 64/66 in their machines, however even that is relatively slow
> and it is extremely rare in PCs.

Probably still a cost issue in my opinion.

> >> BTW: I don't know much about 133MHz PCI project, but simple math
> >> tells me it probably is not either 64bit, or runs much faster, as
> >> 133MHz x 8B = 1.03GB/sec.
>
> Gerard> I just pointed out as irrelevant David's remarks seemed to me.
> Gerard> 100 BUSes x 1.03 GB/s = 103 GB/s. Sorry for my mistake that
> Gerard> just lowered the actual bandwidth to half its theorical value.
>
> It's not the issue, btw. DEC has such systems as well. However on some
> architectures you map the bus to the memory/CPU when you need it and
> unmap it again after a DMA operation.

You still only consider CPU to BUS and BUS to CPU data transfers only.
Why not to envision applications where the CPU controls all the data flaw
but donnot have to route all the data via the main memory?

Regards,
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.041 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site