In the case where has_uart4 is false, en_uart4_mask and grpsel_uart4_mask
are not initialized and so any garbage value is being logically or'd into
the write of PM_WKEN and OMAP3430_PM_MPUGRPSEL. Fix this by initializing
these masks to zero.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This gets rid of need for some exported driver APIs, and simplifies the
initialization of the PRM driver. Done in preparation to make PRM a
separate driver. The init data is now also passed to the SoC specific
implementations, allowing future expansion to add feature flags etc.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
There is no need to provide the PRM base address through a low-level API
from the low-level IO init, as this information is available through DT.
Re-routed the parsing function to be called from the PRM drivers also to
simplify the implementation under io.c.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
OMAP2/3 now use generic API for the prm_clear_mod_irqs, the SoC specific
implementation details are provided through prm_ll_data.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
This makes the API the same as used with OMAP2, and makes it possible
to implement a generic driver API for the functionality.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
of_device_ids (i.e. compatible strings and the respective data) are not
supposed to change at runtime. All functions working with of_device_ids
provided by <linux/of.h> work with const of_device_ids. So mark the
non-const structs in arch/arm as const, too.
While at it also add some __initconst annotations.
Acked-by: Jason Cooper <jason@lakedameon.net>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This patch combines the various prm_warm_reset calls under a common
API prm_reset_system, and adds the SoC specific implementation under
prm_ll_data.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
This adds a generic API for reconfiguring the I/O chain. The implementation
will call the SoC specific function registered during init time. The SoC
specific reconfigure functions are also made static, as they don't need
to be accessed outside the PRM driver itself.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Nishanth Menon <nm@ti.com>
[tony@atomide.com: updated for recent omap3 prcm fixes]
Signed-off-by: Tony Lindgren <tony@atomide.com>
These are not needed outside the PRM driver, so make them static and
remove the prototypes from the public header.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
PRM driver now has a generic API for checking hardreset status. SoC
specific support functions are registered through the prm_ll_data.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
PRM driver now has a generic API for deasserting hardware resets. SoC
specific support functions are registered through the prm_ll_data.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
PRM driver now has a generic API for asserting hardware resets. SoC
specific support functions are registered through the prm_ll_data.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
New and updated SoC support. Among the things new for this release are:
- at91: Added support for the new SAMA5D4 SoC, following the earlier SAMA5D3
- bcm: Added support for BCM63XX family of DSL SoCs
- hisi: Added support for HiP04 server-class SoC
- meson: Initial support for the Amlogic Meson6 (aka 8726MX) platform
- shmobile: added support for new r8a7794 (R-Car E2) automotive SoC
Noteworthy changes to existing SoC support are:
- imx: convert i.MX1 to device tree
- omap: lots of power management work
- omap: base support to enable moving to standard UART driver
- shmobile: lots of progress for multiplatform support, still ongoing
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAVDWVHWCrR//JCVInAQJQVw/+NEfKWh6blDvLEWHpkmBtzdsT3s+r1wwb
ATtvd1Q7RlOMEbzxc2J87tJ44yHb64mSPBbC4BCGuQsM5IIvM4potmBphl/XxLfd
b8PNcI6nvLO+FZOcgon0JWmvVnt+vLGKPUWzURXSRjdrpVRg2qyRpW+nPBnvX4HP
qyzlSskkYzKm7WJQrIV1K3yYwRLrVZdz4DuF340mSFy+4H+uci2Fw91HJ9lKKmPS
24Klx2Q4n6wfg946WazWtz21HjEBuMzRCq0CGZrwcTJffRyMxa4iq/kqE3xGbPtN
onuP1gmAM7UOMewEvc1ZLycY7JyZ3mhKnKduqS/QN2JLLQEY2v1iYFnEKP8mHnnw
ax6RVi91PC2MSLZyPcRtsegSKB9l16I7H+C5pgTOMgsSaqxSG1JtV1qZl3uwhBnE
GB45KHPvTFojrH2+CqneNTLET1ozKgwtuHkWTG61/puYeap/VlpRU2OWj2mQF2E0
SiBzmlbUBpSqzjFgVGD4ywKAuVA/WpJtaOB7Qg26GL2QoNKrY/wsUCY8hU742+jE
b/N6obGcpmjytLkFRHx+AbYc75DHXkPtF4CWawDeQFW30LUeixZJqewQ61a56QF8
49DbO6J+sR0n3xlteD49QdQJzDCtKw3BV+VQaFRcxqVDq4LJAxtUHJZ7c3iyvzEi
6Yt+PsqSP7Y=
=ZHtj
-----END PGP SIGNATURE-----
Merge tag 'soc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC platform changes from Arnd Bergmann:
"New and updated SoC support. Among the things new for this release
are:
- at91: Added support for the new SAMA5D4 SoC, following the earlier
SAMA5D3
- bcm: Added support for BCM63XX family of DSL SoCs
- hisi: Added support for HiP04 server-class SoC
- meson: Initial support for the Amlogic Meson6 (aka 8726MX) platform
- shmobile: added support for new r8a7794 (R-Car E2) automotive SoC
Noteworthy changes to existing SoC support are:
- imx: convert i.MX1 to device tree
- omap: lots of power management work
- omap: base support to enable moving to standard UART driver
- shmobile: lots of progress for multiplatform support, still
ongoing"
* tag 'soc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (171 commits)
ARM: hisi: depend on ARCH_MULTI_V7
CNS3xxx: Fix debug UART.
ARM: at91: fix nommu build regression
ARM: meson: add basic support for MesonX SoCs
ARM: meson: debug: add debug UART for earlyprintk support
irq: Export handle_fasteoi_irq
ARM: mediatek: Add earlyprintk support for mt6589
ARM: hisi: Fix platmcpm compilation when ARMv6 is selected
ARM: debug: fix alphanumerical order on debug uarts
ARM: at91: document Atmel SMART compatibles
ARM: at91: add sama5d4 support to sama5_defconfig
ARM: at91: dt: add device tree file for SAMA5D4ek board
ARM: at91: dt: add device tree file for SAMA5D4 SoC
ARM: at91: SAMA5D4 SoC detection code and low level routines
ARM: at91: introduce basic SAMA5D4 support
clk: at91: add a driver for the h32mx clock
ARM: pxa3xx: provide specific platform_devices for all ssp ports
ARM: pxa: ssp: provide platform_device_id for PXA3xx
ARM: OMAP4+: Remove static iotable mappings for SRAM
ARM: OMAP4+: Move SRAM data to DT
...
We are getting "PRM: I/O chain clock line assertion timed out" errors
on early omaps for device tree based booting. This is because we are
unconditionally calling reconfigure_io_chain while legacy booting
has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c.
For device tree based booting, we are calling reconfigure_io_chain
unconditionally from pinctrl framework. So we need to add a check for
omap3_has_io_chain_ctrl() to avoid the errors for trying to access
a register that does not exist.
For es3.0, the documentation in "4.11.2 Device Off-Mode Configuration"
just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in
documentation for "4.11.2.2 I/O Wake-Up Mechanism" that describes the
PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get
added until in es3.1 probaly to fix issues with flakey wake-up events.
We are doing proper checks for ST_IO_CHAIN already in id.c and with
omap3_has_io_chain_ctrl(). For more information, see also commit
b02b917211 ("ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock
control detection").
Let's fix the issue by selecting the right function during init for
reconfigure_io_chain depending on the omap revision. For es3.0 and
earlier we need to just toggle EN_IO. By doing this, we can move the
check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code
in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain.
Thanks to Paul Walmsley and Nishanth Menon for help with debugging the
issue.
Fixes: 30a69ef785 ("ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap")
Cc: Kevin Hilman <khilman@kernel.org>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Tero Kristo <t-kristo@ti.com>
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Allow the PRM interrupt information to be picked up from device tree.
OMAP3 may use legacy boot and needs to be compatible with old dtbs
(without interrupt populated), for these, we use the value which is
pre-populated.
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Control module related PM initializations are now moved within control
module driver. Done in preparation to isolate the code to its own driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
code into drivers.
Basic build, boot, and PM test results are available here:
http://www.pwsan.com/omap/testlogs/prcm-cleanup-v3.16/20140515213244/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJTdZbbAAoJEMePsQ0LvSpLql4P/2pktswM4PLcmGVlS9AUiH25
+lT8ctTHUAS3n7hBSmZQCPWE/4hAsx7UDGUDTT3t6ASIHxAUsx0/RQ4/RTZQ7ZJZ
3cGUS5Y43v6n1RCP4Ruvs3R7yOamQWVCX2WR4cH0OlwfF2YVfeUDlJIJ0bK0/p5g
appCjso1mxl1VrnHSLGtFLPxuVRDDEUZFa/AIomwsHabZTZcg5KuIEZs/K828CGt
yd8ltx1gZIpJQb8j85ulVWMNeT93I9uNGcAxJcgwWWgqhkr1uZ/Rudl3F+bXkQhd
NTfdI5b9IP+hdJAy47X3LQ6Nj9MKmGClyGdKkj8D6l0mqsC7XwcFEpQHh1XVlXp8
pTV34MZ/hV54eRpoL6ggS06/Yw/9UYOaTR+O2v2w5SNwUdB9ghvKpF2go1sT8aiZ
79M+a05DxwENww7/9ybN7Fxcvb4+5NMmvOH8EeENfsRJVkPXkj8Y/9GaicOdbpkg
sAHKnpWrLRBMlUIEthoI5CT5I2goHBIN754BUnK+EoPsYutGTPH9WkDMJJJ3ZBTt
Jc6krR7QZWfDyraSUiweq9g0b1+2mqp2dG8x9m4klGwyifCtnnNERDRf+eINwAZ3
o9sSjJyijE9eZudLdP3Q9cdTIj5P4moWsn6SqTpkmHDvAPxsZnkrzVa7LVKV2fy3
Q3R2Cc7IoOjFDwxb3FFA
=3vOc
-----END PGP SIGNATURE-----
Merge tag 'for-v3.16/prcm-cleanup-a' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.16/prcm
Some OMAP PRCM cleanup patches. These help prepare to convert the PRCM
code into drivers.
Basic build, boot, and PM test results are available here:
http://www.pwsan.com/omap/testlogs/prcm-cleanup-v3.16/20140515213244/
Conflicts:
arch/arm/mach-omap2/cm3xxx.c
arch/arm/mach-omap2/cm44xx.c
Also fixed up new section mismatch warnings.
SoC specific late_init call is now registered during PRM init, and will
be called automatically by PRM core. This helps to get rid of some
redundant initcalls and cpu_is_X checks from the PRM code.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
prm_features flag will contain SoC specific feature enabler flags. Initially
IO wakeup is added under this. Helps to get rid of runtime cpu_is_X checks.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
This helps to make the PRM registration modular, and also gets rid of a
cpu type check done later.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Done in preparation to make PRM its own driver, as the cpu_is_XXX calls are
not available outside mach-omap2 folder.
The init functions are called only from cpu specific init chain, and thus
don't need to double check against cpu type.
The exit calls check against the data provided during init-time registration
and thus don't need cpu check either.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
[paul@pwsan.com: updated to apply]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
This way the initcalls don't run on other SoCs on multiplatform
kernels. Otherwise we'll get something like this when booting
on vexpress:
omap_hwmod: _ensure_mpu_hwmod_is_setup: MPU initiator hwmod mpu not yet registered
...
WARNING: at arch/arm/mach-omap2/pm.c:82 _init_omap_device+0x74/0x94()
_init_omap_device: could not find omap_hwmod for mpu
...
omap-dma-engine omap-dma-engine: OMAP DMA engine driver
...
Tested-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
logs are available here:
http://www.pwsan.com/omap/testlogs/prcm_fixes_b_3.8-rc/20130102120724/
The 3730 Beagle XM here has an intermittent failure mounting SD root,
but the suspicion right now is that this is due to a failing SD card,
rather than any change introduced by these patches.
This second version includes a few changes requested by Tony Lindgren.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQ5IkPAAoJEMePsQ0LvSpL/RQQAJUbGPZTdMEH2DHHDVPRxgBE
bWEg0RQfzheOLfFvfot2tReJoN7GMlhzcDq2DSHZLwp5b9XgOgOJdNdldvrvFljD
p3QEy+y/7ZSgsAdgDV33vAAUAv4c0CIh0cKgw3JwOn/dqVSbiMXXqXe1kZe419gi
bbJHBr6fZH63qvGzkjI17vl3lDq6RsX7vgtEQ9TeiTMUAOnrXzp3rt9oDNVsChSs
Ml6h1WKnxQdMFjbNNmBOUGltSg7O1rwuWeS/9mg77yV3lIZ5QdmAVlcq6lUB+jqy
CWhAYbrhXMBPYFaxzw0I8h00m0VNBSOZf2e1d5Lw8wU8dVxQ3PVZCI4SyRssBdd3
T+91zy4Axmo+SWrkTxpq+yE2Sn1AMZC4mJwI62UhCZV8TPPvek8IlK3ktKeV97ql
BNehuGYqbc3u5TiIjO8K+akTBKKTVDdXaah9ms8rtQ4hcwLwC0VA/71R9qaQJx3E
mGf3pRK6FSV83vEMrGb2mRk3ByGHzpYlMD0sb4+0OFvkj5Hyv7OCPb0TJapn6OPO
vpeG6pIbHN3p/mKrj/RNHVtvpV5/mHJmMOXgkcXLcdlZhsnGE21dqw/vPrvjf3Wa
SnUp7q48/4a2FP2d0KpQ+CpHyLyNEs4x4zs9hfjHGsYs1fWBwdu0+/8rVPaAEjjB
iUa8sxlv/1o0rJfiyRkd
=oUTN
-----END PGP SIGNATURE-----
Merge tag 'omap-fixes-a2-for-v3.8-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.8-rc2/fixes
Some OMAP PRCM and sparse fixes against v3.8-rc1. A basic set of test
logs are available here:
http://www.pwsan.com/omap/testlogs/prcm_fixes_b_3.8-rc/20130102120724/
The 3730 Beagle XM here has an intermittent failure mounting SD root,
but the suspicion right now is that this is due to a failing SD card,
rather than any change introduced by these patches.
This second version includes a few changes requested by Tony Lindgren.
On OMAP2xxx chips, the register bitfields for the
PM_PWSTCTRL_*.POWERSTATE and PM_PWSTST_*.LASTSTATEENTERED are
different than those used on OMAP3/4. The order is reversed. So, for
example, on OMAP2xxx, 0x0 indicates 'ON'; but on OMAP3/4, 0x0
indicates 'OFF'. Similarly, on OMAP2xxx, 0x3 indicates 'OFF', but on
OMAP3/4, 0x3 indicates 'ON'.
To fix this, we treat the OMAP3/4 values as the powerdomain API
values, and create new low-level powerdomain functions for the
OMAP2xxx chips which translate between the OMAP2xxx values and the
OMAP3/4 values.
Without this patch, the conversion of the OMAP2xxx PM code to the
functional powerstate code results in a non-booting kernel.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
The cpu_is_omap macros are now local to arch/arm/mach-omap2
in soc.h and plat/cpu.h can finally be dropped for omap2+.
Thanks everybody for help with fixing the drivers.
Note that we can now also remove the unused plat/cpu.h from
smartreflex.c and isp.c as they will cause compile errors
with ARCH_MULTIPLATFORM enabled.
Cc: Kevin Hilman <khilman@deeprootsystems.com>
Acked-by: Jean Pihet <jean.pihet@newoldbits.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Some PRM functions will need to be called by the hwmod code early in
kernel init. To handle this, split the PRM initialization code into
early and late phases. The early init is handled via mach-omap2/io.c,
while the late init is handled by subsys_initcall().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
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>
Add SoC reset functions into the PRM code. These functions are based
on code from mach-omap2/prcm.c. They reset the SoC using the CORE DPLL
reset method (as opposed to one of the other two or three chip reset
methods).
Adding them here will facilitate their removal from
arch/arm/mach-omap2/prcm.c. (prcm.c is deprecated.)
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Vaibhav Hiremath <hvaibhav@ti.com>
The OMAP watchdog timer driver needs to determine what caused the SoC
to reset for its GETBOOTSTATUS ioctl. So, define a set of standard
reset sources across OMAP SoCs. For OMAP2xxx, 3xxx, and 4xxx SoCs,
define mappings from the SoC-specific reset source register bits to
the standardized reset source IDs. Create SoC-specific PRM functions
that read the appropriate per-SoC register and use the mapping to
return the standardized reset bits. Register the SoC-specific PRM
functions with the common PRM code via prm_register(). Create a
function in the common PRM code, prm_read_reset_sources(), that
calls the SoC-specific function, registered during boot.
This patch does not yet handle some SoCs, such as AM33xx. Those SoCs
were not handled by the code this will replace.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Move the low-level SoC-specific powerdomain control functions into
prm*.c. For example, OMAP2xxx low-level powerdomain functions go into
prm2xxx.c. Then remove the unnecessary powerdomain*xxx*.c files.
The objective is to centralize low-level PRM register accesses into
the prm*.[ch] files, and then to export an OMAP SoC-independent API to
higher-level OMAP power management code.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Vaibhav Hiremath <hvaibhav@ti.com>
Acked-by: Rajendra Nayak <rnayak@ti.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>
Colin Ian King