Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 24 2月, 2012 3 次提交
    • B
      PCI: collapse pcibios_resource_to_bus · fb127cb9
      由 Bjorn Helgaas 提交于 
      Everybody uses the generic pcibios_resource_to_bus() supplied by the core
now, so remove the ARCH_HAS_GENERIC_PCI_OFFSETS used during conversion.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fb127cb9
    • B
      mips/PCI: get rid of device resource fixups · 96a6b9ad
      由 Bjorn Helgaas 提交于 
      Tell the PCI core about host bridge address translation so it can take
care of bus-to-resource conversion for us.

Here's the wrinkle on Cobalt: we can't generate normal I/O port addresses
on PCI because the GT-64111 doesn't do any address translation, so we have
this:

  CPU I/O port addresses		[io 0x0000-0xffffff]
  PCI bus I/O port addresses	[io 0x10000000-0x10ffffff]

Legacy-mode IDE controllers start out with the legacy bus addresses, e.g.,
0x1f0, assigned by pci_setup_device().  These are outside the range of
addresses GT-64111 can generate on PCI, but pcibios_fixup_device_resources()
converted them to CPU addresses anyway by adding io_offset.  Therefore, we
had to pre-adjust them in cobalt_legacy_ide_fixup().

With io_offset = 0xf0000000, we had this:

  res->start = 0x1f0	initialized in pci_setup_device()
  res->start = 0x100001f0	-= io_offset in cobalt_legacy_ide_fixup()
  res->start = 0x1f0	+= io_offset in pcibios_fixup_device_resources()

The difference after this patch is that the generic pci_bus_to_resource()
only adds the offset if the bus address is inside a host bridge window.
Since 0x1f0 is not a valid bus address and is not inside any windows, it is
unaffected, so we now have this:

  region->start = 0x1f0	initialized in pci_setup_device()
  res->start = 0x1f0	no offset by pci_bus_to_resource()

That means we can remove both pcibios_fixup_device_resources() and
cobalt_legacy_ide_fixup().

I would *rather* set the host bridge offset to zero (which corresponds
to what the GT-64111 actually does), and have both CPU and PCI addresses
of [io 0x10000000-0x10ffffff].  However, that would require changes to
generic code that assumes legacy I/O addresses, such as pic1_io_resource
([io 0x0020-0x00021]), and we'd have to keep a Cobalt IDE fixup.

Of course, none of this changes the fact that references to I/O port
0x1f0 actually go to port 0x100001f0, not 0x1f0, on the Cobalt PCI bus.
Fortunately the VT82C586 IDE controller only decodes the low 24 address
bits, so it does work.

CC: Ralf Baechle <ralf@linux-mips.org>
CC: Yoichi Yuasa <yuasa@linux-mips.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      96a6b9ad
    • B
      mips/PCI: replace pci_probe_only with pci_flags · 29090606
      由 Bjorn Helgaas 提交于 
      Some architectures (alpha, mips, powerpc) have an arch-specific
"pci_probe_only" flag.  Others use PCI_PROBE_ONLY in pci_flags for
the same purpose.  This moves mips to the pci_flags approach so
generic code can use the same test across all architectures.

CC: Ralf Baechle <ralf@linux-mips.org>
CC: linux-mips@linux-mips.org
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      29090606
  3. 05 8月, 2010 1 次提交
  5. 13 3月, 2010 2 次提交
  7. 10 9月, 2009 1 次提交
  9. 18 6月, 2009 1 次提交
  11. 10 12月, 2008 1 次提交
  13. 11 10月, 2008 1 次提交
  15. 31 7月, 2008 1 次提交
  17. 20 7月, 2008 1 次提交
  19. 16 7月, 2008 1 次提交
  21. 12 10月, 2007 1 次提交
  23. 12 7月, 2007 2 次提交
  25. 11 7月, 2007 1 次提交
  27. 19 2月, 2007 1 次提交
    • R
      [MIPS] Iomap implementation. · 140c1729
      由 Ralf Baechle 提交于 
      This implementation has support for the concept of one separate ioport
address space by PCI domain.  A pointer to the virtual address where
the port space of a domain has been mapped has been added to struct
pci_controller and systems should be fixed to fill in this value. For
single domain systems this will be the same value as passed to
set_io_port_base().
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      140c1729
  29. 11 12月, 2006 1 次提交
  31. 26 4月, 2006 1 次提交
  33. 30 10月, 2005 2 次提交
  35. 05 9月, 2005 3 次提交
  37. 12 7月, 2005 1 次提交
  39. 28 6月, 2005 2 次提交
    • A
      [PATCH] PCI: fix up errors after dma bursting patch and CONFIG_PCI=n · bb4a61b6
      由 Andrew Morton 提交于 
      With CONFIG_PCI=n:

In file included from include/linux/pci.h:917,
                 from lib/iomap.c:6:
include/asm/pci.h:104: warning: `enum pci_dma_burst_strategy' declared inside parameter list
include/asm/pci.h:104: warning: its scope is only this definition or declaration, which is probably not what you want.
include/asm/pci.h: In function `pci_dma_burst_advice':
include/asm/pci.h:106: dereferencing pointer to incomplete type
include/asm/pci.h:106: `PCI_DMA_BURST_INFINITY' undeclared (first use in this function)
include/asm/pci.h:106: (Each undeclared identifier is reported only once
include/asm/pci.h:106: for each function it appears in.)
make[1]: *** [lib/iomap.o] Error 1
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      bb4a61b6
    • D
      [PATCH] PCI: DMA bursting advice · e24c2d96
      由 David S. Miller 提交于 
      After seeing, at best, "guesses" as to the following kind
of information in several drivers, I decided that we really
need a way for platforms to specifically give advice in this
area for what works best with their PCI controller implementation.

Basically, this new interface gives DMA bursting advice on
PCI.  There are three forms of the advice:

1) Burst as much as possible, it is not necessary to end bursts
   on some particular boundary for best performance.

2) Burst on some byte count multiple.  A DMA burst to some multiple of
   number of bytes may be done, but it is important to end the burst
   on an exact multiple for best performance.

   The best example of this I am aware of are the PPC64 PCI
   controllers, where if you end a burst mid-cacheline then
   chip has to refetch the data and the IOMMU translations
   which hurts performance a lot.

3) Burst on a single byte count multiple.  Bursts shall end
   exactly on the next multiple boundary for best performance.

   Sparc64 and Alpha's PCI controllers operate this way.  They
   disconnect any device which tries to burst across a cacheline
   boundary.

   Actually, newer sparc64 PCI controllers do not have this behavior.
   That is why the "pdev" is passed into the interface, so I can
   add code later to check which PCI controller the system is using
   and give advice accordingly.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      e24c2d96
  41. 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