- Apr 15, 2016
-
-
Bert Vermeulen authored
This platform is based on a Marvell 88E6282 SoC and 88E6171 switch. [gregory.clement@free-electrons.com: fix block comment style] Signed-off-by: Bert Vermeulen <bert@biot.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Imre Kaloz <kaloz@openwrt.org> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Roger Shimizu authored
Add dts file to support Buffalo/Revogear Kurobox-Pro, which is marvell orion5x based 3.5" HDD NAS. It's a quite old product and already discontinued. So there's no official website for it. But it was an early product which used marvell orion5x 88F5182 chipset, it's popular in the community. Some unofficial site: - http://buffalo.nas-central.org/wiki/Category:KuroboxPro - http://nice.kaze.com/KUROPRO_ProductSpecifications.pdf This device tree is based on the board file: arch/arm/mach-orion5x/kurobox_pro-setup.c However, the probing order of NAND and JEDEC-Flash are different from the original board file, this results in incompatible minor number for a few /dev/mtdX and /dev/mtdblockX devices. So I still want to keep the board file for the time being. Signed-off-by: Roger Shimizu <rogershimizu@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Andrew Lunn authored
The regulator has a reg property so include it in the unit name. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Andrew Lunn authored
The mbus node has a ranges property. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Andrew Lunn authored
gpio-i2c does not have a reg property, just a list of gpios. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Andrew Lunn authored
PCIe has a range property, so the unit name should contain an address. Make use of the label to enable individual PCIe busses. Also, fixup the synology dtsi file which added a label pcie2 rather than using the existing pcie1 label. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Andrew Lunn authored
PHYs have an address on the mdio bus. So the unit name should contain an address. This is complicated in that some .dtsi files contain the node, but the reg is set in the .dts file. In this case, use the abstract address X. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Andrew Lunn authored
The dsa node does not have a reg property, so remove the address from the unit name. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Andrew Lunn authored
leds don't have a reg property, so remove the address from the unit name. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Andrew Lunn authored
The DT compiler is now warning about unit names with addresses but not reg property. Fix all the gpio-key buttons which causes warnings. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
- Mar 30, 2016
-
-
Heinrich Schuchardt authored
Commit be3d7d02 ("ARM: kirkwood: Add DTS file for NSA320") created the new file kirkwood-nsa320.dts but did not add it to the Makefile. Fixes: be3d7d02 ("ARM: kirkwood: Add DTS file for NSA320") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Heinrich Schuchardt authored
Commit 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") created the new file kirkwood-ds112.dts but did not add it to the Makefile. Fixes: 2d0a7add ("ARM: Kirkwood: Add support for many Synology NAS devices") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
Imre Kaloz authored
Some of the GPIO configs were wrong in the submitted DTS files, this patch fixes all affected boards. Signed-off-by: Imre Kaloz <kaloz@openwrt.org> Cc: <stable@vger.kernel.org> # v4.1 + Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
- Mar 29, 2016
-
-
Adam Baker authored
Add an entry for the hardware monitoring MCU [gregory.clement@free-electrons.com: rename the title to use the "standard" format] Signed-off-by: Adam Baker <linux@baker-net.org.uk> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
-
- Mar 22, 2016
-
-
Ludovic Desroches authored
If enabling the hsmci regulator on card detection, the board can reboot on sd card insertion. Keeping the regulator always enabled fixes this issue. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Fixes: 8d545f32 ("ARM: at91/dt: sama5d4 xplained: add regulators for v(q)mmc1 supplies") Cc: stable@vger.kernel.org #4.3 and later Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
-
Ludovic Desroches authored
If enabling the hsmci regulator on card detection, the board can reboot on sd card insertion. Keeping the regulator always enabled fixes this issue. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Fixes: 1b53e341 ("ARM: at91/dt: sama5d3 xplained: add fixed regulator for vmmc0") Cc: stable@vger.kernel.org #4.3 and later Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
-
- Mar 19, 2016
-
-
Masahiro Yamada authored
This will be needed for UniPhier PH1-LD11 and PH1-LD20 SoCs. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
Masahiro Yamada authored
Just for consistent coding style. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Masahiro Yamada authored
Initial commit for PH1-Pro4 Sanji board support. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Masahiro Yamada authored
Initial commit for PH1-Pro4 Ace board support. Note: There are two variants for the amount of DDR memory; 1GB or 2GB. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Masahiro Yamada authored
This is used for on-board inter-connection. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Masahiro Yamada authored
This board has an EEPROM (STMicroelectronics M24C64-WMN6TP) connected to the I2C channel 0 of the SoC. Its slave address is 0x54. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Masahiro Yamada authored
Add master clock nodes generated by crystal oscillators. PH1-sLD3, PH1-LD4: 24.576 MHz PH1-Pro4, ProXstream2: 25.000 MHz PH1-Pro5: 20.000 MHz Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Masahiro Yamada authored
During the review process of the UniPhier System Bus driver (drivers/bus/uniphier.c), the current binding of the System Bus Controller turned out to be no good. In order to make the driver really usable, we have to switch over to the new binding defined by Documentation/devicetree/bindings/bus/uniphier-system-bus.txt. The old binding will be still supported for a while to keep the backward compatibility. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
Masahiro Yamada authored
This property is used in common by several boards. Move it to the common place (uniphier-support-card.dtsi). If necessary, each board can still override the property. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
-
- Mar 17, 2016
-
-
Xing Zheng authored
This patch adds the emac device node for rk3036 SoCs. We need to let mac clock under the DPLL which is able to provide the accurate 50MHz what mac_ref need, since that will cause some unstable things if the cpufreq is working. Signed-off-by: Xing Zheng <zhengxing@rock-chips.com> Signed-off-by: Caesar Wang <wxt@rock-chips.com> Cc: linux-rockchip@lists.infradead.org Cc: Xing Zheng <zhengxing@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: David S. Miller <davem@davemloft.net>
-
- Mar 15, 2016
-
-
Gregory CLEMENT authored
Allow Openblock AX3 using hardware buffer management with mvneta. Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Marcin Wojtas authored
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>
-
Marcin Wojtas authored
Armada XP network controller supports hardware buffer management (BM). Since it is now enabled in mvneta driver, appropriate nodes can be added to armada-xp.dtsi - for the actual common BM unit (bm@c0000) and its internal SRAM (bm-bppi), which is used for indirect access to buffer pointer ring residing in DRAM. Pools - ports mapping, bm-bppi entry in 'soc' node's ranges and optional parameters are supposed to be set in board files. 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>
-
Marcin Wojtas authored
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: * A385-DB-AP - each port has its own pool for long and common pool for short packets, * A388-ClearFog - same as above, * A388-DB - to each port unique 'short' and 'long' pools are mapped, * A388-GP - same as above. Moreover appropriate entry is added to 'soc' node ranges, as well as "okay" status for 'bm' and 'bm-bppi' (internal SRAM) nodes. [gregory.clement@free-electrons.com: add suppport for the ClearFog board] Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Marcin Wojtas authored
Armada 38x network controller supports hardware buffer management (BM). Since it is now enabled in mvneta driver, appropriate nodes can be added to armada-38x.dtsi - for the actual common BM unit (bm@c8000) and its internal SRAM (bm-bppi), which is used for indirect access to buffer pointer ring residing in DRAM. Pools - ports mapping, bm-bppi entry in 'soc' node's ranges and optional parameters are supposed to be set in board files. 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>
-
- Mar 13, 2016
-
-
Masahiro Yamada authored
The compatible string "simple-bus" is well defined in ePAPR, while I see no documentation for the "arm,amba-bus" arnywhere in ePAPR or Documentation/devicetree/. DT is also used by other projects than Linux kernel. It is not a good idea to rely on such an unofficial binding. This commit - replaces "arm,amba-bus" with "simple-bus" - drops "arm,amba-bus" where it is used along with "simple-bus" Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Lars Persson authored
Relaxed the license on the dtsi to permit use in other projects. Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: Olof Johansson <olof@lixom.net>
-
Linus Walleij authored
This adds the Synaptics RMI4 touchscreen to the Ux500 TVK user interface board. Tested on the U8500 HREFv60plus with the TVK UIB. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
-
- Mar 12, 2016
-
-
Thomas Petazzoni authored
When the Crypto SRAM mappings were added to the Device Tree files describing the Armada XP boards in commit c466d997 ("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: c466d997 ("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>
-
- Mar 07, 2016
-
-
Mugunthan V N authored
Errata id: i877 Description: ------------ The RGMII 1000 Mbps Transmit timing is based on the output clock (rgmiin_txc) being driven relative to the rising edge of an internal clock and the output control/data (rgmiin_txctl/txd) being driven relative to the falling edge of an internal clock source. If the internal clock source is allowed to be static low (i.e., disabled) for an extended period of time then when the clock is actually enabled the timing delta between the rising edge and falling edge can change over the lifetime of the device. This can result in the device switching characteristics degrading over time, and eventually failing to meet the Data Manual Delay Time/Skew specs. To maintain RGMII 1000 Mbps IO Timings, SW should minimize the duration that the Ethernet internal clock source is disabled. Note that the device reset state for the Ethernet clock is "disabled". Other RGMII modes (10 Mbps, 100Mbps) are not affected Workaround: ----------- If the SoC Ethernet interface(s) are used in RGMII mode at 1000 Mbps, SW should minimize the time the Ethernet internal clock source is disabled to a maximum of 200 hours in a device life cycle. This is done by enabling the clock as early as possible in IPL (QNX) or SPL/u-boot (Linux/Android) by setting the register CM_GMAC_CLKSTCTRL[1:0]CLKTRCTRL = 0x2:SW_WKUP. So, do not allow to gate the cpsw clocks using ti,no-idle property in cpsw node assuming 1000 Mbps is being used all the time. If someone does not need 1000 Mbps and wants to gate clocks to cpsw, this property needs to be deleted in their respective board files. Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Cc: <stable@vger.kernel.org> Signed-off-by: Paul Walmsley <paul@pwsan.com>
-
- Mar 05, 2016
-
-
Sanchayan Maity authored
Add iio-hwmon node to expose the temperature channel on Vybrid as hardware monitor device using the iio_hwmon driver. Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Acked-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-
Sanchayan Maity authored
Change iio_hwmon nodes to use hypen in node names instead of underscore. Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
-
- Mar 02, 2016
-
-
Wenyou Yang authored
Add the three leds on the sama5d2 Xplained board with their pinctrl node. The blue led is positioned with the "heartbeat" trigger. Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> [nicolas.ferre@atmel.com: add commit message and adapt to newer kernel] Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
-
Ludovic Desroches authored
Add the push button named "PB USER" with code 0x104. Associated pinctrl node is also added. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
-