summaryrefslogtreecommitdiff
path: root/arch/arm/mach-omap2/cm44xx.c
AgeCommit message (Collapse)AuthorFilesLines
2014-10-27ARM: OMAP4+: CM: remove omap4_cm1/cm2_* functionsTero Kristo1-49/+0
These are not used for anything, so remove both the implementations and header file references. Signed-off-by: Tero Kristo <t-kristo@ti.com> Tested-by: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2014-05-16Merge tag 'for-v3.16/prcm-cleanup-a' of ↵Tony Lindgren1-7/+4
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.
2014-05-15ARM: OMAP4: PRCM: remove references to cm-regbits-44xx.h from PRCM core filesTero Kristo1-1/+0
Done in preparation to make PRCM a standalone driver. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2014-05-15ARM: OMAP2+: PRCM: cleanup some header includesTero Kristo1-2/+0
Some of the includes are totally unnecessary, remove some others in preparation to make the PRCM its own driver. Signed-off-by: Tero Kristo <t-kristo@ti.com> [paul@pwsan.com: updated to apply; fixed build error on OMAP2xxx-only configs] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2014-05-15ARM: OMAP4: CM: use cm_base* in register address calculationsTero Kristo1-4/+4
OMAP44XX_CM*_REGADDR macros should be avoided, instead use the cm_base* iomaps. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2014-05-08ARM: OMAP2+: raw read and write endian fixVictor Kamensky1-4/+4
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>
2012-02-24ARM: OMAP2+: Move most of plat/io.h into local iomap.hTony Lindgren1-1/+1
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 Lindgren1-1/+1
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>
2010-12-21OMAP4: PRCM: add OMAP4-specific accessor/mutator functionsPaul Walmsley1-0/+52
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>