summaryrefslogtreecommitdiffstats
path: root/arch/arm/plat-omap/sram.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'pm' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-socLinus Torvalds2012-01-091-0/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * ARM: OMAP4: Fix errata i688 with MPU interconnect barriers.Santosh Shilimkar2011-12-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <santosh.shilimkar@ti.com> Signed-off-by: Richard Woodruff <r-woodruff2@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
* | ARM: OMAP1: Update dpll1 default rate reprogramming methodJanusz Krzysztofik2011-12-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | ARM: OMAP1: Set the omap1623 sram size to 16KTony Lindgren2011-12-091-4/+2
|/ | | | | | | | 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 <tony@atomide.com>
* ARM: OMAP: Map SRAM later on with ioremap_exec()Tony Lindgren2011-10-201-49/+20
| | | | | | | | | This allows us to remove omap hacks for map_io. Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP: Remove calls to SRAM allocations for framebufferTony Lindgren2011-10-201-16/+0
| | | | | | | | | | | | | | | 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 <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: pm: omap3: run the ASM sleep code from DDRJean Pihet2011-06-291-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/Zoom3 Signed-off-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* OMAP: SRAM: Fix warning: format '%08lx' expects type 'long unsigned int'Santosh Shilimkar2011-05-311-6/+6
| | | | | | | | | | | | | | | 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 <santosh.shilimkar@ti.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
* Merge branch 'omap-for-linus' of ↵Linus Torvalds2011-03-181-18/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 * '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
| * omap4: Remove 'FIXME: omap44xx_sram_init not implemented'Santosh Shilimkar2011-02-171-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * omap: Start using CONFIG_SOC_OMAPTony Lindgren2011-01-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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_OMAP3430 No functional changes. Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Thomas Weber <weber@corscience.de> Acked-by: Sourav Poddar <sourav.poddar@ti.com>
* | ARM: 6649/1: omap: use fncpy to copy the PM code functions to SRAMJean Pihet2011-02-041-5/+9
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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/n810 Boots fine on osk5912 and n800 Signed-off-by: Jean Pihet <j-pihet@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Dave Martin <dave.martin@linaro.org> Tested-by: Kevin Hilman <khilman@ti.com> Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* OMAP2/3: PRCM: split OMAP2/3-specific PRCM code into OMAP2/3-specific filesPaul Walmsley2010-12-221-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <felipe.contreras@gmail.com> for comments on this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Jarkko Nikula <jhnikula@gmail.com> Cc: Peter Ujfalusi <peter.ujfalusi@nokia.com> Cc: Liam Girdwood <lrg@slimlogic.co.uk> Cc: Omar Ramirez Luna <omar.ramirez@ti.com> Acked-by: Omar Ramirez Luna <omar.ramirez@ti.com> Cc: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Felipe Contreras <felipe.contreras@gmail.com> Cc: Greg Kroah-Hartman <greg@kroah.com> Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Kevin Hilman <khilman@deeprootsystems.com> Tested-by: Rajendra Nayak <rnayak@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* Merge branch 'pm-next' of ↵Tony Lindgren2010-12-221-5/+2
|\ | | | | | | ssh://master.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into omap-for-linus
| * OMAP2+: use global values for the SRAM PA addressesJean Pihet2010-12-211-5/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <j-pihet@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Nishanth Menon<nm@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* | Merge branch 'devel-board' into omap-for-linusTony Lindgren2010-12-181-1/+1
|\|
| * OMAP1: SRAM: fix size for OMAP1611 SoCsKevin Hilman2010-12-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tim.bird@am.sony.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | arm: omap1: make some functions staticAaro Koskinen2010-11-251-1/+1
|/ | | | | | | | | | | | 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 <aaro.koskinen@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* Merge branch 'omap-for-linus' of ↵Linus Torvalds2010-10-251-26/+11
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 * '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
| * OMAP: split plat-omap/common.cPaul Walmsley2010-10-081-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <b-cousson@ti.com> suggested a new filename and found some bugs in the counter_32k.c comments - thanks Benoît. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
| * OMAP: plat-omap: Fix static function warningsManjunath Kondaiah G2010-10-081-12/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 static arch/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 <manjugk@ti.com> Cc: linux-arm-kernel@lists.infradead.org Cc: Nishanth Menon <nm@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * omap4: sram: Fix start addressVikram Pandita2010-09-241-1/+1
| | | | | | | | | | | | | | | | | | 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 <vikram.pandita@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
| * omap: sram: fix is_sram_locked checkVikram Pandita2010-09-241-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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_BAD In 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 bits Signed-off-by: Vikram Pandita <vikram.pandita@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* | ARM: 6408/1: omap: Map only available sram memorySantosh Shilimkar2010-09-251-20/+5
|/ | | | | | | | | | | | | | | 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 <santosh.shilimkar@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* omap4: Fix multiboot with CONFIG_PM and CONFIG_ARCH_OMAP3 selectedTony Lindgren2010-05-041-1/+15
| | | | | | | | | | | | 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 <tony@atomide.com>
* omap3: Replace ARCH_OMAP34XX with ARCH_OMAP3Tony Lindgren2010-02-151-1/+1
| | | | | | Replace ARCH_OMAP34XX with ARCH_OMAP3 Signed-off-by: Tony Lindgren <tony@atomide.com>
* omap2: Convert ARCH_OMAP24XX to ARCH_OMAP2Tony Lindgren2010-02-151-1/+1
| | | | | | Convert ARCH_OMAP24XX to ARCH_OMAP2 Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP4: Fix SRAM base and sizeSantosh Shilimkar2009-12-121-3/+9
| | | | | | | | This patch fixes the public sram base address and available size on OMAP4430. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP: Add VRAM managerTomi Valkeinen2009-12-091-0/+8
| | | | | | | | | | | | | | | | | | | 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 allocations The 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 <tomi.valkeinen@nokia.com>
* OMAP3: PM: restore SRAM functions after off-mode.Rajendra Nayak2009-11-111-3/+5
| | | | | | | | 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 <rnayak@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
* omap: headers: Move remaining headers from include/mach to include/platTony Lindgren2009-10-201-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mach\/$header" new="#include <plat\/$header" for dir in $omap_dirs; do find $dir -type f -name \*.[chS] | \ xargs sed -i "s/$old/$new/" done find drivers/ -type f -name \*omap*.[chS] | \ xargs sed -i "s/$old/$new/" for file in $other_files; do sed -i "s/$old/$new/" $file done done for header in $(ls $mach_dir_old/*.h); do git mv $header $plat_dir_new/ done Signed-off-by: Tony Lindgren <tony@atomide.com>
* omap: Move SRAM map to claim more io spaceSantosh Shilimkar2009-10-201-3/+3
| | | | | | | This patch moves SRAM map to free up more kernel address io space. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* omap: Split OMAP2_IO_ADDRESS to L3 and L4Santosh Shilimkar2009-10-201-10/+10
| | | | | | | | | | | | | | | 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 space Note 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 <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* omap: SRAM: flush the right address after memcpy in omap_sram_pushye janboe2009-10-061-1/+2
| | | | | | | | | | 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 <janboe.ye@gmail.com> Acked-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP: Remove OMAP_IO_ADDRESS, use OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS insteadTony Lindgren2009-08-281-10/+10
| | | | | | | | | | | 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 <tony@atomide.com>
* Merge branch 'omap_fixes_31' of git://git.pwsan.com/linux-2.6Russell King2009-08-101-12/+18
|\
| * OMAP3 SDRC: add support for 2 SDRAM chip selectsJean Pihet2009-07-251-12/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 CS Note: If the 2nd param to omap2_init_common_hw is NULL, then the parameters are not programmed into the SDRC CS1 registers Tested on 3430 SDP and Beagleboard rev C2 and B5, with suspend/resume and frequency changes (cpufreq). Signed-off-by: Jean Pihet <jpihet@mvista.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
* | OMAP3: Fix omap3 sram virtual addres overlap vmalloc space after increasing ↵Janboe Ye2009-08-101-2/+2
|/ | | | | | | | | | | vmalloc size commit e85c205ac1427f2405021a36f083280ff0d0a35e increase vmalloc size. vmalloc space will overlap with OMAP3 sram virtual address. Signed-off-by: Li Hong Mei <hong-mei.li@motorola.com> Signed-off-by: Janboe Ye <yuan-bo.ye@motorola.com> Reviewed-by: Paul Walmsley <paul@pwsan.com>
* OMAP3: SRAM size fix for HS/EMU devicesTero Kristo2009-06-231-1/+6
| | | | | | | | SRAM size fix for HS/EMU devices Signed-off-by: Tero Kristo <tero.kristo@nokia.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* OMAP3: Add support for DPLL3 divisor values higher than 2Tero Kristo2009-06-201-3/+3
| | | | | | Previously only 1 and 2 was supported. This is needed for DVFS VDD2 control. Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
* OMAP3 clock/SDRC: program SDRC_MR register during SDRC clock changePaul Walmsley2009-06-201-3/+3
| | | | | | | | | Program the SDRC_MR_0 register as well during SDRC clock changes. This register allows selection of the memory CAS latency. Some SDRAM chips, such as the Qimonda HYB18M512160AF6, have a lower CAS latency at lower clock rates. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* OMAP3 clock: add a short delay when lowering CORE clk ratePaul Walmsley2009-06-201-3/+5
| | | | | | | | | | | | | When changing the SDRAM clock from 166MHz to 83MHz via the CORE DPLL M2 divider, add a short delay before returning to SDRAM to allow the SDRC time to stabilize. Without this delay, the system is prone to random panics upon re-entering SDRAM. This time delay varies based on MPU frequency. At 500MHz MPU frequency at room temperature, 64 loops seems to work okay; so add another 32 loops for environmental and process variation. Signed-off-by: Paul Walmsley <paul@pwsan.com>
* Merge branch 'omap4' into for-nextTony Lindgren2009-05-291-0/+21
|\
| * ARM: OMAP4: Add minimal support for omap4Santosh Shilimkar2009-05-281-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | This patch adds the support for OMAP4. The platform and machine specific headers and sources updated for OMAP4430 SDP platform. OMAP4430 is Texas Instrument's SOC based on ARM Cortex-A9 SMP architecture. It's a dual core SOC with GIC used for interrupt handling and SCU for cache coherency. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | Merge branch 'omap-upstream' into for-nextTony Lindgren2009-05-291-2/+2
|\| | | | | | | | | Conflicts: arch/arm/mach-omap2/Makefile
| * ARM: OMAP: Increase VMALLOC_END to allow 256MB RAMMans Rullgard2009-05-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This increases VMALLOC_END to 0x18000000, making room for 256MB RAM with the default 128MB vmalloc region. Note that after this patch there's no longer a hole between vmalloc space and the beginning of IO space on omap2 as the first virtual mapping starts at 0xd8000000. Also fold in a related change from Paul Walmsley <paul@pwsan.com> to change the OMAP2_SRAM addresses accordingly. Signed-off-by: Mans Rullgard <mans@mansr.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * ARM: OMAP: Remove useless omap_sram_error function.Santosh Shilimkar2009-05-251-20/+5
| | | | | | | | | | | | | | | | | | | | This patch removes fixes omap_sram_error() function and replace the error paths with BUG_ON. The proposed fix was suggested by Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | Merge branch 'omap-clock-upstream' of git://git.pwsan.com/linux-2.6 into ↵Tony Lindgren2009-05-261-3/+13
|\ \ | | | | | | | | | for-next
| * | OMAP3 clock: only unlock SDRC DLL if SDRC clk < 83MHzPaul Walmsley2009-05-131-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the 34xx TRM Rev. K section 11.2.4.4.11.1 "Purpose of the DLL/CDL Module," the SDRC delay-locked-loop can be locked at any SDRC clock frequency from 83MHz to 166MHz. CDP code unconditionally unlocked the DLL whenever shifting to a lower SDRC speed, but this seems unnecessary and error-prone, as the DLL is no longer able to compensate for process, voltage, and temperature variations. Instead, only unlock the DLL when the SDRC clock rate would be less than 83MHz. Signed-off-by: Paul Walmsley <paul@pwsan.com>
| * | OMAP3 SRAM: mark OCM RAM as Non-cacheable Normal memoryPaul Walmsley2009-05-131-0/+9
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mark the SRAM (aka OCM RAM) as Non-cacheable Normal memory[1]. This is to prevent the ARM from evicting existing cache lines to SDRAM while code is executing from the SRAM. Necessary since one of the primary uses for the SRAM is to hold the code and data for the CORE DPLL M2 divider reprogramming code, which must execute while the SDRC is idled. If the ARM attempts to write cache lines back to the while the SRAM code is running, the ARM will stall[2]. TI deals with this problem in the CDP kernel by marking the SRAM as Strongly-ordered memory. Tero Kristo <tero.kristo@nokia.com> caught a bug in an earlier version of this patch - thanks Tero. ... 1. ARMv7 ARM (DDI 0406A) pp. A3-30, A3-31, B3-32. 2. Private communication with Richard Woodruff <r-woodruff2@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tero Kristo <tero.kristo@nokia.com> Cc: Richard Woodruff <r-woodruff2@ti.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-14 06:23:37 +0100