RE: Disabling a BAR

["Kimmery, Clifford (FL51)" <kimmery@space.honeywell.com>]

>----------
>From: 	goudreau@dg-rtp.dg.com[SMTP:goudreau@dg-rtp.dg.com]
>Sent: 	Monday, October 21, 1996 3:37 PM
>To: 	Mailing List Recipients
>Subject: 	Re: Disabling a BAR
>
>> This question is really about the way the note on page 26 is worded. 
>> For 
>> reference: 'Note: A Base Address register does not contain a valid
>> address 
>> when it is equal to "0".'
>> 
>> A literal interpretation would conclude that the entire BAR (not just
>> the 
>> address field) would have to be set to zero to not contain a valid
>> address.  
>
>Or perhaps the note was just poorly worded.  Interpreting the "it"
>to apply to the "address" instead of to the "register" will yield the
>meaning that I think everyone believes was intended.  If that is
>truly the case, the note would be better worded if it said that a
>BAR whose address portion is zero does not contain a valid address.
>
>> That doesn't really make sense since the discussion in section 6.2.5.1 
>> (page 196) talks about hardwiring the LS bits.  However, it is possible 
>> to design a BAR that only sets the LS bits if there is a one somewhere 
>> in the address field.
>> 
>> My interpretation is that a BAR is 'unimplemented' if you write all ones
>> 
>> and read back all zeros.  Anything else is a implemented BAR.  Bit 2 
>> handles the case of a 64 bit BAR with all other bits in the lower DWORD 
>> hardwired to zero.  Some may quibble that reading back all zeros 
>> indicates a 4Gig BAR, but I disagree since no practical system could 
>> use such a device.
>
>Count me as someone who disagrees :-).  It may be an impractical
>quibble now, but who knows what the 64-bit PCI future may hold?
>Several years hence, I could certainly envision a specialized video
>device with a huge honkin' frame buffer.  In any case, I think your
>objection fails for another reason: the spec defines a 64-bit BAR as
>a single register in its own right, not as a concatenation of two
>32-bit BARs.  So, a 64-bit BAR could only be said to have a
>zero-valued address if *all* its address bits (including those in
>the second dword) are set to zero.
>
<I am not sure we disagree.  What I attempted to say was that
you cannot confuse an unimplemented 32 bit BAR (based on my
definition) with the lower half of a 64 bit BAR, but that you could
confuse it with a 32 bit BAR requesting the entire 4Gig space of a 
32 bit PCI implementation.  A single PCI device requesting all of 
the 32 bit PCI address space is a trivial case that makes no sense.  
The only conceivable advantage would be to force allocation to the 
low 4Gig in a 64 bit PCI system and that is such a special case as 
to be unlikely.

This is all moot unless configuration software treats a BAR hard-
wired to all-zeros as requesting a 4Gig address space and from 
>what I have seen in the archive discussions, that is not the case.>
>
>> Given that an implemented BAR will read back some ones, my only 
>> possible interpretation for the note on page 26 is that a zero in the 
>> address field is a special case to provide a mechanism for individually 
>> disabling BARs.
>
>Back when this subject was first discussed a number of months ago,
>the focus was on identifying unimplemented registers in the 24-byte
>BAR range of Type 0 Configuration Space.  I believe that the note
>was an attempt to cover this case.  It certainly could use some
>clarification.
>
<I have been informed that the typical configuration software will write

a zero to any BAR that cannot be allocated address space and will 
disable (via the command register) any set of BARs that contain a 
BAR with a zero address.  The OS or device driver is then allowed 
to decide if the device is usable with limited resources.  It must 
disable the unallocated BARs using some device specific method 
before enabling the device.

It appears from this information that the answer to the fundamental 
question 'Is it PCI compliant for a device to assert DEVSEL if the 
>addressed BAR contains zero in the address field?' is yes.>
>
>----------------------------------------------------------------------
>Bob Goudreau			Data General Corporation
>goudreau@dg-rtp.dg.com		62 Alexander Drive	
>+1 919 248 6231			Research Triangle Park, NC  27709, USA
>
<Thanks to everyone that participated in this discussion.  I think 
the consensus is that the note on page 26 does not impose a 
requirement that a zero in the address field of a BAR cause the 
BAR to be disabled by hardware independently of the command 
register.  It is not as clear that it allows configuration software to 
allocate the low 16 bytes of memory space (4 bytes of IO space) 
>to a device.>

Cliff Kimmery
Honeywell Inc.
kimmery@space.honeywell.com
>
 TA