- 19 9月, 2012 2 次提交
-
-
由 Santosh Shilimkar 提交于
Enable Cortex A15 generic timer support for OMAP5 based SOCs. The CPU local timers run on the free running real time counter clock. Acked-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
由 Santosh Shilimkar 提交于
The real time counter also called master counter, is a free-running counter. It produces the count used by the CPU local timer peripherals in the MPU cluster. The timer counts at a rate of 6.144 MHz. The ratio registers needs to be configured based on system clock only onetime. After initialisation, hardware takes care of adjusting the clock in different low power modes to keep counter rate constant. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 31 8月, 2012 1 次提交
-
-
由 Radek Pilar 提交于
Fix inconsistency between mach-types and CONFIG_ name that prevents touchbook board from booting. Signed-off-by: NRadek Pilar <mrkva@mrkva.eu> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 23 8月, 2012 1 次提交
-
-
由 Arnd Bergmann 提交于
The new omap4 cpuidle implementation currently requires ARCH_NEEDS_CPU_IDLE_COUPLED, which only works on SMP. This patch makes it possible to build a non-SMP kernel for that platform. This is not normally desired for end-users but can be useful for testing. Without this patch, building rand-0y2jSKT results in: drivers/cpuidle/coupled.c: In function 'cpuidle_coupled_poke': drivers/cpuidle/coupled.c:317:3: error: implicit declaration of function '__smp_call_function_single' [-Werror=implicit-function-declaration] It's not clear if this patch is the best solution for the problem at hand. I have made sure that we can now build the kernel in all configurations, but that does not mean it will actually work on an OMAP44xx. Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
- 07 8月, 2012 1 次提交
-
-
由 Santosh Shilimkar 提交于
The random config builds with PM and !ARM_CPU_SUSPEND breaks with below error on omap2plus_defconfig. arch/arm/mach-omap2/sleep44xx.S:323: undefined reference to `cpu_resume' arch/arm/mach-omap2/omap-mpuss-lowpower.c:278: undefined reference to `cpu_suspend' This is because recently merged OMAP5 platform shares the common files with OMAP4 but doesn't select ARM_CPU_SUSPEND. Without the ARM_CPU_SUSPEND the sleep code is meaningless. Fix the same by adding ARM_CPU_SUSPEND for OMAP5. The suggestion came from Russell King in an off-list discussion. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Kevin Hilman <khilman@ti.com> Reported-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 26 7月, 2012 1 次提交
-
-
由 Santosh Shilimkar 提交于
OMAP4 CPUDILE driver is converted mainly based on notes from the coupled cpuidle patch series. The changes include : - Register both CPUs and C-states to cpuidle driver. - Set struct cpuidle_device.coupled_cpus - Set struct cpuidle_device.safe_state to non coupled state. - Set CPUIDLE_FLAG_COUPLED in struct cpuidle_state.flags for each state that affects multiple cpus. - Separate ->enter hooks for coupled & simple idle. - CPU0 wait loop for CPU1 power transition. - CPU1 wakeup mechanism for the idle exit. - Enabling ARCH_NEEDS_CPU_IDLE_COUPLED for OMAP4. Thanks to Kevin Hilman and Colin Cross on the suggestions/fixes on the intermediate version of this patch. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 09 7月, 2012 1 次提交
-
-
由 R Sricharan 提交于
Adding the build support required for OMAP5 soc in to omap2+ config. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NR Sricharan <r.sricharan@ti.com> Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
-
- 05 7月, 2012 2 次提交
-
-
由 Vaibhav Hiremath 提交于
The function __omap2_set_globals() can be common across all platforms/architectures, even in case of omap4, internally it calls same set of functions as in __omap2_set_globals() function (except for sdrc). This patch adds new config flag SOC_HAS_OMAP2_SDRC to handle sdrc, so that we can reuse same function across omap2/3/4... Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Vaibhav Hiremath 提交于
Initially, we decided to make am33xx family of device to fall under omap3 class (cpu_is_omap34xx() = true), since it carries Cortex-A8 core. But while adding complete baseport support (like, clock, power and hwmod) support, it is observed that, we are creating more and more problems by treating am33xx device as omap3 family, as nothing matches between them (except cortex-A8 mpu). So, after long discussion we have came to the conclusion that, we should not consider am33xx device as omap3 family, instead create separate class (SOC_AM33XX) under OMAP2PLUS. This means, for am33xx device, cpu_is_omap34xx() will return false, and only cpu_is_am33xx() will be true. Please refer to the link below, for mailing-list discussion on this - http://www.spinics.net/lists/linux-omap/msg69439.htmlSigned-off-by: NVaibhav Hiremath <hvaibhav@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Paul Walmsley <paul@pwsan.com> [tony@atomide.com: fixed typo, updated for soc_is changes] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 29 6月, 2012 1 次提交
-
-
由 Kevin Hilman 提交于
commit 164e0cbf (ARM: OMAP3/4: consolidate cpuidle Makefile) added an OMAP-specific dependency from CPU_IDLE to CONFIG_PM. This causes some randconfig warnings when CONFIG_PM has unmet dependencies: warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME) warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME) warning: (ARCH_OMAP3 && ARCH_OMAP4) selects PM which has unmet direct dependencies (PM_SLEEP || PM_RUNTIME) Fix this by making the dependency on CONFIG_PM_RUNTIME (which in turn will enable CONFIG_PM.) Reported-by: NTony Lindgren <tony@atomide.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Signed-off-by: NKevin Hilman <khilman@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 20 6月, 2012 1 次提交
-
-
由 Daniel Lezcano 提交于
The current Makefile compiles the cpuidle34xx.c and cpuidle44xx.c files even if the cpuidle option is not set in the kernel. This patch fixes this by creating a section in the Makefile where these files are compiled only if the CONFIG_CPU_IDLE option is set. This modification breaks an implicit dependency between CPU_IDLE and PM as they belong to the same block in the Makefile. This is fixed in the Kconfig by selecting explicitely PM is CPU_IDLE is set. The linux coding style recommend to use no-op functions in the headers when the subsystem is disabled instead of adding big section in C files. This patch fix this also. Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NRajendra Nayak <rnayak@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 04 6月, 2012 2 次提交
-
-
由 Tony Lindgren 提交于
The FS (Full Speed) USB controller is available on 2420 and 2430, but not being used. Out of the 2420 based boards only Nokia N8X0 are seeing active development and they have external HS (High Speed) TUSB controller. On omap 2430sdp there is MUSB HS controller, so there's no need to use the legacy USB FS controller. That leaves only H4 and Apollon boards that could use the FS USB controller. As both H4 and Apollon boards are old proprietary development boards, it's unlikely that we have any active developers working on those boards using the USB. So remove the FS USB support for omap2 machines. Patches are welcome if somebody wants to instead fix it all up to the current standards. Cc: linux-usb@vger.kernel.org Cc: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Tony Lindgren 提交于
We should not select ARCH_OMAP_OTG as the hardware does not have the legacy FS (Full Speed) USB interface. Cc: linux-usb@vger.kernel.org Cc: Kyungmin Park <kyungmin.park@samsung.com> Acked-by: NFelipe Balbi <balbi@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 11 5月, 2012 2 次提交
-
-
由 Kevin Hilman 提交于
No need to have an OMAP prefix on these SoCs that are in the family but arent' really called OMAP. Simple rename: CONFIG_SOC_OMAPAM33XX --> CONFIG_SOC_AM33XX No functional change. Signed-off-by: NKevin Hilman <khilman@ti.com> Acked-by: NVaibhav Hiremath <hvaibhav@ti.com> [tony@atomide.com: updated for the driver config change also] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Kevin Hilman 提交于
No need to have an OMAP prefix on these SoCs that are in the family but arent' really called OMAP. Simple rename: CONFIG_SOC_OMAPTI81XX --> CONFIG_SOC_TI81XX No functional change. Signed-off-by: NKevin Hilman <khilman@ti.com> Acked-by: NVaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 10 5月, 2012 1 次提交
-
-
由 Santosh Shilimkar 提交于
HIGMEM support in kernel is quite mature now and we have boards like ZOOM, PANDA, SDP where 1 GB memories are installed. With HIGHMEM disabled not all of the 1GB of RAM (only ~700MB) can be accessed. Hence, enable HIGMEM to make use of the entire memory. On the boards which doesn't have more than 768 MB memory, all the memory is directly mapped in "lowmem" and highmem isn't exercised. Hence, there should be no impact by enabling HIGHMEM for boards that do not need it. Tested on OMAP4460 Panda-ES. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NJon Hunter <jon-hunter@ti.com> Tested-by: NJon Hunter <jon-hunter@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 06 3月, 2012 2 次提交
-
-
由 Tony Lindgren 提交于
This reverts commit c295fb63. This makes existing .config files bloated by selecting in all omaps as noted by Russell King - ARM Linux <linux@arm.linux.org.uk>. Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Aaro Koskinen 提交于
Add minimal support for Nokia RM-696 board. Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 25 2月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
If we don't have ARCH_OMAP2, 3 or 4 selected randconfig will always fail with multiple errors as the CPU and MACHINE are not set. Fix this by changing arch/arm/Makefile to build mach-omap2 based on ARCH_OMAP2PLUS. And let's introduce SOC_OMAP and SOC_OMAP_NOOP that allow randconfig to generate buildable .config files. Note that we can also remove few uncecssary ARCH_OMAP2PLUS lines as they are all within if ARCH_OMAP2PLUS block. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 24 2月, 2012 1 次提交
-
-
由 Tony Lindgren 提交于
Otherwise we get: warning: (ARCH_OMAP3 && ARCH_OMAP4) selects USB_ARCH_HAS_EHCI which has unmet direct dependencies (USB_SUPPORT) Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 15 2月, 2012 1 次提交
-
-
由 Santosh Shilimkar 提交于
arm_memblock_steal() is not suppose to be used outside ->reserve callback. OMAP barrier errata code was using it outside reserve callback and hence it was broken. Move the allocation as part of ->reserve callback to fix the it. Signed-off-by: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 23 1月, 2012 1 次提交
-
-
由 Will Deacon 提交于
To ensure correct alignment of cacheline-aligned data, the maximum cacheline size needs to be known at compile time. Since Cortex-A8 and Cortex-A15 have 64-byte cachelines (and it is likely that there will be future ARMv7 implementations with the same line size) then it makes sense to assume that CPU_V7 implies a 64-byte L1 cacheline size. For CPUs with smaller caches, this will result in some harmless padding but will help with single zImage work and avoid hitting subtle bugs with misaligned data structures. Signed-off-by: NWill Deacon <will.deacon@arm.com> Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 21 1月, 2012 2 次提交
-
-
由 Felipe Contreras 提交于
warning: (MACH_OMAP_ZOOM2 && MACH_OMAP_ZOOM3 && MACH_OMAP_4430SDP && MACH_OMAP4_PANDA && TPS6105X) selects REGULATOR_FIXED_VOLTAGE which has unmet direct dependencies (REGULATOR) Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Felipe Contreras 提交于
warning: (MACH_OMAP3_TOUCHBOOK && DRM_RADEON_KMS && DRM_I915 && STUB_POULSBO && FB_BACKLIGHT && USB_APPLEDISPLAY && FB_OLPC_DCON && ASUS_LAPTOP && SONY_LAPTOP && THINKPAD_ACPI && EEEPC_LAPTOP && ACPI_ASUS && ACPI_CMPC && SAMSUNG_Q10) selects BACKLIGHT_CLASS_DEVICE which has unmet direct dependencies (HAS_IOMEM && BACKLIGHT_LCD_SUPPORT) A lot of boards need BACKLIGHT_CLASS_DEVICE for the framebuffers to work, but it's not *needed* for the device itself. It might be nice to enable it by default somewhoe if graphics stuff is enabled, but that's another story. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 13 1月, 2012 1 次提交
-
-
由 Russell King 提交于
Several platforms are now using the memblock_alloc+memblock_free+ memblock_remove trick to obtain memory which won't be mapped in the kernel's page tables. Most platforms do this (correctly) in the ->reserve callback. However, OMAP has started to call these functions outside of this callback, and this is extremely unsafe - memory will not be unmapped, and could well be given out after memblock is no longer responsible for its management. So, provide arm_memblock_steal() to perform this function, and ensure that it panic()s if it is used inappropriately. Convert everyone over, including OMAP. As a result, OMAP with OMAP4_ERRATA_I688 enabled will panic on boot with this change. Mark this option as BROKEN and make it depend on BROKEN. OMAP needs to be fixed, or 137d105d (ARM: OMAP4: Fix errata i688 with MPU interconnect barriers.) reverted until such time it can be fixed correctly. Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
-
- 19 12月, 2011 3 次提交
-
-
由 Dave Martin 提交于
If running in the Normal World on a TrustZone-enabled SoC, Linux does not have complete control over the L2 cache controller configuration. The kernel cannot work reliably on such platforms without the l2x0 cache support code built in. This patch unconditionally enables l2x0 support for the OMAP4 SoCs. Thanks to Rob Herring for this suggestion. [1] [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074495.htmlSigned-off-by: NDave Martin <dave.martin@linaro.org> Acked-by: NTony Lindgren <tony@atomide.com>
-
由 Dave Martin 提交于
Making SMP depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms are SMP-capable to the individual machines. To enable this, a new HAVE_SMP config option is introduced to allow machines to indicate that they can run in a SMP configuration. Signed-off-by: NDave Martin <dave.martin@linaro.org> Acked-by: NLinus Walleij <linus.walleij@linaro.org> (for nomadik, ux500) Acked-by: NTony Lindgren <tony@atomide.com> (for omap) Acked-by: NKukjin Kim <kgene.kim@samsung.com> (for exynos) Acked-by: NSascha Hauer <s.hauer@pengutronix.de> (for imx) Acked-by: NOlof Johansson <olof@lixom.net> (for tegra)
-
由 Dave Martin 提交于
Making CACHE_L2X0 depend on (huge list of MACH_ and ARCH_ configs) is bothersome to maintain and likely to lead to merge conflicts. This patch moves the knowledge of which platforms have a L2x0 or PL310 cache controller to the individual machines. To enable this, a new MIGHT_HAVE_CACHE_L2X0 config option is introduced to allow machines to indicate that they may have such a cache controller independently of each other. Boards/SoCs which cannot reliably operate without the L2 cache controller support will need to select CACHE_L2X0 directly from their own Kconfigs instead. This applies to some TrustZone-enabled boards where Linux runs in the Normal World, for example. Signed-off-by: NDave Martin <dave.martin@linaro.org> Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com> (for cns3xxx) Acked-by: NTony Lindgren <tony@atomide.com> (for omap) Acked-by: NShawn Guo <shawn.guo@linaro.org> (for imx) Acked-by: NKukjin Kim <kgene.kim@samsung.com> (for exynos) Acked-by: NSascha Hauer <s.hauer@pengutronix.de> (for imx) Acked-by: NOlof Johansson <olof@lixom.net> (for tegra)
-
- 17 12月, 2011 1 次提交
-
-
由 Benoit Cousson 提交于
devicetree will become the mandatory boot method for OMAP2+. In order to avoid cluttering the OMAP code with #ifdef CONFIG_OF, select USE_OF by default for every OMAP2+ systems. Enable PROC_DEVICETREE as well. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 14 12月, 2011 3 次提交
-
-
由 Hemant Pedanekar 提交于
This patch adds minimal support and build configuration for TI8148 EVM. Also adds support for low level debugging on UART1 console on the EVM. Note that existing TI8168 EVM file (board-ti8168evm.c) is updated with machine info for TI8148 EVM. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Hemant Pedanekar 提交于
This patch updates existing macros, functions used for TI816X, to enable addition of other SoCs belonging to TI81XX family (e.g., TI814X). The approach taken is to use TI81XX/ti81xx for code/data going to be common across all TI81XX devices. cpu_is_ti81xx() is introduced to handle code common across TI81XX devices. In addition, ti8168_evm_map_io() is now replaced with ti81xx_map_io() and moved in mach-omap2/common.c as same will be used for TI814X and is not board specific. Signed-off-by: NHemant Pedanekar <hemantp@ti.com> Signed-off-by: NTony Lindgren <tony@atomide.com>
-
由 Afzal Mohammed 提交于
This patch updates the common platform files with AM335X device support (AM33XX family). The approach taken in this patch is, AM33XX device will be considered as OMAP3 variant, and a separate SoC class created for AM33XX family of devices with a subclass type for AM335X device, which is newly added device in the family. This means, cpu_is_omap34xx(), cpu_is_am33xx() and cpu_is_am335x() checks will return success on AM335X device. A kernel config option CONFIG_SOC_OMAPAM33XX is added under OMAP3 to include support for AM33XX build. Also, cpu_mask and RATE_IN_XXX flags have crossed 8 bit hence struct clksel_rate.flags, struct prcm_config.flags and cpu_mask are changed to u16 from u8. Signed-off-by: NAfzal Mohammed <afzal@ti.com> Signed-off-by: NVaibhav Hiremath <hvaibhav@ti.com> Cc: Hemant Pedanekar <hemantp@ti.com> [tony@atomide.com: left out CK_AM33XX for now] Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 09 12月, 2011 1 次提交
-
-
由 Santosh Shilimkar 提交于
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: NSantosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: NRichard Woodruff <r-woodruff2@ti.com> Acked-by: NJean Pihet <j-pihet@ti.com> Reviewed-by: NKevin Hilman <khilman@ti.com> Tested-by: NVishwanath BS <vishwanath.bs@ti.com> Signed-off-by: NKevin Hilman <khilman@ti.com>
-
- 24 11月, 2011 1 次提交
-
-
由 Ming Lei 提交于
This patch selects ARM_AMBA if OMAP3_EMU is defined because OC_ETM depends on ARM_AMBA, so fix the link failure[1]. [1], arch/arm/kernel/built-in.o: In function `etm_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:609: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_remove': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:409: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etm_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:640: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:646: undefined reference to `amba_driver_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:648: undefined reference to `amba_driver_unregister' arch/arm/kernel/built-in.o: In function `etm_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:545: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:595: undefined reference to `amba_release_regions' arch/arm/kernel/built-in.o: In function `etb_probe': /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:347: undefined reference to `amba_request_regions' /home/tom/git/omap/linux-2.6-omap/arch/arm/kernel/etm.c:392: undefined reference to `amba_release_regions' arch/arm/mach-omap2/built-in.o: In function `emu_init': /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:62: undefined reference to `amba_device_register' /home/tom/git/omap/linux-2.6-omap/arch/arm/mach-omap2/emu.c:63: undefined reference to `amba_device_register' make: *** [.tmp_vmlinux1] Error 1 making modules Signed-off-by: NMing Lei <tom.leiming@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: NTony Lindgren <tony@atomide.com>
-
- 16 11月, 2011 2 次提交
-
-
由 Marc Zyngier 提交于
Now that MULTI_IRQ_HANDLER is selected by all the in-tree GIC users, make it mandatory and remove the unused macros. Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
由 Marc Zyngier 提交于
Convert the omap2plus platforms to be using CONFIG_MULTI_IRQ_HANDLER. Each machine is modified to provide either omap2_intc_handle_irq(), omap3_intc_handle_irq() or gic_handle_irq(). This allows for a major cleanup, removing the MULTI_OMAP setup from the interrupt path. Tested on both Panda and IGEPv2 (single kernel image) Tested-by: NTony Lindgren <tony@atomide.com> Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
-
- 24 10月, 2011 1 次提交
-
-
由 Arnd Bergmann 提交于
We currently have two symbols to control compilation the MFD subsystem, MFD_SUPPORT and MFD_CORE. The MFD_SUPPORT is actually not required at all, it only hides the submenu when not set, with the effect that Kconfig warns about missing dependencies when another driver selects an MFD driver while MFD_SUPPORT is disabled. Turning the MFD submenu back from menuconfig into a plain menu simplifies the Kconfig syntax for those kinds of users and avoids the surprise when the menu suddenly appears because another driver was enabled that selects this symbol. Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 05 10月, 2011 1 次提交
-
-
由 Benoit Cousson 提交于
Re-cycle the original board-generic.c file to support Device Tree for every OMAP2+ variants. The current approach is an intermediate step before having only one machine descriptor that will use some generic DT aware functions. Signed-off-by: NBenoit Cousson <b-cousson@ti.com> Cc: Tony Lindgren <tony@atomide.com>
-
- 02 10月, 2011 1 次提交
-
-
由 Arnd Bergmann 提交于
Support for the cpu_suspend functions is only built-in when CONFIG_PM_SLEEP is enabled, but omap3/4, exynos4 and pxa always call cpu_suspend when CONFIG_PM is enabled. Signed-off-by: NArnd Bergmann <arnd@arndb.de>
-
- 06 8月, 2011 1 次提交
-
-
由 Kevin Hilman 提交于
CONFIG_PM is no longer a user-selectable Kconfig option. Rather it is automatically enabled if either CONFIG_SUSPEND or CONFIG_RUNTIME_PM is enabled, so having a 'select PM' here is redunant when 'select CONFIG_PM_RUNTIME' is present. Signed-off-by: NKevin Hilman <khilman@ti.com>
-