1. 21 12月, 2006 1 次提交
    • R
      PCI legacy resource fix · fb0f2b40
      Ralf Baechle 提交于
      Since commit 368c73d4 the kernel will try
      to update the non-writeable BAR registers 0..3 of PIIX4 IDE adapters if
      pci_assign_unassigned_resources() is used to do full resource assignment of
      the bus.  This fails because in the PIIX4 these BAR registers have
      implicitly assumed values and read back as zero; it used to work because
      the kernel used to just write zero to that register the read back value did
      match what was written.
      
      The fix is a new resource flag IORESOURCE_PCI_FIXED used to mark a resource
      as non-movable.  This will also be useful to keep other import system
      resources from being moved around - for example system consoles on PCI
      busses.
      
      [akpm@osdl.org: cleanup]
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      fb0f2b40
  2. 28 6月, 2006 2 次提交
  3. 22 6月, 2006 1 次提交
    • K
      [PATCH] PCI: Add pci_assign_resource_fixed -- allow fixed address assignments · 75acfeca
      Kumar Gala 提交于
      PCI: Add pci_assign_resource_fixed -- allow fixed address assignments
      
      On some embedded systems the PCI address for hotplug devices are not only
      known a priori but are required to be at a given PCI address for other
      master in the system to be able to access.
      
      An example of such a system would be an FPGA which is setup from user space
      after the system has booted.  The FPGA may be access by DSPs in the system
      and those DSPs expect the FPGA at a fixed PCI address.
      
      Added pci_assign_resource_fixed() as a way to allow assignment of the PCI
      devices's BARs at fixed PCI addresses.
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      75acfeca
  4. 01 2月, 2006 1 次提交
  5. 09 9月, 2005 2 次提交
    • D
      [PATCH] Make sparc64 use setup-res.c · 085ae41f
      David S. Miller 提交于
      There were three changes necessary in order to allow
      sparc64 to use setup-res.c:
      
      1) Sparc64 roots the PCI I/O and MEM address space using
         parent resources contained in the PCI controller structure.
         I'm actually surprised no other platforms do this, especially
         ones like Alpha and PPC{,64}.  These resources get linked into the
         iomem/ioport tree when PCI controllers are probed.
      
         So the hierarchy looks like this:
      
         iomem --|
      	   PCI controller 1 MEM space --|
      				        device 1
      					device 2
      					etc.
      	   PCI controller 2 MEM space --|
      				        ...
         ioport --|
                  PCI controller 1 IO space --|
      					...
                  PCI controller 2 IO space --|
      					...
      
         You get the idea.  The drivers/pci/setup-res.c code allocates
         using plain iomem_space and ioport_space as the root, so that
         wouldn't work with the above setup.
      
         So I added a pcibios_select_root() that is used to handle this.
         It uses the PCI controller struct's io_space and mem_space on
         sparc64, and io{port,mem}_resource on every other platform to
         keep current behavior.
      
      2) quirk_io_region() is buggy.  It takes in raw BUS view addresses
         and tries to use them as a PCI resource.
      
         pci_claim_resource() expects the resource to be fully formed when
         it gets called.  The sparc64 implementation would do the translation
         but that's absolutely wrong, because if the same resource gets
         released then re-claimed we'll adjust things twice.
      
         So I fixed up quirk_io_region() to do the proper pcibios_bus_to_resource()
         conversion before passing it on to pci_claim_resource().
      
      3) I was mistakedly __init'ing the function methods the PCI controller
         drivers provide on sparc64 to implement some parts of these
         routines.  This was, of course, easy to fix.
      
      So we end up with the following, and that nasty SPARC64 makefile
      ifdef in drivers/pci/Makefile is finally zapped.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      085ae41f
    • J
      [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it · 064b53db
      John W. Linville 提交于
      Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
      (including BARs) when transitioning from D3hot->D0.  This leaves such
      a device in an inaccessible state.  The patch below causes the BARs
      to be restored when enabling such a device, so that its driver will
      be able to access it.
      
      The patch also adds pci_restore_bars as a new global symbol, and adds a
      correpsonding EXPORT_SYMBOL_GPL for that.
      
      Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
      (re)boot.  Most drivers call pci_enable_device very early, so devices
      left in D3hot that lose configuration during the D3hot->D0 transition
      will be inaccessible to their drivers.
      
      Drivers could be modified to account for this, but it would
      be difficult to know which drivers need modification.  This is
      especially true since often many devices are covered by the same
      driver.  It likely would be necessary to replicate code across dozens
      of drivers.
      
      The patch below should trigger only when transitioning from D3hot->D0
      (or at boot), and only for devices that have the "no soft reset" bit
      cleared in the PM control register.  I believe it is safe to include
      this patch as part of the PCI infrastructure.
      
      The cleanest implementation of pci_restore_bars was to call
      pci_update_resource.  Unfortunately, that does not currently exist
      for the sparc64 architecture.  The patch below includes a null
      implemenation of pci_update_resource for sparc64.
      
      Some have expressed interest in making general use of the the
      pci_restore_bars function, so that has been exported to GPL licensed
      modules.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      064b53db
  6. 27 8月, 2005 1 次提交
    • L
      Ignore disabled ROM resources at setup · 755528c8
      Linus Torvalds 提交于
      Writing even a disabled value seems to mess up some matrox graphics
      cards.  It may be a card-related issue, but we may also be writing
      reserved low bits in the result.
      
      This was a fall-out of switching x86 over to the generic PCI resource
      allocation code, and needs more debugging.  In particular, the old x86
      code defaulted to not doing any resource allocations at all for ROM
      resources.
      
      In the meantime, this has been reported to make X happier by Helge
      Hafting <helgehaf@aitel.hist.no>.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      755528c8
  7. 09 8月, 2005 1 次提交
  8. 08 8月, 2005 1 次提交
    • I
      [PATCH] Fix restore of 64-bit PCI BAR's · cf7bee5a
      Ivan Kokshaysky 提交于
      For 64-bit BAR[i] only pci_dev->resource[i] is valid, ->resource[i+1]
      slot is unused and contains zeroes in all fields.
      
      So when we update a PCI BAR, all we need is just to check that we're
      going to update a _valid_ resource.
      
      Also make sure to write high bits - use "x >> 16 >> 16" (rather than the
      simpler ">> 32") to avoid warnings on 32-bit architectures where we're
      not going to have any high bits.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cf7bee5a
  9. 05 8月, 2005 1 次提交
    • J
      [PATCH] PCI: restore BAR values after D3hot->D0 for devices that need it · fec59a71
      John W. Linville 提交于
      Some PCI devices (e.g. 3c905B, 3c556B) lose all configuration
      (including BARs) when transitioning from D3hot->D0.  This leaves such
      a device in an inaccessible state.  The patch below causes the BARs
      to be restored when enabling such a device, so that its driver will
      be able to access it.
      
      The patch also adds pci_restore_bars as a new global symbol, and adds a
      correpsonding EXPORT_SYMBOL_GPL for that.
      
      Some firmware (e.g. Thinkpad T21) leaves devices in D3hot after a
      (re)boot.  Most drivers call pci_enable_device very early, so devices
      left in D3hot that lose configuration during the D3hot->D0 transition
      will be inaccessible to their drivers.
      
      Drivers could be modified to account for this, but it would
      be difficult to know which drivers need modification.  This is
      especially true since often many devices are covered by the same
      driver.  It likely would be necessary to replicate code across dozens
      of drivers.
      
      The patch below should trigger only when transitioning from D3hot->D0
      (or at boot), and only for devices that have the "no soft reset" bit
      cleared in the PM control register.  I believe it is safe to include
      this patch as part of the PCI infrastructure.
      
      The cleanest implementation of pci_restore_bars was to call
      pci_update_resource.  Unfortunately, that does not currently exist
      for the sparc64 architecture.  The patch below includes a null
      implemenation of pci_update_resource for sparc64.
      
      Some have expressed interest in making general use of the the
      pci_restore_bars function, so that has been exported to GPL licensed
      modules.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fec59a71
  10. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4