Commit Graph

31 Commits

Author SHA1 Message Date
Linus Torvalds
1200b6809d Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next
Pull networking updates from David Miller:
 "Highlights:

   1) Support more Realtek wireless chips, from Jes Sorenson.

   2) New BPF types for per-cpu hash and arrap maps, from Alexei
      Starovoitov.

   3) Make several TCP sysctls per-namespace, from Nikolay Borisov.

   4) Allow the use of SO_REUSEPORT in order to do per-thread processing
   of incoming TCP/UDP connections.  The muxing can be done using a
   BPF program which hashes the incoming packet.  From Craig Gallek.

   5) Add a multiplexer for TCP streams, to provide a messaged based
      interface.  BPF programs can be used to determine the message
      boundaries.  From Tom Herbert.

   6) Add 802.1AE MACSEC support, from Sabrina Dubroca.

   7) Avoid factorial complexity when taking down an inetdev interface
      with lots of configured addresses.  We were doing things like
      traversing the entire address less for each address removed, and
      flushing the entire netfilter conntrack table for every address as
      well.

   8) Add and use SKB bulk free infrastructure, from Jesper Brouer.

   9) Allow offloading u32 classifiers to hardware, and implement for
      ixgbe, from John Fastabend.

  10) Allow configuring IRQ coalescing parameters on a per-queue basis,
      from Kan Liang.

  11) Extend ethtool so that larger link mode masks can be supported.
      From David Decotigny.

  12) Introduce devlink, which can be used to configure port link types
      (ethernet vs Infiniband, etc.), port splitting, and switch device
      level attributes as a whole.  From Jiri Pirko.

  13) Hardware offload support for flower classifiers, from Amir Vadai.

  14) Add "Local Checksum Offload".  Basically, for a tunneled packet
      the checksum of the outer header is 'constant' (because with the
      checksum field filled into the inner protocol header, the payload
      of the outer frame checksums to 'zero'), and we can take advantage
      of that in various ways.  From Edward Cree"

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next: (1548 commits)
  bonding: fix bond_get_stats()
  net: bcmgenet: fix dma api length mismatch
  net/mlx4_core: Fix backward compatibility on VFs
  phy: mdio-thunder: Fix some Kconfig typos
  lan78xx: add ndo_get_stats64
  lan78xx: handle statistics counter rollover
  RDS: TCP: Remove unused constant
  RDS: TCP: Add sysctl tunables for sndbuf/rcvbuf on rds-tcp socket
  net: smc911x: convert pxa dma to dmaengine
  team: remove duplicate set of flag IFF_MULTICAST
  bonding: remove duplicate set of flag IFF_MULTICAST
  net: fix a comment typo
  ethernet: micrel: fix some error codes
  ip_tunnels, bpf: define IP_TUNNEL_OPTS_MAX and use it
  bpf, dst: add and use dst_tclassid helper
  bpf: make skb->tc_classid also readable
  net: mvneta: bm: clarify dependencies
  cls_bpf: reset class and reuse major in da
  ldmvsw: Checkpatch sunvnet.c and sunvnet_common.c
  ldmvsw: Add ldmvsw.c driver code
  ...
2016-03-19 10:05:34 -07:00
Marcin Wojtas
9dd7a57e2c ARM: dts: armada-xp: enable buffer manager support on Armada XP boards
Since mvneta driver supports using hardware buffer management (BM), in
order to use it, board files have to be adjusted accordingly. This commit
enables BM on AXP-DB and AXP-GP in same manner - because number of ports
on those boards is the same as number of possible pools, each port is
supposed to use single pool for all kind of packets.

