[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PCI I/O Space Consumption Limitation



Mike:
  On 23 Aug 1996, 11:32:48, Mike wrote:
 >  Stephen  --  Could you explain once again *why* you want
 >  to put any new PCI device into IO space?  I'm having
 >  trouble following the thread related to your initial
 >  question.  If you are not a legacy device, I argue
 >  that no compelling reason exists.  Also what if your
 >  PWB ends up in an Alpha, Power PC, etc.  These *real*
 >  computers don't have IO space and everything ends up
 >  in memory space anyways.

  As with many scattered but interesting discussions, it was soon difficult to
determine how we got where we were.  Let me summarize and add some details that
we not part of the discussions...
  My expansion bus bridge is not aimed at PC systems.  It is part of a
MIPS-based system (i.e. one address space) where I/O is mapped into its 1536 MB
space (kernel or user).  My original concern is that page 197 of the PCI Rev
2.1 specification requires that I/O space be limited to 256 bytes.  Through
these discussion threads, I have gained an appreciation for why this
requirement is in the spec.  As I suspected, it was based on practical
limitations of Intel PC systems with ISA buses.  I wanted to voice a concern
about limiting I/O space on the PCI bus and get a better understanding of what
designers are doing in the area of I/O BARs.  In my opinion, I/O space on the
PCI bus is not necessarily related to processor I/O space.  The way that
processor bridge devices deal with PCI I/O space is my primary concern.  Do
they expect this limitation to be followed?
  For my system, I am also sitting down the hall from the processor bus bridge
designers for the first article.  However, I wanted to go outside of our world
to get opinions from others.
  For my backplane, each module receives a 4 KB block of register space.  These
are all located on a 256 KB contiguous address space.  I decided I would like
to have 2 PCI I/O spaces in the expansion bus bridge: one 4KB (internal device)
and one 256 KB (all other devices).  When I crossed the requirement on page
197, I became concerned that off-the-shelf processor bridge devices may not be
able to support these large allocations of PCI I/O space, possibly based simply
on PC system legacy experience of the bridge designers.
  To complete the BAR implementation story, I also provide 2 PCI memory space
BARs: prefetchable and non-prefetchable.  Each BAR may be individually
disabled.  Therefore, an application could choose to not implement the 256 KB
I/O BAR and use PCI memory space instead.  However, I did not provide a PCI
memory BAR for the 4KB internal registers.
  For the prototype module, our bridge design will map both my PCI I/O spaces
into either its 16MB IOSEL area or some other area of address space.  If I
needed to use an off-the-shelf processor bridge device, would it be so easy?

Steve Belvin

------------------ RFC822 Header Follows ------------------
Received: by smtp2.space.honeywell.com  with SMTP;23 Aug 1996 11:32:48 -0400
Received: from bos1h.delphi.com by fl51mail.space.honeywell.com with SMTP
	(1.38.193.5/16.2) id AA29683; Thu, 22 Aug 1996 23:40:47 -0400
Received: from delphi.com by delphi.com (PMDF V5.0-7 #10880)
 id <01I8LEJOCCAE8X39AW@delphi.com> for
 belvin_stephen_e@smtp2.space.honeywell.com; Thu,
 22 Aug 1996 23:33:15 -0500 (EST)
Date: Thu, 22 Aug 1996 23:33:15 -0500 (EST)
From: DINI@delphi.com
Subject: Re: PCI I/O Space Consumption Limitation
To: belvin_stephen_e.fl51-p11@smtp2.space.honeywell.com
Message-Id: <01I8LEJOCLXK8X39AW@delphi.com>
X-Vms-To: IN%"belvin_stephen_e@smtp2.space.honeywell.com"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
u