RE: Re[2]: PCI I/O Space Consumption Limitation

["Belvin Stephen E" <belvin_stephen_e@smtp2.space.honeywell.com>]

Thanks for your detailed response.  It's becoming quite clear that too much
Intel-specific discussion would be required to convert people like me over to
this limitation so it became a requirement.  I'm in.

Steve
_______________________________________________________________________________
From: GANESANV on Thu, Aug 22, 1996 9:04 AM
Subject: Re[2]: PCI I/O Space Consumption Limitation
To: Belvin Stephen E
Cc: PCI Reflector

 The restriction for the 256 byte I/O space comes from the fact that 
 some ISA devices do not decode addresses above SA9 on the bus. These 
 devices use addresses x100-x3ffH and there aliases like 1100-13ff,
 2100-23ff,etc. So, PCI devices are not assigned any address between 
 x100-x3ff. In every 1K of I/O space available only the first 256 bytes 
 are allocatable to PCI while the 768 bytes remain reserved for ISA 
 devices. If PCI devices are allocated between x100-x3ff there is a 
 possibility that some ISA devices using aliased address may not seen 
 by their S/W. I have seen some of the old PCI VGA cards using aliases 
 of their VGA addresses which the BIOS has no way of finding out. The 
 only way to avoid this problem is to assign only the first 256 bytes 
 of every 1K of I/O space.


______________________________ Reply Separator
_________________________________
Subject: RE: PCI I/O Space Consumption Limitation
Author:  Belvin Stephen E <belvin_stephen_e@smtp2.space.honeywell.com> at 
Internet
Date:    8/21/96 7:32 PM


 Tripathi:
   Thanks for responding to yet another of my questions.  As far as the
 discussion on page 197 goes, you're right that it is trying to suggest that 
 designers memory map I/O.  My concern is that it doesn't suggest that an I/O 
 BAR be used to represent no more than 256 bytes, it *requires* it.
   In my system, I have a non-prefetch memory BAR that, when properly
 configured, allows the expansion bus registers to be accessed via PCI memory 
 operations.  I have also assigned a large, dedicated I/O space to allow access

 to the expansion bus bridge I/O section if enabled (256 KB total, or 4K per 
 node).
   I would like to express my disappointment that the I/O space restriction is
 not a SHOULD (or even a PLEASE).
 
 Steve
 - - - - - - - - - - - - -
 
 On Aug 21, 1996, Devendra K Tripathi wrote:
 
 > It may be pointed here that you have to have a Memory BAR for 
 > every I/O BAR. The point is that PCI does not encourage to use
 > I/O space at all. Obiously you have some reason to use such big 
 > I/O spaces instead of mapping them to memory, but it may be
 > worth reveiwing those constraints. 
 >
 > Thanks,
 > Tripathi.
 
 On Aug 21, 1996, Steve Belvin wrote:
  >> Hi.
  >>   I am developing a PCI expansion bus bridge and am concerned 
  >> about what appears to be an I/O space consumption limitation. 
  >>   Page 197 of the PCI Rev 2.1 spec states "Devices that map 
  >> control functions into I/O space may not consume more than
  >> 256 bytes per I/O Base Address Register."  In response to 
  >> this and repeated recommendations to minimize I/O space, I
  >> find that many devices are encouraged to minimize I/O space. 
  >> In one book I read that "... subsystem designers should
  >> design a function so as to require no more than 32 bytes of 
  >> user-definable configuration data."
  >>   I am well aware of the shrinking Intel I/O space problem 
  >> but not all systems have I/O space limitations.  My system 
  >> will use a MIPS processor and we plan to implement a large 
  >> I/O space (from 10KB to 1MB).  Where practical, we follow 
  >> IEEE Std 1212 register definitions as a guide, where I/O 
  >> space is sacrificed for well organized control and status 
  >> registers.  Fire Wire also follows this in its register
  >> organization.
  >>   I would think PowerPC host bridges would not find 10-20KB 
  >> of I/O space to be a problem.
  >>   My question is:
  >>
  >>   o   Do designers follow the statement on page 197 and 
  >> implement multiple I/O BARs where more than 256 bytes of 
  >> I/O space are consumed?
  >>
  >>   TIA.
  >> Steve Belvin
 
 
 ------ Message Header Follows ------
 Received: from netcomsv.netcom.com by american.megatrends.com
   (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm))
   id AA-1996Aug21.193220.1665.22241; Wed, 21 Aug 1996 19:32:22 -0400
 Received: from znyx.com by netcomsv.netcom.com with SMTP (8.6.12/SMI-4.1)
  id QAA20415; Wed, 21 Aug 1996 16:07:31 -0700
 Resent-From: pci-sig-request@znyx.com 
 Received: by znyx.com (5.65/1.35)
  id AA25176; Wed, 21 Aug 96 16:07:49 -0700
 Resent-Date: 21 Aug 1996 19:09:30 -0400 
 Message-Id: <9608212305.AA25108@znyx.com> 
 Date: 21 Aug 1996 19:09:30 -0400
 From: "Belvin Stephen E" <belvin_stephen_e@smtp2.space.honeywell.com> 
 Subject: RE: PCI I/O Space Consumption Limitation
 Cc: "PCI Reflector" <pci-sig@znyx.com> 
 Resent-Message-Id: <"VtLcE3.0.U86.CPv6o"@dart> 
 X-Mailing-List: <pci-sig@znyx.com> archive/latest/3519 
 X-Loop: pci-sig@znyx.com
 Precedence: list
 Resent-Sender: pci-sig-request@znyx.com
 To: Mailing List Recipients <pci-sig-request@znyx.com>


------------------ RFC822 Header Follows ------------------
Received: by smtp2.space.honeywell.com  with SMTP;22 Aug 1996 09:04:09 -0400
Received: from american.megatrends.com by fl51mail.space.honeywell.com with
SMTP
	(1.38.193.5/16.2) id AA17839; Wed, 21 Aug 1996 21:12:02 -0400
Received: from cc:Mail (PU Serial #1665)
  by american.megatrends.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm))
  id AA-1996Aug21.210302.1665.35283; Wed, 21 Aug 1996 21:04:07 -0400
From: GANESANV@american.megatrends.com (GANESANV)
To: belvin_stephen_e.fl51-p11@smtp2.space.honeywell.com (Belvin Stephen E)
Cc: pci-sig@znyx.com (PCI Reflector)
Message-Id: <1996Aug21.210302.1665.35283@american.megatrends.com>
X-Conversion-Id: <cc:Mail/#333514/AMI-ATL>
X-Mailer: cc:Mail via PostalUnion/SMTP for Windows NT
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Date: Wed, 21 Aug 1996 21:04:07 -0400
Subject: Re[2]: PCI I/O Space Consumption Limitation
f
�}