summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/prminst44xx.c
AgeCommit message (Collapse)Author
2015-05-08ARM: OMAP4+: PRM: add support for passing status register/bit info to resetTero Kristo
AM43xx has slightly different reset register layout compared to OMAP4+, with varying status bit shifts and status register offsets. Current code assumes static offsets and identical status / reset control bit shifts, which is wrong. This patch adds PRM core support for passing the actual implementations from hwmod code. AM43xx mappings will be fixed in subsequent patch. Signed-off-by: Tero Kristo <t-kristo@ti.com> Reported-by: Dave Gerlach <d-gerlach@ti.com> Reported-by: Suman Anna <s-anna@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2015-03-31ARM: OMAP4+: PRM: determine prm_device_inst based on DT compatibilityTero Kristo
PRM device instance offset is now provided through the prm_init_data. This gets rid of some cpu_is_X / soc_is_X calls from PRM core code, preparing for PRM to be its own separate driver. Signed-off-by: Tero Kristo <t-kristo@ti.com>
2014-10-27ARM: OMAP2+: PRM: add generic API for deasserting hardware resetTero Kristo
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>
2014-09-08ARM: OMAP4+: prminst: provide function to find prm_dev instance offsetNishanth Menon
PRM device instance can vary depending on SoC. We already handle the same during reset of the device, However, this is also needed for other logic instances. So, first abstract this out to a generic function. Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
2014-05-08ARM: OMAP2+: raw read and write endian fixVictor Kamensky
All OMAP IP blocks expect LE data, but CPU may operate in BE mode. Need to use endian neutral functions to read/write h/w registers. I.e instead of __raw_read[lw] and __raw_write[lw] functions code need to use read[lw]_relaxed and write[lw]_relaxed functions. If the first simply reads/writes register, the second will byteswap it if host operates in BE mode. Changes are trivial sed like replacement of __raw_xxx functions with xxx_relaxed variant. Signed-off-by: Victor Kamensky <victor.kamensky@linaro.org> Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-04-05Merge tag 'soc-3.15' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC specific changes from Arnd Bergmann: "Lots of changes specific to one of the SoC families. Some that stick out are: - mach-qcom gains new features, most importantly SMP support for the newer chips (Stephen Boyd, Rohit Vaswani) - mvebu gains support for three new SoCs: Armada 375, 380 and 385 (Thomas Petazzoni and Free-electrons team) - SMP support for Rockchips (Heiko Stübner) - Lots of i.MX changes (Shawn Guo) - Added support for BCM5301x SoC (Hauke Mehrtens) - Multiplatform support for Marvell Kirkwood and Dove (Andrew Lunn and Sebastian Hesselbarth doing the final part of a long journey) - Unify davinci platforms and remove obsolete ones (Sekhar Nori, Arnd Bergmann)" * tag 'soc-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (126 commits) ARM: sunxi: Select HAVE_ARM_ARCH_TIMER ARM: cache-tauros2: remove ARMv6 code ARM: mvebu: don't select CONFIG_NEON ARM: davinci: fix DT booting with default defconfig ARM: configs: bcm_defconfig: enable bcm590xx regulator support ARM: davinci: remove tnetv107x support MAINTAINERS: Update ARM STi maintainers ARM: restrict BCM_KONA_UART to ARCH_BCM_MOBILE ARM: bcm21664: Add board support. ARM: sunxi: Add the new watchog compatibles to the reboot code ARM: enable ARM_HAS_SG_CHAIN for multiplatform ARM: davinci: remove da8xx_omapl_defconfig ARM: davinci: da8xx: fix multiple watchdog device registration ARM: davinci: add da8xx specific configs to davinci_all_defconfig ARM: davinci: enable da8xx build concurrently with older devices ARM: BCM5301X: workaround suppress fault ARM: BCM5301X: add early debugging support ARM: BCM5301X: initial support for the BCM5301X/BCM470X SoCs with ARM CPU ARM: mach-bcm: Remove GENERIC_TIME ARM: shmobile: APMU: Fix warnings due to improper printk formats ...
2014-02-28ARM: OMAP2+: AM43xx: implement support for machine restartLokesh Vutla
Add restart hook so that AM4372 builds can restart the platform. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2014-02-19ARM: OMAP5: PRM: Fix reboot handlingVaibhav Bedia
Use the correct register offset for issuing the reset command in OMAP5. Since dev_inst is set dynamically OMAP4 should not be affected by this change. Signed-off-by: Vaibhav Bedia <vaibhav.bedia@gmail.com> Tested-by: Lokesh Vutla <lokeshvutla@ti.com> Acked-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2013-08-23ARM: OMAP: DRA7: Reuse the omap44xx_restart and fix the device instanceRajendra Nayak
The omap44xx_restart used on omap4 and omap5 devices can be reused on dra7 devices as well. The device instance however is different across omap5 and dra7 as compared to omap4. So fix this for omap5 as well as dra7. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-05-07ARM: OMAP4+: Add prm and cm base init function.R Sricharan
Instead of statically defining seperate arrays for every OMAP4+ archs, have a generic init function to populate the arrays. This avoids the need for creating new array for every arch added in the future that reuses the prm and cm registers read/write code. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: R Sricharan <r.sricharan@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-02-24ARM: OMAP2+: Move most of plat/io.h into local iomap.hTony Lindgren
There's no need to have these defines in plat/io.h. Note that we now need to ifdef omap_read/write calls as they will be available for omap1 only. While at it, clean up the includes to group them like they typically are grouped. Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-11-17ARM: 7159/1: OMAP: Introduce local common.h filesTony Lindgren
As suggested by Russell King - ARM Linux <linux@arm.linux.org.uk>, there's no need to keep local prototypes in non-local headers. Add mach-omap1/common.h and mach-omap2/common.h and move the local prototypes there from plat/common.h and mach/omap4-common.h. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-07-10OMAP4: prm: Replace warm reset API with the offset based versionBenoit Cousson
The warm reset function was still using the obsolete API. Replace it by the new one and move the file to the proper c file. Change the function names to stick to the file convention as suggested by Paul Walmsley <paul@pwsan.com>: prm_xxx -> prminst_xxx Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-07-10OMAP4: hwmod: Replace RSTCTRL absolute address with offset macrosBenoit Cousson
The RSTCTRL register was accessed using an absolute address. The usage of hardcoded macros to calculate virtual address from physical one should be avoided as much as possible. The usage of an offset will allow future improvement like migration from the current architecture code toward a module driver. Update prm_xxx accessors, move definition to the proper header file and update copyrights. Change the s16 register offset parameter to u16. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Rajendra Nayak <rnayak@ti.com> [paul@pwsan.com: use '_prminst_' in function names that are part of the prminst44xx.c file] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-12-21OMAP4: PRCM: add OMAP4-specific accessor/mutator functionsPaul Walmsley
In some ways, the OMAP4 PRCM register layout is quite different than the OMAP2/3 PRCM register layout. For example, on OMAP2/3, from a register layout point of view, all CM instances were located in the CM subsystem, and all PRM instances were located in the PRM subsystem. OMAP4 changes this. Now, for example, some CM instances, such as WKUP_CM and EMU_CM, are located in the system PRM subsystem. And a "local PRCM" exists for the MPU - this PRCM combines registers that would normally appear in both CM and PRM instances, but uses its own register layout which matches neither the OMAP2/3 PRCM layout nor the OMAP4 PRCM layout. To try to deal with this, introduce some new functions, omap4_cminst* and omap4_prminst*. The former is to be used when writing to a CM instance register (no matter what subsystem or hardware module it exists in), and the latter, similarly, with PRM instance registers. To determine which "PRCM partition" to write to, the functions take a PRCM instance ID argument. Subsequent patches add these partition IDs to the OMAP4 powerdomain and clockdomain definitions. As far as I can see, there's really no good way to handle these types of register access inconsistencies. This patch seemed like the least bad approach. Moving forward, the long-term goal is to remove all direct PRCM register access from the PM code. PRCM register access should go through layers such as the powerdomain and clockdomain code that can hide the details of how to interact with the specific hardware variant. While here, rename cm4xxx.c to cm44xx.c to match the naming convention of the other OMAP4 PRCM files. Thanks to Santosh Shilimkar <santosh.shilimkar@ti.com>, Rajendra Nayak <rnayak@ti.com>, and Benoît Cousson <b-cousson@ti.com> for some comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>