Moreover appropriate entry is added to 'soc' node ranges, as well as "okay"
status for 'bm' and 'bm-bppi' (internal SRAM) nodes.

Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-14 12:19:45 -04:00
Thomas Petazzoni
d7d5a43c0d ARM: mvebu: fix overlap of Crypto SRAM with PCIe memory window
When the Crypto SRAM mappings were added to the Device Tree files
describing the Armada XP boards in commit c466d997bb ("ARM: mvebu:
define crypto SRAM ranges for all armada-xp boards"), the fact that
those mappings were overlaping with the PCIe memory aperture was
overlooked. Due to this, we currently have for all Armada XP platforms
a situation that looks like this:

Memory mapping on Armada XP boards with internal registers at
0xf1000000:

 - 0x00000000 -> 0xf0000000	3.75G 	RAM
 - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000	1M	internal registers
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory aperture
 - 0xf8100000 -> 0xf8110000	64KB	Crypto SRAM #0	=> OVERLAPS WITH PCIE !
 - 0xf8110000 -> 0xf8120000	64KB	Crypto SRAM #1	=> OVERLAPS WITH PCIE !
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O aperture
 - 0xfff0000  -> 0xffffffff	1M	BootROM

The overlap means that when PCIe devices are added, depending on their
memory window needs, they might or might not be mapped into the
physical address space. Indeed, they will not be mapped if the area
allocated in the PCIe memory aperture by the PCI core overlaps with
one of the Crypto SRAM. Typically, a Intel IGB PCIe NIC that needs 8MB
of PCIe memory will see its PCIe memory window allocated from
0xf80000000 for 8MB, which overlaps with the Crypto SRAM windows. Due
to this, the PCIe window is not created, and any attempt to access the
PCIe window makes the kernel explode:

[    3.302213] igb: Copyright (c) 2007-2014 Intel Corporation.
[    3.307841] pci 0000:00:09.0: enabling device (0140 -> 0143)
[    3.313539] mvebu_mbus: cannot add window '4:f8', conflicts with another window
[    3.320870] mvebu-pcie soc:pcie-controller: Could not create MBus window at [mem 0xf8000000-0xf87fffff]: -22
[    3.330811] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf08c0018

This problem does not occur on Armada 370 boards, because we use the
following memory mapping (for boards that have internal registers at
0xf1000000):

 - 0x00000000 -> 0xf0000000	3.75G 	RAM
 - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000	1M	internal registers
 - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0 => OK !
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
 - 0xfff0000  -> 0xffffffff	1M	BootROM

Obviously, the solution is to align the location of the Crypto SRAM
mappings of Armada XP to be similar with the ones on Armada 370, i.e
have them between the "internal registers" area and the beginning of
the PCIe aperture.

However, we have a special case with the OpenBlocks AX3-4 platform,
which has a 128 MB NOR flash. Currently, this NOR flash is mapped from
0xf0000000 to 0xf8000000. This is possible because on OpenBlocks
AX3-4, the internal registers are not at 0xf1000000. And this explains
why the Crypto SRAM mappings were not configured at the same place on
Armada XP.

Hence, the solution is two-fold:

 (1) Move the NOR flash mapping on Armada XP OpenBlocks AX3-4 from
     0xe8000000 to 0xf0000000. This frees the 0xf0000000 ->
     0xf80000000 space.

 (2) Move the Crypto SRAM mappings on Armada XP to be similar to
     Armada 370 (except of course that Armada XP has two Crypto SRAM
     and not one).

After this patch, the memory mapping on Armada XP boards with
registers at 0xf1 is:

 - 0x00000000 -> 0xf0000000	3.75G 	RAM
 - 0xf0000000 -> 0xf1000000	16M	NOR flashes (AXP GP / AXP DB)
 - 0xf1000000 -> 0xf1100000	1M	internal registers
 - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
 - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
 - 0xfff0000  -> 0xffffffff	1M	BootROM

And the memory mapping for the special case of the OpenBlocks AX3-4
(internal registers at 0xd0000000, NOR of 128 MB):

 - 0x00000000 -> 0xc0000000	3G 	RAM
 - 0xd0000000 -> 0xd1000000	1M	internal registers
 - 0xe800000  -> 0xf0000000	128M	NOR flash
 - 0xf1100000 -> 0xf1110000	64KB	Crypto SRAM #0
 - 0xf1110000 -> 0xf1120000	64KB	Crypto SRAM #1
 - 0xf8000000 -> 0xffe0000	126M	PCIe memory
 - 0xffe00000 -> 0xfff00000	1M	PCIe I/O
 - 0xfff0000  -> 0xffffffff	1M	BootROM

Fixes: c466d997bb ("ARM: mvebu: define crypto SRAM ranges for all armada-xp boards")
Reported-by: Phil Sutter <phil@nwl.cc>
Cc: Phil Sutter <phil@nwl.cc>
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
2016-03-11 11:49:55 -08:00
Boris Brezillon
c466d997bb ARM: mvebu: define crypto SRAM ranges for all armada-xp boards
Define the crypto SRAM ranges so that the resources referenced by the
sa-sram node can be properly extracted from the DT.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-09-29 16:16:11 +02:00
Rafał Miłecki
e9f3ed4ac4 ARM: mvebu: add "jedec,spi-nor" flash compatible binding
Starting with commit 8947e396a8 ("Documentation: dt: mtd: replace
"nor-jedec" binding with "jedec, spi-nor"") we have "jedec,spi-nor"
binding indicating support for JEDEC identification.

Use it for all flashes that are supposed to support READ ID op according
to the datasheets.

Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-05-25 16:53:40 +02:00
Thomas Petazzoni
9552203cb0 ARM: mvebu: use stdout-path in all armada-*.dts
This commit adds the stdout-path property in /chosen for all Armada
boards that were not yet carrying this property, and gets rid of
/chosen/bootargs which becomes unneeded: earlyprintk should not be
used by default, and the console= parameter is replaced by the
/chosen/stdout-path property.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
2015-03-04 15:02:28 +01:00
Gregory CLEMENT
a0f22f8e43 ARM: mvebu: armada-xp-gp: Relicense the device tree under GPLv2+/X11
The current GPL only licensing on the device tree makes it very
impractical for other software components licensed under another
license.

In order to make it easier for them to reuse our device trees,
relicense our device trees under a GPL/X11 dual-license.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-01-26 19:28:13 -06:00
Thomas Petazzoni
389a367a5b ARM: mvebu: add suspend/resume DT information for Armada XP GP
This commit improves the Armada XP GP Device Tree description to
describe the 3 GPIOs that are used to connect the SoC to the PIC
micro-controller that we talk to shutdown the SoC when entering
suspend to RAM.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1416585613-2113-15-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-11-30 16:40:17 +00:00
Linus Torvalds
755a9ba7bf ARM: SoC devicetree updates for 3.16
As with previous release, this continues to be among the largest branches
 we merge, with lots of new contents.
 
 New things for this release are among other things:
 
 - DTSI contents for the new SoCs supported in 3.16 (see SoC pull request)
 - Qualcomm APQ8064 and APQ8084 SoCs and eval boards
 - Nvidia Jetson TK1 development board (Tegra T124-based)
 
 Two new SoCs that didn't need enough new platform code to stand out
 enough for me to notice when writing the SoC tag, but that adds new DT
 contents are:
 
 - TI DRA72
 - Marvell Berlin 2Q
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.14 (GNU/Linux)
 
 iQIcBAABAgAGBQJTjNNQAAoJEIwa5zzehBx3KyYP/3TEJcXXEYDURXDB0SktPNyy
 cKp5HUnsu4+aq/Ae6jdjVGiX5FZa64Xije9b0kP3oxoPS+fuODvzhlnoEsT84Ab5
 /jeygWJZYUIWAQTxShPT55K8WAEtL7H1WcvswdCZoTDxPBNCLR/nLzv084nv9Die
 IOUWDTKW4qB8+KYQxh2TBx0E1TorZ0J5OWf6qqepZ0i4J5dhL1VYtc/ZNU5C37V5
 rZyyBQNOCBE/MK/Dw9CnResQf4f8DigHBYgpl7VxB+bBqfgzFuSSEPvg21MXLkfi
 ln64yYTVvqhleVjGriDV+mUHOCZr4sUWZPDzeF5HzpvqDAMDWTsWlHNh6WDU6dgo
 b+zFPqqnWaBiWrinY+o7MVvjVzu3Nf8id/GyjnDJEFbSc9ka/8uiC3v9UJXAFawF
 3Huc3K6BC/3qOoCPfnBotzx7Xxxvjk2lPRfnonhSvBoSzPeFc6vz2k4USX1GbdkB
 y/v+Q+n52VebxiKknTMv9HOI06yTOJo2ji+2iKIULb+W86HzNRZL8ZlmNib4WysF
 z/OgHZl+YzbhJQJtvfBecCIH2Hu+A4GD2ES8hhklA0QhFHPiDfB9cqcsthSGS5oL
 dDaGv6XGpHoySlEm1ybgWhvH96dc7lTR+nPGZqCKtRBn5pJiEHczxQ2Jz3aBHYeW
 PUPlrVfYXzIKsh+OU1HO
 =OvOG
 -----END PGP SIGNATURE-----

Merge tag 'dt-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc into next

Pull ARM SoC devicetree updates from Olof Johansson:
 "As with previous release, this continues to be among the largest
  branches we merge, with lots of new contents.

  New things for this release are among other things:

   - DTSI contents for the new SoCs supported in 3.16 (see SoC pull request)
   - Qualcomm APQ8064 and APQ8084 SoCs and eval boards
   - Nvidia Jetson TK1 development board (Tegra T124-based)

  Two new SoCs that didn't need enough new platform code to stand out
  enough for me to notice when writing the SoC tag, but that adds new DT
  contents are:

   - TI DRA72
   - Marvell Berlin 2Q"

* tag 'dt-for-3.16' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (500 commits)
  ARM: dts: add secure firmware support for exynos5420-arndale-octa
  ARM: dts: add pmu sysreg node to exynos3250
  ARM: dts: correct the usb phy node in exynos5800-peach-pi
  ARM: dts: correct the usb phy node in exynos5420-peach-pit
  ARM: dts: add dts files for exynos5410 and exynos5410-smdk5410
  ARM: dts: add dts files for exynos3250 SoC
  ARM: dts: add mfc node for exynos5800
  ARM: dts: add Vbus regulator for USB 3.0 on exynos5800-peach-pi
  ARM: dts: enable fimd for exynos5800-peach-pi
  ARM: dts: enable display controller for exynos5800-peach-pi
  ARM: dts: enable hdmi for exynos5800-peach-pi
  ARM: dts: add dts file for exynos5800-peach-pi board
  ARM: dts: add dts file for exynos5800 SoC
  ARM: dts: add dts file for exynos5260-xyref5260 board
  ARM: dts: add dts files for exynos5260 SoC
  ARM: dts: update watchdog node name in exynos5440
  ARM: dts: use key code macros on Origen and Arndale boards
  ARM: dts: enable RTC and WDT nodes on Origen boards
  ARM: dts: qcom: Add APQ8084-MTP board support
  ARM: dts: qcom: Add APQ8084 SoC support
  ...
2014-06-02 16:34:00 -07:00
Thomas Petazzoni
0d9179fb33 ARM: mvebu: remove clock-frequency of serial port Device Tree nodes
Now that the Armada 370/375/38x/XP SoC-level Device Tree files have
the proper "clocks" property in their UART controllers node, it is no
longer useful to have the clock-frequency property defined in the
board-level Device Tree files.

Therefore, this commit gets rid of all the useless 'clock-frequency'
properties.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Link: https://lkml.kernel.org/r/1397806908-7550-5-git-send-email-thomas.petazzoni@free-electrons.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-26 00:34:44 +00:00
Thomas Petazzoni
80fa10f4e9 ARM: mvebu: use qsgmii phy-mode for Armada XP GP interfaces
The Armada XP GP isn't using rgmii-id connections between the MAC and
PHY, but instead a single QSGMII connection, which is a quad-SGMII
connection: a double pair of differential lines that are multiplexed
to convey the traffic of four network interfaces between a MAC and a
PHY.

Until now, the Armada XP GP was relying on the bootloader setting the
correct values in various configuration registers. With this change,
the mvneta driver can be used as a module on this platform.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397569821-5530-4-git-send-email-thomas.petazzoni@free-electrons.com
Tested-by: Arnaud Ebalard <arno@natisbad.org>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-25 21:23:37 +00:00
Thomas Petazzoni
1a88f809cc ARM: mvebu: fix NOR bus-width in Armada XP GP Device Tree
The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP GP Device Tree: a 8 bits bus width was declared, even
though the hardware actually has a 16 bits bus width connection with
the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
da8d1b3835 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-GP board') which was merged in v3.10.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: da8d1b3835 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board')
Cc: stable@vger.kernel.org # v3.10+
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-04-25 21:23:33 +00:00
Thomas Petazzoni
91ed32200e ARM: mvebu: switch the Armada XP GP to use internal registers at 0xf1000000
Marvell has now provided bootloaders that are Device Tree capable for
the Armada XP GP board, and that also remap the internal register base
address to 0xf1000000. In addition, the bootloader now sets the MBus
Window base address to 0xf0000000, which allows to use much more RAM
in the last GB of RAM before the 4 GB limit (the entire space from
0xC0000000 to 0xFFFFFFFF was not usable due to being used for I/O, not
only the space from 0xF0000000 to 0xFFFFFFFF is used for I/O).

Therefore this commit:

 * Updates the memory->reg Device Tree property with the fact that in
   the first bank of RAM, memory up to 0xf0000000 can be used.

 * Updates the soc->ranges Device Tree property with the fact that the
   internal registers are now mapped at 0xf1000000.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2014-03-06 19:59:37 +00:00
Ezequiel Garcia
2be2bc39c6 ARM: mvebu: Enable NAND controller in Armada XP GP board
The Armada XP GP board has a NAND flash, so enable it in the devicetree.

In order to skip the driver's custom device detection and use only ONFI
detection, the "marvell,keep-config" parameter is used.
This is needed because we haven't support for setting the timings
parameters yet and must rely in bootloader's.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-11-24 03:40:19 +00:00
Ezequiel Garcia
14fd8ed0a7 ARM: mvebu: Relocate Armada 370/XP PCIe device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the PCIe nodes out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the
hardware.

Moving the PCIe nodes, we now need to introduce an extra cell to
encode the window target ID and attribute. Since this depends on
the PCIe port, we split the ranges translation entries, to correspond
to each MBus window.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-08-06 14:11:27 +00:00
Ezequiel Garcia
de1af8d486 ARM: mvebu: Relocate Armada 370/XP DeviceBus device tree nodes
Now that mbus has been added to the device tree, it's possible to
move the DeviceBus out of internal registers, placing it directly
below the mbus. This is a more accurate representation of the hardware.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-08-06 14:11:23 +00:00
Ezequiel Garcia
0cd3754a83 ARM: mvebu: Add BootROM to Armada 370/XP device tree
In order to access the SoC BootROM, we need to declare a mapping
(through a ranges property). The mbus driver will use this property
to allocate a suitable address decoding window.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-08-06 14:11:20 +00:00
Ezequiel Garcia
5e12a613ce ARM: mvebu: Add MBus to Armada 370/XP device tree
The Armada 370/XP SoC family has a completely configurable address
space handled by the MBus controller.

This patch introduces the device tree layout of MBus, making the
'soc' node as mbus-compatible.
Since every peripheral/controller is a child of this 'soc' node,
this makes all of them sit behind the mbus, thus describing the
hardware accurately.

A translation entry has been added for the internal-regs mapping.
This can't be done in the common armada-370-xp.dtsi because A370
and AXP have different addressing width.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-08-06 14:11:16 +00:00
Ezequiel Garcia
38149887ef ARM: mvebu: Use the preprocessor on Armada 370/XP device tree files
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Tested-by: Andrew Lunn <andrew@lunn.ch>
Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-08-06 14:11:08 +00:00
Arnd Bergmann
d5a51af940 mxs device tree changes for 3.11:
* A couple of new board support, cfa10055 and cfa10057
 * A few updates on cfa10036 device tree source
 * Some auart pinctrl data addition
 * Adopt soc bus infrastructure for mach-mxs
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.11 (GNU/Linux)
 
 iQEcBAABAgAGBQJRvwUEAAoJEFBXWFqHsHzOZXgH/jYs9okBIb6UtYegmdGUinCD
 VHJJT+RT8ceosMjBt+aBfpKplUG1X3OOoWbpU7Uv5JKNfY+0QbYTr4bdSE0YTF19
 /ml5lCLLqW1MouErxIIe9yFrs4ZhZLLuW0Uy+ze7XVO/VPUlmJWYGU4D5gLcN+SH
 aDdwAfe0SEydxWKp5euh6O2qPuuOro5/kUOPvYs6xaJj3marWkD9M6YyhaWvaFwF
 2iUWzSd6dGabHRYwG2r38IlKMo6xncnu3b1NPifVMiPtiHFJ8t0SyTEGmpq19G+x
 G6q0TneOUVIgH0PN4YQoCGOR6oAB52Z/dVTVlGx6LE6w9Q95wI3XNHltP5U+bF0=
 =Oeyn
 -----END PGP SIGNATURE-----

Merge tag 'mxs-dt-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6 into next/dt

From Shawn Guo:

mxs device tree changes for 3.11:

* A couple of new board support, cfa10055 and cfa10057
* A few updates on cfa10036 device tree source
* Some auart pinctrl data addition
* Adopt soc bus infrastructure for mach-mxs

* tag 'mxs-dt-3.11' of git://git.linaro.org/people/shawnguo/linux-2.6:
  ARM: mxs: dt: Add Crystalfontz CFA-10057 device tree
  ARM: mxs: dt: Add the Crystalfontz CFA-10055 device tree
  ARM: cfa10049: Switch the chip select pin of the LCD controller
  ARM: cfa10036: Add USB0 OTG port
  ARM: dts: apf28dev: Add touchscreen support for APF28dev
  ARM: mxs: Fix UARTs on M28EVK
  ARM: cfa10036: dt: Change i2c0 clock frequency
  ARM: dts: cfa10036: Change the OLED display to SSD1306
  ARM: mx28: add auart4 2 pins pinmux to imx28.dtsi
  ARM: mx28: add auart3 2 pins pinmux to imx28.dtsi
  ARM: mx28: add auart2 2 pins pinmux to imx28.dtsi
  ARM: mxs: Use soc bus infrastructure
  ARM: dts: mx28: Adjust the digctl compatible string
  ARM: mxs: Remove init_irq declaration in machine description

Includes an update to 3.10-rc6

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2013-06-20 02:06:36 +02:00
Thomas Petazzoni
5f1f3d5088 arm: mvebu: armada-xp-{gp,openblocks-ax3-4}: specify PCIe range
The ranges DT entry needed by the PCIe controller is defined at the
SoC .dtsi level. However, some boards have a NOR flash, and to support
it, they need to override the SoC-level ranges property to add an
additional range. Since PCIe and NOR support came separately, some
boards were not properly changed to include the PCIe range in their
ranges property at the .dts level.

This commit fixes those platforms.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-06-06 19:09:00 +00:00
Olof Johansson
d1ba78cd72 mvebu dt changes for v3.11 (round 3)
- mvebu
     - enable two usb interfaces on Armada XP-GP
 
  - kirkwood
     - move pinmux configs to their individual devices
     - group the pinmux configs on OpenBlocks A6
     - add the Init button for the OpenBlocks A6
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.19 (GNU/Linux)
 
 iQEcBAABAgAGBQJRpPZAAAoJEAi3KVZQDZAe/6AIAIvtbKlec9up7/QoIzM7varY
 Qfb7OU6EQYnNmTiY+n/y2REz03mUC/cnrvRZ0YD31i5WwHZWGQiz1R692Tt1e07A
 Cugl75yLuOFnsSKqkvRy0Km2QF35Irk22stBRP85csGu/LjjSqr0gXDsJ2++oQfZ
 ssco7I5MsTEFJDpeVAB5jFaFm+hs+uM8/WsUf7l7qjyImqkz1WZPZfkgevWm3UjH
 Mz2Ur2Sbapq5gU+/h8GdzWJdCuSM0wmZ3TKGOk2BCbMFBFSr72tPUgVDwYge7Ae4
 5lPoeHg00o8TM6kpf5OBGW8kq6oMij33e7YjVpAp/YdsAmyua1gFCFikW3APuJU=
 =SWgl
 -----END PGP SIGNATURE-----

Merge tag 'dt-3.11-3' of git://git.infradead.org/users/jcooper/linux into next/dt

From jason Cooper, mvebu dt changes for v3.11.

Signed-off-by: Olof Johansson <olof@lixom.net>

* tag 'dt-3.11-3' of git://git.infradead.org/users/jcooper/linux: (27 commits)
  arm: kirkwood: openblocks-a6: add support for Init button
  arm: kirkwood: openblocks-a6: group pinmux configurations
  arm: kirkwood: ts219: move pinmux configs to the right devices
  arm: kirkwood: topkick: move pinmux configs to the right devices
  arm: kirkwood: openblocks_a6: move pinmux configs to the right devices
  arm: kirkwood: nsa310: move pinmux configs to the right devices
  arm: kirkwood: readynas: move pinmux configs to the right devices
  arm: kirkwood: mplcec4: move pinmux configs to the right devices
  arm: kirkwood: buffalo linkstation: move pinmux configs to the right devices
  arm: kirkwood: keymile: move pinmux configs to the right devices
  arm: kirkwood: ns2: move pinmux configs to the right devices
  arm: kirkwood: iomega ix2-200: move pinmux configs to the right devices
  arm: kirkwood: iconnect: move pinmux configs to the right devices
  arm: kirkwood: iconnect: give meaningful names to pinmux configs
  arm: kirkwood: ib62x0: move pinmux configs to the right devices
  arm: kirkwood: guruplug: move pinmux configs to the right devices
  arm: kirkwood: goflexnet: move pinmux configs to the right devices
  arm: kirkwood: dreamplug: move pinmux configs to the right devices
  arm: kirkwood: dockstar: move pinmux configs to the right devices
  arm: kirkwood: dlink dns: move pinmux configs to the right devices
  ...
2013-05-31 22:47:53 -07:00
Thomas Petazzoni
0e99b153be arm: mvebu: enable two USB interfaces on the Armada XP GP board
The Armada XP GP board has two USB slots: one on the front side and
one on the back side. This commit enables the two USB host controllers
that correspond to those wo USB slots.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-05-21 22:29:37 +00:00
Ezequiel Garcia
c6c003af0b ARM: mvebu: Fix ranges entry on XP GP board
With the latest device tree reorganization which introduced the
'internal-reg' node, now the only region translated is the internal register's.
This makes the description of the hardware incomplete, for it lacks the
Device Bus childs address space.

In order to fix this, it's required to add a 'ranges' entry with a suitable
address space to map Device Bus childs, on a per-board basis.
This patch fixes the ranges property on the Armada XP GP board.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-05-17 16:53:15 +00:00
Gregory CLEMENT
74898364e7 ARM: dts: mvebu: Convert mvebu device tree files to 64 bits
In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.

Only Armada XP is LPAE capable, but as it shares a common dtsi file
with Armada 370, then the common file include the skeleton64. Thanks
to the use of the overload capability of the device tree format,
armada-370 include the 32 bit skeleton and all the armada 370 based
dts can remain the same.

This was heavily based on the work of Lior Amsalem.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-15 15:00:29 +00:00
Gregory CLEMENT
467f54b215 ARM: dts: mvebu: introduce internal-regs node
Introduce a 'internal-regs' subnode, under which all devices are
moved. This is not really needed for now, but will be for the
mvebu-mbus driver. This generates a lot of code movement since it's
indenting by one more tab all the devices.  So it was a good
opportunity to fix all the bad indentation.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-15 15:00:24 +00:00
Gregory CLEMENT
82a682676c ARM: dts: mvebu: Convert all the mvebu files to use the range property
This conversion will allow to keep 32 bits addresses for the internal
registers whereas the memory of the system will be 64 bits.
Later it will also ease the move of the mvebu-mbus driver to the
device tree support.

Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-15 15:00:21 +00:00
Thomas Petazzoni
513a7917b1 arm: mvebu: PCIe Device Tree informations for Armada XP GP
The Marvell Armada XP GP board has 3 physical full-size PCIe slots, so
we enable the corresponding PCIe interfaces in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-15 14:53:53 +00:00
Ezequiel Garcia
da8d1b3835 ARM: mvebu: Add support for NOR flash device on Armada XP-GP board
The Armada XP Development Board DB-MV784MP-GP has a NOR flash device
connected to the Device Bus. This commit adds the device tree node
to support this device.

This SoC supports a flexible and dynamic decoding window allocation
scheme; but since this feature is still not implemented we need
to specify the window base address in the device tree node itself.

This base address has been selected in a completely arbitrary fashion.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-04-11 17:29:04 +00:00
Ezequiel Garcia
9dc3e34687 arm: mvebu: Add SPI flash on Armada XP-GP board
This patch adds an SPI master device node for Armada XP-GP board.
This master node is an SPI flash controller 'n25q128a13'.

Since there is no 'partitions' node declared, one full sized
partition named as the device will be created.

Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Lior Amsalem <alior@marvell.com>
Tested-by: Gregory Clement <gregory.clement@free-electrons.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Acked-by: Gregory Clement <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-02-28 18:57:14 +01:00
Gregory CLEMENT
568fc0a321 arm: mvebu: support for the new Armada XP development board(DB-MV784MP-GP)
This is the new Armada XP evaluation board from Marvell. It comes with
a RS232 port over USB, a SATA link, an internal SSD, 4 Ethernet
Gigabit links.

Support for USB (Host and device), SDIO, PCIe will be added as drivers
when they become available for Armada XP in mainline.

Tested-by: Simon Guinot <simon.guinot@sequanux.org>
Tested-by: Florian Fainelli <florian@openwrt.org>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
2013-02-28 18:57:08 +01:00