1. 20 2月, 2009 1 次提交
  2. 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
  3. 09 1月, 2009 2 次提交
  4. 21 12月, 2008 1 次提交
  5. 12 12月, 2008 2 次提交
  6. 04 12月, 2008 1 次提交
  7. 30 11月, 2008 1 次提交
    • R
      [ARM] Hide ISA DMA API when ISA_DMA_API is unset · dcea83ad
      Russell King 提交于
      When ISA_DMA_API is unset, we're not implementing the ISA DMA API,
      so there's no point in publishing the prototypes via asm/dma.h, nor
      including the machine dependent parts of that API.
      
      This allows us to remove a lot of mach/dma.h files which don't contain
      any useful code.  Unfortunately though, some platforms put their own
      private non-ISA definitions into mach/dma.h, so we leave these behind
      and fix the appropriate #include statments.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      dcea83ad
  8. 28 11月, 2008 1 次提交
    • N
      [ARM] remove a common set of __virt_to_bus definitions · b5ee9002
      Nicolas Pitre 提交于
      Let's provide an overridable default instead of having every machine
      class define __virt_to_bus and __bus_to_virt to the same thing.  What
      most platforms are using is bus_addr == phys_addr so such is the default.
      
      One exception is ebsa110 which has no DMA what so ever, so the actual
      definition is not important except only for proper compilation.  Also
      added a comment about the special footbridge bus translation.
      
      Let's also remove comments alluding to set_dma_addr which is not
      (and should not) be commonly used.
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      b5ee9002
  9. 24 10月, 2008 1 次提交
  10. 20 10月, 2008 1 次提交
  11. 26 9月, 2008 6 次提交
  12. 05 9月, 2008 1 次提交
    • L
      mv643xx_eth: remove force_phy_addr field · ac840605
      Lennert Buytenhek 提交于
      Currently, there are two different fields in the
      mv643xx_eth_platform_data struct that together describe the PHY
      address -- one field (phy_addr) has the address of the PHY, but if
      that address is zero, a second field (force_phy_addr) needs to be
      set to distinguish the actual address zero from a zero due to not
      having filled in the PHY address explicitly (which should mean
      'use the default PHY address').
      
      If we are a bit smarter about the encoding of the phy_addr field,
      we can avoid the need for a second field -- this patch does that.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      ac840605
  13. 09 8月, 2008 3 次提交
  14. 07 8月, 2008 2 次提交
  15. 24 7月, 2008 1 次提交
    • L
      mv643xx_eth: use auto phy polling for configuring (R)(G)MII interface · 81600eea
      Lennert Buytenhek 提交于
      The mv643xx_eth hardware has a provision for polling the PHY's
      MII management registers to obtain the (R)(G)MII interface speed
      (10/100/1000) and duplex (half/full) and pause (off/symmetric)
      settings to use to talk to the PHY.
      
      The driver currently does not make use of this feature.  Instead,
      whenever there is a link status change event, it reads the current
      link parameters from the PHY, and programs those parameters into
      the mv643xx_eth MAC by hand.
      
      This patch switches the mv643xx_eth driver to letting the MAC
      auto-determine the (R)(G)MII link parameters by PHY polling, if there
      is a PHY present.  For PHYless ports (when e.g. the (R)(G)MII
      interface is connected to a hardware switch), we keep hardcoding the
      MII interface parameters.
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      81600eea
  16. 01 7月, 2008 2 次提交
  17. 23 6月, 2008 1 次提交
    • S
      [ARM] add Marvell Kirkwood (88F6000) SoC support · 651c74c7
      Saeed Bishara 提交于
      The Marvell Kirkwood (88F6000) is a family of ARM SoCs based on a
      Shiva CPU core, and features a DDR2 controller, a x1 PCIe interface,
      a USB 2.0 interface, a SPI controller, a crypto accelerator, a TS
      interface, and IDMA/XOR engines, and depending on the model, also
      features one or two Gigabit Ethernet interfaces, two SATA II
      interfaces, one or two TWSI interfaces, one or two UARTs, a
      TDM/SLIC interface, a NAND controller, an I2S/SPDIF interface, and
      an SDIO interface.
      
      This patch adds supports for the Marvell DB-88F6281-BP Development
      Board and the RD-88F6192-NAS and the RD-88F6281 Reference Designs,
      enabling support for the PCIe interface, the USB interface, the
      ethernet interfaces, the SATA interfaces, the TWSI interfaces, the
      UARTs, and the NAND controller.
      Signed-off-by: NSaeed Bishara <saeed@marvell.com>
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      651c74c7