summaryrefslogtreecommitdiff
path: root/arch/arm/boot/dts/omap3-overo-base.dtsi
AgeCommit message (Collapse)Author
2016-08-31ARM: dts: omap3: Add missing unit name to memory nodesJavier Martinez Canillas
This patch fixes the following DTC warnings: "Node /memory has a reg or ranges property, but no unit name" Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2016-08-31ARM: omap3: Add missing memory node in overo and torpedo boardsJavier Martinez Canillas
The skeleton.dtsi file was removed in ARM64 for different reasons as explained in commit ("3ebee5a2e141 arm64: dts: kill skeleton.dtsi"). These also applies to ARM and it will also allow to get rid of the following DTC warnings in the future: "Node /memory has a reg or ranges property, but no unit name" But these boards don't have a memory node defined, so removing the skeleton.dtsi inclusion from omap3.dtsi will cause a change in the compiled DTB. Add a dummy memory node so the compiled DTB doesn't change if the skeleton.dtsi is removed from omap3.dtsi. Eventually the correct starting addresses and sizes should be used but I didn't find that information. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2016-08-15ARM: dts: overo: fix gpmc nand on boards with ethernetJohan Hovold
The gpmc ranges property for NAND at CS0 was being overridden by later includes that defined gpmc ethernet nodes, effectively breaking NAND on these systems: omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has malformed 'reg' property Instead of redefining the NAND range in every such dtsi, define all currently used ranges in omap3-overo-base.dtsi. Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND") Cc: stable <stable@vger.kernel.org> # 4.3 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2016-08-15ARM: dts: overo: fix gpmc nand cs0 rangeJohan Hovold
The gpmc ranges property for NAND at CS0 has been broken since it was first added. This currently prevents the nand gpmc child node from being probed: omap-gpmc 6e000000.gpmc: /ocp/gpmc@6e000000/nand@0,0 has malformed 'reg' property and consequently the NAND device from being registered. Fixes: 98ce6007efb4 ("ARM: dts: overo: Support PoP NAND") Cc: stable <stable@vger.kernel.org> # 4.3 Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2016-02-26ARM: dts: omap3: Fix NAND device nodesRoger Quadros
Add compatible id, GPMC register resource and interrupt resource to NAND controller nodes. The GPMC node will provide an interrupt controller for the NAND IRQs. Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-10-12ARM: dts: Use defined GPIO constants in flags cell for OMAP2+ boardsJavier Martinez Canillas
Many OMAP2+ DTS are not using the defined constants to express the GPIO polarity. Replace these so the DTS are easier to read. Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-07-14ARM: dts: overo: Support PoP NANDAsh Charles
Some Overo COM models include NAND flash in the on-board package-on-package (PoP) chip. Add this to the base Overo devicetree. Most commonly, this is 512MB NAND from the Micron MT29C4G96MAZ family but, as discussed [1], several different sized are possible. To support different sizes, the last partition should fill to the end of the chip (i.e. MTDPART_SIZ_FULL). With thanks to Florian Vaussard for the original patch [2] and Adam Lee for updating it here. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/175760.html [2] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-June/175449.html Signed-off-by: Ash Charles <ashcharles@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-07-14ARM: dts: overo: Enable McBSP2 for all Overo COMsAdam YH Lee
Both Gumstix Overo and Overo Storm COMs use TWL4030 audio module connected to the McBSP2. As such, enable the McBSP2 module in the common device tree file, omap3-overo-base.dtsi, rather than in the processor-specific device tree files, omap3-overo.dtsi and omap3-overo-storm.dtsi. This corrects audio on the Storm COMs where the setting was accidentally missing from the device tree. Signed-off-by: Ash Charles <ashcharles@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2015-03-16ARM: dts: omap3: Remove all references to ti,codec propertyMarek Belisko
ti,codec property is not used (parsed) in omap-twl4030 driver. The ti,twl4030-audio which ti,codec points by phandle is mfd driver and device for ASoC codec is created w/o DT compatible string. Removing all references in DT files. Signed-off-by: Marek Belisko <marek@goldelico.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-03-12ARM: dts: overo: Push uart3 pinmux down to expansion boardFlorian Vaussard
UART3 is used by expansion boards to get a tty console. Thus, the pinmux should be defined by expansion boards, instead of being imposed by the processor board. Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-03-12ARM: dts: omap3-overo: Add HSUSB PHYFlorian Vaussard
Add the High-Speed USB PHY. Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> Acked-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-03-12ARM: dts: omap3-overo: Enable WiFi/BT comboFlorian Vaussard
MMC2 is used by the on-board WiFi module populated on some boards (based on Marvell Libertas 8688 SDIO). The Bluetooth is connected to UART2. Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-03-12ARM: dts: omap3-overo: Add missing pinctrlFlorian Vaussard
Add missing pinctrl entries for: - i2c1 - mmc1 Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-03-12ARM: dts: overo: reorganize include filesFlorian Vaussard
Currently, overo-related include files are organized as follow: omap3-overo.dtsi | | omap34xx.dtsi omap3-overo-tobi-common.dtsi omap36xx.dtsi | | | | --------------- --------------- | | omap3-overo-tobi.dts omap3-overo-storm-tobi.dts This is unpractical when one has to deal with SoC-specific pinmux belonging to the omap3_pmx_core2 (defined in omap34xx/omap36xx), for pins related to the processor board. With the current hierarchy, such pinmux has to be defined in the expansion board's .dts, which is not logical. This patches reorganizes the files to add (yet another) abstraction layer between the processor and the expansion boards. omap34xx.dtsi omap3-overo-base.dtsi omap36xx.dtsi | | | | --------------- --------------- | | omap3-overo.dtsi omap3-overo-storm.dtsi | | -------- ------ | omap3-overo-tobi-common.dtsi | | | | | --------------- --------------- | | omap3-overo-tobi.dts omap3-overo-storm-tobi.dts Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch> Signed-off-by: Tony Lindgren <tony@atomide.com>