Add .dts and .dtsi file to support sama5d36ek board.
Also update the the comments for sama5d36 in sama5d3.dtsi.
Signed-off-by: NJosh Wu <josh.wu@atmel.com>
Acked-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NKevin Hilman <khilman@linaro.org>

This patch supplies I2C configuration to B2000 and B2020
based on either STiH415 or STiH416 SoCs.
Signed-off-by: NMaxime Coquelin <maxime.coquelin@st.com>
Acked-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>

This patch supplies I2C configuration to STiH415 SoC.
Signed-off-by: NMaxime Coquelin <maxime.coquelin@st.com>
Acked-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>

This patch supplies I2C configuration to STiH416 SoC.
Signed-off-by: NMaxime Coquelin <maxime.coquelin@st.com>
Acked-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>

This patch fixes a typo for OD define in st-pincfg header file.
Reported-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@st.com>

Some of the clocks that were designated gate-clk do not have a gate, so
change those clocks to be of periph-clk type.
Signed-off-by: NDinh Nguyen <dinguyen@altera.com>
Signed-off-by: NOlof Johansson <olof@lixom.net>

drivers/net/ethernet/smsc/smsc911x.c is expecting supplies named
"vdd33a" and "vddvario". Currently the shared DTS file provides
"vmmc" and "vmmc_aux", and the supply lookup will fail:

smsc911x 2c000000.ethernet: Looking up vdd33a-supply from device tree
smsc911x 2c000000.ethernet: Looking up vdd33a-supply property in node /ocp/gpmc@6e000000/ethernet@gpmc failed
smsc911x 2c000000.ethernet: Looking up vddvario-supply from device tree
smsc911x 2c000000.ethernet: Looking up vddvario-supply property in node /ocp/gpmc@6e000000/ethernet@gpmc failed

Fix it!

Looks like commmit 6b2978ac (ARM: dts: Shared file for omap GPMC
connected smsc911x) made the problem more visible by moving the smc911x
configuration from the omap3-igep0020.dts file to the generic file.
But it seems we've had this problem since commit d72b4415
(ARM: dts: omap3-igep0020: Add SMSC911x LAN chip support).

Tested on OMAP3 Overo platform.
Signed-off-by: NFlorian Vaussard <florian.vaussard@epfl.ch>
[tony@atomide.com: updated comments for the commits causing the problem]
Signed-off-by: NTony Lindgren <tony@atomide.com>

This adds typical McBSP2-TWL4030 audio description to the legacy
Beagle Board.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Mux mode for wlan/sdmmc5 should be MODE0 in pinmux_wl12xx_pins and
Enable Pull up on sdmmc5_clk to detect SDIO card.

This fixes WLAN on omap4-sdp that got broken in v3.10 when we
moved omap4 to boot using device tree only as I did not have
the WL12XX card in my omap4 SDP to test with. The commit that
attempted to make WL12XX working on omap4 SDP was 775d2418
(ARM: dts: Fix muxing and regulator for wl12xx on the SDIO
bus for blaze).
Signed-off-by: NBalaji T K <balajitk@ti.com>
[tony@atomide.com: updated comments for the regression]
Signed-off-by: NTony Lindgren <tony@atomide.com>

pin mux wl12xx_gpio and wl12xx_pins should be part of omap4_pmx_core
and not omap4_pmx_wkup. So, move wl12xx_* to omap4_pmx_core.

Fix the following error message:
pinctrl-single 4a31e040.pinmux: mux offset out of range: 0x38 (0x38)
pinctrl-single 4a31e040.pinmux: could not add functions for pinmux_wl12xx_pins 56x

SDIO card is not detected after moving pin mux to omap4_pmx_core since
sdmmc5_clk pull is disabled. Enable Pull up on sdmmc5_clk to detect SDIO card.

This fixes a regression where WLAN did not work after a warm reset
or after one up/down cycle that happened when we move omap4 to boot
using device tree only. For reference, the kernel bug is described at:

https://bugzilla.kernel.org/show_bug.cgi?id=63821

Cc: stable@vger.kernel.org # v3.10+
Signed-off-by: NBalaji T K <balajitk@ti.com>
[tony@atomide.com: update comments to describe the regression]
Signed-off-by: NTony Lindgren <tony@atomide.com>

