1. 09 6月, 2009 7 次提交
  2. 23 5月, 2009 1 次提交
  3. 22 5月, 2009 1 次提交
  4. 21 5月, 2009 1 次提交
  5. 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
  6. 07 4月, 2009 2 次提交
  7. 24 3月, 2009 3 次提交
  8. 22 3月, 2009 1 次提交
    • L
      dsa: add switch chip cascading support · e84665c9
      Lennert Buytenhek 提交于
      The initial version of the DSA driver only supported a single switch
      chip per network interface, while DSA-capable switch chips can be
      interconnected to form a tree of switch chips.  This patch adds support
      for multiple switch chips on a network interface.
      
      An example topology for a 16-port device with an embedded CPU is as
      follows:
      
      	+-----+          +--------+       +--------+
      	|     |eth0    10| switch |9    10| switch |
      	| CPU +----------+        +-------+        |
      	|     |          | chip 0 |       | chip 1 |
      	+-----+          +---++---+       +---++---+
      	                     ||               ||
      	                     ||               ||
      	                     ||1000baseT      ||1000baseT
      	                     ||ports 1-8      ||ports 9-16
      
      This requires a couple of interdependent changes in the DSA layer:
      
      - The dsa platform driver data needs to be extended: there is still
        only one netdevice per DSA driver instance (eth0 in the example
        above), but each of the switch chips in the tree needs its own
        mii_bus device pointer, MII management bus address, and port name
        array. (include/net/dsa.h)  The existing in-tree dsa users need
        some small changes to deal with this. (arch/arm)
      
      - The DSA and Ethertype DSA tagging modules need to be extended to
        use the DSA device ID field on receive and demultiplex the packet
        accordingly, and fill in the DSA device ID field on transmit
        according to which switch chip the packet is heading to.
        (net/dsa/tag_{dsa,edsa}.c)
      
      - The concept of "CPU port", which is the switch chip port that the
        CPU is connected to (port 10 on switch chip 0 in the example), needs
        to be extended with the concept of "upstream port", which is the
        port on the switch chip that will bring us one hop closer to the CPU
        (port 10 for both switch chips in the example above).
      
      - The dsa platform data needs to specify which ports on which switch
        chips are links to other switch chips, so that we can enable DSA
        tagging mode on them.  (For inter-switch links, we always use
        non-EtherType DSA tagging, since it has lower overhead.  The CPU
        link uses dsa or edsa tagging depending on what the 'root' switch
        chip supports.)  This is done by specifying "dsa" for the given
        port in the port array.
      
      - The dsa platform data needs to be extended with information on via
        which port to reach any given switch chip from any given switch chip.
        This info is specified via the per-switch chip data struct ->rtable[]
        array, which gives the nexthop ports for each of the other switches
        in the tree.
      
      For the example topology above, the dsa platform data would look
      something like this:
      
      	static struct dsa_chip_data sw[2] = {
      		{
      			.mii_bus	= &foo,
      			.sw_addr	= 1,
      			.port_names[0]	= "p1",
      			.port_names[1]	= "p2",
      			.port_names[2]	= "p3",
      			.port_names[3]	= "p4",
      			.port_names[4]	= "p5",
      			.port_names[5]	= "p6",
      			.port_names[6]	= "p7",
      			.port_names[7]	= "p8",
      			.port_names[9]	= "dsa",
      			.port_names[10]	= "cpu",
      			.rtable		= (s8 []){ -1, 9, },
      		}, {
      			.mii_bus	= &foo,
      			.sw_addr	= 2,
      			.port_names[0]	= "p9",
      			.port_names[1]	= "p10",
      			.port_names[2]	= "p11",
      			.port_names[3]	= "p12",
      			.port_names[4]	= "p13",
      			.port_names[5]	= "p14",
      			.port_names[6]	= "p15",
      			.port_names[7]	= "p16",
      			.port_names[10]	= "dsa",
      			.rtable		= (s8 []){ 10, -1, },
      		},
      	},
      
      	static struct dsa_platform_data pd = {
      		.netdev		= &foo,
      		.nr_switches	= 2,
      		.sw		= sw,
      	};
      Signed-off-by: NLennert Buytenhek <buytenh@marvell.com>
      Tested-by: NGary Thomas <gary@mlbassoc.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e84665c9
  9. 20 3月, 2009 1 次提交
    • R
      [ARM] pass reboot command line to arch_reset() · be093beb
      Russell King 提交于
      OMAP wishes to pass state to the boot loader upon reboot in order to
      instruct it whether to wait for USB-based reflashing or not.  There is
      already a facility to do this via the reboot() syscall, except we ignore
      the string passed to machine_restart().
      
      This patch fixes things to pass this string to arch_reset().  This means
      that we keep the reboot mode limited to telling the kernel _how_ to
      perform the reboot which should be independent of what we request the
      boot loader to do.
      Acked-by: NTony Lindgren <tony@atomide.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      be093beb
  10. 16 3月, 2009 3 次提交
  11. 27 2月, 2009 4 次提交
  12. 20 2月, 2009 2 次提交
  13. 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
  14. 09 1月, 2009 2 次提交
  15. 21 12月, 2008 1 次提交
  16. 12 12月, 2008 2 次提交
  17. 04 12月, 2008 1 次提交
  18. 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
  19. 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
  20. 24 10月, 2008 1 次提交
  21. 20 10月, 2008 1 次提交
  22. 26 9月, 2008 2 次提交