From Kukjin Kim <kgene.kim@samsung.com>:
The branch includes updating each Samsung boards such as SMDK4X12,
Aquila, Goni and so on, and it is for audio platform device and
supporting of HSOTG or framebuffer.
* 'next/board-samsung-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: EXYNOS: Add framebuffer support for SMDK4X12
ARM: EXYNOS: Add HSOTG support to SMDK4X12
ARM: S5PV210: Add audio platform device in Goni board
ARM: S5PV210: Add audio platform device in Aquila board
ARM: EXYNOS: Add audio platform device in SMDKV310 board
ARM: S3C64XX: Don't specify an irq_base for WM1192-EV1 board
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From Sascha Hauer <s.hauer@pengutronix.de>:
i.MX clk noncritical fixes and updates
* tag 'imx-clk' of git://git.pengutronix.de/git/imx/linux-2.6:
ARM: imx: clk-imx31: Fix clock id for rnga driver
ARM: imx: add missing item to the list of clock event modes
ARM: i.MX5x CSPI: Fixed clock name for CSPI
ARM: i.MX5x clocks: Fix GPT clocks
ARM: i.MX5x clocks: Fix parent for PWM clocks
ARM: i.MX5x clocks: Add EPIT support
ARM: mx27: Reenable silicon version print
ARM: clk-imx27: Fix rtc clock id
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Patches from Alexander Shiyan <shc_work@mail.ru>:
* clps711x/cleanup:
ARM: clps711x: Remove the setting of the time
ARM: clps711x: Removed superfluous transform virt_to_bus and related functions
ARM: clps711x/p720t: Replace __initcall by .init_early call
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From Tony Lindgren <tony@atomide.com>:
Device tree related patches for omaps
* tag 'omap-devel-dt-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
arm/dts: New dts file for PandaBoardES (4460)
arm/dts: omap4-panda: Audio support for PandaBoard 4430
arm/dts: omap4-sdp: Enable audio support via device tree
arm/dts: omap4-sdp: Add support for twl6040
arm/dts: omap4-sdp: Add fixed regulator to represent VBAT
arm/dts: omap4: Add entry for OMAP DMIC IP
arm/dts: omap4: Add entry for OMAP McPDM IP
arm/dts: am33xx wdt node
arm/dts: remove MMC/SD and SPI related entries from am33xx.dtsi
watchdog: omap_wdt: add device tree support
ARM: OMAP: avoid build wdt platform device if with dt support
arm/dts: add wdt node for omap3 and omap4
arm/dts: OMAP4: Add Variscite OMAP4 System-On-Modeule support
arm/dts: Add support for AM335x BeagleBone
arm/dts: Add support for AM335x EVM
arm/dts: Add initial DT support for AM33XX SoC family
arm/dts: omap3-evm: Add i2c and twl4030 support
arm/dts: Add support for TI AM3517/05 EVM board
arm/dts: OMAP2: Add support for OMAP2420H4 Board
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Imported from mailing list
* picoxcell/timer:
clocksource: dw_apb_timer: Add common DTS glue for dw_apb_timer
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
From Tony Lindgren <tony@atomide.com>:
This branch adds clock data for am33xx. Note that eventually these
will use the common clock framework, but those patches are not quite
ready yet for omaps. This branch depends on omap-cleanup-part2-for-v3.6
branch.
* tag 'omap-devel-am33xx-data-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP3+: clock33xx: Add AM33XX clock tree data
ARM: OMAP3+: clock: Move common clksel_rate & clock data to common file
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Commit cb8ca5897 (ARM: omap3evm: enable VBUS switch for EHCI tranceiver)
added a new randconfig error if TWL4030_CORE is not selected:
arch/arm/mach-omap2/board-omap3evm.c:368: undefined reference to `twl_i2c_read_u8'
arch/arm/mach-omap2/board-omap3evm.c:370: undefined reference to `twl_i2c_write_u8'
Signed-off-by: Tony Lindgren <tony@atomide.com>
Move the irq_match arrays and the irq init functions of OMAP 2,3
and 4 based boards out of board-generic.c file and also rename the
irq init function to match the interrupt controller present in
the SOCs.
This is a preparatory patch to add the OMAP5 evm board's irq init
support with device tree.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Add OMAP5 SMP boot support using OMAP4 SMP code. The relevant code paths
are runtime checked using cpu id
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
OMAP4 and OMAP5 share same WakeupGen IP with below few udpates on OMAP5.
- Additional 32 interrupt support is added w.r.t OMAP4 design.
- The AUX CORE boot registers are now made accessible from non-secure SW.
- SAR offset are changed and PTMSYNC* registers are removed from SAR.
Patch updates the WakeupGen code accordingly.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The l3 interconnect ip is same for OMAP4 and OMAP5.
So reuse the l3 error handler error code for OMAP5
as well. Also a few targets has been newly added for
OMAP5. So updating the driver for that here.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
GPMC module is the same as in OMAP4.
Just update the base address and irq number.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Adding the Initialisaton for clocksource and clockevent device
on OMAP5 Socs.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
OMAP5430 is Texas Instrument's SOC based on ARM Cortex-A15 SMP
architecture. It's a dual core SOC with GIC used for interrupt
handling and with an integrated L2 cache controller.
OMAP5432 is another variant of OMAP5430, with a
memory controller supporting DDR3 and SATA.
Patch includes:
- The machine specific headers and sources updates.
- Platform header updates.
- Minimum initialisation support for serial.
- IO table init
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Adding the OMAP5 ES1.0, 2.0 and OMAP5432 cpu revision
detection support.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
If provided dt support, then skip add wdt platform device as usual.
Signed-off-by: Xiao Jiang <jgq516@gmail.com>
Reviewed-by: Jon Hunter <jon-hunter@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Currently most ads7846 config definitions for OMAP3 series boards have
been moved to common-board-devices.c, and it is transparent for init.
And it's no very proper to do gpio_request based on get_pendown_state
since omap_ads7846_init knows everything about ads7846_config.
So it's more fit to request gpio according to the right gpio_pendown
and set debounce time conditionally. If we don't set proper debouce
time, there are flooded interrupt counters of ads7846 responding to
one time touch on screen, then the driver couldn't work very well.
This patch has been validated on 3530evm.
Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This was chosen by following the trace on the schematic from component U131
and U134 to the CPEN pin on the USB3320 device.
TWL4030.GPIO2-...->(T2_GPIO2_3V3)U131-..>nUSB2_EN-..>U134-..>EXP_nUSB2_1V8
which starts EHCI tranceiver USB3320.
This will set TWL4030.GPIO2 as output pin to drive EHCI tranceiver.
Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
EHCI PHY requires these regulators:
EVM Rev >=E --> VAUX2
EVM Rev < E --> VUSB1V5, VUSB1V8
Adding USB internal LDOs (vusb1v5 & vusb1v8) and VAUX2 to omap3evm
board file. Also removing vaux2_{1/2/3} supplies as they are not
used on omap3 evm.
But we need not to add vaux2 in twl4030_platform_data since it will
be added conditionally.
Signed-off-by: Ajay Kumar Gupta <ajay.gupta@ti.com>
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
With omap_hwmod_get_main_clk() now available, this can be passed to
clk_get() to extract the fclk and thus avoid construction of fclk name.
Corrected the timer fck name mis-match between clock44xx_data.c and
omap_hwmod_44xx_data.c. For other platforms this is already taken care.
Cc: Cousson, Benoit <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Commit ac5b0ea3d (Merge tag 'omap-devel-f-for-3.6'...) had a merge
conflict that somehow got incorrecly resolved in a lossy way for
commit bed9d1bb (ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API).
Fix the issue by applying the missing pieces.
Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Kevin discovered that commit c8d82ff68f
("ARM: OMAP2/3: hwmod data: Add 32k-sync timer data to hwmod
database") broke CORE idle on OMAP3. This prevents device low power
states.
The root cause is that the 32K sync timer IP block does not support
smart-idle mode[1], and so the hwmod code keeps the IP block in
no-idle mode while it is active. This in turn prevents the WKUP
clockdomain from transitioning to idle. There is a hardcoded sleep
dependency that prevents the CORE_L3 and CORE_CM clockdomains from
transitioning to idle when the WKUP clockdomain is active[2], so the
chip cannot enter any device low power states.
It turns out that there is no need to take the 32k sync timer out of
idle. The IP block itself probably does not have any native idle
handling at all, due to its simplicity. Furthermore, the PRCM will
never request target idle for this IP block while the kernel is
running, due to the sleep dependency that prevents the WKUP
clockdomain from idling while the CORE_L3 clockdomain is active. So
we can safely leave the 32k sync timer in target-force-idle mode, even
while we continue to access it.
This workaround is implemented by defining a new clockdomain flag,
CLKDM_ACTIVE_WITH_MPU, that indicates that the clockdomain is
guaranteed to be active whenever the MPU is inactive. If an IP
block's main functional clock exists inside this clockdomain, and the
IP block does not support smart-idle modes, then the hwmod code will
place the IP block into target force-idle mode even when enabled. The
WKUP clockdomains on OMAP3/4 are marked with this flag. (On OMAP2xxx,
no OCP header existed on the 32k sync timer.) Other clockdomains also
should be marked with this flag, but those changes are deferred until
a later merge window, to create a minimal fix.
Another theoretically clean fix for this problem would be to implement
PM runtime-based control for 32k sync timer accesses. These PM
runtime calls would need to located in a custom clocksource, since the
32k sync timer is currently used as an MMIO clocksource. But in
practice, there would be little benefit to doing so; and there would
be some cost, due to the addition of unnecessary lines of code and the
additional CPU overhead of the PM runtime and hwmod code - unnecessary
in this case.
Another possible fix would have been to modify the pm34xx.c code to
force the IP block idle before entering WFI. But this would not have
been an acceptable approach: we are trying to remove this type of
centralized IP block idle control from the PM code.
This patch is a collaboration between Kevin Hilman <khilman@ti.com>
and Paul Walmsley <paul@pwsan.com>.
Thanks to Vaibhav Hiremath <hvaibhav@ti.com> for providing comments on
an earlier version of this patch. Thanks to Tero Kristo
<t-kristo@ti.com> for identifying a bug in an earlier version of this
patch. Thanks to Benoît Cousson <b-cousson@ti.com> for identifying
some bugs in several versions of this patch and for implementation
comments.
References:
1. Table 16-96 "REG_32KSYNCNT_SYSCONFIG" of the OMAP34xx TRM Rev. ZU
(SWPU223U), available from:
http://www.ti.com/pdfs/wtbu/OMAP34x_ES3.1.x_PUBLIC_TRM_vzU.zip
2. Table 4-72 "Sleep Dependencies" of the OMAP34xx TRM Rev. ZU
(SWPU223U)
3. ibid.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tero Kristo <t-kristo@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
The function __omap2_set_globals() can be common across all
platforms/architectures, even in case of omap4, internally it
calls same set of functions as in __omap2_set_globals() function
(except for sdrc).
This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc,
so that we can reuse same function across omap2/3/4...
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
As per recent discussion on the linux-omap list, we are
moving in the direction where, we will have only architecture,
ARCH_OMAP2PLUS and all devices/platforms will be treated
as a SoC underneath.
So the first step in this direction is to adopt this change
for all new devices getting in, converting
cpu_is_am33xx/335x() ==> soc_is_am33xx/335x()
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Initially, we decided to make am33xx family of device to fall
under omap3 class (cpu_is_omap34xx() = true), since it carries
Cortex-A8 core. But while adding complete baseport support
(like, clock, power and hwmod) support, it is observed that,
we are creating more and more problems by treating am33xx device
as omap3 family, as nothing matches between them
(except cortex-A8 mpu).
So, after long discussion we have came to the conclusion that,
we should not consider am33xx device as omap3 family, instead
create separate class (SOC_AM33XX) under OMAP2PLUS.
This means, for am33xx device, cpu_is_omap34xx() will return false,
and only cpu_is_am33xx() will be true.
Please refer to the link below, for mailing-list discussion on this -
http://www.spinics.net/lists/linux-omap/msg69439.html
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
[tony@atomide.com: fixed typo, updated for soc_is changes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
In order to remove unnecessary idefs, move noncore and core
dpll ops to dpll3xxx.c file (where it should have been already).
The clkops (clkops_omap3_core_dpll_ops & clkops_omap3_noncore_dpll_ops)
is used in clock data files, and dependency is already handled by
Makefile rule.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Miscellaneous OMAP clock, hwmod, clockdomain, and powerdomain patches
for 3.6. Mostly small infrastructure improvements, and preparation
for OMAP5 and AM33xx code.
Conflicts:
arch/arm/mach-omap2/omap_hwmod.c
arch/arm/plat-omap/include/plat/omap_hwmod.h
The commit 503d0ea24d
ARM: OMAP4: hwmod data: Add aliases for McBSP fclk clocks
added a wrong "prcm_clk" alias for PRCM clock whereas the McBSP
driver and previous OMAPs are using "prcm_fck".
It thus lead to the following warning.
[ 47.409729] omap-mcbsp: clks: could not clk_get() prcm_fck
Fix that by changing the opt_clk role to prcm_fck.
Reported-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Benoit Cousson <b-cousson@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: Sebastien Guiriec <s-guiriec@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The OMAP4 usb_host_fs (OHCI) and AESS IP blocks require some special
programming for them to enter idle. Without this programming, they
will prevent the rest of the chip from entering full chip idle.
To implement the idle programming cleanly, this will take some
coordination between maintainers. This is likely to take some time,
so it is probably best to leave this for 3.6 or 3.7. So, in the
meantime, prevent these IP blocks from being registered.
Later, once the appropriate support is available, this patch can be
reverted.
This second version comments out the IP block data since Benoît didn't
like removing it.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
The DMADISABLE bit is a semi-automatic bit present in sysconfig register
of some modules. When the DMA must perform read/write accesses, the
DMADISABLE bit is cleared by the hardware. But when the DMA must stop for power
management, software must set the DMADISABLE bit back to 1.
In cases where the ROMCODE/BOOTLOADER uses dma, the hardware clears the
DMADISABLE bit (but the romcode/bootloader might not set it back to 1).
In order for the kernel to start in a clean state, it is
necessary for the kernel to set DMADISABLE bit back to 1 (irrespective
of whether it's been set to 1 in romcode or bootloader).
During _reset of the (hwmod)device, the DMADISABLE bit is set so that it
does not prevent idling of the system. (NOTE: having DMADISABLE to 0,
prevents the system to idle)
DMADISABLE bit is present in usbotgss module of omap5.
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
[paul@pwsan.com: updated to apply; fixed checkpatch warnings]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Some prm and cm registers read/write and status functions
are built only for some custom OMAP2+ builds and are stubbed
in header files for other builds under ifdef statements.
But this results in adding new CONFIG_ARCH_OMAPXXX
checks when SOCs are added in the future. So move them
to a common place for OMAP2+ and make them 'weak' implementations.
This way no new ifdefs would be required in the future and also
cleans up the existing code.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
[paul@pwsan.com: unsplit quoted strings; moved PRM functions to
mach-omap2/prm_common.c; resolved sparse warnings]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The register is used to configure the behaviour of the CSI-2 and CCP-2
receivers. This register is available only in OMAP3630.
The original patch was submitted by Vimarsh Zutshi.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Vimarsh Zutshi <vimarsh.zutshi@gmail.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The wake-up power domain is an alway-on power domain and so this power domain
does not have a power state status (PM_PWSTST_xxx) register that indicates the
current state. However, during the registering of the wake-up power domain the
state of the domain is queried by calling pwrdm_read_pwrst(). This actually
tries to read a register that does not exist and returns a value of 0 that
indicates that the current state is OFF. The OFF state count of the wake-up
power domain is then set to 1 and the current state to OFF. Both of which are
incorrect.
To fix this, if a power domain only supports the ON state, do not attempt to
read the power state status register and simply return ON as the current power
state.
This is based upon Tony's current linux-omap master branch.
Testing:
- Boot tested on OMAP4460 panda.
- Boot tested on OMAP3430 beagle and validated CORE RET still working (using
Paul's 32k timer patch [1]).
[1] http://marc.info/?l=linux-omap&m=134000053229888&w=2
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
Acked-by: Kevin Hilman <khilman@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
[paul@pwsan.com: edited commit message slightly]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
