'make dtbs' in a clean tree will try running the dtc before actually
building it. Make these rules depend upon the scripts to build it.
Cc: <stable@vger.kernel.org>
Signed-off-by: David Brown <davidb@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
During the p2v changes, the PHYS_OFFSET #define moved into a
!__ASSEMBLY__ section. This causes a XIP build to fail with
arch/arm/kernel/head.o: In function 'stext':
arch/arm/kernel/head.S:146: undefined reference to 'PHYS_OFFSET'
Momentarily leave the #ifndef __ASSEMBLY__ section so we can
define PHYS_OFFSET for all compilation units.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Thanks to Vaibhav <hvaibhav@ti.com> omap_device fix
(ARM: OMAP: omap_device: Fix up resource names when booted with devicetre),
we can now specify reg and interrupts using standard device tree
attributes.
Update the OMAP4 dtsi file with missing reg and interrupts attributes.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
The device/node resources (like, IORESOURCE_MEM and IORESOURCE_IRQ)
are overwritten by hwmod resources, due to all known reasons but
that should not be the reason for not providing all the information
in the DTS blob. Ideally we should use DTS resource and use HWMOD
framework wherever required and for only specific things.
Newer platforms like, OMAP5 and AM33XX, we only support DT boot mode,
so this patch is preparation for the future where we supposed to get
rid of hwmod dependency anyway.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
To make it consistent, convert all hex number presentation
to lower-case from all am33xx specific nodes.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Add the needed sections to enable audio support on BeagleBoard when booted
with DT blob.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
To be able to load the McPDM and DMIC driver when booted with device tree.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Create the sections describing the McBSP ports to be able to use them via
DT.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
In order to get the memory areas by name when booted with DT.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Create the sections describing the McBSP ports to be able to use them via
DT.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Create the needed sections to be able to probe McBSP ports via DT.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Since the board is based on OMAP2420 we should include the dedicated dtsi
file (which includes the common omap2 dtsi).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
The McBSP IP within OMAP2420 and 2430 is different we need to create separate
dtsi files for them.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Add the support for D6 and D7 LEDs on Beagle board.
- D6 will be used for heartbeat
- D7 will be used for mmc0
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Add device tree properties for twl4030/gpio, according to the
platform data of corresponding boards. This enables the led
connected to LEDB output for both boards, as well as
pullups/pulldowns on GPIO for the BeagleBoard.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Vaibhav Hiremath <hvaibhav@ti.com>
Remove some useless comment and move GIC controller outside
of the OCP node since it does use the MPU internal bus and
not the OCP.
This will not change the functionality but will reflect the
reality more accurately.
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Add cortex-a9 local timer support for all OMAP4 based
SOCs using DT.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Provide PL310 Level 2 Cache Controller Device Tree
support for OMAP4 based devices.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Device tree data for the EMIF sdram controllers in OMAP4
and LPDDR2 memory devices attached to OMAP4 boards.
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Tested-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Aneesh V <aneesh@ti.com>
[santosh.shilimkar@ti.com: Rebased against 3.6-rc]
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[b-cousson@ti.com: Use label in board to access EMIF nodes]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Add keypad data node in omap4 device tree file.
Also fill the device tree binding parameters
with the required value in "omap4-sdp" dts file.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
[b-cousson@ti.com: Re-align the entries and the comments]
Add keypad data node in omap5 device tree file.
Also fill the device tree binding parameters
with the required value in "omap5-evm" dts file.
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
[b-cousson@ti.com: Fix merge issue with MMC patches,
put node at the proper place, align entries and comments]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
With the new devices (like, AM33XX and OMAP5) we now only support
DT boot mode of operation and now it is the time to start killing
slowly the dependency on hwmod, so with this patch, we are starting
with device resources.
The idea here is implemented considering to both boot modes -
- DT boot mode
OF framework will construct the resource structure (currently
does for MEM & IRQ resource) and we should respect/use these
resources, killing hwmod dependency.
If pdev->num_resources > 0, we assume that MEM & IRQ resources
have been allocated by OF layer already (through DTB).
Once DMA resource is available from OF layer, we should
kill filling any resources from hwmod.
- Non-DT boot mode
Here, pdev->num_resources = 0, and we should get all the
resources from hwmod (following existing steps)
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
[b-cousson@ti.com: Fix some checkpatch CHECK issues]
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
DSI clocks are now configured dynamically by the DSI driver, so we can
remove the hardcoded clock configuration from the board file.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
HDMI requires vdda_hdmi_dac (vdac) power for operation. The regulator,
or the regulator supplying the vdac, has been enabled by default and
things have worked without the HDMI driver enabling the vdac.
I encountered the problem when implementing HDMI device tree support,
where the regulator was not enabled by default.
This patch adds the vdda_hdmi_dac to twl-common.c so that the HDMI
driver can use it.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
We currently manage HDMI GPIOs in the board files via
platform_enable/disable calls. This won't work with device tree, and in
any case the correct place to manage the GPIOs is in the HDMI driver.
This patch moves the handling of the GPIOs to the HDMI driver. The GPIO
handling is moved to the common hdmi.c file, and this probably needs to
be revisited when adding OMAP5 HDMI support to see if the GPIO handling
needs to be moved to IP specific files.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
when rebasing patches on top of Greg's tty-next,
it looks like automerge broke a few things which
I didn't catch (for whatever reason I didn't
have OMAP Serial enabled on .config) so I ended
up breaking the build on Greg's tty-next branch.
Fix the breakage by re-adding the three missing
members on struct uart_omap_port.
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Warnings were generated because following commit changed data type for
address pointer
195bbca ARM: 7500/1: io: avoid writeback addressing modes for __raw_ accessors
arch/arm/mach-tegra/tegra30_clocks.c: In function 'clk_measure_input_freq':
arch/arm/mach-tegra/tegra30_clocks.c:418:2: warning: passing argument 2 of '__raw_writel' makes pointer from integer without a cast
.../arch/arm/include/asm/io.h:88:20: note: expected 'volatile void *' but argument is of type 'unsigned int
Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Include linux/sizes.h to fix below build errors:
CC arch/arm/mach-ep93xx/adssphere.o
arch/arm/mach-ep93xx/adssphere.c: In function 'adssphere_init_machine':
arch/arm/mach-ep93xx/adssphere.c:32:49: error: 'SZ_32M' undeclared (first use in this function)
arch/arm/mach-ep93xx/adssphere.c:32:49: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [arch/arm/mach-ep93xx/adssphere.o] Error 1
make: *** [arch/arm/mach-ep93xx] Error 2
CC arch/arm/mach-ep93xx/gesbc9312.o
arch/arm/mach-ep93xx/gesbc9312.c: In function 'gesbc9312_init_machine':
arch/arm/mach-ep93xx/gesbc9312.c:32:49: error: 'SZ_8M' undeclared (first use in this function)
arch/arm/mach-ep93xx/gesbc9312.c:32:49: note: each undeclared identifier is reported only once for each function it appears in
make[1]: *** [arch/arm/mach-ep93xx/gesbc9312.o] Error 1
make: *** [arch/arm/mach-ep93xx] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Ryan Mallon <rmallon@gmail.com>
This patch adds,
- 4 G-Scaler devices to the DT device list
- G-Scaler specific entries to the machine file
- binding documentation for G-Scaler entries
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Leela Krishna Amudala <l.krishna@samsung.com>
Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Remove machine specific clock implementation and switch to use
new common clock framework.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
module_platform_driver simplifies the code by eliminating
module_init and module_exit calls.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
module_platform_driver simplifies the code by eliminating
module_init and module_exit calls.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
This enables support for Samsung and EXYNOS4 pinctrl driver for device
tree enabled EXYNOS4 platforms.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Add pinctrl driver nodes for the three instances of pin controllers
in SAMSUNG EXYNOS4210 SoC and add the pin group nodes available in the
each of those three instances.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Pinctrl driver includes support for configuring the external wakeup
interrupts. On exynos platforms that use pinctrl driver, the setup
of wakeup interrupts in the exynos platform code can be skipped.
Signed-off-by: Thomas Abraham <thomas.abraham@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Add assembler versions of AES and SHA1 for ARM platforms. This has provided
up to a 50% improvement in IPsec/TCP throughout for tunnels using AES128/SHA1.
Platform CPU SPeed Endian Before (bps) After (bps) Improvement
IXP425 533 MHz big 11217042 15566294 ~38%
KS8695 166 MHz little 3828549 5795373 ~51%
Signed-off-by: David McCullough <ucdevel@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Even though system suspend/resume hasn't been validated on Tegra yet,
this Kconfig option needs to be enabled so that system shutdown is
reliable on an SMP system. Without it, I2C interrupts may be routed
to CPU0, whereas shutdown code may be running on CPU1, causing I2C
timeouts, preventing communication with the external PMIC.
This reverts 3d5e8af "ARM: disable SUSPEND/ARCH_SUSPEND_POSSIBLE for
ARCH_TEGRA".
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tegra30 has more powerdomains than Tegra20. The debugfs code did not take this
into account.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
tegra_powergate_debugfs_init() always returns -ENOMEM. It shouldn't do that
when registering the debugfs entry succeeded.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Whistler uses a Maxim 8907 regulator. Instantiate this.
The voltage settings were derived from the schematic. The only exception
is the BBAT voltage; the schematic says 1.2v, but the HW can't go that
low, so use the HW default of 2.4v instead.
Almost all regulators list all driven supply signal names in their
regulator-names property. The exception is nvvdd_sv3, which is in turn
named 12 more different names on the schematic, so these were omitted
for brevity.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this.
Three data sources were used for the data encoded here:
* The HW defaults, as extracted from real HW.
* The schematic, which specifies a voltage for each rail in the signal
names.
* The AC100 kernel used by the Ubuntu port:
repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git
branch chromeos-ac100-3.0
file arch/arm/mach-tegra/board-paz00-power.c
For many rails, the constraints in that tree specified differing min
and max voltages. In all cases, the min value was ignored, since
there's no need currently to vary any of the voltages at run-time.
DVFS might change this in the future.
In most cases these sources all matched. Differences are:
sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max
of 1.3v, but this higher voltage was only applied to HW by DVFS code,
which isn't currently supported in mainline.
sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max
of 1.125v, but this higher voltage was only applied to HW by DVFS code,
which isn't currently supported in mainline.
ldo3: The HW default is on. marvin24's kernel didn't specify always-on,
but since the board wasn't marked as having fully constrained regulators,
the rail was not turned off, so the difference had no effect. The rail
is needed for USB.
ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However,
since this regulator is used for the same purpose as on other boards that
require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT
VDAC on Tegra, and so in practice is unlikely to be used, even though it
is actaully hooked up in HW.
Portions based on work by Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Marc Dietrich <marvin24@gmx.de> # v2
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Ventana uses a TPS6586x regulator. Instantiate this, and hook up a
couple of fixed GPIO-controlled regulators too.
The data was chosen to match the PMIC HW defaults, with the following
exception:
ldo6: The HW default is 2.85v. The schematics are unlabelled. Internal
research indicates that 1.8v is correct. Our downstream kernel also uses
1.8v.
Portions based on work by Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Seaboard uses a TPS6586x regulator. Instantiate this, and hook up a
couple of fixed GPIO-controlled regulators too.
Two data sources were used for the data encoded here:
* The HW defaults, as extracted from real HW.
* The schematic, which specifies a voltage for each LDO rail.
In most cases these sources matched. The only differences is:
ldo6: The HW default on Springbank is 2.85v. The HW default on Seaboard
is 1.8v. The schematics for both Springbank and Seaboard match at 2.85v.
However, internal research indicates that the schematics are incorrectly
labelled, and 1.8v is correct. The ChromeOS kernel also uses 1.8v.
Note that these settings don't entirely match those in the ChromeOS
kernel found at the URL below. However, the selected values generally
cause no behavior change in the kernel, and so were picked to avoid
regressions.
repo http://git.chromium.org/chromiumos/third_party/kernel.git
branch chromeos-3.2
file arch/arm/mach-tegra/board-seaboard-power.c
Portions based on work by Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Cadhu have multiple power rails which are controlled by
GPIOs. Add support of these power rail control through
fixed regulators. Add entry for all fixed regulators for
cardhu-a02 and a04.
The details are taken from downstream kernel.
Some points on this change are:
* Add the tps65910-LDO5 entry and make it always ON
to supply power to SDMMC. Once the sd driver support
regulator handling, this flag will be remove.
* Dropping registration of rail vdd_sdmmc1 as the gpio
is used by sdhci power-gpio. This need to fix in
sdhci driver and then need to add the registration
mechanism. Just removing power-gpio and adding fixed
regulator with this gpio is causing the sd access to
fail because first probe call of this regulator fails
due to non-available of parent and so it calls
gpio_free() which disable the pins in gpio mode make
pin output to LOW causes power to OFF. In probe retry,
it got success and it powered-on but it again need to
do again numeration of card here.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
There is multiple version of cardhu starting from A01 to A07.
Cardhu A01 and A03 are not supported. Cardhu A02 will have
different sets of GPIOs for fixed regulator compare to
cardhu A04. The Cardhu A05, A06, A07 are compatibe with A04.
Based on cardhu version, the related dts file need to be chosen
like for cardhu A02, use tegra30-cardhu-a02.dts, cardhu A04 and
more, use tegra30-cardhu-a04.dts.
This patch create the DTS file A02 and A04 and convert tegra30-cardhu.dts
as dts include file.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tegra30 based platform "cardhu" have the power management
IC TPS65911 for the regulator.
Adding DT entry for this device.
Data are chosen from downstream kernel and making the
voltage output as require by default for device to
operate.
The default interrupt line is HIGH from PMIC device and so
inverting the interrupt detection line of PMU interrupt
through configuring PMC.
In this patch, do not registering LDO5 because the input
supply for this rail is different for different version of
cardhu i..e A02 and A04. The registration will be done once
the dts file for cardhu A02 and A04 are added in follow on
patches.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
