Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 04 3月, 2011 2 次提交
  3. 14 1月, 2011 1 次提交
  5. 23 12月, 2010 3 次提交
  7. 22 10月, 2010 1 次提交
    • N
      [ARM] Kirkwood: restrict the scope of the PCIe reset workaround · 3924996b
      由 Nicolas Pitre 提交于 
      Commit 21f0ba90 "orion/kirkwood: reset PCIe unit on boot" made the
reset of the PCIe unit unconditional.  While this may fix problems on some
targets, this also causes problems on other targets.

Saeed Bishara <saeed@marvell.com> said about the original problem: "We
couln't pinpoint the root cause of this issue, actually we failed to
reproduce that issue."

So let's restrict the reset of the PCIe unit only to the target where
the original problem was observed.
Signed-off-by: NNicolas Pitre <nico@fluxnic.net>
      3924996b
  9. 17 7月, 2010 1 次提交
  11. 31 5月, 2010 1 次提交
  13. 14 5月, 2010 1 次提交
  15. 29 12月, 2009 1 次提交
  17. 24 8月, 2009 1 次提交
    • M
      [ARM] Kirkwood: __init requires linux/init.h · 3e475f57
      由 Martin Michlmayr 提交于 
      Include linux/init.h for __init to fix this error:

CC [M]  drivers/net/wireless/wl12xx/boot.o
In file included from arch/arm/mach-kirkwood/include/mach/gpio.h:13,
                 from arch/arm/include/asm/gpio.h:5,
                 from include/linux/gpio.h:7,
                 from drivers/net/wireless/wl12xx/boot.c:24:
arch/arm/plat-orion/include/plat/gpio.h:32: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘orion_gpio_init’
make[6]: *** [drivers/net/wireless/wl12xx/boot.o] Error 1
make[5]: *** [drivers/net/wireless/wl12xx] Error 2
Signed-off-by: NMartin Michlmayr <tbm@cyrius.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
      3e475f57
  19. 09 6月, 2009 4 次提交
  21. 24 4月, 2009 1 次提交
    • N
      [ARM] 5460/1: Orion: reduce namespace pollution · fdd8b079
      由 Nicolas Pitre 提交于 
      Symbols like SOFT_RESET are way too generic to be exported at large.
To avoid this, let's move the mbus bridge register defines into a
separate file and include it where needed.  This affects mach-kirkwood,
mach-loki, mach-mv78xx0 and mach-orion5x simultaneously as they all
share code in plat-orion which relies on those defines.

Some other defines have been moved to narrower scopes, or simply deleted
when they had no user.

This fixes compilation problem with mpt2sas on the above listed
platforms.
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fdd8b079
  23. 22 4月, 2009 1 次提交
  25. 25 3月, 2009 2 次提交
  27. 27 2月, 2009 1 次提交
  29. 20 2月, 2009 1 次提交
  31. 18 2月, 2009 1 次提交
    • N
      [ARM] 5401/1: Orion: fix edge triggered GPIO interrupt support · fd4b9b36
      由 Nicolas Pitre 提交于 
      The GPIO interrupts can be configured as either level triggered or edge
triggered, with a default of level triggered.  When an edge triggered
interrupt is requested, the gpio_irq_set_type method is called which
currently switches the given IRQ descriptor between two struct irq_chip
instances: orion_gpio_irq_level_chip and orion_gpio_irq_edge_chip. This
happens via __setup_irq() which also calls irq_chip_set_defaults() to
assign default methods to uninitialized ones.  The problem is that
irq_chip_set_defaults() is called before the irq_chip reference is
switched, leaving the new irq_chip (orion_gpio_irq_edge_chip in this
case) with uninitialized methods such as chip->startup() causing a kernel
oops.

Many solutions are possible, such as making irq_chip_set_defaults() global
and calling it from gpio_irq_set_type(), or calling __irq_set_trigger()
before irq_chip_set_defaults() in __setup_irq().  But those require
modifications to the generic IRQ code which might have adverse effect on
other architectures, and that would still be a fragile arrangement.
Manually copying the missing methods from within gpio_irq_set_type()
would be really ugly and it would break again the day new methods with
automatic defaults are added.

A better solution is to have a single irq_chip instance which can deal
with both edge and level triggered interrupts.  It is also a good idea
to switch the IRQ handler instead, as the edge IRQ handler allows for
one edge IRQ event to be queued as the IRQ is actually masked only when
that second IRQ is received, at which point the hardware can queue an
additional IRQ event, making edge triggered interrupts a bit more
reliable.
Tested-by: NMartin Michlmayr <tbm@cyrius.com>
Signed-off-by: NNicolas Pitre <nico@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fd4b9b36
  33. 21 12月, 2008 2 次提交
  35. 13 12月, 2008 1 次提交
  37. 04 12月, 2008 1 次提交
  39. 03 12月, 2008 1 次提交
  41. 09 8月, 2008 1 次提交
  43. 07 8月, 2008 1 次提交
  45. 23 6月, 2008 3 次提交
    • L
      [ARM] Orion: PCIe x4/x1 detection support · a9311cfe
      由 Lennert Buytenhek 提交于 
      The Discovery Duo (MV78xx0) has two x4 PCIe ports which can either
be used in x4 mode or in quad x1 mode.  This patch adds an accessor
function to the generic plat-orion PCIe handling code to detect in
which of the two modes we're running (which is determined by strap
pins and/or configured by the bootloader).
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      a9311cfe
    • K
      [ARM] Orion: add a separate BRIDGE_INT_TIMER1_CLR define · 1219715d
      由 Ke Wei 提交于 
      Some Feroceon-based SoCs have an MBUS bridge interrupt controller
that requires writing a one instead of a zero to clear edge
interrupt sources such as timer expiry.

This patch adds a new BRIDGE_INT_TIMER1_CLR define, which platform
code can set to either ~BRIDGE_INT_TIMER1 (write-zero-to-clear) or
BRIDGE_INT_TIMER1 (write-one-to-clear) depending on the platform.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      1219715d
    • L
      [ARM] Orion: top-level IRQs are level-triggered · 000e99c3
      由 Lennert Buytenhek 提交于 
      Make it clear that Orion top-level IRQs are level-triggered.  This
means that we don't need an ->ack() handler, or at least, we don't
need the ->ack() handler (or the acking part of the ->mask_ack()
handler) to actually do anything.

Given that, we might as well point our ->mask_ack() handler at the
->mask() handler instead of providing a dummy ->ack() handler, since
providing a ->mask_ack() handler on level IRQ sources will prevent
->ack() from ever being called.
Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
Acked-by: NRussell King <linux@arm.linux.org.uk>
      000e99c3
  47. 10 4月, 2008 1 次提交
  49. 28 3月, 2008 4 次提交