summaryrefslogtreecommitdiffstats
path: root/arch/arm
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'devel-gpio' into omap-for-linusTony Lindgren2010-12-1051-538/+2175
|\
| * omap1: Fix gpio mpuio bank to work for multi-omap for 7xx/15xx/16xxTony Lindgren2010-12-075-31/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to divide the 15xx/16xx offset by 2 for 7xx. Use bank->stride for that. This allows us to get rid of the duplicate defines for the MPUIO registers. Note that this will cause omap-keypad.c driver to not work on 7xx. However, the right fix there is to move over to matrix_keypad instead as suggested by Cory Maccarrone <darkstar6262@gmail.com> and Janusz Krzysztofik <jkrzyszt@tis.icnet.pl>. Cc: Cory Maccarrone <darkstar6262@gmail.com> Acked-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP: GPIO: Implement GPIO as a platform deviceVaradarajan, Charulatha2010-12-0743-359/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement GPIO as a platform device. GPIO APIs are used in machine_init functions. Hence it is required to complete GPIO probe before board_init. Therefore GPIO device register and driver register are implemented as postcore_initcalls. omap_gpio_init() does nothing now and this function would be removed in the next patch as it's usage is spread across most of the board files. Inorder to convert GPIO as platform device, modifications are required in clockxxxx_data.c file for OMAP1 so that device names can be used to obtain clock instead of getting clocks by name/NULL ptr. Use runtime pm APIs (pm_runtime_put*/pm_runtime_get*) for enabling or disabling the clocks, modify sysconfig settings and remove usage of clock FW APIs. Note 1: Converting GPIO driver to use runtime PM APIs is not done as a separate patch because GPIO clock names are different for various OMAPs and are different for some of the banks in the same CPU. This would need usage of cpu_is checks and bank id checks while using clock FW APIs in the gpio driver. Hence while making GPIO a platform driver framework, PM runtime APIs are used directly. Note 2: While implementing GPIO as a platform device, pm runtime APIs are used as mentioned above and modification is not done in gpio's prepare for idle/ resume after idle functions. This would be done in the next patch series and GPIO driver would be made to use dev_pm_ops instead of sysdev_class in that series only. Due to the above, the GPIO driver implicitly relies on CM_AUTOIDLE = 1 on its iclk for power management to work, since the driver never disables its iclk. This would be taken care in the next patch series (see Note 3 below). Refer to http://www.mail-archive.com/linux-omap@vger.kernel.org/msg39112.html for more details. Note 3: only pm_runtime_get_sync is called in gpio's probe() and pm_runtime_put* is never called. This is to make the implementation similar to the existing GPIO code. Another patch series would be sent to correct this. In OMAP3 and OMAP4 gpio's debounce clocks are optional clocks. They are enabled/ disabled whenever required using clock framework APIs TODO: 1. Cleanup the GPIO driver. Use function pointers and register offest pointers instead of using hardcoded values 2. Remove all cpu_is_ checks and OMAP specific macros 3. Remove usage of gpio_bank array so that only instance specific information is used in driver code 4. Rename 'method'/ avoid it's usage 5. Fix the non-wakeup gpios handling for OMAP2430, OMAP3 & OMAP4 6. Modify gpio's prepare for idle/ resume after idle functions to use runtime pm implentation. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Reviewed-by: Basak, Partha <p-basak2@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> [tony@atomide.com: updated for bank specific revision and updated boards] Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP2+: GPIO: device registrationVaradarajan, Charulatha2010-12-071-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use omap_device_build() API to do platform_device_register of GPIO devices. For OMAP2+ chips, the device specific data defined in the centralized hwmod database will be used. gpio_init needs to be done before machine_init functions access gpio APIs. Hence gpio_init is made as a postcore_initcall. Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Reviewed-by: Basak, Partha <p-basak2@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP4: hwmod data: Add GPIOBenoit Cousson2010-12-071-0/+341
| | | | | | | | | | | | | | | | | | Add GPIO hwmod data for OMAP4 Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP3: hwmod data: Add GPIOVaradarajan, Charulatha2010-12-071-1/+360
| | | | | | | | | | | | | | | | | | | | | | | | | | Add GPIO hwmod data for OMAP3 Also remove "omap34xx.h" header file as it is not required anymore. Signed-off-by: Charulatha V <charu@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP2430: hwmod data: Add GPIOVaradarajan, Charulatha2010-12-071-1/+279
| | | | | | | | | | | | | | | | | | | | | | | | Add GPIO hwmod data for OMAP2430 Also remove "omap24xx.h" header file as it is not required anymore. Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP2420: hwmod data: Add GPIOVaradarajan, Charulatha2010-12-072-1/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | Add GPIO hwmod data for OMAP2420 and add the required GPIO device attributes in the gpio header file Also remove "omap24xx.h" header file as it is not required anymore. Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Benoit Cousson <b-cousson@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP7xx: GPIO: Introduce support for GPIO initVaradarajan, Charulatha2010-12-071-0/+261
| | | | | | | | | | | | | | | | | | Add support for handling OMAP7xx specific gpio_init by providing platform device data and doing device registration. Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP16xx: GPIO: Introduce support for GPIO initVaradarajan, Charulatha2010-12-071-0/+199
| | | | | | | | | | | | | | | | | | Add support for handling OMAP16xx specific gpio_init by providing platform device data and doing device registration. Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP15xx: GPIO: Introduce support for GPIO initVaradarajan, Charulatha2010-12-073-8/+118
| | | | | | | | | | | | | | | | | | Add support for handling OMAP15xx specific gpio_init by providing platform device data and doing device registration. Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP: GPIO: Make omap_gpio_show_rev bank specificTony Lindgren2010-12-071-6/+6
| | | | | | | | | | | | | | | | Otherwise GPIO init on 16xx may try to access uninitialized GPIO bank as the MPUIO bank does not have a revision register. Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * OMAP: GPIO: prepare for platform driverVaradarajan, Charulatha2010-12-071-116/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prepare for implementing GPIO as a platform driver. Modifies omap_gpio_init() to make use of omap_gpio_chip_init() and omap_gpio_mod_init(). omap_gpio_mod_init() does the module init by clearing the status register and initializing the GPIO control register. omap_gpio_chip_init() initializes the chip request, free, get, set and other function pointers and sets the gpio irq handler. This is only to reorganize the code so that the "omap gpio platform driver implementation patch" looks cleaner and better to review. Signed-off-by: Charulatha V <charu@ti.com> Acked-by: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * omap: Fix gpio_request calls to happen as arch_initcallTony Lindgren2010-12-078-36/+42
| | | | | | | | | | | | | | | | | | Looks like some boards are calling gpio_request from init_irq. This will make the request_irq fail, as GPIO will be initialized as postcore_initcall. Reported-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | omap1: Delete old defconfigsTony Lindgren2010-12-1015-1266/+0
| | | | | | | | | | | | | | Please use omap1_defconfig instead, or search online for a more optimized defconfig for your omap1 board. Signed-off-by: Tony Lindgren <tony@atomide.com>
* | omap1: Add omap1_defconfigTony Lindgren2010-12-101-0/+286
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The omap1_defconfig this should be eventually usable for booting all omap1 machines. Generated based on: $ grep ARCH_OMAP1=y arch/arm/configs/* | cut -d: -f1 | xargs cat | \ sort | uniq >> arch/arm/configs/omap1_defconfig Then change few things manually, like use Nokia 770 CONFIG_CMDLINE as it does not allow setting it in the bootloader. Finally ran make savedefconfig on it. Signed-off-by: Tony Lindgren <tony@atomide.com>
* | omap1: Add initcall checks for omap1 and booted boardTony Lindgren2010-12-109-0/+30
| | | | | | | | | | | | | | Otherwise multi-omap1 configurations will fail. Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
* | omap: Split omap_read/write functions for omap1 and omap2+Tony Lindgren2010-12-103-58/+79
| | | | | | | | | | | | | | | | | | Otherwise multi-omap1 support for omap1 won't work as the cpu_class_is_omap1() won't work until the SoC is detected. Note that eventually these will go away, please use ioremap + read/write instead. Signed-off-by: Tony Lindgren <tony@atomide.com>
* | Merge branch 'devel-omap-irq' into omap-for-linusTony Lindgren2010-12-1043-1583/+495
|\ \
| * | omap2+: Initialize omap_irq_base for entry-macro.S from platform codeTony Lindgren2010-12-102-29/+37
| | | | | | | | | | | | | | | | | | This way we can use the generic omap SoC detection code instead. Signed-off-by: Tony Lindgren <tony@atomide.com>
| * | omap1: Use asm_irq_flags for entry-macro.STony Lindgren2010-12-093-14/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Initialize asm_irq_flags in omap_init_irq and use it in get_irqnr_and_base to detect between omap7xx and omap15xx/16xx. Note that both INT_1510_IH2_IRQ and INT_1510_IH2_IRQ are defined as 0, so use INT_1510_IH2_IRQ for both of them. Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * | ARM: tegra: fix regression from addruart rewriteOlof Johansson2010-12-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 0ea129300982 ("arm: return both physical and virtual addresses from addruart") took out the test for MMU on/off but didn't switch the ldr instructions to no longer be conditionals based on said test. Fix that. Signed-off-by: Olof Johansson <olof@lixom.net> Acked-by: Colin Cross <ccross@android.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| * | Merge master.kernel.org:/home/rmk/linux-2.6-armLinus Torvalds2010-12-0614-30/+55
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * master.kernel.org:/home/rmk/linux-2.6-arm: ARM: 6524/1: GIC irq desciptor bug fix ARM: 6523/1: iop: ensure sched_clock() is notrace ARM: 6456/1: Fix for building DEBUG with sa11xx_base.c as a module. ARM: 6519/1: kuser: Fix incorrect cmpxchg syscall in kuser helpers ARM: 6505/1: kprobes: Don't HAVE_KPROBES when CONFIG_THUMB2_KERNEL is selected ARM: 6508/1: vexpress: Correct data alignment in headsmp.S for CONFIG_THUMB2_KERNEL ARM: 6507/1: RealView: Correct data alignment in headsmp.S for CONFIG_THUMB2_KERNEL ARM: 6504/1: Thumb-2: Fix long-distance conditional branches in head.S for Thumb-2. ARM: 6503/1: Thumb-2: Restore sensible zImage header layout for CONFIG_THUMB2_KERNEL ARM: 6502/1: Thumb-2: Fix CONFIG_THUMB2_KERNEL breakage in compressed/head.S ARM: 6501/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in mm/proc-v7.S ARM: 6500/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in kernel/head.S ARM: 6499/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in bootp/init.S ARM: 6498/1: vfp: Correct data alignment for CONFIG_THUMB2_KERNEL ARM: 6497/1: kexec: Correct data alignment for CONFIG_THUMB2_KERNEL ARM: 6496/1: GIC: Do not try to register more then NR_IRQS interrupts ARM: cns3xxx: Fix build with CONFIG_PCI=y
| | * \ Merge branch 'for-rmk-fixes' of git://git.infradead.org/users/cbou/linux-cns3xxxRussell King2010-12-061-1/+1
| | |\ \
| | | * | ARM: cns3xxx: Fix build with CONFIG_PCI=yAnton Vorontsov2010-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 6338a6aa7c082f11d55712251e14178c68bf5869 ("ARM: 6269/1: Add 'code' parameter for hook_fault_code()") breaks CNS3xxx build: CC arch/arm/mach-cns3xxx/pcie.o pcie.c: In function 'cns3xxx_pcie_init': pcie.c:373: warning: passing argument 4 of 'hook_fault_code' makes integer from pointer without a cast pcie.c:373: error: too few arguments to function 'hook_fault_code' This commit fixes the small issue. Cc: stable@kernel.org [36] Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
| | * | | ARM: 6524/1: GIC irq desciptor bug fixChao Xie2010-12-061-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | gic_set_cpu will directly use irq_desc[]. If CONFIG_SPARSE_IRQ is enabled, there is no irq_desc[]. So we need use irq_to_desc(irq) to get the descriptor for irq. Signed-off-by: Chao Xie <chao.xie@marvell.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6523/1: iop: ensure sched_clock() is notraceRabin Vincent2010-12-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Include sched.h to ensure sched_clock() has the notrace annotation, and mark any functions it calls as notrace too. Include sched.h to ensure sched_clock() has the notrace annotation, and mark any functions it calls as notrace too. Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Rabin Vincent <rabin@rab.in> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6519/1: kuser: Fix incorrect cmpxchg syscall in kuser helpersDave Martin2010-12-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The existing code invokes the syscall with rubbish in r7, due to what looks like an incorrect literal load idiom. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6505/1: kprobes: Don't HAVE_KPROBES when CONFIG_THUMB2_KERNEL is selectedDave Martin2010-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the kprobes implementation for ARM only supports the ARM instruction set, so it only works if CONFIG_THUMB2_KERNEL is not enabled. Until kprobes is updated to work with Thumb-2, turning it on will cause horrible things to happen, so this patch disables it for now. Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6508/1: vexpress: Correct data alignment in headsmp.S for ↵Dave Martin2010-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_THUMB2_KERNEL Directives such as .long and .word do not magically cause the assembler location counter to become aligned in gas. As a result, using these directives in code sections can result in misaligned data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL). This is a Bad Thing, since the ABI permits the compiler to assume that fundamental types of word size or above are word- aligned when accessing them from C. If the data is not really word-aligned, this can cause impaired performance and stray alignment faults in some circumstances. In general, the following rules should be applied when using data word declaration directives inside code sections: * .quad and .double: .align 3 * .long, .word, .single, .float: .align (or .align 2) * .short: No explicit alignment required, since Thumb-2 instructions are always 2 or 4 bytes in size. immediately after an instruction. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6507/1: RealView: Correct data alignment in headsmp.S for ↵Dave Martin2010-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_THUMB2_KERNEL Directives such as .long and .word do not magically cause the assembler location counter to become aligned in gas. As a result, using these directives in code sections can result in misaligned data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL). This is a Bad Thing, since the ABI permits the compiler to assume that fundamental types of word size or above are word- aligned when accessing them from C. If the data is not really word-aligned, this can cause impaired performance and stray alignment faults in some circumstances. In general, the following rules should be applied when using data word declaration directives inside code sections: * .quad and .double: .align 3 * .long, .word, .single, .float: .align (or .align 2) * .short: No explicit alignment required, since Thumb-2 instructions are always 2 or 4 bytes in size. immediately after an instruction. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6504/1: Thumb-2: Fix long-distance conditional branches in head.S for ↵Dave Martin2010-11-301-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Thumb-2. The 32-bit conditional branches in Thumb-2 have a shorter range (+/-512K) than their ARM counterparts (+/-32MB). The linker does not currently generate trampolines to extend the range of these Thumb-2 conditional branches, resulting in link errors when vmlinux is sufficiently large, e.g.: head.o:(.text+0x464): relocation truncated to fit: R_ARM_THM_JUMP19 This patch forces the longer-range, unconditional branch encoding by use of an explicit IT instruction. The resulting branches are triggered on the same conditions as before. Signed-off-by: Dave Martin <dave.martin@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6503/1: Thumb-2: Restore sensible zImage header layout for ↵Dave Martin2010-11-302-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CONFIG_THUMB2_KERNEL The code which makes up the zImage header intends to leave a 32-byte gap followed by a branch to the real entry point, a magic number, and a word containing the absolute entry point address. This gets messed up with with CONFIG_THUMB2_KERNEL, because the size of the initial padding NOPs changes. Instead, the header can be made fully compatible by restoring it to ARM. In the Thumb-2 case, we can replace the initial NOPs with a sequence which switches to Thumb and jumps to the real entry point. As a consequence, the zImage entry point is now always ARM, so no special magic is needed any more for the uImage rules in the Thumb-2 case. Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6502/1: Thumb-2: Fix CONFIG_THUMB2_KERNEL breakage in compressed/head.SDave Martin2010-11-301-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some instruction operand combinations are used here which are nor permitted in Thumb-2. In particular, most uses of pc as an operand are disallowed in Thumb-2, and deprecated in ARM from ARMv7 onwards. The modified code introduced by this patch should be compatible with all architecture versions >= v3, with or without CONFIG_THUMB2_KERNEL. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6501/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in ↵Dave Martin2010-11-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mm/proc-v7.S Directives such as .long and .word do not magically cause the assembler location counter to become aligned in gas. As a result, using these directives in code sections can result in misaligned data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL). This is a Bad Thing, since the ABI permits the compiler to assume that fundamental types of word size or above are word- aligned when accessing them from C. If the data is not really word-aligned, this can cause impaired performance and stray alignment faults in some circumstances. In general, the following rules should be applied when using data word declaration directives inside code sections: * .quad and .double: .align 3 * .long, .word, .single, .float: .align (or .align 2) * .short: No explicit alignment required, since Thumb-2 instructions are always 2 or 4 bytes in size. immediately after an instruction. In this specific case, we can achieve the desired alignment by forcing a 32-bit branch instruction using the W() macro, since the assembler location counter is already 32-bit aligned in this case. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6500/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in ↵Dave Martin2010-11-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kernel/head.S Directives such as .long and .word do not magically cause the assembler location counter to become aligned in gas. As a result, using these directives in code sections can result in misaligned data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL). This is a Bad Thing, since the ABI permits the compiler to assume that fundamental types of word size or above are word- aligned when accessing them from C. If the data is not really word-aligned, this can cause impaired performance and stray alignment faults in some circumstances. In general, the following rules should be applied when using data word declaration directives inside code sections: * .quad and .double: .align 3 * .long, .word, .single, .float: .align (or .align 2) * .short: No explicit alignment required, since Thumb-2 instructions are always 2 or 4 bytes in size. immediately after an instruction. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6499/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in ↵Dave Martin2010-11-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bootp/init.S Directives such as .long and .word do not magically cause the assembler location counter to become aligned in gas. As a result, using these directives in code sections can result in misaligned data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL). This is a Bad Thing, since the ABI permits the compiler to assume that fundamental types of word size or above are word- aligned when accessing them from C. If the data is not really word-aligned, this can cause impaired performance and stray alignment faults in some circumstances. In general, the following rules should be applied when using data word declaration directives inside code sections: * .quad and .double: .align 3 * .long, .word, .single, .float: .align (or .align 2) * .short: No explicit alignment required, since Thumb-2 instructions are always 2 or 4 bytes in size. immediately after an instruction. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6498/1: vfp: Correct data alignment for CONFIG_THUMB2_KERNELDave Martin2010-11-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Directives such as .long and .word do not magically cause the assembler location counter to become aligned in gas. As a result, using these directives in code sections can result in misaligned data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL). This is a Bad Thing, since the ABI permits the compiler to assume that fundamental types of word size or above are word- aligned when accessing them from C. If the data is not really word-aligned, this can cause impaired performance and stray alignment faults in some circumstances. In general, the following rules should be applied when using data word declaration directives inside code sections: * .quad and .double: .align 3 * .long, .word, .single, .float: .align (or .align 2) * .short: No explicit alignment required, since Thumb-2 instructions are always 2 or 4 bytes in size. immediately after an instruction. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6497/1: kexec: Correct data alignment for CONFIG_THUMB2_KERNELDave Martin2010-11-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Directives such as .long and .word do not magically cause the assembler location counter to become aligned in gas. As a result, using these directives in code sections can result in misaligned data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL). This is a Bad Thing, since the ABI permits the compiler to assume that fundamental types of word size or above are word- aligned when accessing them from C. If the data is not really word-aligned, this can cause impaired performance and stray alignment faults in some circumstances. In general, the following rules should be applied when using data word declaration directives inside code sections: * .quad and .double: .align 3 * .long, .word, .single, .float: .align (or .align 2) * .short: No explicit alignment required, since Thumb-2 instructions are always 2 or 4 bytes in size. immediately after an instruction. Reviewed-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Dave Martin <dave.martin@linaro.org> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| | * | | ARM: 6496/1: GIC: Do not try to register more then NR_IRQS interruptsPawel Moll2010-11-301-15/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change limits number of GIC-originating interrupts to the platform maximum (defined by NR_IRQS) while still initialising all distributor registers. Signed-off-by: Pawel Moll <pawel.moll@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | | | at91/board-yl-9200: fix typo in video supportJean-Christophe PLAGNIOL-VILLARD2010-11-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for the epson frambuffer support it's CONFIG_FB_S1D13XXX not CONFIG_FB_S1D135XX Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
| * | | | at91/picotux200: remove commenting usb device and dataflash supportJean-Christophe PLAGNIOL-VILLARD2010-11-301-30/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | as based on http://www.picotux.com/pt200/picotux200.pdf these board does not have such I/O Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
| * | | | at91: rename rm9200ek and rm9200dk board file nameJean-Christophe PLAGNIOL-VILLARD2010-11-303-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to be a few more concistant with the other boards as ek is for evaluation kit and dk for development kit Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Andrew Victor <linux@maxim.org.za>
| * | | | at91rm9200ek: fix warning: 'ek_mmc_data' defined but not usedJean-Christophe PLAGNIOL-VILLARD2010-11-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Andrew Victor <linux@maxim.org.za>
| * | | | at91rm9200dk: fix warning: 'dk_mmc_data' defined but not usedJean-Christophe PLAGNIOL-VILLARD2010-11-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Andrew Victor <linux@maxim.org.za>
| * | | | at91: Convert remaining boards to new-style UART initializationJean-Christophe PLAGNIOL-VILLARD2010-11-305-90/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Convert the following AT91RM9200-based boards to the new-style UART initialization: - Ajeco 1ARM Single Board Computer - Sperry-Sun KAFA board - picotux 200 Remove the deprecated at91_init_serial Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Andrew Victor <linux@maxim.org.za>
| * | | | at91: merge all at91rm9200 defconfig in one single fileEric Benard2010-11-3014-1383/+341
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | About all options present in each file are activated in the single file. Signed-off-by: Eric Benard <eric@eukrea.com> Tested-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
* | | | Merge branch 'devel-cleanup' into omap-for-linusTony Lindgren2010-12-0921-74/+20
|\ \ \ \ | |_|_|/ |/| | |
| * | | arm: mach-omap2: rx51: clean up dummy onenand initAaro Koskinen2010-12-021-19/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When OneNAND support is disabled, the platform code defines NULL board_onenand_data and empty init function for us. By utilizing this we can avoid cluttering board files with dummy definitions/wrappers. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
| * | | arm: mach-omap2: n8x0: clean up dummy onenand initAaro Koskinen2010-12-021-17/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When OneNAND support is disabled, the platform code defines NULL board_onenand_data and empty init function for us. By utilizing this we can avoid cluttering board files with dummy definitions/wrappers. Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
OpenPOWER on IntegriCloud