Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 18 10月, 2005 1 次提交
  3. 10 9月, 2005 1 次提交
  5. 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
  7. 05 9月, 2005 1 次提交
  9. 17 8月, 2005 1 次提交
  11. 09 8月, 2005 1 次提交
  13. 30 7月, 2005 1 次提交
  15. 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
  19. 08 6月, 2005 1 次提交
  21. 27 5月, 2005 2 次提交
  23. 04 5月, 2005 2 次提交
  25. 17 4月, 2005 2 次提交