device tree support for dmtimer by simplifying the platform
data structure used by dmtimr.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP8AbkAAoJEBvUPslcq6Vz46YQAJZ7dWwSKHSQjuIx2j9iloi6
zIgvX8secC8yrli88I27fcAB7qGI9fulebEGQXCu7s3OzHI3/FO1KTAMdW31y4it
6WUkdWkSHfFtFiOcRjR9QTEuQ58Fii550iVcn8qezDizYfnd6ThwPHhhZek39oJC
qSzb2jqvvHgVuMPqpXkCDmQnH3JoEqGZ2Qg+JlyuW9mMmq3ipK7BTY9vLIcCPvdu
ET0rBvSmTr7s/XBMtDLseCHD3XsgnQ8dY0i7j3BWtCSkNjz2DFhj4zXL3/3f+ff6
KCIrkY5CK1R4x4vithXyLpqgniwj66eOOHdnL78iV4Am7jQrbIyvC9k5LeQE28XD
QgB718tO8UVRfAKmA9/zAwLJUN4lg8OUw2PrCBPxy4GXxY0Wu670gD+AqtSEwqV8
8ifOEltLO/46jb/zdBFvNJ+69C0XZdSN48SpdZbGzVVaNMxWprSGxF3hdf8EnbjF
/0F0A8dCtgMcIDgr+hUkSSM+AVVzlxr9imvATsAFTLlgq3G8LQ4bGSh/ywuNN5jn
Ql5ZkuxBVIWwWcd68vCKQVH/X/mPj6jtmz1qRZZTOCbV7oM8/YVQP37tkn6jk+xl
2ZCUrggvUcDYxVx0N1Eb4Yixje4BsrMPFn0zVjKSTzVMpYobxqVuNYPFfZ7ROJnf
caxP57fcIOC3pYp4VYtq
=L0+0
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-dmtimer-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/timer
From Tony Lindgren <tony@atomide.com>:
Here are some omap dmtimer changes to make it easier to add
device tree support for dmtimer by simplifying the platform
data structure used by dmtimr.
* tag 'omap-devel-dmtimer-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: Simplify dmtimer clock aliases
ARM: OMAP2+: Move dmtimer clock set function to dmtimer driver
ARM: OMAP1: Fix dmtimer support
ARM: OMAP: Add flag to indicate if a timer needs a manual reset
ARM: OMAP: Remove timer function pointer for context loss counter
ARM: OMAP: Remove loses_context variable from timer platform data
ARM: OMAP2+: Fix external clock support for dmtimers
ARM: OMAP2+: HWMOD: Correct timer device attributes
ARM: OMAP: Add DMTIMER capability variable to represent timer features
ARM: OMAP2+: Add dmtimer platform function to reserve systimers
ARM: OMAP2+: Remove unused max number of timers definition
ARM: OMAP: Remove unnecessary clk structure
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
hwmod, clock, and System Control Module cleanup, and the removal
of the last instance of omap_read/write usage for omap2+ with
the removal of unused USB OHCI Full Speed driver support. The
removed OHCI is only currently used for omap1 as the actively
used omap2+ boards have either MUSB or another instance of
OHCI+EHCI that's more usable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP8AYmAAoJEBvUPslcq6VzH2sP/0QlWA9Xl31AnGUgKJ3p5W3A
mjtLf9jHicOisSfYiEnuePHKwLnw7HZniI0xNcHXnFpRcDsxK8q2bmuFVpmqpIBv
OaCTfnOY+hpZR0/sLRQrKRZF13zYiro40StrhgxrSUV6cGwky+fJx/63J3j16NeV
TJkX4FjJXdAiGi/E7v+5XmQn3rpfcjntaDZgGSravVv1U1kYMMfN/2lHAvrALS+w
c8xqommerOnSp0IfjAtPeLnDdgdDXDxSq7MRGyDbNmxffjDR/leTC7j1xl0j0S+O
PSSvUa8aypeBWo9ckH77sXgiaAaMxVLu/X4ksPDijDdBkHsuQSffuj4swJP9B3d5
4d0ryvBqJhfvvgnL6a3emYhiZXgdbYbnerA+smm1Hf5VhGt5BWvZkJgS2RBUWLdW
j4OsaSI+vGhsYFjINNZ6QY3S1OeolGb8qBjNVHN0XsUg/tQPQZCMIjm2Zl+OM7Ex
60mtVoNysA0VKl/bzQ9jH6BwAYkcKli8bHDrvHm5a73DunVrCOG7TmKM4g108kvo
ccVCcEb3XEuqOfi+Nk6MSUQcHc1TkeDeAA9OtoFSi5hYwEh19w7UotRpsAVw2/Qe
D+Rrm4QvfUrDYKRfbj6LRaNRxkgvVnqJ5mC1SyiIbuLLjkZPJDomMATOZ66dYNUi
/tUf+6znwg+Iki+8rlhx
=A9qD
-----END PGP SIGNATURE-----
Merge tag 'omap-cleanup-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/cleanup
From Tony Lindgren <tony@atomide.com>
Here is some more omap clean-up. The biggest changes are
hwmod, clock, and System Control Module cleanup, and the removal
of the last instance of omap_read/write usage for omap2+ with
the removal of unused USB OHCI Full Speed driver support. The
removed OHCI is only currently used for omap1 as the actively
used omap2+ boards have either MUSB or another instance of
OHCI+EHCI that's more usable.
* tag 'omap-cleanup-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain
ARM: OMAP3: Move McBSP fck clock alias to hwmod data
ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2430
ARM: OMAP2: Move McBSP fck clock alias to hwmod data for OMAP2420
ARM: OMAP: dsp: interface to control module functions
ARM: OMAP2+: control: new APIs to configure boot address and mode
ARM: OMAP2+: CLEANUP: Remove ARCH_OMAPx ifdef from struct dpll_data
ARM: OMAP2+: hwmod: use init-time function pointer for _init_clkdm
ARM: OMAP2+: hwmod: use init-time function pointer for hardreset
ARM: OMAP2+: hwmod: use init-time function pointer for wait_target_ready
ARM: OMAP4: hwmod: drop extra cpu_is check from _wait_target_disable()
ARM: OMAP2+: hwmod: use init-time function ptrs for enable/disable module
ARM: OMAP4: hwmod: rename _enable_module to _omap4_enable_module()
ARM: OMAP: Make FS USB omap1 only
ARM: OMAP2: Remove legacy USB FS support
ARM: OMAP3: There is no FS USB controller on omap3
ARM: OMAP: dma: Clear status registers on enable/disable irq
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
critical enough for the 3.5 -rc cycle. The biggest changes are
fixes for the am35xx clock and hwmod data, and the removal of dead
code for the 730 and 850 headers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP8AHPAAoJEBvUPslcq6VzXbcP/0EIL3u8e8eAjXJok1F5NT8u
U8ESDp29dR+5WrfuXpL+EnDxMuQxn0eITpeCm0rzREMm3cg+b7prqArWmcusaj3Y
lt3Th6t+1X/kJYc5RSsnTpWFTpN+2Ycten8cRDCGT2k/3kM8ZmFHfK7mMUMgaCEZ
yNMl75Db45RMMAM7ZFjwSbiLSyFdNYb7fgDyJPJpl8DiMQDLSyUshKpFjECFFv8L
zxALEpvqvb4nPHiynAju6mSDY8zCRLyl0ogRcp+Gqxv1GdZpxM5nR2g9ObnBeflo
sTyC5D/johsOMkv4+npUzodEdqBcaBZS9YZ5CRiFRdN6c+Cxan2tprJZfvJpgHsZ
TMT1aVH2xuu55FWbC7ne/1LDrmMzwbxAHclPYy+toy0Aks5cMy2QMz6lmHDZUfMv
bvoF/UwZ1g3cpO6LERmRjyrTVbPwNAeR+omKKkjcilvT0bVvDTORgRTZjvAOKW4J
lVGBOEijcU1MUAOoYafKssvgl4rouXiZR2pOyoC6+LUqj7aEPjK4+YftPgyhGMz+
M5kR92DBYIsJP42xV84BBubpVIgr6zz1jwT3ttMv5XZF/Ua9cM3WprLnbgLXAjiz
lZfLGgCL85XU0ArtjJSDi6xyffzWEQrh/RgHs/pN4LBWcQfTnlbL2KfuthXv2IYZ
WCtK57YjjjAG58xhjJV0
=UD1/
-----END PGP SIGNATURE-----
Merge tag 'omap-fixes-non-critical-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into next/fixes-non-critical
From Tony Lindgren <tony@atomide.com>:
This branch contains fixes that were too intrusive or not
critical enough for the 3.5 -rc cycle. The biggest changes are
fixes for the am35xx clock and hwmod data, and the removal of dead
code for the 730 and 850 headers.
* tag 'omap-fixes-non-critical-for-v3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap: (25 commits)
ARM: OMAP2+: fix CONFIG_CPU_IDLE dependency on CONFIG_PM
ARM: OMAP: remove unused cpu detection macros
ARM: OMAP: fix typos related to OMAP330
ARM: OMAP7XX: Remove omap730.h and omap850.h
ARM: OMAP2+: fix naming collision of variable nr_irqs
ARM: OMAP: omap2plus_defconfig: Enable EXT4 support
ARM: OMAP depends on MMU
arm: omap3: am35x: Set proper powerdomain states
ARM: OMAP AM35x: clockdomain data: Fix clockdomain dependencies
ARM: OMAP AM35x: EMAC/MDIO integration: Add Davinci EMAC/MDIO hwmod support
ARM: OMAP: AM35xx: fix UART4 softreset
ARM: OMAP AM35xx: clock and hwmod data: fix UART4 data
ARM: OMAP AM35xx: clock and hwmod data: fix AM35xx HSOTGUSB hwmod
ARM: OMAP: Fix dts files w/ status property: "disable" -> "disabled"
ARM: OMAP: beagle: Set USB Host Port 1 to OMAP_USBHS_PORT_MODE_UNUSED
ARM: OMAP2: twl-common: Fix compiler warning
ARM: OMAP: fix the ads7846 init code
mfd: twl: remove pdata->irq_base/_end, no more users
ARM: OMAP2+: TWL: remove usage of pdata->irq_base/_end
ARM: OMAP2+: OPP: Fix to ensure check of right oppdef after bad one
...
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The SYS_NIRQ1 pin is the interupt line for the PMIC part of the TWL6030
and interrupts from the PMIC are needed as wakeup sources.
Ensure this pin is mux'd as input and has wakeup enabled so PMIC
interupts (e.g. RTC) can be used as wakeup sources.
Tested on OMAP4430/Panda.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
In order for suspend/resume dependencies to work correctly, I2C has to
be initialized (more specifically, registered with the driver core)
before MMC. Without this, the MMC driver fails to adjust the VMMC
regulator (using i2c writes) during the suspend path.
Problem found testing suspend/resume on 3730/OveroSTORM platform.
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Register the tvp5150 video decoder in ISP subsystem.
Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Setup pinmux for CPI and register the mt9t001 camera sensor
in ISP subsystem.
Signed-off-by: Dmitry Lifshitz <lifshitz@compulab.co.il>
Signed-off-by: Igor Grinberg <grinberg@compulab.co.il>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Register OMAP DRM/KMS platform device. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross <andy.gross@ti.com>
Signed-off-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
AM33XX clock implementation is different than any existing OMAP
family of devices. Although DPLL module is similar to OMAP4
device, but the usage is very much different than OMAP4.
AM33XX has different peripheral set and each module gets
integrated to the clock framework differently than OMAP
family of devices.
This patch adds full Clock tree data for AM33XX family
of devices and also integrates it into existing OMAP framework.
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Afzal Mohammed <afzal@ti.com>
Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
CC: Tony Lindgren <tony@atomide.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
[paul@pwsan.com: updated to apply; changed 'soc_is_am33xx' to
'cpu_is_am33xx' to match usage in Tony's current am33xx branch]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
commit 99b59df0 (ARM: OMAP3: PM: fix shared PRCM interrupt leave
disabled at boot) added IRQ_NOAUTOEN to the PRCM interrupt so it could
be enabled later if needed. However, this commit was partially undone
when merging the IO daisy chain rework in 9a17d88e (Merge tag
'omap-devel-c-for-3.6' of
git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into
devel-pm
This patch adds back the IRQ_NOAUTOEN fix that was removed by the
merge resolution.
This also fixes the following boot-time warning that showed up after
merging the IO daisy chain rework:
[ 3.849334] WARNING: at kernel/irq/manage.c:436 enable_irq+0x3c/0x78()
[ 3.856231] Unbalanced enable for IRQ 297
[ 3.860473] Modules linked in:
[ 3.863739] [<c001a114>] (unwind_backtrace+0x0/0xf0) from [<c003c7e8>] (warn_slowpath_common+0x4c/0x64)
[ 3.873687] [<c003c7e8>] (warn_slowpath_common+0x4c/0x64) from [<c003c894>] (warn_slowpath_fmt+0x30/0x40)
[ 3.883819] [<c003c894>] (warn_slowpath_fmt+0x30/0x40) from [<c00993e0>] (enable_irq+0x3c/0x78)
[ 3.893035] [<c00993e0>] (enable_irq+0x3c/0x78) from [<c067b1e8>] (omap3_pm_init+0x328/0x5f4)
[ 3.902099] [<c067b1e8>] (omap3_pm_init+0x328/0x5f4) from [<c067161c>] (init_machine_late+0x1c/0x28)
[ 3.911773] [<c067161c>] (init_machine_late+0x1c/0x28) from [<c0008648>] (do_one_initcall+0x34/0x178)
[ 3.921539] [<c0008648>] (do_one_initcall+0x34/0x178) from [<c066e8f4>] (kernel_init+0xfc/0x1c0)
[ 3.930847] [<c066e8f4>] (kernel_init+0xfc/0x1c0) from [<c00140b0>] (kernel_thread_exit+0x0/0x8)
[ 3.940246] ---[ end trace 55a0ad32ca2ca682 ]---
Reported-by: Javier Martinez Canillas <javier@dowhile0.org>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The powerdomain and clockdomain data for the AM35xx are finally fixed.
The AM35xx EMAC/MDIO Ethernet controller integration code has been
converted to use the OMAP device and hwmod framework. Also the UART4
and HSOTGUSB warnings have been fixed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP7BHOAAoJEMePsQ0LvSpLCrcP/RwJliq2ITgQMEj3N2BbDkKP
kvS63qYv+QqH+mhGm/RFrmB/p3LSxgOkgdQByavfsQnsE0v5+FYjDnXAB3tvUVHI
Tv9vSJLIAgC9n4Z8pdJ8u71VGu8XVYnGnCKNz6UhVfHX8Q5BEs01eSPw3wgDVTIq
gKpMHaeNdi4Atkh2KmxyLwEBF9QC+vSNxMtkqcYbT5faBrqOEKeLz5igG8+VQBTU
RNeUOHb99+Rf/H2eRsynwMgX63xMzh7hSwW2GAJ5O7+uoMLmdPuI7MUAQR/zcPzQ
gmFUb1yKkmvu9OKtNR+3VCgGGlvvhaJBwTFJj9IL10xrj4LnDlA3N9bC9vwHG8zw
0YbrPA2iLU6ufdmLf5rANQFJL3ttg65MZTsjA8q3tjE04QkJncRpDtzr89dQYw/C
hv3vqCYpo0b2UCMPcyf4pUR5rzzHjPiM4Np9GEj3Ak1puUASwNXGTvXWusWXND9i
ixcFxd6LppyIa8FxMKXONEGaeNKbp+T63EugBCDEeCCWkXXQQGXU54xWy7w939ib
pvDtk1+ZqHC5rzPfuNokD+H95W3pc5AYr2pPjW8fctH6Wp9dFZV8sg77pgbenS/E
u2UX5N7rlqtj/Km7fJgy6h3EUVg8ky6W5nMtF2Jad8D89FOZHoSRAICPA4dIxTYl
hvv7kdtT23AqZKbxQUNu
=2b0z
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-d-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into fixes-non-critical
Some OMAP AM35xx fixes.
The powerdomain and clockdomain data for the AM35xx are finally fixed.
The AM35xx EMAC/MDIO Ethernet controller integration code has been
converted to use the OMAP device and hwmod framework. Also the UART4
and HSOTGUSB warnings have been fixed.
commit 164e0cbf60 (ARM: OMAP3/4: consolidate cpuidle Makefile) added
an OMAP-specific dependency from CPU_IDLE to CONFIG_PM. This causes
some randconfig warnings when CONFIG_PM has unmet dependencies:
warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME)
Fix this by making the dependency on CONFIG_PM_RUNTIME (which in turn
will enable CONFIG_PM.)
Reported-by: Tony Lindgren <tony@atomide.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The dispc_disable_outputs() function currently disables all LCD managers except
LCD3. This patch adds disabling functionality for LCD3 manager thereby
maintaining consistency of Display Subsystem for in case Display Controller is
reset when LCD3 manager is in use.
Signed-off-by: Chandrabhanu Mahapatra <cmahapatra@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Using nr_irqs as local variable name triggers the sparse warning..
./arch/arm/mach-omap2/irq.c:265:6: warning: symbol 'nr_irqs' shadows an earlier one
./linux/include/linux/irqnr.h:26:12: originally declared here
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The am35x family of SoCs only support the PWRSTS_ON
state so create a new set of powerdomain structures
that ensure that only the ON state is entered.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
The am35x family of SoCs do not have an IVA so
a parallel set of clockdomain dependencies are
required that are simililar to OMAP3 but without
any IVA dependencies.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Add hwmod support for the EMAC (and MDIO)
ethernet controller that's on the am35x
family of SoC's.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
[paul@pwsan.com: updated subject line; updated to apply on v3.5-rc4;
added comments to hwmod data regarding IPSS]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
During kernel init, the AM3505/AM3517 UART4 cannot complete its softreset:
omap_hwmod: uart4: softreset failed (waited 10000 usec)
This also results in another warning later in the boot process:
omap_hwmod: uart4: enabled state can only be entered from initialized, idle, or disabled state
From empirical observation, the AM35xx UART4 IP block requires either
uart1_fck or uart2_fck to be enabled while UART4 resets. Otherwise
the reset will never complete. So this patch adds uart1_fck as an
optional clock for UART4 and adds the appropriate hwmod flag to cause
uart1_fck to be enabled during the reset process. (The choice of
uart1_fck over uart2_fck was arbitrary.)
Unfortunately this observation raises many questions. Is it necessary
for uart1_fck or uart2_fck to be controlled with uart4_fck for the
UART4 to work correctly? What exactly do the AM35xx UART4 clock
tree and the related PRCM idle management FSMs look like? If anyone
has the ability to answer these questions through empirical functional
testing, or hardware information from the AM35xx designers, it would
be greatly appreciated.
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Kyle Manna <kyle.manna@fuel7.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Mark A. Greer <mgreer@animalcreek.com>
Add missing terminators to the arrays of IRQ, DMA, and address space
structure records in the AM35xx UART4 hwmod data. Without these
terminators, the following warnings appear on boot:
omap_uart.3: failed to claim resource 58
omap_device: omap_uart: build failed (-16)
WARNING: at /home/paul/linux/arch/arm/mach-omap2/serial.c:375 omap_serial_init_port+0x198/0x284()
Could not build omap_device for omap_uart: uart4.
Also, AM35xx uart4_fck has an incorrect parent clock pointer. Fix it
and clean up a whitespace issue.
Fix some incorrectly-named macros related to AM35xx UART4.
Cc: Kyle Manna <kyle.manna@fuel7.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Cc: Ranjith Lohithakshan <ranjithl@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Mark A. Greer <mgreer@animalcreek.com>
Partially fix the hwmod data for the AM35xx USB OTG hwmod. This
should resolve the following boot warning on AM35xx platforms:
omap_hwmod: am35x_otg_hs: cannot be enabled for reset (3)
While here, also fix the clkdev records, to avoid warnings about
duplicate clock aliases.
The hwmod is also connected to the wrong interconnect. It should be
connected to the IPSS, not the L4 CORE. But that is left for a future
fix, since it probably has a dependency on some hwmod core changes.
Cc: Felipe Balbi <balbi@ti.com>
Cc: Hema HK <hemahk@ti.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Mark A. Greer <mgreer@animalcreek.com>
OMAP4470 currently fails to boot, printing various messages such as ...
omap_hwmod: mpu: cannot clk_get main_clk dpll_mpu_m2_ck
omap_hwmod: mpu: cannot _init_clocks
------------[ cut here ]------------
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:2062 _init+0x2a0/0x2e4()
omap_hwmod: mpu: couldn't init clocks
Modules linked in:
[<c001c7fc>] (unwind_backtrace+0x0/0xf4) from [<c0043c64>] (warn_slowpath_common+0x4c/0x64)
[<c0043c64>] (warn_slowpath_common+0x4c/0x64) from [<c0043d10>] (warn_slowpath_fmt+0x30/0x40)
[<c0043d10>] (warn_slowpath_fmt+0x30/0x40) from [<c0674208>] (_init+0x2a0/0x2e4)
[<c0674208>] (_init+0x2a0/0x2e4) from [<c067428c>] (omap_hwmod_setup_one+0x40/0x60)
[<c067428c>] (omap_hwmod_setup_one+0x40/0x60) from [<c0674280>] (omap_hwmod_setup_one+0x34/0x60)
[<c0674280>] (omap_hwmod_setup_one+0x34/0x60) from [<c06726f4>] (omap_dm_timer_init_one+0x30/0x250)
[<c06726f4>] (omap_dm_timer_init_one+0x30/0x250) from [<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108)
[<c0672930>] (omap2_gp_clockevent_init+0x1c/0x108) from [<c0672c60>] (omap4_timer_init+0x10/0x5c)
[<c0672c60>] (omap4_timer_init+0x10/0x5c) from [<c066c418>] (time_init+0x20/0x30)
[<c066c418>] (time_init+0x20/0x30) from [<c0668814>] (start_kernel+0x1b0/0x304)
[<c0668814>] (start_kernel+0x1b0/0x304) from [<80008044>] (0x80008044)
---[ end trace 1b75b31a2719ed1c ]---
The problem is that currently none of the clocks are being registered for
OMAP4470 devices and so on boot-up no clocks can be found and the kernel panics.
This fix allows the kernel to boot without failure using a simple RAMDISK file
system on OMAP4470 blaze board.
Per feedback from Paul and Benoit the 4470 clock data is incomplete for new
modules such as the 2D graphics block that has been added to the 4470.
Therefore add a warning to indicate that the clock data is incomplete.
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
[tony@atomide.com: updated comments]
Signed-off-by: Tony Lindgren <tony@atomide.com>
OMAP3, OMAP4 and AM33xx share some common data like, clksel_rate
oscillator clock input (Virtual clock nodes), required for
clock tree; so move common data to common data file so that it
can be reused.
[hvaibhav@ti.com: Created separate commit from Paul's developement
branch]
Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
an oops on boot for all omap3xxx platforms that use usbhs_omap for
EHCI. The actual oops comes from faulty ehci-omap cleanup, but the
failure caused by the change is evidenced here:
[ 3.655059] ehci-omap ehci-omap.0: utmi_p1_gfclk failed error:-2
[ 3.661376] ehci-omap: probe of ehci-omap.0 failed with error -2
utmi_p1_gfclk is a clock that exists on OMAP4, but not OMAP3. In the
OMAP3 case, it is configured as a dummy clock. However, OMAP4 lists
the dev_id as NULL, but OMAP3 lists it as "usbhs_omap".
Attempting to get that clock from ehci-omap then fails. The solution
is to just change the clock3xxx_data.c for dummy clocks used in the
errata fix to match the dev_id, NULL, used in clock44xx_data.c.
Tested on BB-xM.
Signed-off-by: Russ Dill <Russ.Dill@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8259573b (ARM: OMAP2+: nand: Make board_onenand_init() visible
to board code) broke the build for configs with OneNAND disabled. By
removing the static in the header file, it created a duplicate definition
in the .c and the .h files, resuling in a build error:
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.c:102:111: error: redefinition of 'board_onenand_init'
/work/kernel/omap/dev/arch/arm/mach-omap2/board-flash.h:56:51: note: previous definition of 'board_onenand_init' was here
make[2]: *** [arch/arm/mach-omap2/board-flash.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [arch/arm/mach-omap2] Error 2
make: *** [sub-make] Error 2
Fix this by removing the duplicate dummy entry from the C file.
Cc: Enric Balletbò i Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This allows us to pass dma request lines in platform data to
MMC driver the same way as we already do for omap2430 and later.
Also note that we need to only build this code if MMC_OMAP
is selected, so change Makefile accordingly and place it near
the MMC_OMAP_HS in the Makefile.
Signed-off-by: Tony Lindgren <tony@atomide.com>
For a power domain to idle all the clock domains in it must idle.
This patch implements an optimization of the cpuidle code by
denying and later allowing only the first registered clock domain
of a power domain, and so optimizes the latency of the low power code.
The functions _cpuidle_allow_idle and _cpuidle_deny_idle are
not used anymore and so are removed.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
One of the main contributors of the low power code latency is
the PER power domain. To optimize the high-performance and
low-latency C1 state, prevent any PER state which is lower
than the CORE state in C1.
Reported and suggested by Kevin Hilman.
Reported-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
If the next state is no found in the next_valid_state function,
fallback to the default value of C1 (which is state 0).
This prevents the use of a bogus state -1 in the rest of the cpuidle
code.
Signed-off-by: Jean Pihet <j-pihet@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
commit e7410cf7 (OMAP3: PM: move device-specific special cases from PM
core into CPUidle) moved mangement of cam_pwrdm to CPUidle but left
some remnants behind, namely the call to clkcm_allo_idle() for the
clockdomains in the MPU pwrdm. Remove these since they are not
necessary and cause unwanted latency in the idle path.
Acked-by: Tero Kristo <Tero Kristo <t-kristo@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
We only need to call the pre/post transtion methods when we know the
power state is changing. First, split up the pre/post transition
calls to be per-powerdomain, and then make them conditional on whether
the power domain is actually changing states.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Iteration over all power domains in the idle path is unnecessary since
only power domains that are transitioning need to be accounted for.
Also PRCM register accesses are known to be expensive, so the
additional latency added to the idle path is signficiant.
In order allow the pre/post transitions to be isolated and called
per-pwrdm, change the API so passing in a specific power domain will
trigger the pre/post transtion accounting for only that specific power
domain. Passing NULL means iterating over all power domains as is
current behavior.
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
all OMAP2+ chips that appear to have it integrated. Fix a problem
preventing it from being used on OMAP4.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP5ABnAAoJEMePsQ0LvSpL9sUP/RGCJ6olg1HbS8AVOIMHt0h2
WAwAZOE9urKSARtAxOeGNESZU2WzLEHRYmMkWz1kufMrD+7iYC+7McFb2jpf04nm
vszvgESdrYrgu/D9ThrbB/RMGLxM9pzLqWA8NTMMQLypSQ8O+swCXXxJquvKcr8u
+ek5qym2NX6YrE+uhzqA+MaUATcfX3JkXz4gUFTfhCAs5L6c/7h6F+RVtU2Shx4F
1onLeGhibSKXIzns8cfyituCgk5oLVhgWn4Thv0LmXTpE5kOl/F8ilXc95ljzrtk
Z4OgOnDHHXFxgOEXT1PL7X46yKWaKClymyPGr6UdkwLMq2LkmFjjyBqDSRA/KMFV
PIlCv+7SoqhajDxhjJXryZEwuzxayQcnjwGU+rWgI3ArFTCq3nTJ4IzJyQVTngEA
YQUkvXMfKJeRhOZ+5888tRemY4pHt4Dm9H4P6KZuDr/kgNk2d/7FHxWBkHDEzfE8
0JpNY3UFm8Pj2vSiusOd0qDLEQttvaOpUiuDlZm/WCzLTayVO7S6fJwMIxbvBsWj
91VqVnu2RvCO5OOvLuOZ7SAdDuuPy4u+8fAFMB0gf6W55NaFRqQzaQVH7rV3GQnd
arshoPv480x4p6KXejdcKm5xio+a7Ihc27fPNKzi2Ts2zcYOv/qu1LCQZ7UJEl2Z
YCcn1kLQcf/Qg93jUwrW
=Fpsi
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-b-for-3.6' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into devel-driver
Convert the OMAP HDQ1W driver to use runtime PM. Make it available on
all OMAP2+ chips that appear to have it integrated. Fix a problem
preventing it from being used on OMAP4.
reset. All of them are regression fixes, except for the missing omap2
interrupt controller binding that somehow got missed earlier.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJP40b1AAoJEBvUPslcq6Vz9iUP/0JUq0xvUEctn9HMOx4xt4Iz
MYC4DSwdUk9AHdbfzQSxHHHIYULjXJDtO0WlAgt9wHNG4lSHQHEG7XTTvpkWbyaQ
fzIQG/U7xW37HjHTS/v2JFftr/ZaF3gE4e1hcu+GJmUifACR5MBkfOPhqmJDqku2
eN4suYTUoV4Ey4Ijh+bc/T6XKFFyg0YaxyAKaMRpLQKhDK/Ihy8pyA/3+ggLCbnT
2U/ZszJgbc34N9VEYG2kLvz+JVVtG6JzHjI4Oa7wQQ9UpsK/NVWhbZ/F/0yjjyuw
TWWUFSxOIrU+/i1G2Bz1NS4rniCAnNlAMsodmrRbSRgJLItIjdILPV/apX5N8WRL
bus3kV/2I7C1OwbCqiXBCXXQlPZmMzTLhQyQWs6bGhjtmVdpVpoolE4Wgk4okxWJ
eBDh10xmTHwoYh/y3wAcN7q3s1A6cNj6Vl0+nnUFIfTo2w6ca4znLjZUvhVEBkNg
wufARvMP1o1YBRN9yS9wlFsLdVS3J+ALu/+zbHeJKWIzPXSaHLfrVTNSCpb3iHEX
3ZXMPooFjpP23ZYJoi8eILaBP6mD+3vD9eM0PYJYeL181Huihk8i8rQYZDbLQbCL
avWZAyfgul4Pcg48IlStsjE3pBnr0HZ6WPP8T8TCg6oqS19dKqjSG/Jwv1+iuNo6
GQuu/hCsFjrJ3YOBgcDj
=cMPJ
-----END PGP SIGNATURE-----
Merge tag 'omap-fixes-for-v3.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
From Tony Lindgren:
"Here are a few fixes with the biggest one being fix for Beagle DVI
reset. All of them are regression fixes, except for the missing omap2
interrupt controller binding that somehow got missed earlier."
* tag 'omap-fixes-for-v3.5-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP: Fix Beagleboard DVI reset gpio
arm/dts: OMAP2: Fix interrupt controller binding
ARM: OMAP2: Fix tusb6010 GPIO interrupt for n8x0
ARM: OMAP2+: Fix MUSB ifdefs for platform init code
As IO Daisy chain sequence is triggered via hwmod mux, there is no need to
control it from cpuidle path for OMAP3.
Also as omap3_disable_io_chain is no longer being used, just remove the
function.
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>
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>
Enable IO Wake up for OMAP3/4 as part of PRM Init. Currently this has been
managed in cpuidle path which is not the right place. Subsequent patch
will remove IO Daisy chain handling in cpuidle path once daisy chain is
handled as part of hwmod mux. This patch also moves the OMAP4 IO wakeup
enable code from the trigger function to init time setup.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: harmonize function names with other PRM functions; add
kerneldoc; resolve checkpatch warnings]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
IO daisychain is a mechanism that allows individual IO pads to generate
wakeup events on their own based on a switch of an input signal level.
This allows the hardware module behind the pad to be powered down, but
still have device level capability to detect IO events, and once this
happens the module can be powered back up to resume IO. See section
3.9.4 in OMAP4430 Public TRM for details.
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: use the shared MAX_IOPAD_LATCH_TIME declaration; renamed
omap4_trigger_io_chain() to conform to other PRM function names;
added kerneldoc; resolved checkpatch warnings]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Since IO Daisychain modifies only PRM registers, it makes sense to move
it to PRM File. Also changed the timeout value for IO chain enable to
100us and added a wait for status disable at the end.
Thanks to Nishanth Menon <nm@ti.com> for contributing a fix to the
timeout code waiting for WUCLKOUT to go high.
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Nishanth Menon <nm@ti.com>
Reviewed-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: renamed omap3_trigger_io_chain() to better describe the
end result and to match other PRM functions; removed
omap3_disable_io_chain(); moved MAX_IOPAD_LATCH_TIME to prcm-common as it
will also be used by the OMAP4 code; removed unnecessary barrier;
added kerneldoc; added credit for fix from Nishanth]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Currently the enabling and disabling of IO Daisy chain is not
according to the TRM. The below steps are followed to enable/
disable the IO chain, based loosely on the "Sec 3.5.7.2.2
I/O Wake-Up Mechanism" section in OMAP3630 Public TRM[1].
Steps to enable IO chain:
[a] Set PM_WKEN_WKUP.EN_IO bit
[b] Set the PM_WKEN_WKUP.EN_IO_CHAIN bit
[c] Poll for PM_WKST_WKUP.ST_IO_CHAIN.
[d] When ST_IO_CHAIN bit set to 1, clear PM_WKEN_WKUP.EN_IO_CHAIN
[e] Clear ST_IO_CHAIN bit.
Steps to disable IO chain:
[a] Clear PM_WKEN_WKUP.EN_IO_CHAIN bit
[b] Clear PM_WKEN_WKUP.EN_IO bit
[c] Clear PM_WKST_WKUP.ST_IO bit by writing 1 to it.
Step [e] & [c] in each case can be skipped, as these are handled
by the PRCM interrupt handler later.
[1] http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vV.zip
Signed-off-by: Mohan V <mohanv@ti.com>
Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com>
[paul@pwsan.com: modified commit message to clarify that these steps are
based loosely on the TRM section, rather than documented exactly]
Reviewed-by: Rajendra Nayak <rnayak@ti.com>
[paul@pwsan.com: resolved new warnings from checkpatch]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
For OMAP4 only builds, the omap2_prm_* functions have dummy wrappers
to detect incorrect usage. However, several unrelated omap3 PRM
functions have made it inside the #else clause of the #ifdef wrapping
the omap2_prm stubs, causing them to disappear on OMAP4-only builds.
This was unnoticed until the IO chain support was added and introduced
a new function in this section which is referenced by omap_hwmod.c:
arch/arm/mach-omap2/omap_hwmod.c: In function '_reconfigure_io_chain':
arch/arm/mach-omap2/omap_hwmod.c:1665:3: error: implicit declaration of function 'omap3xxx_prm_reconfigure_io_chain' [-Werror=implicit-function-declaration]
Fix by using the #ifdef to only wrap the omap2_prm functions that
need stubs on OMAP4-only builds.
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
[paul@pwsan.com: fixed checkpatch warnings for patch description]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Convert the old-style device registration code for HDQ1W to use
omap_device. This will allow the driver to be converted to use PM
runtime and to take advantage of the OMAP IP block management
infrastructure (hwmod, PM, etc.).
A side benefit of this conversion is that it also makes the HDQ device
available on OMAP2420. The previous code only enabled it on 2430 and
3430.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: NeilBrown <neilb@suse.de>
Tested-by: NeilBrown <neilb@suse.de>
