svn commit: r235007 - stable/9/sys/dev/pci

[Warner Losh]

On May 4, 2012, at 1:41 PM, Hans Petter Selasky wrote:

> On Friday 04 May 2012 19:18:56 Warner Losh wrote:
>> On May 4, 2012, at 10:26 AM, Hans Petter Selasky wrote:
>>> On Friday 04 May 2012 18:14:16 John Baldwin wrote:
>>>> On Friday, May 04, 2012 11:38:47 am Hans Petter Selasky wrote:
>>>>> Author: hselasky
>>>>> Date: Fri May  4 15:38:47 2012
>>>>> New Revision: 235007
>>>>> URL: http://svn.freebsd.org/changeset/base/235007
>>>>> 
>>>>> Log:
>>>>> MFC r233662, r233677 and r233678:
>>>>> 
>>>>> Writing zero to BAR actually does not disable it and
>>>>> it is even harmful as hselasky found out.  Historically,
>>>>> this code was originated from (OLDCARD) CardBus driver and later
>>>>> leaked into PCI driver when CardBus was newbus'ified and refactored
>>>>> with PCI driver. However, it is not really necessary even for
>>>>> CardBus.
>>>> 
>>>> FYI, I've got one bug report on HEAD where these changes broke a
>>>> machine's ATA controller.
>>> 
>>> Have you considered adding code to disable the I/O or memory range
>>> instead of writing 0 to the bar in this case?
>> 
>> I tried that once upon a time, but was problematical with some bridges that
>> had BARs at non-standard locations that needed the I/O or MEM bit set in
>> order to work...
>> 
>> Warner
> 
> If the size of the bar is a few megabytes, then moving it to location 0 is 
> definitely wrong. Else it might work!

Only if the bridge passes the transactions for that memory to the PCI bus for decoding.  The reason it worked for as long as it did was that we had bridges that passed the memory cycles to DRAM for addresses near 0 and they didn't make it onto the PCI bus.  Except in embedded systems, I fail to see how that could have changed in the interim.  The physical layout of x86 has actual memory at location 0 and it would be a big performance hit to push those transactions onto the pci bus, so nobody in their right mind would do that.

Warner

Warner