This patch removes the old main clk node which is now useless as sama5d3
SoCs and boards are no longer compatible with the old at91 clk
implementations.

It also remove old clock definitions (clock definitions using at91 old clk
framework).
Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Define the main clock frequency for the new main clock node
in sama5d3xcm.dtsi.
Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Define sama5d3 clocks in sama5d3 device tree.
Add references to the appropriate clocks in each peripheral.
Signed-off-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Alias was missing for SoC of the at91sam9x5 familly that embed USART3.
Reported-by: NJiri Prchal <jiri.prchal@aksignal.cz>
[b.brezillon@overkiz.com: advised to place changes in at91sam9x5_usart3.dtsi]
Acked-by: NBoris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>

Almost all hardware parts of the NETGEAR ReadyNAS NV+ v2 ([1] for more
details) are supported by mainline kernel. The only missing elements in
provided .dts file are:

 - the front LCD module (Winstar WINSTAR WH1602): driver development is
   ongoing. This is the same LCD module as on ReadyNAS 104.
 - the Macronix MX25L512 512Kbit SPI flash: no time to play with it yet.

The device is the big brother (4 vs 2 bay) of the ReadyNAS Duo v2. The
main differences are some additional LEDs for the disks, a Marvell
88SM4140 SATA Port multiplier (no driver required to access the disk)
and previously described LCD module. Otherwise, it shares the same SoC
(kirkwood 88F6282), RAM (256MB), NAND (128MB), RTC chip (Ricoh rs5c372a),
fan controller (GMT G762), XHCI controller (NEC/Renesas µPD720200).

[1]: http://natisbad.org/NAS5/Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

All hardware parts of the (mv78230 Armada XP based) NETGEAR ReadyNAS
2120 are supported by mainline kernel (USB 3.0 and eSATA rear ports,
USB 2.0 front port, Gigabit controller and PHYs for the two rear ports,
serial port, LEDs, Buttons, 88SE9170 SATA controllers, three G762 fan
controllers, G751 temperature sensor) except for:

 - the Intersil ISL12057 I2C RTC Chip,
 - the Armada NAND controller.

Support for both of those is currently work in progress and does not
prevent boot.
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

This patch provides some whitespace cleanup for NETGEAR
ReadyNAS Duo v2 and 102 .dts files:

 - Fixed bad spaces
 - Added some space between nodes to improve readability
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The patch does some cleanup work on NETGEAR ReadyNAS 104 .dts
file. Changes are listed below:

 - Completed conversion from value to macros for GPIO voltage level
 - Converted all numeric input key values to macros
 - Fixed all node names and labels to use respectively '-' and '_'
 - Made button names more explicit
 - Changed order of included files from general to local
 - Removed useless clocks and gpio-keys properties
 - Document ethernet PHY (Marvell 88E1318) via a comment
 - Made G762 clock node name unique by including g762 in it
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The patch does some cleanup work on NETGEAR ReadyNAS 102 .dts
file. Changes are listed below

 - Added missing button mpp in pinctrl
 - Converted from value to macros for GPIO voltage level
 - Converted all numeric input key values to macros
 - Added GPIO keys pins to pinctrl
 - Made button names more explicit
 - Document ethernet PHY (Marvell 88E1318) via a comment
 - Made G762 clock node name unique by including g762 in it
 - Fixed all node names and labels to use respectively '-' and '_'
 - Changed order of included files from general to local
 - Removed useless clocks and gpio-keys properties
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

The patch does some cleanup work on NETGEAR ReadyNAS Duo v2 .dts
file. Changes are listed below:

 - Converted from value to macros for GPIO voltage level
 - Converted all numeric input key values to macros
 - Made button names more explicit
 - Document ethernet PHY (Marvell 88E1318) via a comment
 - Added header for the file to describe content and author
 - Made G762 clock node name unique by including g762 in it
 - Fixed all node names and labels to use respectively '-' and '_'
 - Changed order of included files from general to local
 - Removed useless clocks and gpio-keys properties
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NJason Cooper <jason@lakedaemon.net>

Beagle (rev. C4) and Beagle-XM (all revs) need VAUX2 1.8V supply
for the USB PHY.

As the generic PHY driver can't handle more than one supply
at the moment, we configure this supply to be always on.
This will cause a very small power impact if the USB host subsystem
is not in use, about 76.86 micro-W + LDO power.

