Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 29 6月, 2007 2 次提交
  3. 28 6月, 2007 1 次提交
  5. 14 6月, 2007 1 次提交
    • B
      [POWERPC] Rewrite IO allocation & mapping on powerpc64 · 3d5134ee
      由 Benjamin Herrenschmidt 提交于 
      This rewrites pretty much from scratch the handling of MMIO and PIO
space allocations on powerpc64.  The main goals are:

 - Get rid of imalloc and use more common code where possible
 - Simplify the current mess so that PIO space is allocated and
   mapped in a single place for PCI bridges
 - Handle allocation constraints of PIO for all bridges including
   hot plugged ones within the 2GB space reserved for IO ports,
   so that devices on hotplugged busses will now work with drivers
   that assume IO ports fit in an int.
 - Cleanup and separate tracking of the ISA space in the reserved
   low 64K of IO space. No ISA -> Nothing mapped there.

I booted a cell blade with IDE on PIO and MMIO and a dual G5 so
far, that's it :-)

With this patch, all allocations are done using the code in
mm/vmalloc.c, though we use the low level __get_vm_area with
explicit start/stop constraints in order to manage separate
areas for vmalloc/vmap, ioremap, and PCI IOs.

This greatly simplifies a lot of things, as you can see in the
diffstat of that patch :-)

A new pair of functions pcibios_map/unmap_io_space() now replace
all of the previous code that used to manipulate PCI IOs space.
The allocation is done at mapping time, which is now called from
scan_phb's, just before the devices are probed (instead of after,
which is by itself a bug fix). The only other caller is the PCI
hotplug code for hot adding PCI-PCI bridges (slots).

imalloc is gone, as is the "sub-allocation" thing, but I do beleive
that hotplug should still work in the sense that the space allocation
is always done by the PHB, but if you unmap a child bus of this PHB
(which seems to be possible), then the code should properly tear
down all the HPTE mappings for that area of the PHB allocated IO space.

I now always reserve the first 64K of IO space for the bridge with
the ISA bus on it. I have moved the code for tracking ISA in a separate
file which should also make it smarter if we ever are capable of
hot unplugging or re-plugging an ISA bridge.

This should have a side effect on platforms like powermac where VGA IOs
will no longer work. This is done on purpose though as they would have
worked semi-randomly before. The idea at this point is to isolate drivers
that might need to access those and fix them by providing a proper
function to obtain an offset to the legacy IOs of a given bus.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3d5134ee
  7. 17 5月, 2007 1 次提交
  9. 10 5月, 2007 1 次提交
    • P
      [POWERPC] Fix incorrect calculation of I/O window addresses · 31e92e0a
      由 Paul Mackerras 提交于 
      My patch "Cope with PCI host bridge I/O window not starting at 0"
introduced a bug in the calculation of the virtual addresses for the
I/O windows of PCI host bridges other than the first, because it
didn't account for the fact that hose->io_resource gets offset so that
it reflects the range of global I/O port numbers assigned to the
bridge.  This fixes it and simplifies get_bus_io_range() in the
process.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      31e92e0a
  11. 08 5月, 2007 1 次提交
    • P
      [POWERPC] Cope with PCI host bridge I/O window not starting at 0 · 11fbb00c
      由 Paul Mackerras 提交于 
      Currently our code to set up the data structures for a PCI host bridge
and create the mapping for its I/O window assumes that the window
starts at I/O port 0 on the PCI side.  If this is not true, we can end
up with I/O port numbers in the resources for PCI devices which will
cause an oops if a driver tries to access them via inb/outb etc.,
because there is no mapping for the corresponding addresses.

Normally the I/O window starts at 0, but there are some situations on
partitioned machines with a hypervisor where the window may not start
at 0.

This fixes the problem by allocating space for the range from 0 to the
end of the I/O window.  That is, hose->io_base_virt contains the
virtual address for I/O port 0 on the PCI bus, and thus the assumption
that hose->io_base_virt - pci_io_base is the offset between the
"global" I/O port numbers (those in the PCI device resources) and the
I/O port numbers on the PCI bus is maintained.

