This driver registers a restart handler to set a GPIO line high/low
to reset a board based on devicetree bindings.
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
According to Wikipedia, Innolux started out in 2003 as InnoLux Display
Corporation and merged with Chi Mei Optoelectronics in 2006. It went by
the name of Chimei Innolux Corporation for a while and changed its name
back to Innolux Corporation in late 2012.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Rob Herring <robh@kernel.org>
The stock ticker for Sitronix is just a number.
"sitronix,st1232" is already in use for the Sitronix st1232 touchscreen
controller on Atmark Techno Armadillo 800 EVA.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Rob Herring <robh@kernel.org>
Add Gateworks Corporation to the list of device tree vendor prefixes.
Gateworks designs and manufactures single board computers designed for
embedded wireless and wired network applications.
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Rob Herring <robh@kernel.org>
The kernel supports devices with the following compatible strings
already:
energymicro,efm32-i2c
energymicro,efm32-uart
energymicro,efm32-spi
energymicro,efm32-timer
So add "energymicro" to the list of vendors.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Recently we introduced the generic device tree infrastructure for couple of DMA
bus parameter, dma-ranges and dma-coherent. Update the documentation so that
its useful for future users.
The "dma-ranges" property is intended to be used for describing the
configuration of DMA bus RAM addresses and its offset w.r.t CPU addresses.
The "dma-coherent" property is intended to be used for identifying devices
supported coherent DMA operations.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Acked-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Document DT bindings used to describe the Qualcomm SPMI PMICs.
Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The rtc driver now supports PM8941 PMIC device, reflect this
in the binding document.
Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
ti,system-power-controller is more or less the standard way of
indicating that the PMIC is the system wide power controller and hence
may be used to switch off the system. Almost ALL TI PMIC drivers and
many Maxim PMIC drivers follow the same style.
So support 'ti,system-power-controller' in addition to the usual
'ti,use_poweroff' to indicate that the PMIC instance has control for
switching off the system.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The GPBR block provides a set of battery-backed registers that can be used
to save data which need to be kept when the system is powered down and
VDD-core is maintained by an external battery.
A typical usage is the RTT block (when used as an RTC) which needs one of
those registers to save the current time.
Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Acked-by: Johan Hovold <johan@kernel.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
STMPE now supports using a GPIO as an IRQ source. Document the device
tree binding for this option.
Signed-off-by: Sean Cross <xobs@kosagi.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This patch update DT binding to support INn_MODE init_data. Each
input signal path can be configurated either as a Analogue or
Digital using the INn_MODE registers.
Signed-off-by: Inha Song <ideal.song@samsung.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Add the device tree bindings documentation for the Amlogic Meson
variant of the Synopsys DesignWare MAC.
Signed-off-by: Beniamino Galvani <b.galvani@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull "Second SoC batch for 3.18" from Nicolas Ferre:
- introduction of the new SAMA5D4 SoC and associated Evaluation Kit
- low level soc detection and early printk code
- taking advantage of this, documentation of all AT91 SoC DT strings
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'at91-soc2' of git://github.com/at91linux/linux-at91:
ARM: at91: document Atmel SMART compatibles
ARM: at91: add sama5d4 support to sama5_defconfig
ARM: at91: dt: add device tree file for SAMA5D4ek board
ARM: at91: dt: add device tree file for SAMA5D4 SoC
ARM: at91: SAMA5D4 SoC detection code and low level routines
ARM: at91: introduce basic SAMA5D4 support
clk: at91: add a driver for the h32mx clock
Pull "part 2 of omap SoC changes" from Tony Lindgren:
Few hwmod changes to support upcoming 8250 driver with DMA,
start using the SRAM driver for some omaps, and update the
defconfig.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'soc-part2-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP4+: Remove static iotable mappings for SRAM
ARM: OMAP4+: Move SRAM data to DT
ARM: AM335x: Get rid of unused sram init function
ARM: omap2plus_defconfig: Enable some display features
ARM: omap2plus_defconfig: Enable battery and reset drivers
ARM: omap2plus_defconfig: Add support for distros with systemd
ARM: omap2plus_defconfig: Add cpufreq to defconfig
ARM: omap2plus_defconfig: Shrink with savedefconfig
ARM: OMAP3: Use manual idle for UARTs because of DMA errata
ARM: OMAP2+: Add hwmod flag for HWMOD_RECONFIG_IO_CHAIN
Merge "ARM: BCM: Broadcom BCM63138 support" from Florian Fainelli:
This patchset adds very minimal support for the BCM63138 SoC which is
a xDSL SoC using a dual Cortex A9 CPU complex.
* tag 'bcm63138-v4' of http://github.com/brcm/linux:
MAINTAINERS: add entry for the Broadcom BCM63xx ARM SoCs
ARM: BCM63XX: add BCM963138DVT Reference platform DTS
ARM: BCM63XX: add BCM63138 minimal Device Tree
ARM: BCM63XX: add low-level UART debug support
ARM: BCM63XX: add basic support for the Broadcom BCM63138 DSL SoC
Conflicts:
arch/arm/Kconfig.debug
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Pull AVS changes for v3.18 from Kevin Hilman:
- Add new driver for Rockchip IO voltage domains
- update MAINTAINERS to reflect maintenance of drivers/power/avs/*
* tag 'avs-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux:
MAINTAINERS: update entry for drivers/power/avs
PM / AVS: rockchip-io: add driver handling Rockchip io domains
IO domain voltages on some Rockchip SoCs are variable but need to be
kept in sync between the regulators and the SoC using a special
register.
A specific example using rk3288:
- If the regulator hooked up to a pin like SDMMC0_VDD is 3.3V then
bit 7 of GRF_IO_VSEL needs to be 0. If the regulator hooked up to
that same pin is 1.8V then bit 7 of GRF_IO_VSEL needs to be 1.
Said another way, this driver simply handles keeping bits in the SoC's
general register file (GRF) in sync with the actual value of a voltage
hooked up to the pins.
Note that this driver specifically doesn't include:
- any logic for deciding what voltage we should set regulators to
- any logic for deciding whether regulators (or internal SoC blocks)
should have power or not have power
If there were some other software that had the smarts of making
decisions about regulators, it would work in conjunction with this
driver. When that other software adjusted a regulator's voltage then
this driver would handle telling the SoC about it. A good example is
vqmmc for SD. In that case the dw_mmc driver simply is told about a
regulator. It changes the regulator between 3.3V and 1.8V at the
right time. This driver notices the change and makes sure that the
SoC is on the same page.
Signed-off-by: Heiko Stübner <heiko@sntech.de>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[khilman: fix compiler warnings]
Signed-off-by: Kevin Hilman <khilman@linaro.org>
Pull "Allwinner drivers additions for 3.18" from Maxime Ripard:
Nothing major, just handling the RTC driver changes needed for the A31/A23.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'sunxi-drivers-for-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux:
rtc: sunxi: Depend on platforms sun4i/sun7i that actually have the rtc
rtc: sun6i: Add sun6i RTC driver
Pull "Fifth Round of Renesas ARM Based SoC DT Updates for v3.18" from Simon Horman:
* Document manufacturer for KZM boards
* Use SoC-specific irqc compatible property
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'renesas-dt5-for-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: Add manufacturer for KZM boards
ARM: shmobile: r8a73a4 dtsi: Add SoC-specific irqc compatible property
Pull "ARM: tegra: core SoC code changes for 3.18" from Stephen Warren:
the primary change here gets its address information from DT rather than
iomap.h. This removes one more user of iomap.h, and will help allow the
code to move to a location that can be shared between arch/arm and
arch/arm64.
An unused header file was also removed.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
* tag 'tegra-for-3.18-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra:
ARM: tegra: remove unused tegra_emc.h
ARM: tegra: Initialize flow controller from DT
of: Add NVIDIA Tegra flow controller bindings
Pull devicetree bug fixes and documentation from Grant Likely:
"Several bug fix commits for issues found in the v3.17 rc series.
Most of these are minor in that they aren't actively dangerous, but
they have been seen in the wild. The one important fix is commit
7dbe5849fb ("of: make sure of_alias is initialized before accessing
it"), without which some powerpc platforms will fail to find stdout
for the console"
* tag 'devicetree-for-linus' of git://git.secretlab.ca/git/linux:
of/fdt: fix memory range check
of: Fix memory block alignment in early_init_dt_add_memory_arch()
of: make sure of_alias is initialized before accessing it
of: Documentation regarding attaching OF Selftest testdata
of: Disabling OF functions that use sysfs if CONFIG_SYSFS disabled
of: correct of_console_check()'s return value
Kishon writes:
Adds 3 new PHY drivers stih407, stih41x and rcar gen2 PHY. It also
includes miscellaneous cleanup of other PHY drivers.
Conflicts:
MAINTAINERS
These are the specific changes for ARM64 to make it possible to integrate the
DT based generic cpuidle driver in this tree.
It contains:
* The documentation for the DT definitions for ARM
* The refactoring of the cpu_suspend function for ARM64
* Introduce the cpu_idle_init function for ARM64
* Add the PSCI CPU SUSPEND based on the previous changes on cpu_suspend
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Merge "ARM: imx: device tree changes for 3.18" from Shawn Guo:
The i.MX device tree changes for 3.18:
- Device tree support for i.MX ADS and Armadeus APF9328 boards
- Enable thermal sensor support for i.MX6SL
- Add LCD support for i.MX6SL EVK board
- Fix display duplicate name for a bunch of board dts files
- Configure imx6qdl-sabresd board pins locally to remove the dependency
on bootloader
- A set of imx28-tx28 board dts updates from Lothar
- Add pci config space as platform resource
- Enable devices RTC, I2C and HDMI for nitrogen6x board
- Split HummingBoard DT to support s/dl and d/q
- mSATA and IR input support for HummingBoard
- Add SSI baud clock for i.MX6 device trees
- Add USB support for vf610-colibri and vf610-twr boards
- A set of cleanup and updates on Gateworks boards
* tag 'imx-dt-3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: (86 commits)
ARM: dts: imx6: make gpt per clock can be from OSC
ARM: dts: imx: ventana: add canbus support for GW52xx
ARM: dts: imx: ventana: cleanup pinctrl groups
ARM: dts: imx: ventana: configure padconf for all pins
ARM: dts: imx: ventana: use gpio constants
ARM: dts: imx: ventana: remove unused aliases
ARM: dts: imx: ventana: remove unsupported dt nodes
ARM: dts: imx28-tx28: add alias for CAN XCVR regulator
ARM: dts: imx28-tx28: add spi-gpio as alternative for spi-mxs
ARM: dts: imx28-tx28: use GPIO flags
ARM: dts: imx28-tx28: remove spidev labels and add third instance of spidev
ARM: dts: imx6sl: add baud clock and clock-names for ssi
ARM: dts: imx6qdl: add baud clock and clock-names for ssi
ARM: dts: imx6qdl-sabresd: Configure the pins locally
ARM: dts: imx28-m28evk: Fix display duplicate name warning
ARM: dts: imx28-tx28: Fix display duplicate name warning
ARM: dts: imx28-m28cu: Fix display duplicate name warning
ARM: dts: imx28-cfa100: Fix display duplicate name warning
ARM: dts: imx28-apf28dev: Fix display duplicate name warning
ARM: dts: imx28-apx4devkit: Fix display duplicate name warning
...
Signed-off-by: Olof Johansson <olof@lixom.net>
Add the missing 'compatible' property to device tree root node of
- mt6589-aquaris5.dts
and document the new values.
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Merge "soc: Keystone SOC Navigator drivers for 3.18" from Santosh Shilimkar:
Keystone SOC Navigator drivers for 3.18
The Keystone Multi-core Navigator contains QMSS and packet DMA
subsystems which interwork together to form the Navigator cloud
used by various subsystems like NetCP, SRIO, SideBand Crypto
engines etc.
* tag 'drivers-soc-ti-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone:
MAINTAINERS: Add Keystone Multicore Navigator drivers entry
soc: ti: add Keystone Navigator DMA support
Documentation: dt: soc: add Keystone Navigator DMA bindings
soc: ti: add Keystone Navigator QMSS driver
Documentation: dt: soc: add Keystone Navigator QMSS bindings
Signed-off-by: Olof Johansson <olof@lixom.net>
Add document describing device tree bindings for MAX14577 MFD
drivers: MFD core, extcon, regulator and charger.
Both MAX14577 and MAX77836 chipsets are documented.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The Keystone Navigator DMA driver sets up the dma channels and flows for
the QMSS(Queue Manager SubSystem) who triggers the actual data movements
across clients using destination queues. Every client modules like
NETCP(Network Coprocessor), SRIO(Serial Rapid IO) and CRYPTO
Engines has its own instance of packet dma hardware. QMSS has also
an internal packet DMA module which is used as an infrastructure
DMA with zero copy.
Initially this driver was proposed as DMA engine driver but since the
hardware is not typical DMA engine and hence doesn't comply with typical
DMA engine driver needs, that approach was naked. Link to that
discussion -
https://lkml.org/lkml/2014/3/18/340
As aligned, now we pair the Navigator DMA with its companion Navigator
QMSS subsystem driver.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
Multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kumar Gala <galak@codeaurora.org>
Cc: Olof Johansson <olof@lixom.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sandeep Nair <sandeep_n@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Currently the DP_PHY_ENABLE register is mapped in the driver,
and accessed to control power to the PHY.
With mfd-syscon and regmap interface available at our disposal,
it's wise to use that instead of using a 'reg' property for the
controller and allocating a memory resource for that.
To facilitate this, we have added another compatible string
for Exynso5420 SoC to acquire driver data which contains
different DP-PHY-CONTROL register offset.
Signed-off-by: Vivek Gautam <gautam.vivek@samsung.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This patch adds dt documentation bindings for the usb phy found
on STiH415/5 SoC's from STMicroelectronics, which support USB 1.1 and 2.0.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This patch adds the dt documentation for the usb picophy found on stih407 SoC family
available from STMicroelectronics.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This PHY, though formally being a part of Renesas USBHS controller, contains the
UGCTRL2 register that controls multiplexing of the USB ports (Renesas calls them
channels) to the different USB controllers: channel 0 can be connected to either
PCI EHCI/OHCI or USBHS controllers, channel 2 can be connected to PCI EHCI/OHCI
or xHCI controllers.
This is a new driver for this USB PHY currently already supported under drivers/
usb/phy/. The reason for writing the new driver was the requirement that the
multiplexing of USB channels to the controller be dynamic, depending on what
USB drivers are loaded, rather than static as provided by the old driver. The
infrastructure provided by drivers/phy/phy-core.c seems to fit that purpose
ideally. The new driver only supports device tree probing for now.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Some boards have this pin statically tied and do not require any configuration,
some other boards allow to enable chip using GPIO.
Add an option that tells which GPIO is used to power the audio codec.
Signed-off-by: Anatol Pomozov <anatol.pomozov@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