Older Beagle boards (prior to C4) don't have VAUX2 connected anywhere,
so there won't be any functional impact on those boards other than
some additional LDO power consumption.
Reported-by: NNishanth Menon <nm@ti.com>
Tested-by: NNishanth Menon <nm@ti.com>
Signed-off-by: NRoger Quadros <rogerq@ti.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

On Device Tree boot the VDDS_DSI regulator is not linked to
the DPI device so omapfb driver probing fails with:

[    3.186035] OMAPFB: omapfb_probe
[    3.190704] omapdss DPI error: can't get VDDS_DSI regulator
[    3.196594] omapfb omapfb: failed to connect default display
[    3.202667] omapfb omapfb: failed to init overlay connections
[    3.208892] OMAPFB: free_resources
[    3.212493] OMAPFB: free all fbmem
[    3.216735] omapfb omapfb: failed to setup omapfb

As a workaround name the VPLL2 regulator from twl4030 as vdds_dsi
so getting the VDDS_DSI regulator will succeed on dpi_init_regulator().
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add node to support the USB Host and the USB OTG on the IGEP AQUILA
Processor Board.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@iseebcn.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The IGEP AQUILA EXPANSION has a 32KBit EEPROM for user data storage.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@iseebcn.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Enable the user leds on the IGEP AQUILA EXPANSION. The has two leds,
one green and one red, that are controllable by software.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@iseebcn.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Enable the hdmi output and the LCD Controller on IGEP AQUILA. Also
configure the correct pinmux for output of video data from the SoC
to the HDMI encoder.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

The IGEPv2 has a TFP410 DPI-to-DVI encoder attached to OMAP's
Display SubSystem (DSS).

Add mux setup for DSS pins and also for the GPIO 170 pin that
is used to ensure that the DVI-D is powered down on power up.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add pin muxing support for IGEP boards i2c controllers.
Signed-off-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Most of the boards are using the TI AM/DM37x processor, there is only a small
quantity of IGEP Processor Boards based on TI OMAP3530. So it's better use the
omap36xx.dtsi include instead of omap34xx.dtsi include. We can add support
for the 34xx based variant later on as needed.

To avoid confusion we have added to the model the (TI AM/DM37x) comment.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
[tony@atomide.com: updated comments for the 34xx to 36xx include change]
Signed-off-by: NTony Lindgren <tony@atomide.com>

The LBEE1USJYC is a WiFi/BT combo module used on OMAP3-based IGEP boards. In
both cases, IGEPv2 Rev. C and IGEP COM MODULE, the module is connected using
the same MMC interface and uses the same GPIOs.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Both, IGEPv2 and IGEP COM MODULE have a bus-width of 4 not 8, so fix this and
do not mux data pins from mmc1_data4 to mmc1_data7.
Signed-off-by: NEnric Balletbo i Serra <eballetbo@gmail.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Move the few remaining snowball pin configurations to the device
tree, reference these as hogs to the pin controller until there
are real devices that can make use of them.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This moves the Snowball LED pin config to the device tree.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The SPI0 block is not at all connected to the AB8500 on the
Snowball: it is connected to the external header. These pins
on the header may also be used for GPIO, but let's assume
that SPI is a probable usecase on the Snowball and mux in the
SPI block and use these for SPI.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This transfers the muxing and biasing of the ethernet-related
pins on the snowball over to the device tree.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Move the few remaining HREFv60 pin configurations to the device
tree, reference these as hogs to the pin controller until there
are real devices that can make use of them.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Put two extra configs into the device tree to handle the default
configuration of the display reset signals on the HREFv60plus,
move this over from the board file to the device tree.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Move the control of muxing and enabling the IPGPIO (image
processor GPIO) from the static set-up to the device tree.
Use a hog as we have no device for the flash controller yet.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This moves some of the pin setup related to the CW1200 WLAN
module over to the device tree. As the driver is not yet
activated for the CW1200 WLAN we do not assign this pinctrl
state to any device node yet.

Get rid of the cmdline argument passing of a certain U9500
platform variant, as this is not supported by the kernel or
any device tree.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This moves over the configuration of the GPIO keys (used for
proximity sensor and Hall effect sensor) from the static pin
configuration file to the device tree. As part of the exercise,
implement the GPIO keys properly in a per-UIB file as this
setup actually differs with each UIB.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>