For PCI host bridges that are present at boot, we only map the portion
of that range that correspond to the bridge's I/O window.  For bridges
added after boot we ioremap the range from 0 to the end of the I/O
window, for now; in fact hot-added bridges should be using
reserve_phb_iospace() and __ioremap_explicit (so they get sensible
global port numbers), but we don't have the infrastructure yet to do
that (basically a free_phb_iospace() routine plus appropriate
locking).

Interestingly, this makes the two arms of the if statement in
get_bus_io_range do almost exactly the same thing; that function could
now be simplified in a further patch.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      11fbb00c
  13. 03 5月, 2007 1 次提交
  15. 13 4月, 2007 2 次提交
  17. 09 3月, 2007 2 次提交
  19. 08 2月, 2007 1 次提交
  21. 28 1月, 2007 1 次提交
  23. 24 1月, 2007 1 次提交
  25. 20 12月, 2006 1 次提交
  27. 08 12月, 2006 1 次提交
    • B
      [POWERPC] Fix mmap of PCI resource with hack for X · 396a1a58
      由 Benjamin Herrenschmidt 提交于 
      The powerpc version of pci_resource_to_user() and associated hooks
used by /proc/bus/pci and /sys/bus/pci mmap have been broken for some
time on machines that don't have a 1:1 mapping of devices (basically
on non-PowerMacs) and have PCI devices above 32 bits.

This attempts to fix it as well as possible.

The rule is supposed to be that pci_resource_to_user() always converts
the resources back into a BAR values since that's what the /proc
interface was supposed to deal with. However, for X to work on
platforms where PCI MMIO is not mapped 1:1, it became a habit of
platforms like powerpc to pass "fixed up" values there since X expects
to be able to use values from /proc/bus/pci/devices as offsets to mmap
of /dev/mem...

