Device tree conversion and enablement branch. Mostly a bunch of new
bindings and setup for various platforms, but the Via/Winchip VT8500
platform is also converted over from being 100% legacy to now use
device tree for probing. More of that will come for 3.8.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQaiKNAAoJEIwa5zzehBx329AP/1TwJk1dTHaAA7vDxyz2mq1E
F0MBL9p32R1SczrFGjbmb9ouVW5tTjbK1zted5zBrGBXDIX9Kdz3Dmm7x6b2/JvZ
8yMrdiBNpF3r8au6IaMuMlOq5yAaN+F4SxbC2rE0a9y3YmMZ6ug5dgoZ4O8orAC4
il3eq1sb+rTTPCf7C5cGlKzdRQi2KYdAycpa7ChQCYSamxJjdM7cXR7pohVv9vhd
9sF+h1I0ArxcVYn/mUOoCin8MyIWXlBQvbUnF+3aYO8CO9erhKH/owPngVBWGKZH
+X6dk0ChUJfjzaWr2HPZIYUqLUnIoO8TsRhQVmLp1rPrSzSXMG3iDq0M4WEwL4Xo
bMbAZ1KWYg53HRqbIOEQk5q9Mg7HUgtbJuOE7WLgBO5ubdKFFWLmDUJ+WVcoWzSW
qyWaWpECSptlQjFyqZJd9MjizIDhuYjog2EWaSWXETQ+1XRmCSsqx8AX6n1MVdhP
6jDLnYHYiJoOtGiaDpYxsXgMXdOVsrTegecNduqH/XhdEL1iwy3fwgK1DjoclYoj
iFbn0/Tw3N5SvJlG4xitl12DQ7MeCCbfzJGRKenVh9/O4U+qrTbFRmsNaaZw5dA1
bt+iEZ3aU8YBaKj02LexunAevpZJ2rfGNX2tBjQrIzzZK6CZibPWg42qfKJfdn7w
etXVVApw5jQjAImY64kh
=q7ZY
-----END PGP SIGNATURE-----
Merge tag 'dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM soc device tree updates from Olof Johansson:
"Device tree conversion and enablement branch. Mostly a bunch of new
bindings and setup for various platforms, but the Via/Winchip VT8500
platform is also converted over from being 100% legacy to now use
device tree for probing. More of that will come for 3.8."
Trivial conflicts due to removal of vt8500 files, and one documentation
file that was added with slightly different contents both here and in
the USb tree.
* tag 'dt' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (212 commits)
arm: vt8500: Fixup for missing gpio.h
ARM: LPC32xx: LED fix in PHY3250 DTS file
ARM: dt: mmp-dma: add binding file
arm: vt8500: Update arch-vt8500 to devicetree support.
arm: vt8500: gpio: Devicetree support for arch-vt8500
arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices
arm: vt8500: clk: Add Common Clock Framework support
video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb
serial: vt8500: Add devicetree support for vt8500-serial
rtc: vt8500: Add devicetree support for vt8500-rtc
arm: vt8500: Add device tree files for VIA/Wondermedia SoC's
ARM: tegra: Add Avionic Design Tamonten Evaluation Carrier support
ARM: tegra: Add Avionic Design Medcom-Wide support
ARM: tegra: Add Avionic Design Plutux support
ARM: tegra: Add Avionic Design Tamonten support
ARM: tegra: dts: Add pwm label
ARM: ux500: Fix SSP register address format
ARM: ux500: Apply tc3589x's GPIO/IRQ properties to HREF's DT
ARM: ux500: Remove redundant #gpio-cell properties from Snowball DT
ARM: ux500: Add all encompassing sound node to the HREF Device Tree
...
Most notable here is probably the addition of basic support for the
BCM2835, an SoC used in some of the Roku 2 players as well as the
much-hyped Raspberry Pi, cleaned up and contributed by Stephen
Warren. It's still early days on mainline support, with just the
basics working. But it has to start somewhere!
Beyond that there's some conversions of clock infrastructure on tegra
to common clock, misc updates for several other platforms, and OMAP
now has its own bus (under drivers/bus) to manage its devices through.
This branch adds two new directories outside of arch/arm:
drivers/irqchip for new irq controllers, and drivers/bus for the above
OMAP bus. It's expected that some of the other platforms will migrate
parts of their platforms to those directories over time as well.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJQaO2SAAoJEIwa5zzehBx3TBIQAJYc+vpAqiv8MLQ1XV3cLiIP
X57fxM9u1A+uXpXsiCTGR+ga8W4a5tlfGMXDBnl/K2bnFs2x11b9NkFLDJ7mdkih
J4c/iOWT/mT5suLnnybyg6ZGaxGkAKou2AumiSmkazmq5hGG67hkpAOqFEfDK0J2
Au7/6VN6GZXgiwt8nYaAB/qR5NVcww4m/6GQ2looaWgRLT/wgC3W2ZKvw6zEdl2J
OxOpwf2ujG/75zLQaxTeZ5rKnGtAXH4v0KhY9CWQacQPi4L2MVCrvUrDB4j0as4H
Wmsu7g6fZA9Vlf1aW/mlDY1ftozfbDaKORoYVS+CsWhm1oiQI5t+sAWRTkbbS85t
pobgKfFdvNsl9kS1zRdEddK2tyotwtXh2jz+P/s1l95hfqZ8IdVBJNMlcrHRINOI
2iQXFfGRhCCqMcfFiGXJ43tYja/aCsaIc4M5TrEma57czZT5jK8HSLh0ZUmFYDoe
/TfUegVhFASmkNTk7dVZgZ2UoQVkv4lWs+xuf8YgX3UalWgl/YIRRFl4NnylGlEc
jjrX3MjXATqXzLPEZaf8dRZHIpB6FYmZq1QqaoefcUQ46gBOueThElZP3sNWR8a2
MOtknauLfLwQbrcH5CmqKpIpXTB4LKgbf/omH2jQlxBhQ5t7PXHVD1NFsbZbwM8J
RVCZb4PwqEwOt/wibTrk
=BCp4
-----END PGP SIGNATURE-----
Merge tag 'soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM soc-specific updates from Olof Johansson:
"Most notable here is probably the addition of basic support for the
BCM2835, an SoC used in some of the Roku 2 players as well as the
much-hyped Raspberry Pi, cleaned up and contributed by Stephen Warren.
It's still early days on mainline support, with just the basics
working. But it has to start somewhere!
Beyond that there's some conversions of clock infrastructure on tegra
to common clock, misc updates for several other platforms, and OMAP
now has its own bus (under drivers/bus) to manage its devices through.
This branch adds two new directories outside of arch/arm:
drivers/irqchip for new irq controllers, and drivers/bus for the above
OMAP bus. It's expected that some of the other platforms will migrate
parts of their platforms to those directories over time as well."
Fix up trivial conflicts with the clk infrastructure changes.
* tag 'soc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (62 commits)
ARM: shmobile: add new __iomem annotation for new code
ARM: LPC32xx: Support GPI 28
ARM: LPC32xx: Platform update for devicetree completion of spi-pl022
ARM: LPC32xx: Board cleanup
irqchip: fill in empty Kconfig
ARM: SAMSUNG: Add check for NULL in clock interface
ARM: EXYNOS: Put PCM, Slimbus, Spdif clocks to off state
ARM: EXYNOS: Add bus clock for FIMD
ARM: SAMSUNG: Fix HDMI related warnings
ARM: S3C24XX: Add .get_rate callback for "camif-upll" clock
ARM: EXYNOS: Fix incorrect help text
ARM: EXYNOS: Turn off clocks for NAND, OneNAND and TSI controllers
ARM: OMAP: AM33xx hwmod: fixup SPI after platform_data move
MAINTAINERS: add an entry for the BCM2835 ARM sub-architecture
ARM: bcm2835: instantiate console UART
ARM: bcm2835: add stub clock driver
ARM: bcm2835: add system timer
ARM: bcm2835: add interrupt controller driver
ARM: add infra-structure for BCM2835 and Raspberry Pi
ARM: tegra20: add CPU hotplug support
...
* 'for-arm-soc-next' of git://git.linaro.org/people/ljones/linux-3.0-ux500:
ARM: ux500: Fix SSP register address format
ARM: ux500: Apply tc3589x's GPIO/IRQ properties to HREF's DT
ARM: ux500: Remove redundant #gpio-cell properties from Snowball DT
ARM: ux500: Add all encompassing sound node to the HREF Device Tree
ARM: ux500: Add nodes for the MSP into the HREF Device Tree
ARM: ux500: Add all known I2C sub-device nodes to the HREF DT
ARM: ux500: Stop registering I2C sub-devices for HREF when DT is enabled
ARM: ux500: Stop registering Audio devices for HREF when DT is enabled
ARM: ux500: Add all encompassing sound node to the Snowball Device Tree
ARM: ux500: Add nodes for the MSP into Device Tree
ARM: ux500: Rename MSP board file to something more meaningful
ARM: ux500: Remove platform registration of MSP devices
ARM: ux500: Stop registering the MOP500 Audio driver from platform code
ARM: ux500: Pass MSP DMA platform data though AUXDATA
ARM: ux500: Fork MSP platform registration for step-by-step DT enablement
ARM: ux500: Add AB8500 CODEC node to DB8500 Device Tree
ARM: ux500: Clean-up MSP platform code
ARM: ux500: Pass SDI DMA information though AUX_DATA to MMCI
ARM: ux500: Add UART support to the HREF Device Tree
ARM: ux500: Add skeleton Device Tree for the HREF reference board
...
+ sync to v3.6-rc6
Misc SoC-related fixes/cleanups for Samsung platforms
* 'next/devel-samsung' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
ARM: SAMSUNG: Add check for NULL in clock interface
ARM: EXYNOS: Put PCM, Slimbus, Spdif clocks to off state
ARM: EXYNOS: Add bus clock for FIMD
ARM: SAMSUNG: Fix HDMI related warnings
ARM: S3C24XX: Add .get_rate callback for "camif-upll" clock
ARM: EXYNOS: Fix incorrect help text
ARM: EXYNOS: Turn off clocks for NAND, OneNAND and TSI controllers
+ sync to 3.6-rc6
The Tegra code-base has contained both a legacy DMA and a dmaengine
driver since v3.6-rcX. This series flips Tegra's defconfig to enable
dmaengine rather than the legacy driver, and removes the legacy driver
and all client code.
The branch is based on v3.6-rc6 in order to pick up a bug-fix to the
ASoC Tegra PCM driver that's required for audio to work correctly when
using dmaengine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAABAgAGBQJQV0gxAAoJEMzrak5tbycx9mIP/0uU4fVrAyIgbRkJ7nrPS/K7
vRKEfYJlXqr4zM79i3flpD/QPK6ImWcj0RptrdU3851yjVGkSehp8wbozKoBVDXQ
ZqPEBG039Vshmum/AD6Km3LSl4LBYurNJp/OC7ms5r0jIsU2IxZYaoofLGPXmgwn
LTlsG35Y/Bug6P4bbSNPhR/9CFAe695oQgvkIMnYROwVZTmQwu7Xh1CE2moKMEJN
top1Z3tZ+gtbb84eU1KR9BSNXAhQi7S7d4vWJe3RjnrhuSTVMIxiyNZSFjt8DrLL
7THzpmY/K2qV9k6CAO7bTl9X6m9cw8j+IbN6Ljc1NjbBiMcFe3TQRwFXicmt/Pma
VPjppGIfTUzC9WJI5Tj8GOV6I6B6X5oCSILcXjeJpNE3TEvdLnVXhiclbhiVuB/0
j9x0+w1SMfRr8RtsMvZyZHy1XQ+WJg/rXojGxLEsKJrZmmJ7yRkfqIr/Q9nSrh87
KYHhy8lsOuSPXq1qEVKQLwenc1VPbbDcDow1fBURPmz1CFCvNnR/mWtY2uCu5gk/
XPcqZu5I/T7DlrNGTfYCZbOow67tfHgAxW5MYLPXV+Fqkj1l9EimUGW5fIq7S6bA
2ouTuCS1e79d9kFLjgAzdbfqtdjy93v7G5vlBV7gUIrMg5PtGnQvQK9ab/YzasOt
XtP5p/eeV8NDo3MCw3+b
=4eRL
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-3.7-dmaengine' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra into next/cleanup
ARM: tegra: switch to dmaengine
The Tegra code-base has contained both a legacy DMA and a dmaengine
driver since v3.6-rcX. This series flips Tegra's defconfig to enable
dmaengine rather than the legacy driver, and removes the legacy driver
and all client code.
* tag 'tegra-for-3.7-dmaengine' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra:
ASoC: tegra: remove support of legacy DMA driver based access
spi: tegra: remove support of legacy DMA driver based access
ARM: tegra: apbio: remove support of legacy DMA driver based access
ARM: tegra: dma: remove legacy APB DMA driver
ARM: tegra: config: enable dmaengine based APB DMA driver
+ sync to 3.6-rc6
work properly with sparse IRQ. It also removes
dependencies to mach/hardware.h. These help moving
things towards ARM single zImage support.
This branch is based on a commit in tty-next
branch with omap-devel-gpmc-fixed-for-v3.7 and
cleanup-omap-tags-for-v3.7 merged in to keep things
compiling and sort out some merge conflicts.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQUUgbAAoJEBvUPslcq6VzsEgQANbHSsPDajdFnaCn3goS16M3
Nwmnvqd3Ay4VqhLpJuiF9SWzPtCno0gu/9caUKhodYDrHDVttdMKQWKLsmkSPFOD
uHnKToA3y0J5O/KQJB+bubinZvcHNnBwCgP6YFposFwH561aCRhp4DiCIlqAiqlV
g6jyEtTkOrIyHULokgFSmWrLDcTxvx4lWyZbmeltju4KXzzfPojc6m4daVN9Z3cQ
VP9+6mLuJcF/aIbdyGnxg7pgsfy6+roHI1+vHfufVEyTt1funm1Mt1Wq+kUFC0XW
YRQILq82tr3OgvcB3xmXllE3XcklN4Vv922Up0fQ+8OV36jA2q6N5vTsk8fctuD4
8O+j4kmomCEavj2JEIB5SFfsZ+Cdycx79+1pvOtDSYOM7svFpQs6kdhq+JXGRSql
W00xgLQj82tmXpaLV36pXPGoc7ZXQolQbc6SYFQn8oHTTvHDdFiQkG5TKafj7r5u
ayaV/VqytSy+Hiq8XWNpEjfxn467fQ5UmHXQoVAIZnpk323SpPbLQ5aDOMk/9+DT
u0mDnIP4k6w8ViTnalLPEBOqqpZZo358t+cRD1kD55X4IR2YPSFhrhJTq23Z9Rv3
EW9ZUQYrK6WDuYO8/4SZ1J/HTx5MFb1Na6dKAXwO3v0S7CBzIbN9gqbU7IxfQ8ZA
qKT726r923PHKL2x8VZc
=GLSh
-----END PGP SIGNATURE-----
Merge tag 'omap-cleanup-sparseirq-for-v3.7' into devel-dt
This branch contains changes needed to make omap2+
work properly with sparse IRQ. It also removes
dependencies to mach/hardware.h. These help moving
things towards ARM single zImage support.
This branch is based on a commit in tty-next
branch with omap-devel-gpmc-fixed-for-v3.7 and
cleanup-omap-tags-for-v3.7 merged in to keep things
compiling and sort out some merge conflicts.
Conflicts:
arch/arm/mach-omap2/omap4-common.c
drivers/gpio/gpio-twl4030.c
should now boot on mainline after this is applied, according to
Vaibhav.
This second version includes trailing commas at the end of structure
records at Tony's request. It also adds a OMAP_INTC_START macro
expansion to each IRQ number to make the sparseirq conversion easier.
Basic build, boot, and PM test transcripts are here:
http://www.pwsan.com/omap/testlogs/am33xx_hwmod_clock_devel_3.7/20120912165952/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQURsaAAoJEMePsQ0LvSpLl24QAIMeCOw7z+SEjOetmWPRekS6
uPj9mz7EkWjBITMAPToQ7v9oESn+M0jcaD7wkOKaVBhPj6shXUwaMy6KmcZ5BuKf
1zrjL57ljhVLYumX8sKO3vPfKt1JvRCvcgu7xtgDKc9ywmuJLqolbi9BNxh/xo94
7IQHJk6Snrz6DxRTcvX2jUOwHG5o8WCGjPST5ZTQCKQKdpxKyeUILrhddbJMQdaq
U7DTxZVdk75KM0dbt8wVRP7AWczh8TLBEKR/bsWF47g/iL0neMDuLXyfrOd0A5ct
+JyGycl5a6lF/TiTQ7Is36s0uquidKozIx+2PwCdJGX/ntvme1wOZUGq1NSET/sw
/Uos1NjJqhM1wLPL0AbuJ8hQlZkvZThYL6c0a+GSxKGKE2dtk5ZH8vC/JMv17u21
RUzxjq1rDZVGYnm3CtO305kzQYxdUu/7aBMCE29gWKrlPr8Pz2O6wvkFePja9Qxe
YmlxakogwpFkmMaQ3eeN14VEuXCd7c2i1o8XiF/9ph250qzzKd6wTSra6Xggd32L
17GXtAfGWySqgFhb3Mfupbbr/lWGSFLeW2NhT7ZGsORvTC8J4KCql0r7f9V0/1WH
DjUcljoYF15CdOxh71vIsUOKDqN0RtyRIgeBXaIam8RDNhaF5WJjjtiIbFIS4EAm
Xw9zTjalQzJnbivxz/cy
=yRjp
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-a2-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into devel-am33xx
AM33xx hwmod data and miscellaneous clock and hwmod fixes. AM33xx
should now boot on mainline after this is applied, according to
Vaibhav.
This second version includes trailing commas at the end of structure
records at Tony's request. It also adds a OMAP_INTC_START macro
expansion to each IRQ number to make the sparseirq conversion easier.
Basic build, boot, and PM test transcripts are here:
http://www.pwsan.com/omap/testlogs/am33xx_hwmod_clock_devel_3.7/20120912165952/
These changes fix some of the more meaningful warnings that smatch
returns for the OMAP subarch code, and unwraps strings that are
wrapped at the 80-column boundary, to conform with the current
practice.
Basic build, boot, and PM logs are available here:
http://www.pwsan.com/omap/testlogs/warnings_a_cleanup_3.7/20120912025927/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQUKL1AAoJEMePsQ0LvSpL+a8QAJlJR9uwqUKu60GfbQEeegce
k6pr0xXYvHEmbro/v6O4ezs2o716EBgwBWnId97oOZvVnwhPbEHR87UH8FFOIWOQ
+/ui5MxXtYWNjYcDOzdF95reFM1szAAxQu8k9wXg+WBtZ4zCkhknpoftShRbOdg0
BgO0r1iY/wuoFaYgGFKSNdObPVgSTENjbtg/LVvB/V3PQjYmUBosJVH0tPO/LQio
pWhozfFuiWbARYxPg6dMOn8yQ5mCeWErpv4WZjM+dgcrkLYyPdI2uUS3Ka8F7Az2
ImC+k0gU6WwkjyKqv/SG2wg5+3Sh8ZZsX0EKXwq0gQEmLWacENS1ELRT3+HcxGru
HoAhE46URb4NGzBt7rkIkGg0HcajfORDtZSrGfsEclDmrVV5+JgUzC+PEDiwSxVU
LqpJIZ8lxjqBNPSlmXqtEgTG32M6E9fDII8JdGC64vUv+vXzuhpJCXF78I8+A+Hv
oSBbTOCzYGz1xp06G6Hzadpo5I1LocBRemsnhw2O9oNDdUZxiGo/qJcWfk2wpMQ6
4c/kHbYEsJ6/7eVe5kNtdkeptAXp1AFO5XIhQpSAs1O1Rr++nDNahaUJA56xev8x
GoEZCYLGMGpQnINW6g0Srzwp8n1ywSgt3Gt2fbDTAP+Q02DPT3IIWWs4LlIDIrjZ
w0q1kAp1+In5is3pxJvT
=ythb
-----END PGP SIGNATURE-----
Merge tag 'omap-cleanup-b-for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-makefile-sparse
smatch and string-wrapping cleanups for the OMAP subarch code.
These changes fix some of the more meaningful warnings that smatch
returns for the OMAP subarch code, and unwraps strings that are
wrapped at the 80-column boundary, to conform with the current
practice.
Basic build, boot, and PM logs are available here:
http://www.pwsan.com/omap/testlogs/warnings_a_cleanup_3.7/20120912025927/
As the plat and mach includes need to disappear for single zImage work,
we need to remove plat/hardware.h.
Do this by splitting plat/hardware.h into omap1 and omap2+ specific files.
The old plat/hardware.h already has omap1 only defines, so it gets moved
to mach/hardware.h for omap1. For omap2+, we use the local soc.h
that for now just includes the related SoC headers to keep this patch more
readable.
Note that the local soc.h still includes plat/cpu.h that can be dealt
with in later patches. Let's also include plat/serial.h from common.h for
all the board-*.c files. This allows making the include files local later
on without patching these files again.
Note that only minimal changes are done in this patch for the
drivers/watchdog/omap_wdt.c driver to keep things compiling. Further
patches are needed to eventually remove cpu_is_omap usage in the drivers.
Also only minimal changes are done to sound/soc/omap/* to remove the
unneeded includes and to define OMAP44XX_MCPDM_L3_BASE locally so there's
no need to include omap44xx.h.
While at it, also sort some of the includes in the standard way.
Cc: linux-watchdog@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Liam Girdwood <lrg@ti.com>
Acked-by: Wim Van Sebroeck <wim@iguana.be>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Find and unwrap wrapped strings in the style:
pr_debug("clockdomain: hardware cannot set/clear wake up of "
"%s when %s wakes up\n", clkdm1->name, clkdm2->name);
Keeping these strings contiguous seems to be the current Linux kernel
policy.
The offending lines were found with the following command:
pcregrep -rnM '"\s*$\s*"' arch/arm/*omap*
While here, some messages have been clarified, some pr_warning(
... calls have been converted to pr_warn( ..., and some printk(KERN_*
... have been converted to pr_*.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Resolve the following warnings from smatch:
arch/arm/mach-omap2/gpmc.c:282 gpmc_cs_set_timings() info: why not propagate 'div' from gpmc_cs_calc_divider() instead of -1?
arch/arm/mach-omap2/serial.c:328 omap_serial_init_port() error: 'pdev' dereferencing possible ERR_PTR()
arch/arm/mach-omap2/timer.c:213 omap2_gp_clockevent_init() Error invalid range 4096 to -1
arch/arm/mach-omap2/gpio.c:63 omap2_gpio_dev_init() warn: possible memory leak of 'pdata'
arch/arm/mach-omap2/omap_hwmod.c:1478 _assert_hardreset() warn: assigning -22 to unsigned variable 'ret'
arch/arm/mach-omap2/omap_hwmod.c:1487 _assert_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same.
arch/arm/mach-omap2/omap_hwmod.c:1545 _read_hardreset() warn: assigning -22 to unsigned variable 'ret'
arch/arm/mach-omap2/omap_hwmod.c:1554 _read_hardreset() warn: 4294963201 is more than 255 (max '(ret)' can be) so this is always the same.
arch/arm/mach-omap2/dpll3xxx.c:629 omap3_clkoutx2_recalc() error: we previously assumed 'pclk' could be null (see line 627)
arch/arm/mach-omap2/board-n8x0.c:422 n8x0_mmc_late_init() Error invalid range 14 to 13
arch/arm/mach-omap1/leds-h2p2-debug.c:71 h2p2_dbg_leds_event() error: potentially derefencing uninitialized 'fpga'.
arch/arm/plat-omap/mux.c:79 omap_cfg_reg() Error invalid range 4096 to -1
Thanks to Tony Lindgren <tony@atomide.com> for pointing out that BUG()
can be disabled. The changes in the first version that removed the
subsequent return() after BUG() states have been dropped.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
AM33XX PRCM architecture is different that any OMAP family
of devices, so it is required to have separate implementation
to handle AM33XX module enable/disable, reset assert/deassert
functionality.
This patch adds wrapper api's in omap_hwmod framework to
access prm/cm for AM33XX family of devices.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
[paul@pwsan.com: fixed checkpatch messages]
Signed-off-by: Paul Walmsley <paul@pwsan.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>
Clock and module mode are explictly enable when hwmod is enabled. But if
the hwmod doesn't get ready on time, clocks are disabled but module is left
enabled.
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
These are various power management related changes, mainly concerning
cpuidle on i.MX and OMAP, as well as a the move of the omap smartreflex
driver to live in the power subsystem.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIVAwUAUA2dhWCrR//JCVInAQLuqRAA1FxxzAMTESs3/rpjnQmZUUKef4SuJwY2
GBenXFLY5PlxgcrwTbKwepapu8IWfmw171+tRrrMWvQgtBwa+SefwFCaLcRkvRrs
kNAHIVI+Gqm4/m6d+WC+ymJLOZdkcTHES+40eycxcjiIElGEMtiW5/qwh060GAgC
YxtjoN9BKegjsDLPZdZghO855YUV8CKEg+q5kIYW0Q3Ci0POGvOhgvbI61K5w8z7
fTdbFRDRBqy0BEx9noKTu8XIB/inwlyUY7N3bAv494TsU48kxMIb95FdSGiY/0yV
1883wCacBYBNemWRvWBHNilSsDcuDmM3yNvdwi3JvQnzFBPc8uyze9wbPFOW4aQd
Vhf+g8hjuHkw1xreWpO+nREysOjiiSzRUci2nT6aAQTcpWCacVTJ5sW7KOQ63nrH
OQpe/fvm/qT8FKPDh/lcrqIUKrHfeFjZx7XlYjw7j0ZL+99mIpwuOql18mQee9G5
OV6c0rfgeTnGLdc1kOlLPElkXe7SQ/GJK1JI1mA5BNYJlVKx+o0qVlcnRzY6bWaP
dmSIA+9Bs/fglvmAQHT3u68zn5KfoTbnJWb0v5PQJfitEBdlugKG8nF9mVRIX70X
EygOta8vApF9N20WhE2TLLaDhlrOmd4bOtRVdoO8pDVN/hsWIylnEu952ZBSZg3U
9wF0Ydy2LP4=
=tgT5
-----END PGP SIGNATURE-----
Merge tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull arm-soc power management changes from Arnd Bergmann:
"These are various power management related changes, mainly concerning
cpuidle on i.MX and OMAP, as well as a the move of the omap
smartreflex driver to live in the power subsystem."
Fix up conflicts in arch/arm/mach-{imx/mach-imx6q.c,omap2/prm2xxx_3xxx.h}
* tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (37 commits)
ARM: OMAP2+: PM: fix IRQ_NOAUTOEN removal by mis-merge
ARM: OMAP2+: do not allow SmartReflex to be built as a module
ARM: OMAP2: Use hwmod to initialize mmc for 2420
ARM: OMAP3: PM: cpuidle: optimize the clkdm idle latency in C1 state
ARM: OMAP3: PM: cpuidle: optimize the PER latency in C1 state
ARM: OMAP3: PM: cpuidle: default to C1 in next_valid_state
ARM: OMAP3: PM: cleanup cam_pwrdm leftovers
ARM: OMAP3: PM: call pre/post transition per powerdomain
ARM: OMAP2+: powerdomain: allow pre/post transtion to be per pwrdm
ARM: OMAP3: PM: Remove IO Daisychain control from cpuidle
ARM: OMAP3PLUS: hwmod: reconfigure IO Daisychain during hwmod mux
ARM: OMAP3+: PRM: Enable IO wake up
ARM: OMAP4: PRM: Add IO Daisychain support
ARM: OMAP3: PM: Move IO Daisychain function to omap3 prm file
ARM: OMAP3: PM: correct enable/disable of daisy io chain
ARM: OMAP2+: PRM: fix compile for OMAP4-only build
W1: OMAP HDQ1W: use runtime PM
ARM: OMAP2+: HDQ1W: use omap_device
W1: OMAP HDQ1W: use 32-bit register accesses
W1: OMAP HDQ1W: allow driver to be built on all OMAP2+
...
This adds support for three new SoC types:
* The mvebu platform includes Marvell's Armada XP and Armada 370 chips,
made by the mvebu business unit inside of Marvell. Since the same
group also made the older but similar platforms we call "orion5x",
"kirkwood", "mv78xx0" and "dove", we plan to move all of them into
the mach-mvebu directory in the future.
* socfpga is Altera's platform based on Cortex-A9 cores and a lot of
FPGA space. This is similar to the Xilinx zynq platform we already
support. The code is particularly clean, which is helped by the fact
that the hardware doesn't do much besides the parts that are
expected to get added in the FPGA.
* The OMAP subarchitecture gains support for the latest generation,
the OMAP5 based on the new Cortex-A15 core. Support is rather
rudimentary for now, but will be extended in the future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIVAwUAUA2deGCrR//JCVInAQJLxg/8DHL6usaciRX0rDzxAkv2h0cezjgR/ect
OfHdxhge7R50NEbf4Jayyly8fIvADJB5nIgk1jhYzAOroVAGxiZQxhyGn3p+Cpbm
4weu78Uk5habgGA3DmV/R8rKhd1iFtr1DSHbogU43UjPj9Zz5WOREGNJehvxOr/2
hUfymdqxNg4ivCWyA3w4IKhxA/Hrs351n3J3sY3wjLRPn/uZIlvyx4Q8InteAJZp
96u5F9y34CxB9SkXAX0P+Bdb0L1fWhZ1J6E8wjOMp/t3LaSXvvWVgCl6MxTcERpf
jeeABKPTQx99zkH3MdPRQfgBMwsez4L4dXh3qcJaEoqF//UXpE9cTTdjqYu6NRsJ
znO8Ns8a2X4zX6KF4ySQf2jtLzH4aF21nq6NTJyYyfDWZixqRSKawbSsYqc1vtmi
ReQ00feJrO60/A4Ks25asUfubqm/SXZ6BfHSgS/ZaOjgJaW9X42CUKnuIywXPTrY
cAGDh4v1ZrWdXiQIu7oKgESSQNi4GrAEDYqVYs/PmSk2UiuzHcSuPMYxsCmLk8mH
By7CLByXGOjzD9678LX2VHvKhK2l7Wd+Vkp/pGk4N4fK581JBfyBWfE0T5rpOU28
+fIFVAV6U0I1OW879b5LmC/kjtmHPxePP6XUcHE152ef1CiT6zm5IE+C2Ukso71V
+WKxBRBOxII=
=MwdJ
-----END PGP SIGNATURE-----
Merge tag 'newsoc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull support for three new arm SoC types from Arnd Bergmann:
- The mvebu platform includes Marvell's Armada XP and Armada 370 chips,
made by the mvebu business unit inside of Marvell. Since the same
group also made the older but similar platforms we call "orion5x",
"kirkwood", "mv78xx0" and "dove", we plan to move all of them into
the mach-mvebu directory in the future.
- socfpga is Altera's platform based on Cortex-A9 cores and a lot of
FPGA space. This is similar to the Xilinx zynq platform we already
support. The code is particularly clean, which is helped by the fact
that the hardware doesn't do much besides the parts that are expected
to get added in the FPGA.
- The OMAP subarchitecture gains support for the latest generation, the
OMAP5 based on the new Cortex-A15 core. Support is rather
rudimentary for now, but will be extended in the future.
* tag 'newsoc' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (25 commits)
ARM: socfpga: initial support for Altera's SOCFPGA platform
arm: mvebu: generate DTBs for supported SoCs
ARM: mvebu: MPIC: read number of interrupts from control register
arm: mach-mvebu: add entry to MAINTAINERS
arm: mach-mvebu: add compilation/configuration change
arm: mach-mvebu: add defconfig
arm: mach-mvebu: add documentation for new device tree bindings
arm: mach-mvebu: add support for Armada 370 and Armada XP with DT
arm: mach-mvebu: add source files
arm: mach-mvebu: add header
clocksource: time-armada-370-xp: Marvell Armada 370/XP SoC timer driver
ARM: Kconfig update to support additional GPIOs in OMAP5
ARM: OMAP5: Add the build support
arm/dts: OMAP5: Add omap5 dts files
ARM: OMAP5: board-generic: Add device tree support
ARM: omap2+: board-generic: clean up the irq data from board file
ARM: OMAP5: Add SMP support
ARM: OMAP5: Add the WakeupGen IP updates
ARM: OMAP5: l3: Add l3 error handler support for omap5
ARM: OMAP5: gpmc: Update gpmc_init()
...
Conflicts:
Documentation/devicetree/bindings/arm/omap/omap.txt
arch/arm/mach-omap2/Makefile
drivers/clocksource/Kconfig
drivers/clocksource/Makefile
These omap cleanups have dependencies on earlier omap branches that in
turn depend on other cleanups, so they could not go into the same
branch.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIVAwUAUA2ddmCrR//JCVInAQL19BAAypIWzygTKBQOcxk8czo9thEbwQWwall2
8TnfVT/dLqBtDlvOY7sWE/J+fNVfHLG9JcEw1mE8VABYCW1N9LSdHqpHrF3q2qg7
/JGNCFFMMpID8PCL4RjwAxlyNN15TzgJ29PUacI1MGRhwqbkuZpiCRCh6e9cRH94
pNnJbABojWp0rzN+xb9hwHBMCst6snlKHR2C3T5E5JIDB0YW+F9uC3pV+4RpXGTd
o56h6rwSXR3F3vS4aqdR/C11fSKJ2cDUR0ttR0shLWgPcdk4CP9Pd5FEdMSGLmH7
/YCDHb4iS59k2raaSaToSj1rykpk1d1X+sGYD2pg+Tc+84jT3/W/pHvxmnb7r9b5
H9hV6cISZyzhrxlapNhH2SUCdbSq7xdehes9IOoxJlNvR8TdwDGJK0XIAuMaHm/x
m/d6m2cgtfvqkuiveK6P/JBkXy4V14yoG2CELJcRxMsOQwHRtBnLuxSSlcnY7VOv
9mSoR4RvRxkcb3T37UG53lSiA5dliT9TS8p5jg6bJvkh4mi932wJpXpmitx/+Ev4
o9KEzeTx+9my4eBcwOiaH/J7xkBG4219aaL6wbOGB6Qpt7v8/E35SnWWKW7RSJUi
WxyTQjghpr4hhqceVTw3y1/qyo2B6WI+U4KknjRek8JLqWIm3SABG1N21x2ht9PG
OpzKEjDyQxg=
=kMNb
-----END PGP SIGNATURE-----
Merge tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull arm-soc cleanups, part 2, from Arnd Bergmann:
"These omap cleanups have dependencies on earlier omap branches that in
turn depend on other cleanups, so they could not go into the same
branch."
* tag 'cleanup2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: OMAP: sdrc: Fix the build break for OMAP4 only builds
ARM: OMAP2+: dmtimer: cleanup fclk usage
ARM: OMAP2+: Fix mismerge for omap_hwmod_get_main_clk() API
ARM: OMAP2+: Remove unnecessary ifdef around __omap2_set_globals
ARM: OMAP2+: am33xx: Change cpu_is_am33xx to soc_is_am33xx
ARM: OMAP2+: am33xx: Make am33xx as a separate class
ARM: OMAP2+: Move omap3 dpll ops to dpll3xxx.c
ARM: OMAP2+: All OMAP2PLUS uses omap-device.o target so add one entry
ARM: OMAP: dmtimer: use devm_ API and do some cleanup in probe()
ARM: OMAP2+: hwmod code: add support to set dmadisable in hwmod framework
ARM: OMAP2+: PRM/CM: Move the stubbed prm and cm functions to prcm.c file and make them __weak
ARM: OMAP2+: hwmod: add omap_hwmod_get_main_clk() API
ARM: OMAP3+: dpll: optimize noncore dpll locking logic
ARM: OMAP3: control: add definition for CONTROL_CAMERA_PHY_CTRL
ARM: OMAP2+: powerdomain code: Fix Wake-up power domain power status
ARM: OMAP4: clockdomain/CM code: Update supported transition modes
ARM: OMAP3/4: omap_hwmod: Add rstst_offs field to struct omap_hwmod_omap4_prcm
ARM: OMAP2+: hwmod: Add new sysc_type3 into omap_hwmod required for am33xx
These are all boring changes, moving stuff around or renaming things
mostly, and also getting rid of stuff that is duplicate or should
not be there to start with. Platform-wise this is all over the place,
mainly omap, samsung, at91, imx and tegra.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIVAwUAUA2dZmCrR//JCVInAQLMBA/9E53C1TOKQv3I9jPGMMeaN13jdAjIOM8w
KNyfZE8qdB7vlmhltJi/yWH9cW1e27Q5qxocH98fpgDjNWYTx5qQ+ZWOBaXoYdkb
tjkjI9/38bapHtBytznjr8SMx7+dhBCrTfcnBLhbkejMWeYcGS2cE3zUGil1UY0Y
lHaKSh/A45XzhjSC/1fbtxwNG+pD5W4omzsJtHWwWcyucLVzqTzwwfBc/SNWWapA
LFAaaxLc3UzI36TuRFjTHvZUwbU/rOSdF20T64qfMNd4svpnVWKtk6cOWdfCfPZe
NNafRZg082Ig9J4Yx8AxV1ntQMF5LF8sgZIGxI1LI9ADbBjoSHSNWaeGB4seCGTk
zvs71ITRzF0RkpUMnNbnk8ZQRcL0fkWLNs/nTjrlFGQR3Bjo6g29vXbTWmohnzAu
SK4yoYvtc6nKvxiROBcb2TcgizEj4s/YCdfAmWbW1sOVcx200UeL2qxvh8kSYtk+
anySIj4FndbhbIZutsMu10nFZ/At5q3Dsp9M8Wqs/jRBUIdCm21jfJoHCbgMAQWa
NQOBSwMsVL9Z8T9EEubBbhEqnwuHwY+z0VfiiyIoICtmdKjssOvEM6EsHq7IWuUU
Sc/Ha1FEXQEDhc3u1RvrCZHZKBjEjZJqwF2ZDkTcDX9TGEsqMJERxgW/0h/I6g5i
pixEzZ7/u40=
=4zvd
-----END PGP SIGNATURE-----
Merge tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull general arm-soc cleanups from Arnd Bergmann:
"These are all boring changes, moving stuff around or renaming things
mostly, and also getting rid of stuff that is duplicate or should not
be there to start with. Platform-wise this is all over the place,
mainly omap, samsung, at91, imx and tegra."
Resolve trivial conflict in arch/arm/mach-omap2/clockdomains3xxx_data.c
* tag 'cleanup' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (67 commits)
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
ARM: S3C24XX: Remove unused GPIO definitions for Openmoko GTA02 board
ARM: S3C24XX: Remove unused GPIO definitions for port J
ARM: S3C24XX: Remove unused GPA, GPE, GPH bank GPIO aliases
ARM: S3C24XX: Convert the touchscreen setup code to common GPIO API
ARM: S3C24XX: Convert the PM code to gpiolib API
ARM: S3C24XX: Convert QT2410 board file to the gpiolib API
ARM: S3C24XX: Convert SMDK board file to the gpiolib API
ARM: S3C24XX: Free the backlight gpio requested in Mini2440 board code
ARM: imx: remove unused pdata from device macros
ARM: imx: Kconfig: Remove IMX_HAVE_PLATFORM_IMX_SSI from MACH_MX25_3DS
ARM: at91: fix new build errors
ARM: at91: add AIC5 support
ARM: at91: remove mach/irqs.h
ARM: at91: sparse irq support
ARM: at91: at91 based machines specify their own irq handler at run time
ARM: at91: remove static irq priorities for sam9x5
ARM: at91: add of irq priorities support
...
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>
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>
for 3.6. Mostly small infrastructure improvements, and preparation
for OMAP5 and AM33xx code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP9F5FAAoJEMePsQ0LvSpLocAP/00cPRZ+sOrZO6KYjoh84AwB
mMfJd2QKhqwe19nBfPoGL3F+bClM5x9yIgX2pT2X46kJ25DqLcIDUnUeKydo/euF
qON+8n2E2Z24iaiLnQvSLYyIJokTX+81l+RmddGYkT2Go8KT6U6XRcOnQ1J/kkIC
Z9rkHkMtzL7wAtYUBcZktlEMw8PKzcLAayCSQsPQ4Q757JHONijtJFID24UyQQPQ
azsuL4bxUJ5zhSeVjJRmCE7sFWbTgJ6vztMm/d1bc/TH4X7dFNKwhKIuZsMrAMBf
fzf+lyB/UFX7CCt7oqQs8E3mX0E9B2ijq5WCal4SSLf7piLIIHxIpTT9LGAzO/of
zYhRA3hY4o/HsaDmgsYxHZAPYGZoODosI93bYBVxBW2qZceYZ1j3nUfd0dY+AkCe
Nm0L1TWeBhVG0oX3fP8bqTTxyiMCn4eDUUAUe002oJrsEFkeUb1+lAvTNoibXyns
rQ9uQjbtR53V8nHT62sYcORxKdfUxGoDT3KFp2CHtKf/agjsuUe6JqP0Z3IkeYvT
nmd+vUmO7D4delpbsT4OIt7vzmXCzTr6qB0hZIyXitFqQHlz9bBO4Fdow51CG+0V
PNykHS9tfU7Ioe0bOMm9MhqjicbbxAJOc1Y4bBh8JGsNDsnfIAm9ZjHEjq7td/yz
sZnZqUUrQHSB5EHBW5LU
=sy5d
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-f-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into cleanup-part2
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 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>
Add an API to get main clock name associated with a given @oh.
This will avoid the need to construct fclk names during early
initialization in order to get fclk handle using clk_get().
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
IO Daisychain feature has to be triggered whenever there is a change in
device's mux configuration (See section 3.9.4 in OMAP4 Public TRM vP).
Now devices can idle independent of the powerdomain, there can be a
window where device is idled and corresponding powerdomain can be
ON/INACTIVE state. In such situations, since both module wake up is
enabled at padlevel as well as io daisychain sequence is triggered,
there will be 2 PRCM interrupts (Module async wake up via swakeup and
IO Pad interrupt). But as PRCM Interrupt handler clears the Module
Padlevel WKST bit in the first interrupt, module specific interrupt
handler will not triggered for the second time
Also look at detailed explanation given by Rajendra at
http://www.spinics.net/lists/linux-serial/msg04480.html
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: remove dependency on pm.c & pm.h; add kerneldoc]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
If an IP is configured in Smart-Standby-Wakeup, when disabling wakeup feature the
IP will not go back to Smart-Standby, but will remain in Smart-Standby-Wakeup.
Signed-off-by: Djamil Elaidi <d-elaidi@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Remove prm_clkdm and cm_clkdm and allow hwmods to have no clockdomain.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Rather than use runtime cpu_is* checking inside _init_clkdm, initialize
SoC specific function pointer at init time.
Signed-off-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: convert to use soc_ops function pointers; remove second para
from commit message since soc_ops function pointers are now set during hwmod
layer init]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Rather than using cpu_is* checking at runtime, initialize SoC specific
function pointers for the various hard reset functions at init time.
Signed-off-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Rather than using cpu_is* checking at runtime, initialize an SoC specific
function pointer for wait_target_ready().
While here, downgrade the BUG() to a WARN_ON() so it gives a noisy
warning instead of causing a kernel panic.
Signed-off-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: convert to use soc_ops function pointers; add kerneldoc;
move soc_ops functions to their own section in the code; integrated
the _wait_target_ready() function with the OMAP2/OMAP4 variants;
renamed the wait_module_ready field to wait_target_ready]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
_omap4_wait_target_disable() is called only from inside _omap4_disable_module()
which is already protected by SoC specific checks. Remove the cpu_is check
here.
Signed-off-by: Kevin Hilman <khilman@ti.com>
The enable/disable module functions are specific to SoCs with
OMAP4-class PRCM. Rather than use cpu_is* checks at runtime inside
the enable/disable module functions, use cpu_is at init time to
initialize function pointers only for SoCs that need them.
NOTE: the cpu_is* check for _enable_module was different than
the one for _disable_module, and this patch uses
cpu_is_omap44xx() for both.
Signed-off-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: moved soc_ops function pointers to be per-kernel rather than
per-hwmod since they do not vary by hwmod; added kerneldoc]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
_enable_module is specific to SoCs with PRCM interfaces similar to
that of the OMAP4, so rename it to be consistent with the
corresponding _omap4_disable_module.
Signed-off-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: tweaked commit message]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Now that the data has been converted to use interface registration, we
can remove the (now unused) direct hwmod registration code.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Add support for direct IP block interconnect ("link") registration to
the hwmod code via a new function, omap_hwmod_register_links(). This
will replace direct registration of hwmods, and a subsequent patch
will remove omap_hwmod_register().
This change will allow a subsequent patch to remove the hwmod data
link arrays. This will reduce the size of the hwmod static data and
also make it easier to generate the data files. It will also make it
possible to share some of the struct omap_hwmod records across
multiple SoCs, since the link array pointers will be removed from the
struct omap_hwmod.
The downside is that boot time will increase. Minimizing boot time
was the reason why the link arrays were originally introduced.
Removing them will require extra computation during boot to allocate
memory and associate IP blocks with their interconnects. However,
since the current kernel development focus is on reducing the number
of lines in arch/arm/mach-omap2/, boot time impact is now seemingly
considered a lower priority.
This patch contains additional complexity to reduce the number of
memory allocations required for this change. This reduces the boot
time impact: total hwmod link registration time was ~ 2655
microseconds with a simple allocation strategy, but is now ~ 549
microseconds[1] with the approach taken by this patch.
1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average
of 7 samples. Total uncertainty is +/- 61 microseconds.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
An IP block's MPU interface port only needs to be found once. The result
can be cached to speed further lookups. This patch consolidates these
two steps into a single function.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
To reduce the number of lines of data in the OMAP portion of the Linux
code base, subsequent patches will remove the lists of hwmod
interconnect links from the static hwmod data. These lists will be
built dynamically during boot. To ease this transition, this patch
centralizes the way that interconnect links are iterated into a single
function, _fetch_next_ocp_if().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Most IP blocks on the OMAP SoC have an interconnect link that is
intended to be used by the MPU to communicate with the IP block.
Several parts of the hwmod code need to be able to identify this link.
Currently, this is open-coded. However, future patches will change
the way that interconnect links are represented and will make
identifying the link more complex. So to avoid code duplication, this
patch centralizes the MPU port link identification code into a new
function, _find_mpu_rt_port().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
The timer integration code pokes around in hwmod data structures.
Those data structures are about to change. Define a function,
omap_hwmod_get_resource_byname(), for the timer integration code to
use instead.
The original patch has been changed to use struct resource by Tony's
request, although the caller of this function should not be a driver._
Platform drivers should get their data through the regular platform_*
functions; DT drivers through the appropriate of_* functions. This a
function is only for use by OMAP core code in arch/arm/*omap*.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
A subsequent patch will need to know the struct omap_hwmod_addr_space
record corresponding to the module's register target, used by the MPU.
So, convert _find_mpu_rt_base() into _find_mpu_rt_addr_space(). Then
modify its sole current user, _populate_mpu_rt_base(), to extract the
MPU RT base address itself from the struct omap_hwmod_addr_space record.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable. But driver authors inside TI have commented to us that their
drivers require direct control over these lines. Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori. This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.
The semantics implemented by this patch are as follows:
- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
associated hardreset lines during IP block setup. This is intended
to place the IP blocks into a known state that will not interfere
with other devices during kernel boot.
- IP blocks with hardreset lines will not be automatically enabled or
idled during setup. Instead, they will be left in the INITIALIZED
state.
- When the hwmod code is asked to enable, idle, or shutdown an IP
block with asserted hardreset lines, the hwmod code will do nothing.
The driver integration code must do the remaining work needed to
control these IP blocks. Once this driver integration code is posted
to the lists, hopefully we can consolidate it and move it inside the
hwmod code.
Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed. It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.
This reverts most of commit 5365efbe29
("OMAP: hwmod: Add hardreset management support"). Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Reorganize the code involved in resetting and configuring an IP block
to make it easier to read and maintain. This involves improving
documentation, splitting some large functions up into smaller ones to
better conform with Documentation/CodingStyle, and removing some
unnecessary code.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Reorganize the code involved in initializing the internal data for
each hwmod to make it easier to read and maintain. This involves
improving documentation and removing some duplicated and unnecessary
code.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Revise the IP block reset process. This patch ensures that the
OCP_SYSCONFIG registers are reloaded after a custom reset. Since
OCP_SYSCONFIG bits are cleared during reset, they should be
reprogrammed unless the IP block is being left in reset. (The only IP
blocks that are left in reset are IP blocks with hardreset lines and
no custom reset function.) If the IP block is left in reset, then it
is inaccessible to the MPU, and an access to the OCP_SYSCONFIG
register will cause an abort.
This version incorporates comments from Omar Ramirez Luna
<omar.ramirez@ti.com> to skip the OCP_SYSCONFIG access after asserting
hardreset lines. This allows the MMU (IOMMU) IP block, which has
both hardreset lines and an OCP_SYSCONFIG register.
Also, ignore _ocp_softreset() errors if the IP block doesn't include a
softreset bit. This is needed since a subsequent patch will start
taking the return value of the _reset() function seriously.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>
Parts of the hwmod code test to see if a module has one and only one
hardreset line before taking an action. It seems more appropriate
to control all hardreset lines associated with a hwmod, not just one.
It so happens that with the current hwmod data, this patch will not
change any behavior, since hwmods with hardreset lines have only one
hardreset line associated with them, and 'pseudo-hwmods' are used to
handle the other hardreset lines. But future hwmod data patches to
remove the pseudo-hwmods will change this.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
This reverts commit f9a2f9c3fa. This
commit caused a regression in the I2C hwmod reset on OMAP2/3/4,
logging messages similar to these during boot:
[ 0.200378] omap_hwmod: i2c1: softreset failed (waited 10000 usec)
[ 0.222076] omap_hwmod: i2c2: softreset failed (waited 10000 usec)
While the original patch was intended to fix some reset-related timing
issues, it's believed that these problems were actually fixed by
commit 2800852a07 ("ARM: OMAP2+: hwmod:
Restore sysc after a reset"):
http://marc.info/?l=linux-arm-kernel&m=133410322617245&w=2
Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Due to HW limitation, some IPs should not be accessed just after a
softreset. Since the current hwmod sequence is accessing the sysconfig
register just after the reset, it might lead to OCP bus error in
that case.
Add a new field in the sysconfig structure to specify a delay in usecs
needed after doing a softreset.
In the case of the ISS and FDIF modules, the L3 OCP port will be
disconnected upon a SW reset. That issue was confirmed with HW simulation
and an errata should be available soon. The HW recommendation to avoid
that is to wait for 100 OCP clk cycles, before accessing the IP.
Considering the worse case (OPP50), the L3 bus will run at 100 MHz,
so a 1 usec delay is needed. Add an x2 margin to be safe.
Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
[paul@pwsan.com: dropped FDIF change for now since the hwmod data is not
yet upstream; the FDIF change will need to be added later once the FDIF
data is merged]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
