cvs commit: src/sys/bus/pci pci_pcib.c src/sys/bus/pci/i386 pcibus.c

[Sepherosa Ziehau <sephe@xxxxxxxxxxxxxxxxxxxxxxx>]

sephe       2007/06/08 06:52:09 PDT

DragonFly src repository

  Modified files:
    sys/bus/pci          pci_pcib.c 
    sys/bus/pci/i386     pcibus.c 
  Log:
  If PCI_MAP_FIXUP is defined, following fixes will be applied:
  - For PCI/PCI bridge, adjust requested IO port/memory's start/range according
    to bridge's base/limit register value.
  - For Host/PCI bridge, if requested IO port/memory's starts from 0 and range
    is ~0,
    o  If the request is for IO port, the start address is set to 0x1000.
    o  If the request is for IO memory, the start address is set to tunable
       hw.pci.host_mem_start, which is 0x80000000 by default.
  
  This unbreaks cardbus bridge support, if PCI_MAP_FIXUP is defined.
  
  My laptop's cardbus bridge is on the PCI bus mastered by a PCI/PCI bridge,
  while swildner@'s laptop's cardbus bridge is on the PCI bus mastered by
  Host/PCI bridge.
  
  Tested-by: swildner@ and me
  Obtained-from: FreeBSD (imp@freebsd.org)
  
  #
  # It seems BIOS does not set cardbus bridge's BAR for most of the system,
  # so in the original code, the resource_list_alloc() in pci_alloc_resource()
  # will return NULL for cardbus bridge's IO memory allocation request; cardbus
  # bridge's code actually depends on that to reallocate IO memory using
  # hw.cbb.start_memory as start address.
  #
  # Before this commit, if PCI_MAP_FIXUP is defined, cardbus bridge's invalid
  # IO memory request will be delivered to various PCI bridge code, which does
  # not validate/fixup the request and returns "successful" result bindly.
  #
  
  Revision  Changes    Path
  1.7       +6 -2      src/sys/bus/pci/pci_pcib.c
  1.19      +47 -0     src/sys/bus/pci/i386/pcibus.c


http://www.dragonflybsd.org/cvsweb/src/sys/bus/pci/pci_pcib.c.diff?r1=1.6&r2=1.7&f=u
http://www.dragonflybsd.org/cvsweb/src/sys/bus/pci/i386/pcibus.c.diff?r1=1.18&r2=1.19&f=u