lkml.org 
[lkml]   [1998]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Accessing MMIO PCI space - crossplatform
From
Date
>>>>> "Gerard" == Gerard Roudier <groudier@club-internet.fr> writes:

Gerard> On 15 Nov 1998, Jes Sorensen wrote:

>> Add a bus-key to the virt/phys conversion functions and you are
>> all

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

Well I do not consider adding a bus-key as adding complexity. In fact
it would be very similar to the register offset one normally passes to
MMIO access macros. Adding such an identifier to the inb/outb macros
would be very easy and wouldn't cost any anything whatsoever for
systems where PCI/ISA I/O space is guaranteed to start at 0x0000. On
the other hand it would solve a lot of problems when we try to port
drivers written for PC ISA devices to other architectures which
utilize the same chips but not attached to an ISA bus.

>> 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.

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

If you want inter PCI support, you will need to figure out an API for
that. I don't know how Sun, DEC and others do this.

>> 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.

Gerard> PCI specs allows 64 bit / 66 MHz transfers = 512 MB/sec.

Except that you have to take into account that setting up a data
transfers on a 64-bit bus takes exactly as long as setting up the
transfer on a 32-bit bus, thus going from 32-bit to 64-bit PCI doesn't
provice you with a 2x speed-up.

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

I agree that it is more expensive than 32-bit PCI, but one of the
reasons for that is that people are not shipping 64-bit PCI in large
numbers. The probably chose AGP because it's simpler and most standard
PC owners care mainly about the performance of the 3D graphics in
their latest game, thus no need for a generic bus.

However your second argument is totally void, the memory subsystem in
most modern PCs is 64-bit and thats what matters when we are talking
PCI bandwidth as it is primarily DMA transfers to/from main memory
which are going on.

>> 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.

Gerard> Probably still a cost issue in my opinion.

We can't disagree on that, but I still blame them for shipping that
useless crap instead of a sane bus.

>> 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.

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

I consider BUS<->memory transactions which are the primary ones going
with most high-performance devices. I don't care all that much about
the speed for CPU<->device operations as you don't want to run
high-performance devices in PIO mode (won't allow you to perform
bursts on the bus and get the speed). I am not sure I understand your
last comment though.

Jes

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