Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 09 3月, 2009 1 次提交
  3. 15 2月, 2009 1 次提交
  5. 07 2月, 2009 2 次提交
  7. 29 1月, 2009 2 次提交
  9. 13 1月, 2009 1 次提交
  11. 08 1月, 2009 2 次提交
    • T
      powerpc/fsl-pci: Set relaxed ordering on prefetchable ranges · 565f3764
      由 Trent Piepho 提交于 
      Provides a small speedup when accessing pefetchable ranges.  To indicate
that a memory range is prefetchable, mark it in the dts file with 42000000
instead of 02000000.

A powepc pci_controller is allowed three memory ranges, any of which may be
prefetchable.  However, the PCI-PCI bridge configuration space only has one
field for "non-prefetchable memory behind bridge", which has a 32 bit
address, and one field for "prefetchable memory behind bridge", which may
have a 64 bit address.  These are PCI bus addresses, not CPU physical
addresses.

So really you're only allowed one memory range of each type.  And if you
want the range at a PCI address above 32 bits you must make it
prefetchable.
Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      565f3764
    • T
      powerpc/fsl-pci: Better ATMU setup for 85xx/86xx · a097a78c
      由 Trent Piepho 提交于 
      The code that sets up the outbound ATMU windows, which is used to map CPU
physical addresses into PCI bus addresses where BARs will be mapped, didn't
work so well.

For one, it leaked the ioremap() of the ATMU registers.  Another small bug
was the high 20 bits of the PCI bus address were left as zero.  It's legal
for prefetchable memory regions to be above 32 bits, so the high 20 bits
might not be zero.

Mainly, it couldn't handle ranges that were not a power of two in size or
were not naturally aligned.  The ATMU windows have these requirements (size
& alignment), but the code didn't bother to check if the ranges it was
programming met them.  If they didn't, the windows would silently be
programmed incorrectly.

This new code can handle ranges which are not power of two sized nor
naturally aligned.  It simply splits the ranges into multiple valid ATMU
windows.  As there are only four windows, pooly aligned or sized ranges
(which didn't even work before) may run out of windows.  In this case an
error is printed and an effort is made to disable the unmapped resources.

An improvement that could be made would be to make use of the default
outbound window.  Iff hose->pci_mem_offset is zero, then it's possible that
some or all of the ranges might not need an outbound window and could just
use the default window.

The default ATMU window can support a pci_mem_offset less than zero too,
but pci_mem_offset is unsigned.  One could say the abilities allowed a
powerpc pci_controller is neither subset nor a superset of the abilities of
a Freescale PCIe controller.  Thankfully, the most useful bits are in the
intersection of the two abilities.
Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      a097a78c
  13. 31 12月, 2008 5 次提交
  15. 21 12月, 2008 6 次提交
  17. 17 12月, 2008 1 次提交
  19. 16 12月, 2008 1 次提交
  21. 13 12月, 2008 1 次提交
  23. 04 12月, 2008 2 次提交
  25. 03 12月, 2008 1 次提交
  27. 01 12月, 2008 1 次提交
    • A
      powerpc/mpic: Don't reset affinity for secondary MPIC on boot · cc353c30
      由 Arnd Bergmann 提交于 
      Kexec/kdump currently fails on the IBM QS2x blades when the kexec happens
on a CPU other than the initial boot CPU.  It turns out that this is the
result of mpic_init trying to set affinity of each interrupt vector to the
current boot CPU.

As far as I can tell,  the same problem is likely to exist on any
secondary MPIC, because they have to deliver interrupts to the first
output all the time. There are two potential solutions for this: either
not set up affinity at all for secondary MPICs, or assume that a single
CPU output is connected to the upstream interrupt controller and hardcode
affinity to that per architecture.

This patch implements the second approach, defaulting to the first output.
Currently, all known secondary MPICs are routed to their upstream port
using the first destination, so we hardcode that.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cc353c30
  29. 19 11月, 2008 1 次提交
  31. 15 11月, 2008 1 次提交
  33. 14 11月, 2008 1 次提交
  35. 31 10月, 2008 2 次提交
    • K
      powerpc/mpic: Fix regression caused by change of default IRQ affinity · 3c10c9c4
      由 Kumar Gala 提交于 
      The Freescale implementation of MPIC only allows a single CPU destination
for non-IPI interrupts.  We add a flag to the mpic_init to distinquish
these variants of MPIC.  We pull in the irq_choose_cpu from sparc64 to
select a single CPU as the destination of the interrupt.

This is to deal with the fact that the default smp affinity was
changed by commit 18404756 ("genirq:
Expose default irq affinity mask (take 3)") to be all CPUs.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NPaul Mackerras <paulus@samba.org>
      3c10c9c4
    • T
      gianfar: Fix race in TBI/SerDes configuration · c132419e
      由 Trent Piepho 提交于 
      The init_phy() function attaches to the PHY, then configures the
SerDes<->TBI link (in SGMII mode).  The TBI is on the MDIO bus with the PHY
(sort of) and is accessed via the gianfar's MDIO registers, using the
functions gfar_local_mdio_read/write(), which don't do any locking.

The previously attached PHY will start a work-queue on a timer, and
probably an irq handler as well, which will talk to the PHY and thus use
the MDIO bus.  This uses phy_read/write(), which have locking, but not
against the gfar_local_mdio versions.

The result is that PHY code will try to use the MDIO bus at the same time
as the SerDes setup code, corrupting the transfers.

Setting up the SerDes before attaching to the PHY will insure that there is
no race between the SerDes code and *our* PHY, but doesn't fix everything.
Typically the PHYs for all gianfar devices are on the same MDIO bus, which
is associated with the first gianfar device.  This means that the first
gianfar's SerDes code could corrupt the MDIO transfers for a different
gianfar's PHY.

The lock used by phy_read/write() is contained in the mii_bus structure,
which is pointed to by the PHY.  This is difficult to access from the
gianfar drivers, as there is no link between a gianfar device and the
mii_bus which shares the same MDIO registers.  As far as the device layer
and drivers are concerned they are two unrelated devices (which happen to
share registers).

Generally all gianfar devices' PHYs will be on the bus associated with the
first gianfar.  But this might not be the case, so simply locking the
gianfar's PHY's mii bus might not lock the mii bus that the SerDes setup
code is going to use.

We solve this by having the code that creates the gianfar platform device
look in the device tree for an mdio device that shares the gianfar's
registers.  If one is found the ID of its platform device is saved in the
gianfar's platform data.

A new function in the gianfar mii code, gfar_get_miibus(), can use the bus
ID to search through the platform devices for a gianfar_mdio device with
the right ID.  The platform device's driver data is the mii_bus structure,
which the SerDes setup code can use to lock the current bus.
Signed-off-by: NTrent Piepho <tpiepho@freescale.com>
CC: Andy Fleming <afleming@freescale.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>
      c132419e
  37. 18 10月, 2008 1 次提交
  39. 14 10月, 2008 5 次提交
  41. 13 10月, 2008 1 次提交
  43. 02 10月, 2008 1 次提交