10 Jan, 2012
1 commit
-
power management changes for omap and imx
A significant part of the changes for these two platforms went into
power management, so they are split out into a separate branch.* tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (65 commits)
ARM: imx6: remove __CPUINIT annotation from v7_invalidate_l1
ARM: imx6: fix v7_invalidate_l1 by adding I-Cache invalidation
ARM: imx6q: resume PL310 only when CACHE_L2X0 defined
ARM: imx6q: build pm code only when CONFIG_PM selected
ARM: mx5: use generic irq chip pm interface for pm functions on
ARM: omap: pass minimal SoC/board data for UART from dt
arm/dts: Add minimal device tree support for omap2420 and omap2430
omap-serial: Add minimal device tree support
omap-serial: Use default clock speed (48Mhz) if not specified
omap-serial: Get rid of all pdev->id usage
ARM: OMAP2+: hwmod: Add a new flag to handle hwmods left enabled at init
ARM: OMAP4: PRM: use PRCM interrupt handler
ARM: OMAP3: pm: use prcm chain handler
ARM: OMAP: hwmod: add support for selecting mpu_irq for each wakeup pad
ARM: OMAP2+: mux: add support for PAD wakeup interrupts
ARM: OMAP: PRCM: add suspend prepare / finish support
ARM: OMAP: PRCM: add support for chain interrupt handler
ARM: OMAP3/4: PRM: add functions to read pending IRQs, PRM barrier
ARM: OMAP2+: hwmod: Add API to enable IO ring wakeup
ARM: OMAP2+: mux: add wakeup-capable hwmod mux entries to dynamic list
...
09 Dec, 2011
3 commits
-
According to comments in omap1_select_table_rate(), reprogramming dpll1
is tricky, and should always be done from SRAM.While being at it, move OMAP730 special case handling inside
omap_sram_reprogram_clock().Created on top of version 2 of the series "ARM: OMAP1: Fix dpll1
reprogramming related issues", which it depends on.
Tested on Amstrad Delta.Signed-off-by: Janusz Krzysztofik
Signed-off-by: Tony Lindgren -
Now that we're always reprogramming the core clock we must make
sure SRAM works. It seems that neither omap1621 or omap1623
has 256K of SRAM. Set the SRAM size to safe value of 16K.Signed-off-by: Tony Lindgren
-
On OMAP4 SOC, intecronnects has many write buffers in the async bridges
and they need to be drained before CPU enters into standby state.Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support
but OMAP errata i688 (Async Bridge Corruption) needs to be taken
care to avoid issues like system freeze, CPU deadlocks, random
crashes with register accesses, synchronisation loss on initiators
operating on both interconnect port simultaneously.As per the errata, if a data is stalled inside asynchronous bridge
because of back pressure, it may be accepted multiple times, creating
pointer misalignment that will corrupt next transfers on that data
path until next reset of the system (No recovery procedure once
the issue is hit, the path remains consistently broken).
Async bridge can be found on path between MPU to EMIF and
MPU to L3 interconnect. This situation can happen only when the
idle is initiated by a Master Request Disconnection (which is
trigged by software when executing WFI on CPU).The work-around for this errata needs all the initiators
connected through async bridge must ensure that data path
is properly drained before issuing WFI. This condition will be
met if one Strongly ordered access is performed to the
target right before executing the WFI. In MPU case, L3 T2ASYNC
FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure
that there is no synchronisation loss on initiators operating
on both interconnect port simultaneously.Thanks to Russell for a tip to conver assembly function to
C fuction there by reducing 40 odd lines of code from the patch.Signed-off-by: Santosh Shilimkar
Signed-off-by: Richard Woodruff
Acked-by: Jean Pihet
Reviewed-by: Kevin Hilman
Tested-by: Vishwanath BS
Signed-off-by: Kevin Hilman
20 Oct, 2011
2 commits
-
This allows us to remove omap hacks for map_io.
Acked-by: Nicolas Pitre
Reviewed-by: Santosh Shilimkar
Tested-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren -
This assumes fixed mappings which will not work once we move
to use ioremap_exec(). It seems that these are currently
not in use, or in use for some out of tree corner cases.If SRAM support for framebuffer is wanted, it should be done
with ioremap in the driver.Note that further removal of the code can now be done,
but that can be done seprately by the driver maintainers.Acked-by: Tomi Valkeinen
Signed-off-by: Tony Lindgren
30 Jun, 2011
1 commit
-
Most of the ASM sleep code (in arch/arm/mach-omap2/sleep34xx.S)
is copied to internal SRAM at boot and after wake-up from CORE OFF
mode. However only a small part of the code really needs to run from
internal SRAM.This fix lets most of the ASM idle code run from the DDR in order to
minimize the SRAM usage and the overhead in the code copy.The only pieces of code that are mandatory in SRAM are:
- the i443 erratum WA,
- the i581 erratum WA,
- the security extension code.SRAM usage:
- original code:
. 560 bytes for omap3_sram_configure_core_dpll (used by DVFS),
. 852 bytes for omap_sram_idle (used by suspend/resume in RETention),
. 124 bytes for es3_sdrc_fix (used by suspend/resume in OFF mode on ES3.x),
. 108 bytes for save_secure_ram_context (used on HS parts only).With this fix the usage for suspend/resume in RETention goes down 288
bytes, so the gain in SRAM usage for suspend/resume is 564 bytes.Also fixed the SRAM initialization sequence to avoid an unnecessary
copy to SRAM at boot time and for readability.Tested on Beagleboard (ES2.x) in idle with full RET and OFF modes.
Kevin Hilman tested retention and off on 3430/n900, 3530/Overo and
3630/Zoom3Signed-off-by: Jean Pihet
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Signed-off-by: Russell King
31 May, 2011
1 commit
-
Fix below build warning.
CC arch/arm/plat-omap/sram.o
arch/arm/plat-omap/sram.c: In function 'omap_map_sram':
arch/arm/plat-omap/sram.c:224: warning: format '%08lx' expects
type 'long unsigned int', but argument 2 has type 'unsigned int'While at this, convert SRAM printk(* "") to pr_*("").
Signed-off-by: Santosh Shilimkar
Acked-by: Russell King
Signed-off-by: Tony Lindgren
18 Mar, 2011
1 commit
-
* 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6: (258 commits)
omap: zoom: host should not pull up wl1271's irq line
arm: plat-omap: iommu: fix request_mem_region() error path
OMAP2+: Common CPU DIE ID reading code reads wrong registers for OMAP4430
omap4: mux: Remove duplicate mux modes
omap: iovmm: don't check 'da' to set IOVMF_DA_FIXED flag
omap: iovmm: disallow mapping NULL address when IOVMF_DA_ANON is set
omap2+: mux: Fix compile when CONFIG_OMAP_MUX is not selected
omap4: board-omap4panda: Initialise the serial pads
omap3: board-3430sdp: Initialise the serial pads
omap4: board-4430sdp: Initialise the serial pads
omap2+: mux: Add macro for configuring static with omap_hwmod_mux_init
omap2+: mux: Remove the use of IDLE flag
omap2+: Add separate list for dynamic pads to mux
perf: add OMAP support for the new power events
OMAP4: Add IVA OPP enteries.
OMAP4: Update Voltage Rail Values for MPU, IVA and CORE
OMAP4: Enable 800 MHz and 1 GHz MPU-OPP
OMAP3+: OPP: Replace voltage values with Macros
OMAP3: wdtimer: Fix CORE idle transition
Watchdog: omap_wdt: add fine grain runtime-pm
...Fix up various conflicts in
- arch/arm/mach-omap2/board-omap3evm.c
- arch/arm/mach-omap2/clock3xxx_data.c
- arch/arm/mach-omap2/usb-musb.c
- arch/arm/plat-omap/include/plat/usb.h
- drivers/usb/musb/musb_core.h
18 Feb, 2011
1 commit
-
The omap44xx_sram_init() implements functionality to push some
code on SRAM whenever the code can't be executed from external
memory. The low power and DVFS code can be executed from
external DDR itself thanks to OMAP4 memory controller hardware
support. So on OMAP4, sram_push kind of functionality isn't needed.Hence remove the FIXME warning added for implementing sram push
feature on OMAP4.Signed-off-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren
04 Feb, 2011
1 commit
-
The new fncpy API is better suited* for copying some
code to SRAM at runtime. This patch changes the ad-hoc
code to the more generic fncpy API.*: 1. fncpy ensures that the thumb mode bit is propagated,
2. fncpy provides the security of type safety between the
original function and the sram function pointer.Tested OK on OMAP3 in low power modes (RET/OFF)
using omap2plus_defconfig with !CONFIG_THUMB2_KERNEL.
Compile tested on OMAP1/2 using omap1_defconfig.Boot tested on OMAP1 & OMAP2
Tested OK with suspend/resume on OMAP2420/n810Boots fine on osk5912 and n800
Signed-off-by: Jean Pihet
Acked-by: Kevin Hilman
Acked-by: Tony Lindgren
Reviewed-by: Dave Martin
Tested-by: Kevin Hilman
Tested-by: Tony Lindgren
Signed-off-by: Russell King
28 Jan, 2011
1 commit
-
We want to have just CONFIG_ARCH_OMAP2, 3 and 4. The rest
are nowadays just subcategories of these.Search and replace the following:
ARCH_OMAP2420 SOC_OMAP2420
ARCH_OMAP2430 SOC_OMAP2430
ARCH_OMAP3430 SOC_OMAP3430No functional changes.
Signed-off-by: Tony Lindgren
Signed-off-by: Thomas Weber
Acked-by: Sourav Poddar
22 Dec, 2010
3 commits
-
In preparation for adding OMAP4-specific PRCM accessor/mutator
functions, split the existing OMAP2/3 PRCM code into OMAP2/3-specific
files. Most of what was in mach-omap2/{cm,prm}.{c,h} has now been
moved into mach-omap2/{cm,prm}2xxx_3xxx.{c,h}, since it was
OMAP2xxx/3xxx-specific.This process also requires the #includes in each of these files to be
changed to reference the new file name. As part of doing so, add some
comments into plat-omap/sram.c and plat-omap/mcbsp.c, which use
"sideways includes", to indicate that these users of the PRM/CM includes
should not be doing so.Thanks to Felipe Contreras for comments on this
patch.Signed-off-by: Paul Walmsley
Cc: Jarkko Nikula
Cc: Peter Ujfalusi
Cc: Liam Girdwood
Cc: Omar Ramirez Luna
Acked-by: Omar Ramirez Luna
Cc: Felipe Contreras
Acked-by: Felipe Contreras
Cc: Greg Kroah-Hartman
Acked-by: Mark Brown
Reviewed-by: Kevin Hilman
Tested-by: Kevin Hilman
Tested-by: Rajendra Nayak
Tested-by: Santosh Shilimkar -
…an/linux-omap-pm into omap-for-linus
-
The SRAM PA addresses are locally defined and used at
different places, i.e. SRAM management code and idle sleep code.The macros are now defined at a centralized place, for
easier maintenance.Tested on N900 and Beagleboard with full RET and OFF modes,
using cpuidle and suspend.Signed-off-by: Jean Pihet
Acked-by: Santosh Shilimkar
Tested-by: Nishanth Menon
Signed-off-by: Kevin Hilman
18 Dec, 2010
1 commit
10 Dec, 2010
1 commit
-
Kernel was failing to boot on omap1611 based OSK boards due to
mis-configured SRAM size. Existing code was using a hard-coded value
for 250k, which was then rounded down by PAGE_SIZE. Increasing this to
256k allows kernel to boot on omap1611 SoCs.Problem reported by and initial fix suggested by Tim Bird.
Thanks to Tony Lindgren for helping diagnose the problem to being
specific to OMAP1611 and not affecting OMAP1610/OMAP1623.Reported-by: Tim Bird
Signed-off-by: Kevin Hilman
Signed-off-by: Tony Lindgren
25 Nov, 2010
1 commit
-
Make some functions static to get rid of the following sparse warnings:
arch/arm/mach-omap1/mcbsp.c:177:12: warning: symbol 'omap1_mcbsp_init' was not declared. Should it be static?
arch/arm/mach-omap1/mux.c:346:22: warning: symbol 'omap1_cfg_reg' was not declared. Should it be static?
arch/arm/plat-omap/dma.c:177:5: warning: symbol 'omap_dma_in_1510_mode' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:273:12: warning: symbol 'omap1_sram_init' was not declared. Should it be static?Signed-off-by: Aaro Koskinen
Signed-off-by: Tony Lindgren
26 Oct, 2010
1 commit
-
* 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6: (163 commits)
omap: complete removal of machine_desc.io_pg_offst and .phys_io
omap: UART: fix wakeup registers for OMAP24xx UART2
omap: Fix spotty MMC voltages
ASoC: OMAP4: MCPDM: Remove unnecessary include of plat/control.h
serial: omap-serial: fix signess error
OMAP3: DMA: Errata i541: sDMA FIFO draining does not finish
omap: dma: Fix buffering disable bit setting for omap24xx
omap: serial: Fix the boot-up crash/reboot without CONFIG_PM
OMAP3: PM: fix scratchpad memory accesses for off-mode
omap4: pandaboard: enable the ehci port on pandaboard
omap4: pandaboard: Fix the init if CONFIG_MMC_OMAP_HS is not set
omap4: pandaboard: remove unused hsmmc definition
OMAP: McBSP: Remove null omap44xx ops comment
OMAP: McBSP: Swap CLKS source definition
OMAP: McBSP: Fix CLKR and FSR signal muxing
OMAP2+: clock: reduce the amount of standard debugging while disabling unused clocks
OMAP: control: move plat-omap/control.h to mach-omap2/control.h
OMAP: split plat-omap/common.c
OMAP: McBSP: implement functional clock switching via clock framework
OMAP: McBSP: implement McBSP CLKR and FSR signal muxing via mach-omap2/mcbsp.c
...Fixed up trivial conflicts in arch/arm/mach-omap2/
{board-zoom-peripherals.c,devices.c} as per Tony
09 Oct, 2010
2 commits
-
Split plat-omap/common.c into three pieces:
1. the 32KiHz sync timer and clocksource code, which now lives in
plat-omap/counter_32k.c;2. the OMAP2+ common code, which has been moved to mach-omap2/common.c;
3. and the remainder of the OMAP-wide common code, which includes the
deprecated ATAGs code and a deprecated video RAM reservation function.The primary motivation for doing this is to move the OMAP2+-specific parts
into an OMAP2+-specific file, so that build breakage related to the
System Control Module code can be resolved.Benoît Cousson suggested a new filename and found
some bugs in the counter_32k.c comments - thanks Benoît.Signed-off-by: Paul Walmsley
Cc: Benoît Cousson -
This patch fixes sparse warnings due non declarations of static functions.
arch/arm/plat-omap/sram.c:130:13: warning: symbol 'omap_detect_sram' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:216:13: warning: symbol 'omap_map_sram' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:450:12: warning: symbol 'omap_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:348:12: warning: symbol 'omap242x_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:369:12: warning: symbol 'omap243x_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:425:12: warning: symbol 'omap34xx_sram_init' was not declared. Should it be static?
arch/arm/plat-omap/sram.c:441:12: warning: symbol 'omap44xx_sram_init' was not declared. Should it be staticarch/arm/plat-omap/mcbsp.c:36:6: warning: symbol 'omap_mcbsp_write' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:50:5: warning: symbol 'omap_mcbsp_read' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:65:6: warning: symbol 'omap_mcbsp_st_write' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:70:5: warning: symbol 'omap_mcbsp_st_read' was not declared. Should it be static?
arch/arm/plat-omap/mcbsp.c:1648:15: warning: symbol 'omap_st_add' was not declared. Should it be static?arch/arm/plat-omap/fb.c:414:15: warning: symbol 'omapfb_reserve_sram' was not declared. Should it be static?
arch/arm/plat-omap/cpu-omap.c:43:5: warning: symbol 'omap_verify_speed' was not declared. Should it be static?
arch/arm/plat-omap/cpu-omap.c:61:14: warning: symbol 'omap_getspeed' was not declared. Should it be static?Signed-off-by: Manjunath Kondaiah G
Cc: linux-arm-kernel@lists.infradead.org
Cc: Nishanth Menon
Signed-off-by: Tony Lindgren
25 Sep, 2010
1 commit
-
Currently we map 1 MB section while setting up SRAM on OMAPs
Regardless of the actual memory. The physical OCM RAM available
on OMAP SOCs is in order of KBs. This patch maps only available
sram and cleans up some un-necessary cpu_is_xxx checks.Mapping un-available or non-accessible(secure) memory on the newer ARM
processor is dangerous. Because ARM CPUs can now speculatively prefetch,
we should avoid mapping any no-existing or secure memory.Signed-off-by: Santosh Shilimkar
Acked-by: Tony Lindgren
Signed-off-by: Russell King
24 Sep, 2010
2 commits
-
On OMAP4 there is no need to have SRAM_BOOTLOADER_SZ provision
Hence put this macro under CONFIG_ARCH_OMAP2PLUS check
Signed-off-by: Vikram Pandita
Reviewed-by: Santosh Shilimkar -
For OMAP24xx/34xx/44xx: omap_type() returns the correct type:
OMAP2_DEVICE_TYPE_TEST
OMAP2_DEVICE_TYPE_EMU
OMAP2_DEVICE_TYPE_SEC
OMAP2_DEVICE_TYPE_GP
OMAP2_DEVICE_TYPE_BADIn current implementation there are two problems:
Problem 1:
For 34xx, the current if check will never return true.Problem 2:
For 24xx the correct type check should be with omap_type() function
Verified by checking the TRM 24xx for CONTROL_STATUS register bitsSigned-off-by: Vikram Pandita
Acked-by: Santosh Shilimkar
05 May, 2010
1 commit
-
We cannot use the omap34xx_sram_init(). It needs to be implemented
for omap4. Otherwise we get an error and the system won't boot:Unhandled fault: imprecise external abort (0x1406) at 0xea963e94
...Fix this by adding a dummy omap44xx_sram_init().
Signed-off-by: Tony Lindgren
16 Feb, 2010
2 commits
-
Replace ARCH_OMAP34XX with ARCH_OMAP3
Signed-off-by: Tony Lindgren
-
Convert ARCH_OMAP24XX to ARCH_OMAP2
Signed-off-by: Tony Lindgren
12 Dec, 2009
1 commit
-
This patch fixes the public sram base address and available
size on OMAP4430.Signed-off-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren
09 Dec, 2009
1 commit
-
Add a Video RAM manager for OMAP 2 and 3 platforms. VRAM manager is used
to allocate large continuous blocks of SDRAM or SRAM. The features VRAM
manager has that are missing from dma_alloc_* functions are:- Support for OMAP2's SRAM
- Allocate without ioremapping
- Allocate at defined physical addresses
- Allows larger VRAM area and larger allocationsThe upcoming DSS2 uses VRAM manager.
VRAM area size can be defined in kernel config, board file or with
kernel boot parameters. Board file definition overrides kernel config,
and boot parameter overrides kernel config and board file.Signed-off-by: Tomi Valkeinen
12 Nov, 2009
1 commit
-
Generalize the copy of SRAM functions into omap_push_sram_idle()
so it can be used on init but also after off-mode transitions.Signed-off-by: Rajendra Nayak
Signed-off-by: Kevin Hilman
21 Oct, 2009
1 commit
-
Move the remaining headers under plat-omap/include/mach
to plat-omap/include/plat. Also search and replace the
files using these headers to include using the right path.This was done with:
#!/bin/bash
mach_dir_old="arch/arm/plat-omap/include/mach"
plat_dir_new="arch/arm/plat-omap/include/plat"
headers=$(cd $mach_dir_old && ls *.h)
omap_dirs="arch/arm/*omap*/ \
drivers/video/omap \
sound/soc/omap"
other_files="drivers/leds/leds-ams-delta.c \
drivers/mfd/menelaus.c \
drivers/mfd/twl4030-core.c \
drivers/mtd/nand/ams-delta.c"for header in $headers; do
old="#include
20 Oct, 2009
2 commits
-
This patch moves SRAM map to free up more kernel address io space.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren -
This patch splits OMAP2_IO_ADDRESS to OMAP2_L3_IO_ADDRESS and
OMAP2_L4_IO_ADDRESS to reclaim more IO space.The omap_read*() and omap_write*() functions will work only over
L4 address space. Current omap kernel stack uses these functions
only to access registers over L4 io address spaceNote that these macros should only be used when ioremap does
not work. Please use ioremap instead in all new code.Signed-off-by: Santosh Shilimkar
Signed-off-by: Tony Lindgren
06 Oct, 2009
1 commit
-
the original flush operation is to flush the function address which is
copied from.
But we do not change the function code and it is not necessary to flush it.Signed-off-by: janboe
Acked-by: Paul Walmsley
Signed-off-by: Tony Lindgren
29 Aug, 2009
1 commit
-
Search and replace OMAP_IO_ADDRESS with OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS,
and convert omap_read/write into a functions instead of a macros.Also rename OMAP_MPUIO_VBASE to OMAP1_MPUIO_VBASE.
In the long run, most code should use ioremap + __raw_read/write instead.
Signed-off-by: Tony Lindgren
10 Aug, 2009
2 commits
-
commit e85c205ac1427f2405021a36f083280ff0d0a35e increase vmalloc size.
vmalloc space will overlap with OMAP3 sram virtual address.Signed-off-by: Li Hong Mei
Signed-off-by: Janboe Ye
Reviewed-by: Paul Walmsley
25 Jul, 2009
1 commit
-
Some OMAP3 boards (Beagle Cx, Overo, RX51, Pandora) have 2
SDRAM parts connected to the SDRC.This patch adds the following:
- add a new argument of type omap_sdrc_params struct*
to omap2_init_common_hw and omap2_sdrc_init for the 2nd CS params
- adapted the OMAP boards files to the new prototype of
omap2_init_common_hw
- add the SDRC 2nd CS registers offsets defines
- adapt the sram sleep code to configure the SDRC for the 2nd CSNote: If the 2nd param to omap2_init_common_hw is NULL, then the
parameters are not programmed into the SDRC CS1 registersTested on 3430 SDP and Beagleboard rev C2 and B5, with
suspend/resume and frequency changes (cpufreq).Signed-off-by: Jean Pihet
Signed-off-by: Paul Walmsley
23 Jun, 2009
1 commit
-
SRAM size fix for HS/EMU devices
Signed-off-by: Tero Kristo
Signed-off-by: Kevin Hilman
Signed-off-by: Tony Lindgren
20 Jun, 2009
1 commit
-
Previously only 1 and 2 was supported. This is needed for DVFS VDD2 control.
Signed-off-by: Tero Kristo