Commit a819c4f1 (ARM: OMAP3: PM: Only access IVA if one exists)
changed PM to not access IVA registers on omaps that don't have
them. Turns out we still need to idle iva2 as otherwise
iva2_pwrdm will stay on and block deeper idle states.
It seems that the only part of the reset that may not be needed
is the setting of the iva2 boot mode to idle. But as that register
seems to be there and is harmless if no iva2 is on the SoC, it's
probably safest to do the complete reset.
Acked-by: Mark A. Greer <mgreer@animalcreek.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
On OMAP platform, FIQ is reserved for secure environment only. If at all
the FIQ needs to be disabled, it involves going through security
API call. Hence the local_fiq_[enable/disable]() in the OMAP code is bogus.
On GP devices too, the fiq is disabled for non-secure software.
So just get rid of it.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
The text in Documentation said it would be removed in 2.6.41;
the text in the Kconfig said removal in the 3.1 release. Either
way you look at it, we are well past both, so push it off a cliff.
Note that the POWER_CSTATE and the POWER_PSTATE are part of the
legacy tracing API. Remove all tracepoints which use these flags.
As can be seen from context, most already have a trace entry via
trace_cpu_idle anyways.
Also, the cpufreq/cpufreq.c PSTATE one is actually unpaired, as
compared to the CSTATE ones which all have a clear start/stop.
As part of this, the trace_power_frequency also becomes orphaned,
so it too is deleted.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Based on earlier discussions[1] we attempted to find a suitable
location for the omap DMA header in commit 2b6c4e73 (ARM: OMAP:
DMA: Move plat/dma.h to plat-omap/dma-omap.h) until the conversion
to dmaengine is complete.
Unfortunately that was before I was able to try to test compile
of the ARM multiplatform builds for omap2+, and the end result
was not very good.
So I'm creating yet another all over the place patch to cut the
last dependency for building omap2+ for ARM multiplatform. After
this, we have finally removed the driver dependencies to the
arch/arm code, except for few drivers that are being worked on.
The other option was to make the <plat-omap/dma-omap.h> path
to work, but we'd have to add some new header directory to for
multiplatform builds.
Or we would have to manually include arch/arm/plat-omap/include
again from arch/arm/Makefile for omap2+.
Neither of these alternatives sound appealing as they will
likely lead addition of various other headers exposed to the
drivers, which we want to avoid for the multiplatform kernels.
Since we already have a minimal include/linux/omap-dma.h,
let's just use that instead and add a note to it to not
use the custom omap DMA functions any longer where possible.
Note that converting omap DMA to dmaengine depends on
dmaengine supporting automatically incrementing the FIFO
address at the device end, and converting all the remaining
legacy drivers. So it's going to be few more merge windows.
[1] https://patchwork.kernel.org/patch/1519591/#
cc: Russell King <linux@arm.linux.org.uk>
cc: Kevin Hilman <khilman@ti.com>
cc: "Benoît Cousson" <b-cousson@ti.com>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: "David S. Miller" <davem@davemloft.net>
cc: Vinod Koul <vinod.koul@intel.com>
cc: Dan Williams <djbw@fb.com>
cc: Mauro Carvalho Chehab <mchehab@infradead.org>
cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
cc: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Kyungmin Park <kyungmin.park@samsung.com>
cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
cc: Hans Verkuil <hans.verkuil@cisco.com>
cc: Vaibhav Hiremath <hvaibhav@ti.com>
cc: Lokesh Vutla <lokeshvutla@ti.com>
cc: Rusty Russell <rusty@rustcorp.com.au>
cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
cc: Afzal Mohammed <afzal@ti.com>
cc: linux-crypto@vger.kernel.org
cc: linux-media@vger.kernel.org
cc: linux-mtd@lists.infradead.org
cc: linux-usb@vger.kernel.org
cc: linux-fbdev@vger.kernel.org
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Some miscellaneous OMAP hwmod changes for 3.8, along with a PRM
change needed for one of the hwmod patches to function.
Basic test logs for this branch on top of Tony's
omap-for-v3.8/clock branch at commit
558a0780b0 are here:
http://www.pwsan.com/omap/testlogs/hwmod_devel_a_3.8/20121121161522/
However, omap-for-v3.8/clock at 558a0780 does not include some fixes
that are needed for a successful test. With several reverts,
fixes, and workarounds applied, the following test logs were
obtained:
http://www.pwsan.com/omap/testlogs/TEST_hwmod_devel_a_3.8/20121121162719/
which indicate that the series tests cleanly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQs9J2AAoJEBvUPslcq6Vznz0QAM5Q8krs4fAZ35ekOnAAeh4a
kWbkSq/VH74uPMbobUOeHVusJbfZBxm24CT/911wNXIHg/hku6WPhnQzStX2n/6w
JKtHcQXeftgXecHBeyjDGdypcwknwTzIg78BECJi1FO+y/imaMjvxLDm74BXdBRF
bLLmMLe2+Fnwz4IjwtOPz9mbje9NexMy+ppDyIVT36H+t9PQwDArOJMqLINWdioW
e9LjUM4mr/5YZEOVu1tC30bJIcKq/m5yYS7dwifcSN67EsMUw90kQTKFtmNC2SzL
DozIUHdsc990U65LhrH5EzoluT/tWPFl+ijkLmehfaVgSYIT5CmkDCgKUFNNY83r
7eVcPYvK8Nf2V8s0rMwy2mBy8j9p3Yug/kmOpRxdI90YCqxikJD5zdW+yQVX4qnt
GXOyfw9BwK8g0Y7lEea1MN2s+y1E3n8EcaVyvQAW4N0wCkm3ELE6rm9HZoBXD3+d
4EovXn8DmTfvqiJ/M/FCqphyMMvp+NhO8Cg2vJUotEiCHdbIkaeXNI4AWg/sMlId
aXUazd2i1WvynXvcSqJBbSKZQM+8GBPAuxqSQc8tP0JuOZo//sBYbXSUFClWksaw
bvp+iJ6g/4/QqIG/B5EARSbkfCI1fTfTYObLe2Pd3cRdML3F0f/rCWRjPfl20BnQ
weUVgyikcXT+aH2sfdIB
=JSAM
-----END PGP SIGNATURE-----
Merge tag 'tags/omap-for-v3.8/devel-prcm-signed' into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3
omap prcm changes via Paul Walmsley <paul@pwsan.com>:
Some miscellaneous OMAP hwmod changes for 3.8, along with a PRM
change needed for one of the hwmod patches to function.
Basic test logs for this branch on top of Tony's
omap-for-v3.8/clock branch at commit
558a0780b0 are here:
http://www.pwsan.com/omap/testlogs/hwmod_devel_a_3.8/20121121161522/
However, omap-for-v3.8/clock at 558a0780 does not include some fixes
that are needed for a successful test. With several reverts,
fixes, and workarounds applied, the following test logs were
obtained:
http://www.pwsan.com/omap/testlogs/TEST_hwmod_devel_a_3.8/20121121162719/
which indicate that the series tests cleanly.
Conflicts:
arch/arm/mach-omap2/cm33xx.c
arch/arm/mach-omap2/io.c
arch/arm/mach-omap2/prm_common.c
arch/arm/mach-omap2/prcm.c and arch/arm/plat-omap/include/plat/prcm.h
are now completely unused and can be removed.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
Most of the defines are specific to omap1 and omap2+,
and should be in the local headers. Only minimal function
prototypes need to be shared.
As discussed on linux-arm-kernel, we want to avoid
relative includes for the arch/arm/*omap* shared code:
http://www.spinics.net/lists/linux-omap/msg80520.html
So this patch re-adds a minimal plat/sram.h.
The new plat/sram.h must not be included from drivers,
that will break build for omap2+ CONFIG_MULTIPLATFORM.
Note that this patch temporarily adds two more
relative includes; Those will be removed in the
following patch.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Prepares for the future move of the PRM/CM code to drivers/. Also
includes some prcm.[ch] cleanup patches from the WDTIMER cleanup
series that don't need external acks.
Basic test logs for this branch on top of v3.7-rc2 are here:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/
But due to the number of unrelated regressions present in v3.7-rc[12],
it's not particularly usable as a testing base. With reverts, fixes,
and workarounds applied as documented in:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt
the following test logs were obtained:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/
which indicate that the series tests cleanly.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQhEVeAAoJEMePsQ0LvSpLXMAP/R823zHuhSBsFYTAzoLpOsBu
1btfoXY+aTh/ZYQpn2zqbseHyBVoN7JuBNFA25UlgCIB/+tL2o+B62HQE3c31HZi
zrOlUrSvIl7zYTLhbu8rezULSYGO3RHqtUGLJ9/RUV3su8zIATmHKgzA1f/aYH9x
2OKVIijXjvK4kKRpHhg8BGlD6stbuFDJbmik2/wgcO+159lKY6ZTRnHsj6PgZVIO
BjbxpBujLYVBhJRJP0NNLVtGToGK54GvnHZxfVCu9oJ87n2amgaP6RHHHfEX0eMJ
K65toYNIzZEmMahnazCcsiB+xK2Y2iiSZdOMPhH0FspCPTKTUl+czOlMGq7oyHmU
xVmDyVHOVd5JRt5d985VlVScDrye06GxjWri557eeGcvOyQrlhJSntjdL2RZZaiu
bpIhT1PRo8hqxtajcZlqBT7jSaH8kxQIQRXgGqJzY9iYLfUGU6DU7WYoqQTrrev7
aCZG8SnDbmltXMvhw13owDzy8xpdssCFaT8Fbxaxa6jq1GF1xyfEucDZDQPlZZd7
vbhdjYCBMiFcgJ3xWAmivboLPR1r5nZQdpwuYJTqoIvuJutB8Y0dJza7Dm0DGehc
uJw/K/L/2qBdlOatFU4nk1c4AoTXZ+zn+ZVziTFus6ajhdB46C0i/vMLAXF68aDQ
23ow9fKjRsuHfKqjfzMP
=asxx
-----END PGP SIGNATURE-----
Merge tag 'omap-cleanup-a-for-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8/cleanup-prcm
The first set of OMAP PRM/CM-related cleanup patches for 3.8.
Prepares for the future move of the PRM/CM code to drivers/. Also
includes some prcm.[ch] cleanup patches from the WDTIMER cleanup
series that don't need external acks.
Basic test logs for this branch on top of v3.7-rc2 are here:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/
But due to the number of unrelated regressions present in v3.7-rc[12],
it's not particularly usable as a testing base. With reverts, fixes,
and workarounds applied as documented in:
http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt
the following test logs were obtained:
http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/
which indicate that the series tests cleanly.
Conflicts:
arch/arm/mach-omap2/Makefile
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c
arch/arm/mach-omap2/pm24xx.c
On OMAP34xx/35xx, and OMAP36xx chips with ES < 1.2, if the PER
powerdomain goes to OSWR or OFF while CORE stays at CSWR or ON, or if,
upon chip wakeup from OSWR or OFF, the CORE powerdomain goes ON before
PER, the UART3/4 FIFOs and McBSP2/3 SIDETONE memories will be
unusable. This is erratum i582 in the OMAP36xx Silicon Errata
document.
This patch implements one of several parts of the workaround: the
addition of the wakeup dependency between the PER and WKUP
clockdomains, such that PER will wake up at the same time CORE_L3
does.
This is not a complete workaround. For it to be complete:
1. the PER powerdomain's next power state must not be set to OSWR or
OFF if the CORE powerdomain's next power state is set to CSWR or
ON;
2. the UART3/4 FIFO and McBSP2/3 SIDETONE loopback tests should be run
if the LASTPOWERSTATEENTERED bits for PER and CORE indicate that
PER went OFF while CORE stayed on. If loopback tests fail, then
those devices will be unusable until PER and CORE can undergo a
transition from ON to OSWR/OFF and back ON.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Move OMAP3xxx-specific CM functions & macros into cm3xxx.[ch] and
OMAP2xxx-specific macros into cm2xxx.[ch]. Move basic CM register
access functions into static inline functions in cm2xxx_3xxx.h,
leaving only OMAP2/3 hardreset functions in cm2xxx_3xxx.c.
As part of this, split the CM and hwmod code that waits for devices to
become ready into SoC-specific functions.
This is in preparation for the upcoming move of this code to drivers/.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Move OMAP3xxx-specific PRM functions & macros into prm3xxx.[ch] and
OMAP2xxx-specific macros into prm2xxx.h. (prm2xxx.c will be created
by a subsequent patch when it's needed.) Move basic PRM register
access functions into static inline functions in prm2xxx_3xxx.h, leaving
only OMAP2/3 hardreset functions in prm2xxx_3xxx.c.
Also clarify the initcall function naming to reinforce that this code
is specifically for the PRM IP block.
This is in preparation for the upcoming powerdomain series and the
upcoming move of this code to drivers/.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Reviewed-by: Russ Dill <Russ.Dill@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
We want to remove plat/cpu.h. To do this, let's first split
it to private soc.h to mach-omap1 and mach-omap2. We have to
keep plat/cpu.h around until the remaining drivers are fixed,
so let's include the local soc.h in plat/cpu.h and for drivers
still including plat/cpu.h.
Once the drivers are fixed not to include plat/cpu.h, we
can remove the file.
This is needed for the ARM common zImage support.
[tony@atomide.com: updated to not print a warning]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Remove arch/arm/plat-omap/include/plat/sdrc.h by folding its contents
into arch/arm/mach-omap2/sdrc.h. The objective is to assist Tony in
cleaning out arch/arm/plat-omap/, as his upstreams request.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>
[tony@atomide.com: updated to remove rotate macros]
Signed-off-by: Tony Lindgren <tony@atomide.com>
Move plat/dma.h to plat-omap/dma-omap.h as part of single
zImage work
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Requirement of gpmc header outside of mach-omap2 has been
cutoff, move gpmc header file in plat-omap folder to local
mach-omap2 folder
Objective - common zImage participation of omap
Signed-off-by: Afzal Mohammed <afzal@ti.com>
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/
This way we can remove includes of plat/gpio.h which won't work
with the single zImage support.
Note that we also remove the cpu_class_is_omap2() check
in gpio-omap.c as the drivers should not call it as we need to
make it local to arch/arm/mach-omap2 for single zImage support.
While at it, arrange the related includes in the standard way.
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: linux-mtd@lists.infradead.org
Cc: alsa-devel@alsa-project.org
Acked-by: Linus Walleij <linus.walleij@linaro.org>
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>
This reverts commit 58f0829b71.
Converstion to per-pwrdm per/post transition calls was a bit
premature. Only tracking MPU, PER & CORE in the idle path means we
lose the accounting for all the other powerdomains which may also
transition in idle. On OMAP3, due to autodeps, several powerdomains
transition along with MPU (e.g. DSS, USBHOST), and the accounting for
these was lost with this patch. Since the accounting includes the
context loss counters, drivers for devices in those power domains
would never notice context lost, so would likely hang after any
off-mode transitions.
This patch should be revisited when the upcoming clkdm/pwrmdm/voltdm
use-counting seires is merged since then we can properly do accounting
without relying on a call in the idle path.
In addition, the original patch had another bug because the PER
powerdomain accounting was not updated until after the GPIO resume
hook is called. Since gpio_resume_after_idle() checks the context
loss count (which is not yet updated) it would not properly restore
context, leaving the GPIO banks in an undefined state.
Cc: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Reported-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.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+
...
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 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>
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>
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>
prcm_setup_regs() blindly accesses IVA bits
in the PRM and calls omap3_iva_idle() which
does more IVA related register accesses.
Only do this if the IVA hardware actually
exists.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
This is a patch series from Shawn Guo that moves from individual
late_initcalls() to using a member in the machine structure to invoke
a platform's late initcalls.
This cleanup is a step in the move towards multiplatform kernels since
it would reduce the need to check for compatible platforms in each and
every initcall.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQIcBAABAgAGBQJPwHYJAAoJEIwa5zzehBx3PugP/2Wd6HN030iO5EhFBcBcrh5T
WaJ4KfzK3tWev5QA3idvenVNhk5My1HQ+PLij7BLpjNqKCKlNK0k/K9wMI5X827T
wkFFprdUcoMVrB1ZCjzwCk4/uTGWB5BMxoZ6mlBh1sZIR/yXo91t+wO971Uqr0ho
Ky1oW9uaPZ6Eja00iDLkfJfygquA5+zNb0a29q19zWnHlRkH76jtqZgfDKy9I2nq
virYZ4uhoPnY2g1JxhnaMNNC861CgfTDEtmtNjgeEbA6t9bbjqsZoQRhcYHZP4OM
a4Iu8FOyIvAAzQzUglfAZ4Ar4uYTmVRnG39XFh4wK/8tJYt0hEQwFS26B0pYKx/5
F76bwc4SqO7H9AWBF0WhyUbny5XmJcNwJjobm/oCeAvemTi3xA6BbubyfKMHPoIr
dDSEqcAcMt9G6sS48h3Pm0caEYDVzxf202vdylz1JABiJZi1W/7v+NMdhujfotJh
7IGehNRu0foPEsRIS9wsvD2TzSdQtDdjyFkGHd83XMc3JpvwmyePO6ynbbxrVnJJ
HzlPnbLIk3VyqyVCqVXj21NKEY1dbsYPItketAwwzc1BUGcld0qvQY/t/UI4JQT6
9vq77AwNjUhfomDdEWTp7aNx0whkY0R5KEY9jHjuu9WoE+xdPZbQKm589AJ6LA4U
j6HPMzWKUHOKT6g10rCl
=21h6
-----END PGP SIGNATURE-----
Merge tag 'cleanup-initcall' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull sweeping late_initcall cleanup for arm-soc from Olof Johansson:
"This is a patch series from Shawn Guo that moves from individual
late_initcalls() to using a member in the machine structure to invoke
a platform's late initcalls.
This cleanup is a step in the move towards multiplatform kernels since
it would reduce the need to check for compatible platforms in each and
every initcall."
Fix up trivial conflicts in arch/arm/mach-{exynos/mach-universal_c210.c,
imx/mach-cpuimx51.c, omap2/board-generic.c} due to changes nearby (and,
in the case of cpuimx51.c the board support being deleted)
* tag 'cleanup-initcall' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: ux500: use machine specific hook for late init
ARM: tegra: use machine specific hook for late init
ARM: shmobile: use machine specific hook for late init
ARM: sa1100: use machine specific hook for late init
ARM: s3c64xx: use machine specific hook for late init
ARM: prima2: use machine specific hook for late init
ARM: pnx4008: use machine specific hook for late init
ARM: omap2: use machine specific hook for late init
ARM: omap1: use machine specific hook for late init
ARM: msm: use machine specific hook for late init
ARM: imx: use machine specific hook for late init
ARM: exynos: use machine specific hook for late init
ARM: ep93xx: use machine specific hook for late init
ARM: davinci: use machine specific hook for late init
ARM: provide a late_initcall hook for platform initialization
By default, request_irq() will auto-enable the requested IRQ.
For PRCM interrupts, we may want to avoid that until the PM core code
is fully ready to handle the interrupts. This is particularily true
for IO pad interrupts on OMAP3, which are shared between the hwmod
core and the PRM core.
In order to avoid PRCM IO-chain interrupts until the PM core is ready
to handle them, ready, set the IRQ_NOAUTOEN flag for the PRCM IO-chain
interrupt, which means it will remain disabled after request_irq().
Then, explicitly enable the PRCM interrupts after the request_irq() in
the PM core (but not in the hwmod core.)
Special thanks to Tero Kristo for suggesting to isolate the fix to
only the IO-chain interrupt on OMAP3 instead of all PRCM interrupts.
Cc: Tero Kristo <t-kristo@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Resolve some warnings identified by cppcheck in arch/arm/mach-omap2:
[arch/arm/mach-omap2/usb-tusb6010.c:129]: (style) Checking if unsigned variable 'tmp' is less than zero.
[arch/arm/mach-omap2/prm_common.c:241]: (error) Possible null pointer dereference: irq_setup - otherwise it is redundant to check if irq_setup is null at line 247
[arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'per_clkdm' is assigned a value that is never used
[arch/arm/mach-omap2/pm34xx.c:790]: (style) Variable 'core_clkdm' is assigned a value that is never used
[arch/arm/mach-omap2/pm24xx.c:185]: (style) Variable 'only_idle' is assigned a value that is never used
[arch/arm/mach-omap2/mux.c:254]: (error) Possible null pointer dereference: mux
[arch/arm/mach-omap2/mux.c:258]: (error) Possible null pointer dereference: mux
[arch/arm/mach-omap2/gpmc-onenand.c:178]: (style) Variable 'tick_ns' is assigned a value that is never used
[arch/arm/mach-omap2/gpio.c:56]: (error) Possible null pointer dereference: pdata - otherwise it is redundant to check if pdata is null at line 57
[arch/arm/mach-omap2/devices.c:45]: (style) Variable 'l' is assigned a value that is never used
[arch/arm/mach-omap2/board-omap3evm.c:641] -> [arch/arm/mach-omap2/board-omap3evm.c:639]: (style) Found duplicate branches for if and else.
[arch/arm/mach-omap2/am35xx-emac.c:95]: (style) Variable 'regval' is assigned a value that is never used
[arch/arm/mach-omap2/devices.c:74]: (style) Variable 'l' is assigned a value that is never used
[arch/arm/mach-omap2/pm34xx.c:277]: (style) Variable 'per_prev_state' is assigned a value that is never used
[arch/arm/plat-omap/dmtimer.c:352]: (error) Possible null pointer dereference: timer - otherwise it is redundant to check if timer is null at line 354
[arch/arm/plat-omap/omap_device.c:478]: (style) Variable 'c' is assigned a value that is never used
[arch/arm/plat-omap/usb.c:42]: (style) Variable 'status' is assigned a value that is never used
[arch/arm/mach-omap1/clock.c:197]: (style) Variable 'dpll1_rate' is assigned a value that is never used
[arch/arm/mach-omap1/lcd_dma.c:60]: (style) struct or union member 'lcd_dma_info::size' is never used
[arch/arm/mach-omap1/pm.c:572]: (style) Variable 'entry' is assigned a value that is never used
Some of them are pretty good catches, such as gpio.c:56 and
usb-tusb6010.c:129.
Thanks to Jarkko Nikula for some comments on the sscanf() warnings.
It seems that the kernel sscanf() ignores the field width anyway for the
%d format, so those changes have been dropped from this second version.
Thanks to Daniel Marjamäki <daniel.marjamaki@gmail.com> for pointing
out that a variable was unnecessarily marked static in the
board-omap3evm.c change.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Felipe Balbi <balbi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: Charulatha Varadarajan <charu@ti.com>
Cc: Daniel Marjamäki <daniel.marjamaki@gmail.com>
Cc: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: Charulatha Varadarajan <charu@ti.com> # for gpio.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAT3NKzROxKuMESys7AQKElw/+JyDxJSlj+g+nymkx8IVVuU8CsEwNLgRk
8KEnRfLhGtkXFLSJYWO6jzGo16F8Uqli1PdMFte/wagSv0285/HZaKlkkBVHdJ/m
u40oSjgT013bBh6MQ0Oaf8pFezFUiQB5zPOA9QGaLVGDLXCmgqUgd7exaD5wRIwB
ZmyItjZeAVnDfk1R+ZiNYytHAi8A5wSB+eFDCIQYgyulA1Igd1UnRtx+dRKbvc/m
rWQ6KWbZHIdvP1ksd8wHHkrlUD2pEeJ8glJLsZUhMm/5oMf/8RmOCvmo8rvE/qwl
eDQ1h4cGYlfjobxXZMHqAN9m7Jg2bI946HZjdb7/7oCeO6VW3FwPZ/Ic75p+wp45
HXJTItufERYk6QxShiOKvA+QexnYwY0IT5oRP4DrhdVB/X9cl2MoaZHC+RbYLQy+
/5VNZKi38iK4F9AbFamS7kd0i5QszA/ZzEzKZ6VMuOp3W/fagpn4ZJT1LIA3m4A9
Q0cj24mqeyCfjysu0TMbPtaN+Yjeu1o1OFRvM8XffbZsp5bNzuTDEvviJ2NXw4vK
4qUHulhYSEWcu9YgAZXvEWDEM78FXCkg2v/CrZXH5tyc95kUkMPcgG+QZBB5wElR
FaOKpiC/BuNIGEf02IZQ4nfDxE90QwnDeoYeV+FvNj9UEOopJ5z5bMPoTHxm4cCD
NypQthI85pc=
=G9mT
-----END PGP SIGNATURE-----
Merge tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system
Pull "Disintegrate and delete asm/system.h" from David Howells:
"Here are a bunch of patches to disintegrate asm/system.h into a set of
separate bits to relieve the problem of circular inclusion
dependencies.
I've built all the working defconfigs from all the arches that I can
and made sure that they don't break.
The reason for these patches is that I recently encountered a circular
dependency problem that came about when I produced some patches to
optimise get_order() by rewriting it to use ilog2().
This uses bitops - and on the SH arch asm/bitops.h drags in
asm-generic/get_order.h by a circuituous route involving asm/system.h.
The main difficulty seems to be asm/system.h. It holds a number of
low level bits with no/few dependencies that are commonly used (eg.
memory barriers) and a number of bits with more dependencies that
aren't used in many places (eg. switch_to()).
These patches break asm/system.h up into the following core pieces:
(1) asm/barrier.h
Move memory barriers here. This already done for MIPS and Alpha.
(2) asm/switch_to.h
Move switch_to() and related stuff here.
(3) asm/exec.h
Move arch_align_stack() here. Other process execution related bits
could perhaps go here from asm/processor.h.
(4) asm/cmpxchg.h
Move xchg() and cmpxchg() here as they're full word atomic ops and
frequently used by atomic_xchg() and atomic_cmpxchg().
(5) asm/bug.h
Move die() and related bits.
(6) asm/auxvec.h
Move AT_VECTOR_SIZE_ARCH here.
Other arch headers are created as needed on a per-arch basis."
Fixed up some conflicts from other header file cleanups and moving code
around that has happened in the meantime, so David's testing is somewhat
weakened by that. We'll find out anything that got broken and fix it..
* tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system: (38 commits)
Delete all instances of asm/system.h
Remove all #inclusions of asm/system.h
Add #includes needed to permit the removal of asm/system.h
Move all declarations of free_initmem() to linux/mm.h
Disintegrate asm/system.h for OpenRISC
Split arch_align_stack() out from asm-generic/system.h
Split the switch_to() wrapper out of asm-generic/system.h
Move the asm-generic/system.h xchg() implementation to asm-generic/cmpxchg.h
Create asm-generic/barrier.h
Make asm-generic/cmpxchg.h #include asm-generic/cmpxchg-local.h
Disintegrate asm/system.h for Xtensa
Disintegrate asm/system.h for Unicore32 [based on ver #3, changed by gxt]
Disintegrate asm/system.h for Tile
Disintegrate asm/system.h for Sparc
Disintegrate asm/system.h for SH
Disintegrate asm/system.h for Score
Disintegrate asm/system.h for S390
Disintegrate asm/system.h for PowerPC
Disintegrate asm/system.h for PA-RISC
Disintegrate asm/system.h for MN10300
...
Disintegrate asm/system.h for ARM.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Russell King <linux@arm.linux.org.uk>
cc: linux-arm-kernel@lists.infradead.org
Currently, pm34xx.c has a mix of printk() and pr_*() statements
so replace the printk() statements with the equivalent pr_*()
statements.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
It appears that the error paths were overlooked when the
omap3_pm_init() routine had the prcm chain handler code
added. Fix this by adding a goto target and reordering
the error handling code. Also fix how the irq argument
for free_irq() is determined.
Signed-off-by: Mark A. Greer <mgreer@animalcreek.com>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
* 'cleanup-pm' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
ARM: OMAP2+: PM: share some suspend-related functions across OMAP2, 3, 4
ARM: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set
ARM: OMAP: omap_device: remove omap_device_parent
ARM: OMAP2+: PM debug: fix the use of debugfs_create_* API
ARM: OMAP2+: PM: share clkdms_setup() across OMAP2, 3, 4
ARM: OMAP2+: PM: clean up omap_set_pwrdm_state()
ARM: OMAP3: PM: remove superfluous calls to pwrdm_clear_all_prev_pwrst()
ARM: OMAP: convert omap_device_build() and callers to __init
ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __init
ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pins
ARM: OMAP: omap_device: Expose omap_device_{alloc, delete, register}
ARM: OMAP: Fix build error when mmc_omap is built as module
ARM: OMAP: Fix kernel panic with HSMMC when twl4030_gpio is a module
The platform_suspend_ops can be shared across OMAP2, 3, and 4, along
with all of the functions referenced in that structure. This patch
shares them. It also removes the suspend_state file-scoped variable
in the OMAP2 and 3 PM code; it does not appear to be actually needed
by anything.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
[khilman@ti.com: minor rework needed due to rebase/merge with conflicting changes]
Signed-off-by: Kevin Hilman <khilman@ti.com>
clkdms_setup() is identical across OMAP2, 3, and 4, so share it.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Remove some superfluous calls to pwrdm_clear_all_prev_pwrst().
pwrdm_pre_transition(), which appears a few lines after these calls,
invokes pwrdm_clear_all_prev_pwrst() on each powerdomain -- there's no
need to do it twice.
N.B.: some of us have observed that accesses to the previous
powerstate registers seem to be quite slow. Although the writes
removed by this patch should be buffered by the write buffer, there is
a read to a PRM register immediately afterwards. That will block the
OMAP3 MPU until all of those writes complete. So this patch should
result in a minor performance improvement during idle entry.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Tero Kristo <t-kristo@ti.com>
[khilman@ti.com: removed a couple more for OMAP4]
Tested-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Conflicts:
arch/arm/mach-omap1/gpio16xx.c
drivers/gpio/gpio-omap.c
Merge in the runtime-pm-cleanup branch from the gpio tree into
next/cleanup, this resolves a nonobvious merge conflict between
the two branches. Both branches move parts of the gpio-omap
driver into platform code, this takes the superset of both
changes.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Modify omap_gpio_prepare_for_idle() & omap_gpio_resume_after_idle() functions
to handle save context & restore context respectively in the OMAP GPIO driver
itself instead of calling these functions from pm specific files.
For this, in gpio_prepare_for_idle(), call *_get_context_loss_count() and in
gpio_resume_after_idle() call it again. If the count is different, do restore
context.
Signed-off-by: Charulatha V <charu@ti.com>
Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
Tony Lindgren