So we keep that contraption here, causing also /sys/*/resource to
expose fully absolute MMIO addresses instead of BAR values, which is
ugly, but should still work as long as those are only used to calculate
alignment within a page.

X is still broken when built 32 bits on machines where PCI MMIO can be
above 32-bit space unfortunately.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      396a1a58
  29. 04 12月, 2006 7 次提交
    • Y
      [POWERPC] Replace kmalloc+memset with kzalloc · f8485350
      由 Yan Burman 提交于 
      Replace kmalloc+memset with kzalloc.
Signed-off-by: NYan Burman <burman.yan@gmail.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f8485350
    • B
      [POWERPC] Allow hooking of PCI MMIO & PIO accessors on 64 bits · 4cb3cee0
      由 Benjamin Herrenschmidt 提交于 
      This patch reworks the way iSeries hooks on PCI IO operations (both MMIO
and PIO) and provides a generic way for other platforms to do so (we
have need to do that for various other platforms).

While reworking the IO ops, I ended up doing some spring cleaning in
io.h and eeh.h which I might want to split into 2 or 3 patches (among
others, eeh.h had a lot of useless stuff in it).

A side effect is that EEH for PIO should work now (it used to pass IO
ports down to the eeh address check functions which is bogus).

Also, new are MMIO "repeat" ops, which other archs like ARM already had,
and that we have too now: readsb, readsw, readsl, writesb, writesw,
writesl.

In the long run, I might also make EEH use the hooks instead
of wrapping at the toplevel, which would make things even cleaner and
relegate EEH completely in platforms/iseries, but we have to measure the
performance impact there (though it's really only on MMIO reads)

Since I also need to hook on ioremap, I shuffled the functions a bit
there. I introduced ioremap_flags() to use by drivers who want to pass
explicit flags to ioremap (and it can be hooked). The old __ioremap() is
still there as a low level and cannot be hooked, thus drivers who use it
should migrate unless they know they want the low level version.

The patch "arch provides generic iomap missing accessors" (should be
number 4 in this series) is a pre-requisite to provide full iomap
API support with this patch.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4cb3cee0
    • B
      [POWERPC] Generic OF platform driver for PCI host bridges. · 4c9d2800
      由 Benjamin Herrenschmidt 提交于 
      When enabled in Kconfig, it will pick up any of_platform_device
matching it's match list (currently type "pci", "pcix", "pcie",
or "ht" and setup a PHB for it.

Platform must provide a ppc_md.pci_setup_phb() for it to work
(for doing the necessary initialisations specific to a given PHB
like setting up the config space ops).

It's currently only available on 64 bits as the 32 bits PCI code
can't quite cope with it in it's current form. I will fix that
later.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4c9d2800
    • B
      [POWERPC] Add "parent" struct device for PCI host bridges · 803d4573
      由 Benjamin Herrenschmidt 提交于 
      Add a "parent" struct device to our PCI host bridge data structure so that
PCI can be rooted off another device in sysfs.

Note that arch/ppc doesn't use it, only arch/powerpc, though it's available
for both 32 and 64 bits.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      803d4573
    • B
      [POWERPC] Resolve the parent address of a PCI bus range · e557a1c9
      由 Benjamin Herrenschmidt 提交于 
      When parsing the OF "ranges" properties of PCI host busses to determine
the mapping of a PCI bus, we need to translate the "parent" address using
the prom_parse.c routines in order to obtain a CPU physical address.

This wasn't necessary while PCI busses were always at the root of the
device-tree but this is no longer the case on Cell where they can be
anywhere in the tree.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      e557a1c9
    • B
      [POWERPC] Refactor 64 bits DMA operations · 12d04eef
      由 Benjamin Herrenschmidt 提交于 
      This patch completely refactors DMA operations for 64 bits powerpc. 32 bits
is untouched for now.

We use the new dev_archdata structure to add the dma operations pointer
and associated data to struct device. While at it, we also add the OF node
pointer and numa node. In the future, we might want to look into merging
that with pci_dn as well.

The old vio, pci-iommu and pci-direct DMA ops are gone. They are now replaced
by a set of generic iommu and direct DMA ops (non PCI specific) that can be
used by bus types. The toplevel implementation is now inline.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      12d04eef
    • B
      [POWERPC] Make pci_read_irq_line the default · f90bb153
      由 Benjamin Herrenschmidt 提交于 
      This patch reworks the way IRQs are fixed up on PCI for arch powerpc.

It makes pci_read_irq_line() called by default in the PCI code for
devices that are probed, and add an optional per-device fixup in
ppc_md for platforms that really need to correct what they obtain
from pci_read_irq_line().

It also removes ppc_md.irq_bus_setup which was only used by pSeries
and should not be needed anymore.

I've also removed the pSeries s7a workaround as it can't work with
the current interrupt code anyway. I'm trying to get one of these
machines working so I can test a proper fix for that problem.

I also haven't updated the old-style fixup code from 85xx_cds.c
because it's actually buggy :) It assigns pci_dev->irq hard coded
numbers which is no good with the new IRQ mapping code. It should
at least use irq_create_mapping(NULL, hard_coded_number); and possibly
also set_irq_type() to set them as level low.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      f90bb153
  31. 13 11月, 2006 1 次提交
  33. 16 10月, 2006 1 次提交
  35. 25 9月, 2006 1 次提交
  37. 30 8月, 2006 1 次提交
  39. 31 7月, 2006 1 次提交
  41. 11 7月, 2006 1 次提交
    • B
      [PATCH] powerpc: fix trigger handling in the new irq code · 6e99e458
      由 Benjamin Herrenschmidt 提交于 
      This patch slightly reworks the new irq code to fix a small design error.  I
removed the passing of the trigger to the map() calls entirely, it was not a
good idea to have one call do two different things.  It also fixes a couple of
corner cases.

Mapping a linux virtual irq to a physical irq now does only that.  Setting the
trigger is a different action which has a different call.

The main changes are:

- I no longer call host->ops->map() for an already mapped irq, I just return
  the virtual number that was already mapped.  It was called before to give an
  opportunity to change the trigger, but that was causing issues as that could
  happen while the interrupt was in use by a device, and because of the
  trigger change, map would potentially muck around with things in a racy way.
   That was causing much burden on a given's controller implementation of
  map() to get it right.  This is much simpler now.  map() is only called on
  the initial mapping of an irq, meaning that you know that this irq is _not_
  being used.  You can initialize the hardware if you want (though you don't
  have to).

- Controllers that can handle different type of triggers (level/edge/etc...)
  now implement the standard irq_chip->set_type() call as defined by the
  generic code.  That means that you can use the standard set_irq_type() to
  configure an irq line manually if you wish or (though I don't like that
  interface), pass explicit trigger flags to request_irq() as defined by the
  generic kernel interfaces.  Also, using those interfaces guarantees that
  your controller set_type callback is called with the descriptor lock held,
  thus providing locking against activity on the same interrupt (including
  mask/unmask/etc...) automatically.  A result is that, for example, MPIC's
  own map() implementation calls irq_set_type(NONE) to configure the hardware
  to the default triggers.

- To allow the above, the irq_map array entry for the new mapped interrupt
  is now set before map() callback is called for the controller.

- The irq_create_of_mapping() (also used by irq_of_parse_and_map()) function
  for mapping interrupts from the device-tree now also call the separate
  set_irq_type(), and only does so if there is a change in the trigger type.

- While I was at it, I changed pci_read_irq_line() (which is the helper I
  would expect most archs to use in their pcibios_fixup() to get the PCI
  interrupt routing from the device tree) to also handle a fallback when the
  DT mapping fails consisting of reading the PCI_INTERRUPT_PIN to know wether
  the device has an interrupt at all, and the the PCI_INTERRUPT_LINE to get an
  interrupt number from the device.  That number is then mapped using the
  default controller, and the trigger is set to level low.  That default
  behaviour works for several platforms that don't have a proper interrupt
  tree like Pegasos.  If it doesn't work for your platform, then either
  provide a proper interrupt tree from the firmware so that fallback isn't
  needed, or don't call pci_read_irq_line()

- Add back a bit that got dropped by my main rework patch for properly
  clearing pending IPIs on pSeries when using a kexec
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      6e99e458
  43. 07 7月, 2006 1 次提交
  45. 03 7月, 2006 1 次提交
    • B
      [POWERPC] Add new interrupt mapping core and change platforms to use it · 0ebfff14
      由 Benjamin Herrenschmidt 提交于 
      This adds the new irq remapper core and removes the old one.  Because
there are some fundamental conflicts with the old code, like the value
of NO_IRQ which I'm now setting to 0 (as per discussions with Linus),
etc..., this commit also changes the relevant platform and driver code
over to use the new remapper (so as not to cause difficulties later
in bisecting).

This patch removes the old pre-parsing of the open firmware interrupt
tree along with all the bogus assumptions it made to try to renumber
interrupts according to the platform. This is all to be handled by the
new code now.

For the pSeries XICS interrupt controller, a single remapper host is
created for the whole machine regardless of how many interrupt
presentation and source controllers are found, and it's set to match
any device node that isn't a 8259.  That works fine on pSeries and
avoids having to deal with some of the complexities of split source
controllers vs. presentation controllers in the pSeries device trees.

The powerpc i8259 PIC driver now always requests the legacy interrupt
range. It also has the feature of being able to match any device node
(including NULL) if passed no device node as an input. That will help
porting over platforms with broken device-trees like Pegasos who don't
have a proper interrupt tree.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0ebfff14
  47. 01 7月, 2006 1 次提交
  49. 28 6月, 2006 1 次提交
  51. 26 6月, 2006 1 次提交
  53. 15 6月, 2006 2 次提交
  55. 24 5月, 2006 1 次提交
  57. 22 4月, 2006 2 次提交