summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)Author
2010-07-27ARM: SMP: Always enable clock event broadcast supportRussell King
The TWD local timers are unable to wake up the CPU when it is placed into a low power mode, eg. C3. Therefore, we need to adapt things such that the TWD code can cope with this. We do this by always providing a broadcast tick function, and marking the fact that the TWD local timer will stop in low power modes. This means that when the CPU is placed into a low power mode, the core timer code marks this fact, and allows an IPI to be given to the core. Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Thomas Gleixner <tglx@linutronix.de>
2010-07-27ARM: Factor out common code from cpu_proc_fin()Russell King
All implementations of cpu_proc_fin() start by disabling interrupts and then flush caches. Rather than have every processors proc_fin() implementation do this, move it out into generic code - and move the cache flush past setup_mm_for_reboot() (so it can benefit from having caches still enabled.) This allows cpu_proc_fin() to become independent of the L1/L2 cache types, and eventually move the L2 cache flushing into the L2 support code. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: 6268/1: ARMv6K and ARMv7 use fault statuses 3 and 6 as Access Flag faultKirill A. Shutemov
Statuses 3 (0b00011) and 6 (0x00110) of DFSR are Access Flags faults on ARMv6K and ARMv7. Let's patch fsr_info[] at runtime if we are on ARMv7 or later. Unfortunately, we don't have runtime check for 'K' extension, so we can't check for it. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: 6256/1: Check arch version and modify fsr_info[] depends on it at runtimeKirill A. Shutemov
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: 6255/1: Workaround infinity loop in handling of translation faultsKirill A. Shutemov
On ARM one Linux PGD entry contains two hardware entries (see page tables layout in pgtable.h). We normally guarantee that we always fill both L1 entries. But create_mapping() doesn't follow the rule. It can create inidividual L1 entries, so here we have to call pmd_none() check in do_translation_fault() for the entry really corresponded to address, not for the first of pair. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: 6269/1: Add 'code' parameter for hook_fault_code()Kirill A. Shutemov
Add one more parameter to hook_fault_code() to be able to set 'code' field of struct fsr_info. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: 6252/1: Use SIGBUS for unaligned access instead of SIGILLKirill A. Shutemov
POSIX specify to use signal SIGBUS with code BUS_ADRALN for invalid address alignment. Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: 6251/1: Make SPARSE_IRQ a hidden optioneric miao
SPARSE_IRQ doesn't need to be a visible option, only those platforms supporting that will select it. Signed-off-by: Eric Miao <eric.miao@canonical.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: DMA coherent allocator: align remapped addressesRussell King
The DMA coherent remap area is used to provide an uncached mapping of memory for coherency with DMA engines. Currently, we look for any free hole which our allocation will fit in with page alignment. However, this can lead to fragmentation of the area, and allows small allocations to cross L1 entry boundaries. This is undesirable as we want to move towards allocating sections of memory. Align allocations according to the size, limiting the alignment between the page and section sizes. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: use generic ioremap_page_range()Russell King
We don't need our own implementation of this, use the generic library implementation instead. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27Merge branch 'origin' into miscRussell King
2010-07-27ARM: 6225/1: make TCM allocation static and common for all archsLinus Walleij
This changes the TCM handling so that a fixed area is reserved at 0xfffe0000-0xfffeffff for TCM. This areas is used by XScale but XScale does not have TCM so the mechanisms are mutually exclusive. This change is needed to make TCM detection more dynamic while still being able to compile code into it, and is a must for the unified ARM goals: the current TCM allocation at different places in memory for each machine would be a nightmare if you want to compile a single image for more than one machine with TCM so it has to be nailed down in one place. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: Versatile: fix section mismatchRussell King
WARNING: vmlinux.o(.text+0xbf38): Section mismatch in reference from the function pci_versatile_scan_bus() to the function .devinit.text:pci_scan_bus_parented() The function pci_versatile_scan_bus() references the function __devinit pci_scan_bus_parented(). Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: Remove unnecessary call to find_limits()Russell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: LMB: convert pfn_valid to use LMBRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: LMB: Convert arm_memory_present() to use LMB memory informationRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: OMAP: Convert OMAPFB and VRAM SDRAM reservation to LMBRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: Convert platform reservations to use LMB rather than bootmemRussell King
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: initial LMB trialRussell King
Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: early_pte_alloc()Russell King
Provide a common function for allocating early PTE tables. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-27ARM: 6267/1: mop500: add AB8500 interrupt supportRabin Vincent
Add the platform data to enable AB8500 interrupt support. Acked-by: Linus Walleij <linus.walleij@stericsson.com> Acked-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Signed-off-by: Rabin Vincent <rabin.vincent@stericsson.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2010-07-26OMAP: PM constraints: add omap_pm_set_min_clk_rate()Paul Walmsley
Add omap_pm_set_min_clk_rate(). This constraint is meant for use by device drivers to translate a certain device-specific performance constraint (e.g., "minimum polygons per second") to a clock rate for the driver's device, given the driver's intimate knowledge of the device hardware (e.g., device type, device hardware revision, firmware revision, etc.) From a general PM core perspective, clock rate is probably the closest general analog to "performance" that is available, but the exact mapping from a use-case-specific performance constraint to clock rate must be done by the driver. Drivers intended for upstream merging shouldn't hardcode specific clock rates in their code without basing those rates on some performance criteria requested through the driver's subsystem (ideally, from userspace). Imre Deak <imre.deak@nokia.com> described the need and use-case for this constraint, and discussed the implementation - thanks, Imre. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Imre Deak <imre.deak@nokia.com>
2010-07-26OMAP: PM constraints: add return values; add requesting device param to ↵Paul Walmsley
omap_pm_set_max_dev_wakeup_lat() Add return values to the PM constraint functions. This allows the PM core to provide feedback to the caller if a constraint is not possible. Update the one upstream user of omap_pm_set_max_mpu_wakeup_lat() to add a compatibility wrapper, needed until the driver is changed. Update some of the documentation to conform more closely to kerneldoc style. Add an additional device parameter to omap_pm_set_max_dev_wakeup_lat() to identify the device requesting the constraint. This is so repeated calls to omap_pm_set_max_dev_wakeup_lat() with the same requesting device can override the device's previously-set constraint. Also, it allows the PM core to make a decision as to whether or not the constraint should be satisfied, based on the caller's identity. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP2+: hwmod/device: update documentation and copyrightPaul Walmsley
Update some minor documentation issues and update copyright for omap_device/omap_hwmod code. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com>
2010-07-26OMAP: hwmod/device: add omap_{device,hwmod}_get_mpu_rt_vaPaul Walmsley
Add omap_device_get_mpu_rt_va(). This is intended to be used by device drivers (currently, via a struct platform_data function pointer) to retrieve their corresponding device's virtual base address that the MPU should use to access the device. This is needed because the omap_hwmod code does its own ioremap(), in order to gain access to the module's OCP_SYSCONFIG register. Add omap_hwmod_get_mpu_rt_va(). omap_device_get_mpu_rt_va() calls this function to do the real work. While here, rename struct omap_hwmod._rt_va to struct omap_hwmod._mpu_rt_va, to reinforce that it refers to the MPU's register target virtual address base (as opposed to, for example, the L3's). In the future, this belongs as a function in an omap_bus, so it is not necessary to call this through a platform_data function pointer. The use-case for this function was originally presented by Santosh Shilimkar <santosh.shilimkar@ti.com>. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
2010-07-26OMAP2: hwmod data: add IVA1 (2420), IVA2 (2430) hwmodsPaul Walmsley
Add IVA1 hwmod data for OMAP2420 and IVA2 hwmod data for 2430. The data is based on Benoît Cousson's hwmod data for the OMAP3 IVA blocks. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2010-07-26OMAP3: hwmod data: add data for OMAP3 IVA2Kevin Hilman
Add hwmod data for IVA2 module on OMAP3. Naming of "iva" instead of "iva2" to be aligned with OMAP4 naming done by Benoit Cousson. Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP2&3: hwmod: Replace l3 -> l3_mainKevin Hilman
Replace all the struct that contain l3 with l3_main in order to be consistent with the OMAP4 naming convention. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP: hwmod data: add class for IVA hwmodsKevin Hilman
Add a new hwmod class for IVA devices. To be used when hwmods are created for IVA2 on OMAP3. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Cc: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP: PM: create omap_devices for MPU, DSP, L3Kevin Hilman
Create simple omap_devices for the main processors and busses. This is required to support the forth-coming device-based OPP approach, where OPPs are managed and tracked at the device level. Also, move these common PM init functions into a common_pm_init call that is called as a device_initcall(). The PM init is done at this level to ensure that the driver core is initialized before initialized. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> [paul@pwsan.com: sparse warnings cleaned up; newly-created functions moved from mach-omap2/io.c to mach-omap2/pm.c; newly-created functions renamed to start with "omap2" rather than "omap"] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP: omap_device: ensure hwmod tracks attached omap_device pointerKevin Hilman
The omap_hwmod struct has a field to track the omap_device that is attached to it, but it was not being assigned. Fix by assigning omap_device pointer when omap_device is built. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> [paul@pwsan.com: use an array index rather than pointer arithmetic] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP4: hwmod: Enable omap_device build for OMAP4Rajendra Nayak
Enable omap_device layer support for OMAP4, so that drivers can use them to enable/idle/shutdown devices. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP: hwmod: allow omap_hwmod_late_init() caller to skip module idle in _setup()Paul Walmsley
On kernels that don't use the omap_device_enable() calls to enable devices, leave all on-chip devices enabled in hwmod _setup(). Otherwise, accesses to those devices are likely to fail, crashing the system. It's expected that kernels built without CONFIG_PM_RUNTIME will be the primary use-case for this. This functionality is controlled by adding an extra parameter to omap_hwmod_late_init(). This patch is based on the patch "OMAP: hwmod: don't auto-disable hwmod when !CONFIG_PM_RUNTIME" by Kevin Hilman <khilman@deeprootsystems.com>. Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP: hwmod: add non-locking versions of enable and idle functionsKevin Hilman
Some hwmods may need to be idled/enabled in atomic context, so non-locking versions of these functions are required. Most users should not need these and usage of theses should be controlled to understand why access is being done in atomic context. For this reason, the non-locking functions are only exposed at the hwmod level and not at the omap-device level. The use-case that led to the need for the non-locking versions is hwmods that are enabled/idled from within the core idle/suspend path. Since interrupts are already disabled here, the mutex-based locking in hwmod can sleep and will cause potential deadlocks. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP2&3: hwmod: Remove _hwmod prefix in name stringBenoit Cousson
In the lastest OMAP4 hwmod data file, the _hwmod was removed in order to save some memory space and because it does not bring a lot. Align OMAP2420, 2430 and 3430 data files with the same convention. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Cc: Rajendra Nayak <rnayak@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP2/3: hwmod: L3 and L4 CORE/PER/WKUP hwmods don't have IDLESTKevin Hilman
Since these hwmods do not have IDLEST, set the HWMOD_NO_IDLEST flag, otherwise _enable() will fail due to failing _wait_target_ready(). Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP24xx: CM: fix mask used for checking IDLEST statusKevin Hilman
On OMAP24xx, the polarity for the IDLEST bits is opposite of OMAP3. The mask used to check this was using the bit position instead of the bit mask. This patch fixes the problem by using the bit mask instead of the bit field. Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP1: clock: some cleanupPaul Walmsley
Convert most of the magic numbers in mach-omap1/clock_data.c to use macros. Clean up a few comments to conform with Documentation/CodingStyle. Mark the current clkops_uart as being OMAP16xx-only, and add some comments to indicate that it does not belong there, for future cleanup. This patch should not cause any functional changes. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP1: OPP: add KConfig entry for 96MHz ARM rate (using a 12MHz oscillator)Paul Walmsley
Add KConfig entry for one of the OMAP1 DVFS rates that was missing it. Based on the surrounding rate KConfigs and the oscillator frequency, this patch marks it as valid for all OMAP1 platforms -- Richard, Tuukka, Tony, perhaps you can comment if this does not look right? In the long term, all of these CONFIG_OMAP_ARM_*MHZ should be removed. The OPP settings should be associated with the platform information in the structure data (perhaps by extending the omap_chip defines). The selection of which rates to use should be handled at runtime; rates that are impossible due to xtal frequency mismatch or SoC-type mismatch should not be included. If implemented correctly, this should save some CPU time and some memory on OMAP1 kernels. Reported-by: Christoph Egger <siccegge@cs.fau.de> Reported-by: The VAMOS Research Project <vamos@i4.informatik.uni-erlangen.de> Cc: Marek Vasut <marek.vasut@gmail.com> Cc: Richard Woodruff <r-woodruff2@ti.com> Cc: Tuukka Tikkanen <tuukka.tikkanen@nokia.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP: clock: add kerneldoc for structures; move flags closer to structsPaul Walmsley
Add kerneldoc for struct clk, struct clksel_rate, struct clksel. Move flag macros for struct clk.flags and struct clksel_rate.flags closer to the structures. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26OMAP3: wait on IDLEST after enabling USBTLL fclkAnand Gadiyar
We need to wait on the IDLEST bit after the clocks are enabled before attempting to access any register. Currently, the USBTLL i-clock ops uses the clkops_omap2_dflt_wait, while the USBTLL f-clock ops uses clkops_omap2_dflt. If the i-clock is enabled first, the clkops_omap2_dflt_wait is short-circuited as the companion f-clock is not enabled. This can cause a data abort if the IDLEST has not transitioned, and we try to access a USBTLL register. Since the USBTLL i-clock and f-clock could be enabled in any order, this is a bug. Fix it by changing the clkops for the f-clock. Signed-off-by: Anand Gadiyar <gadiyar@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-07-26Merge master.kernel.org:/home/rmk/linux-2.6-armLinus Torvalds
* master.kernel.org:/home/rmk/linux-2.6-arm: ARM: 6265/1: kirkwood: move qnap_tsx1x_register_flash() to .init.text ARM: 6263/1: ns9xxx: fix FTBFS for zImage ARM: 6262/1: arm/clps711x: fix debug macro compilation failure ARM: 6261/1: arm/shark: fix debug macro compilation failure ARM: 6260/1: arm/plat-spear: fix debug macro compilation failure ARM: 6259/1: arm/ns9xxx: fix debug macro compilation failure ARM: 6258/1: arm/h720x: fix debug macro compilation failure ARM: 6233/1: Delete a wrong redundant right parenthesis ARM: 6230/1: fix nuc900 touchscreen clk definition bug [ARM] pxa: fix incorrect CONFIG_CPU_PXA27x to CONFIG_PXA27x [ARM] pxa/colibri-pxa300: fix AC97 init [ARM] pxa: fix incorrect order of AC97 reset pin configs [ARM] pxa: fix frequency scaling for pcmcia/pxa2xx_base [ARM] pxa: cpufreq-pxa2xx: fix DRI recomputation routine [ARM] pxa/corgi: fix MMC/SD card detection failure
2010-07-26Input: RX51 keymap - fix recent compile breakageDmitry Torokhov
Commit 3fea60261e73 ("Input: twl40300-keypad - fix handling of "all ground" rows") broke compilation as I managed to use non-existent keycodes. Reported-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Dmitry Torokhov <dtor@mail.ru> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-07-26i.MX51: add support for cpuimx51 module and its baseboardEric Bénard
CPUIMX51 is build around Freescale's i.MX515 and has up to 512MB of RAM, NAND Flash, Ethernet, USB Host with 4 ports hub, USB OTG, ST16554 Quad UART on nCS1, I2C RTC ... MBIMX51 adds LEDS, Keypad, TSC2007 touchscreen controler ... Signed-off-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2010-07-26imx: move gpio init after to irq initJason Wang
The commit 9a763bf "get rid of mxc_gpio_init" changed gpio_init and irq_init sequence. Usually we will call set_irq_chained_handler in gpio_init functions, this should be called after the irq_init called, otherwise the chained irq can't get propoer irq_chip and this irq will remain masked even we called set_irq_chained_handler. Signed-off-by: Jason Wang <jason77.wang@gmail.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2010-07-26eukrea-baseboards: merge includes in one fileEric Bénard
as per suggested by Sascha Signed-off-by: Eric Bénard <eric@eukrea.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2010-07-26Fix KConfig warningEric Bénard
This patch fixes the following Kconfig warning : "arch/arm/mach-mx25/Kconfig:18:warning: choice value used outside its choice group Signed-off-by: Eric Bénard <eric@eukrea.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2010-07-26mbimxsd baseboards : remove unnecessary includeEric Bénard
Signed-off-by: Eric Bénard <eric@eukrea.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2010-07-26pcm043: register flexcan deviceMarc Kleine-Budde
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2010-07-26imx: dynamically register flexcan devices for mx25 and mx35Marc Kleine-Budde
In order to make this patch compile, even if the flexcan driver with it's header defining the platform data isn't merged yet, two ifdefs have been added. They effect that the "imx_add_flexcan" function results in a no-op function if the driver hasn't been activated. These ifdefs can be removed after the flexcan driver has been merged. Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>