1. 24 3月, 2006 1 次提交
  2. 18 1月, 2006 1 次提交
  3. 10 1月, 2006 1 次提交
    • D
      [PATCH] PCI Quirk: 1K I/O space granularity on Intel P64H2 · 9d265124
      Daniel Yeisley 提交于
      I've implemented a quirk to take advantage of the 1KB I/O space
      granularity option on the Intel P64H2 PCI Bridge.  I had to change
      probe.c because it sets the resource start and end to be aligned on 4k
      boundaries (after the quirk sets them to 1k boundaries).  I've tested
      this patch on a Unisys ES7000-600 both with and without the 1KB option
      enabled.  I also tested this on a 2 processor Dell box that doesn't have
      a P64H2 to make sure there were no negative affects there.
      Signed-off-by: NDan Yeisley <dan.yeisley@unisys.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      9d265124
  4. 13 12月, 2005 1 次提交
    • J
      [PATCH] add boot option to control Intel SATA/PATA combined mode · 2bd0fa3b
      Jesse Barnes 提交于
      Combined mode sucks.  Especially when both libata and the legacy IDE
      drivers try to drive ports on the same device, since that makes DMA
      rather difficult.
      
      This patch addresses the problem by allowing the user to control which
      driver binds to the ports in a combined mode configuration.  In many
      cases, they'll probably want the libata driver to control both ports
      since it can use DMA for talking with ATAPI devices (when
      libata.atapi_enabled=1 of course).  It also allows the user to get old
      school behavior by letting the legacy IDE driver bind to both ports.
      But neither is forced, the patch doesn't change current behavior unless
      one of combined_mode=ide or combined_mode=libata is passed
      on the boot line.  Either of those options may require you to access
      your devices via different device nodes (/dev/hd* in the ide case
      and /dev/sd* in the libata case), though of course if you have udev
      installed nicely you may not notice anything.  :)
      
      Let me know if the documentation is too cryptic, I'd be happy to expand
      on it if necessary.  I think most users will want to boot with
      'combined_mode=libata' and add 'options libata atapi_enabled=1'
      to their modules.conf to get good DVD playing and disk behavior
      (haven't tested CD or DVD writing though).
      
      I'd much rather things behave sanely by default (i.e. DMA for devices on
      both ports), but apparently that's difficult given the various chip
      bugs and hardware configs out there (not to mention that people's
      drives may suddenly change from /dev/hdc to /dev/sdb), so this boot
      option may be the correct long term fix.
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      Signed-off-by: NJeff Garzik <jgarzik@pobox.com>
      2bd0fa3b
  5. 11 11月, 2005 2 次提交
  6. 31 10月, 2005 1 次提交
  7. 29 10月, 2005 4 次提交
  8. 26 10月, 2005 1 次提交
  9. 18 10月, 2005 1 次提交
  10. 10 9月, 2005 1 次提交
  11. 09 9月, 2005 1 次提交
    • 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
  12. 05 9月, 2005 1 次提交
  13. 17 8月, 2005 1 次提交
  14. 09 8月, 2005 1 次提交
  15. 30 7月, 2005 1 次提交
  16. 02 7月, 2005 1 次提交
  17. 10 6月, 2005 1 次提交
    • N
      [PATCH] PCI: MSI functionality broken on Serverworks GC chipset · 1e062767
      Narendra Sankar 提交于
      MSI functionality is broken on the GC_LE x86 chipset that Serverworks
      developed and that is being used in various platforms today. Broadcom is
      going to push out to the kernel MSI enabled Gigabit drivers (in the very
      near future), and we would like to make sure that MSI does not get
      enabled on any platforms using the GC_LE chipset (device id 0x17).
      Following the AMD 8131 example, I am including a patch to disable MSI
      functionality when a GCNB_LE is detected. Please let me know if there
      are any issues with this. This is a permanent fix for this chipset, as
      the hardware will not be updated.
      Signed-off-by: NNarendra Sankar <nsankar@broadcom.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      1e062767
  18. 08 6月, 2005 1 次提交
  19. 27 5月, 2005 2 次提交
  20. 04 5月, 2005 2 次提交
  21. 17 4月, 2005 2 次提交