summaryrefslogtreecommitdiff
path: root/arch/arm
AgeCommit message (Collapse)Author
2011-09-27ARM: OMAP: mcbsp: Use per instance register cache sizeJarkko Nikula
Rationale here is to remove one global variable and to make possible to have variable size McBSP register maps inside SoC. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-27ARM: OMAP: mcbsp: Make threshold based transfer code genericJarkko Nikula
Remove CONFIG_ARCH_OMAP3 conditional compilation and cpu_is_omap34xx test around buffer threshold based transfer and DMA operating mode control. Use instead the buffer_size in platform data to determine when these sysfs controls are exposed and when to access related McBSP registers. Rationale for this is to make code generic and to allow to use it on OMAP4 that also supports threshold based transfers. Currently buffer_size variable is set only for OMAP3 SoCs but it is easy to extend to OMAP4 and any later OMAP version. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-27ARM: OMAP: mcbsp: Make tranceiver configuration control register access genericJarkko Nikula
McBSP transmit and receive configuration control registers must be set up for OMAP2430 and later. Replace is_omap tests in generic code with a new feature flag has_ccr in platform data so that there is no need to change code for any upcoming OMAP version. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-27ARM: OMAP: mcbsp: Make wakeup control genericJarkko Nikula
Currently wakeup control code is compiled only when CONFIG_ARCH_OMAP3 is set even it should be available for CONFIG_ARCH_OMAP4 only builds also. Fix this by making wakeup control generic so that it is executed whenever new feature flag has_wakeup in platform data is set. Currently flag is set for McBSP config types 3 and 4. Remove also old comments about idle mode settings and HW bug workarounds that were not updated during hwmod conversion. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-27ARM: OMAP: mcbsp: Implement generic register accessJarkko Nikula
Register access can be made more generic by calculating register address offsets runtime from common register definitions and by using reg_size and reg_step variables that are passed via platform data. Common register definitions are possible since McBSP registers are ordered similarly between OMAP versions. Remove also references to OMAP2+ specific config_type variable from generic McBSP code since other variables and feature flags are better to carry needed information from platform code. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-27ARM: OMAP: mcbsp: Move out omap_mcbsp_register_board_cfg from ↵Jarkko Nikula
plat-omap/devices.c Only OMAP1s are using omap_mcbsp_register_board_cfg after OMAP2+ hwmod conversion so it can be moved to mach-omap1/mcbsp.c. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-26ARM: OMAP: mcbsp: Remove unused variables from platform dataJarkko Nikula
These variables got unused after McBSP was converted to use resource structures. Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-22Merge branch 'for_3.2/pm-cleanup' of ↵Tony Lindgren
git://gitorious.org/khilman/linux-omap-pm into cleanup
2011-09-22Merge branch 'for_3.2/omap_device' of ↵Tony Lindgren
git://gitorious.org/khilman/linux-omap-pm into cleanup
2011-09-21ARM: 7082/1: platform_device: pdev_archdata: add omap_device pointerKevin Hilman
Add omap_device pointer to the ARM-specific arch data in the platform_device. This will be used to attach OMAP-specific device-data to the platform device with device lifetime. Suggested-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-09-20ARM: OMAP2+: Fix missing inline functions for Makefile cleanupTony Lindgren
Commit f41caddbe73f52a42f529d668ce47b4d693fd2c0 (omap2+: Use Kconfig symbol in Makefile instead of obj-y) cleaned up the omap2+ Makefile. However this did not account for the inline functions that are now needed for board_flash_init and board_nand_init. Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-16OMAP3: PM: fix UART handling when using no_console_suspendKevin Hilman
During the idle/suspend path, we expect the console lock to be held so that no console output is done during/after the UARTs are idled. However, when using the no_console_suspend argument on the command-line, the console driver does not take the console lock. This allows the possibility of console activity after UARTs have been disabled. To fix, update the current is_suspending() to also check the console_suspend_enabled flag. Reported-by: Abhilash Koyamangalath <abhilash.kv@ti.com> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP: omap_device: decouple platform_device from omap_deviceKevin Hilman
Rather than embedding a struct platform_device inside a struct omap_device, decouple them, leaving only a pointer to the platform_device inside the omap_device. Use the arch-specific data field of the platform_device (pdev_archdata) to add an omap_device pointer after the platform_device has been created. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP: omap_device: _disable_idle_on_suspend() takes platform_device pointerKevin Hilman
Public omap_device functions need to take platform_device pointers, conversion to omap_device pointers is done internal to the omap_device layer. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP: omap_device: device register functions now take platform_device pointerKevin Hilman
The internal device register functions do not need or use any omap_device internals, so pass in a platform_device pointer instead of an omap_device pointer. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP: omap_device: when building return platform_device instead of omap_deviceKevin Hilman
All of the device init and device driver interaction with omap_device is done using platform_device pointers. To make this more explicit, have omap_device return a platform_device pointer instead of an omap_device pointer. All current users of the omap_device pointer were only using it to get at the platform_device pointer or struct device pointer, so fixing all of the users was trivial. This also makes it more difficult for device init code to directly access members of struct omap_device, and allows for easier changing of omap_device internals. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP: omap_device: remove internal functions from omap_device.hKevin Hilman
The *_device_register() functions and the count/fill resources functions are internal to omap_device and do not need to be in the header. Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP: omap_device: make latency autoadjust messages debugGrazvydas Ignotas
During normal system operation warning messages similar to this are appearing quite often: omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035 This doesn't seem to be reporting a problem, nor is it very useful for non-developers, so reduce it to debug level. Acked-by: Steve Sakoman <steve@sakoman.com> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15OMAP: omap_device: replace debug/warning/error prints with dev_* macrosKevin Hilman
For consistency in kernel printk output for devices, use dev_dbg(), dev_warn(), dev_err() instead of pr_debug(), pr_warning() and pr_err(), some of which currently use direct access of name from platform_device and others of which use dev_name(). Using the dev_* versions uses the standard device naming from the driver core. Some pr_* prints were not converted with this patch since they are used before the platform_device and struct device are created so neither the dev_* prints or dev_name() is valid. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-15omap: mcbsp: Remove omap device APIJarkko Nikula
struct omap_device *od is only set with find_omap_device_by_dev but not used otherwise so remove them and references to omap device API. Acked-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Jarkko Nikula <jarkko.nikula@bitmer.com>
2011-09-15Merge branch 'omap_chip_remove_cleanup_3.2' of git://git.pwsan.com/linux-2.6 ↵Tony Lindgren
into cleanup
2011-09-14OMAP: id: remove OMAP_CHIP declarations, codePaul Walmsley
Now that all of the users of the OMAP_CHIP bitfield code have been converted to use lists, the OMAP_CHIP code, data, and declarations can be removed. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-09-14OMAP2+: hwmod: remove OMAP_CHIP*Paul Walmsley
At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and replace it instead with chip family, variant, and ES level-specific lists of hwmods to register. Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the AM3517/3505 support, and for other review comments. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Gražvydas Ignotas <notasas@gmail.com>
2011-09-14OMAP: powerdomain: remove omap_chip bitmasksPaul Walmsley
At Tony's request, remove the omap_chip bitmasks from the powerdomain definitions. Instead, initialize powerdomains based on one or more lists that are applicable to a particular SoC family, variant, and silicon revision. Gražvydas Ignotas <notasas@gmail.com> found and reported a bug in a related patch that also applied to this patch - thanks Gražvydas. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Gražvydas Ignotas <notasas@gmail.com>
2011-09-14OMAP: powerdomain: split pwrdm_init() into two functionsPaul Walmsley
In preparation for OMAP_CHIP() removal, split pwrdm_init() into three functions. This allows some of them to be called multiple times: for example, pwrdm_register_pwrdms() can be called once to register powerdomains that are common to a group of SoCs, and once to register powerdomains that are specific to a single SoC. The appropriate order to call these functions - which is enforced by the code - is: 1. pwrdm_register_platform_funcs() 2. pwrdm_register_pwrdms() (can be called multiple times) 3. pwrdm_complete_init() Convert the OMAP2, 3, and 4 powerdomain init code to use these new functions. While here, improve documentation, and increase CodingStyle conformance by shortening some local variable names. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-09-14OMAP: clockdomain code/data: remove omap_chip bitmask from struct clockdomainPaul Walmsley
At Tony's request, remove the omap_chip bitmasks from the clockdomain and clockdomain dependency definitions. Instead, initialize clockdomains based on one or more lists that are applicable to a particular SoC family, variant, and silicon revision. Tony Lindgren <tony@atomide.com> found a bug in a previous version of this patch - thanks Tony. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Tony Lindgren <tony@atomide.com>
2011-09-14OMAP: clockdomain: split clkdm_init()Paul Walmsley
In preparation for OMAP_CHIP() removal, split clkdm_init() into four functions. This allows some of them to be called multiple times: for example, clkdm_register_clkdms() can be called once to register clockdomains that are common to a group of SoCs, and once to register clockdomains that are specific to a single SoC. The appropriate order to call these functions - which is enforced by the code - is: 1. clkdm_register_platform_funcs() 2. clkdm_register_clkdms() (can be called multiple times) 3. clkdm_register_autodeps() (optional; deprecated) 4. clkdm_complete_init() Convert the OMAP2, 3, and 4 clockdomain init code to use these new functions. While here, improve documentation, and increase CodingStyle conformance by shortening some local variable names. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-09-14OMAP2+: id: remove OMAP_REVBITS_* macrosPaul Walmsley
The OMAP_REVBITS_* macros are just used as otherwise meaningless aliases for the numbers zero through five, so remove these macros. Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
2011-09-14OMAP3: id: remove duplicate code for testing SoC ES levelPaul Walmsley
omap3_cpuinfo() contains essentially duplicated code from omap3_check_revision(), just for the purpose of determining the chip ES level. Set the cpu_rev char array pointer in omap3_check_revision() instead, and drop the now-useless code from omap3_cpuinfo(). Signed-off-by: Paul Walmsley <paul@pwsan.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
2011-09-14OMAP3: id: add fallthrough warning; fix some CodingStyle issuesPaul Walmsley
Emit a warning to the console in omap3_check_revision() if that code cannot determine what type of SoC the system is currently running on. Remove some extra whitespace, remove some duplicate code, and add an appropriate comment to a fallthrough case. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Hemant Pedanekar <hemantp@ti.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
2011-09-14OMAP3: id: use explicit omap_revision codes for 3505/3517 ES levelsPaul Walmsley
Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest of the OMAP2+ SoCs do in mach-omap2/cpu.c. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Sanjeev Premi <premi@ti.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
2011-09-14OMAP3: id: remove useless strcpy()sPaul Walmsley
omap3_cpuinfo() is filled with useless strcpy() calls; remove them. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Sanjeev Premi <premi@ti.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
2011-09-14OMAP3: id: remove identification codes that only correspond to marketing namesPaul Walmsley
The OMAP3505/AM3505 appears to be based on the same silicon as the OMAP3517/AM3517, with some features disabled via eFuse bits. Follow the same practice as OMAP3430 and identify these devices internally as part of the OMAP3517/AM3517 family. The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon as the OMAP3430, with some features disabled via eFuse bits. Identify these devices internally as part of the OMAP3430 family. Remove the old OMAP35XX_CLASS, which actually covered two very different chip families. The OMAP3503/3515/3525/3530 chips will now be covered by OMAP343X_CLASS, since the silicon appears to be identical. For the OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS. Thanks to Tony Lindgren <tony@atomide.com> for some help with the second revision of this patch. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Sanjeev Premi <premi@ti.com> Cc: Tony Lindgren <tony@atomide.com> Tested-by: Igor Grinberg <grinberg@compulab.co.il> Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
2011-09-12Merge branch 'fixes' of git://git.linaro.org/people/arnd/arm-socLinus Torvalds
* 'fixes' of git://git.linaro.org/people/arnd/arm-soc: ARM: CSR: add missing sentinels to of_device_id tables ARM: cns3xxx: Fix newly introduced warnings in the PCIe code ARM: cns3xxx: Fix compile error caused by hardware.h removed ARM: davinci: fix cache flush build error ARM: davinci: correct MDSTAT_STATE_MASK ARM: davinci: da850 EVM: read mac address from SPI flash OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlers OMAP2430: hwmod: musb: add missing terminator to omap2430_usbhsotg_addrs[] OMAP3: clock: indicate that gpt12_fck and wdt1_fck are in the WKUP clockdomain OMAP4: clock: fix compile warning OMAP4: clock: re-enable previous clockdomain enable/disable sequence OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain force wakeup OMAP: powerdomains: Make all powerdomain target states as ON at init
2011-09-12Merge branch 'for_3.1/pm-fixes-2' of ↵Arnd Bergmann
git://gitorious.org/khilman/linux-omap-pm into fixes
2011-09-12Merge branch 'sirf/fixes' into fixesArnd Bergmann
2011-09-11ARM: CSR: add missing sentinels to of_device_id tablesJamie Iles
The of_device_id tables used for matching should be terminated with empty sentinel values. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Barry Song <baohua.song@csr.com>
2011-09-10ARM: 7088/1: entry: fix wrong parameter name used in do_thumb_abortJanusz Krzysztofik
Commit be020f8618ca, "ARM: entry: abort-macro: specify registers to be used for macros", while replacing register numbers with macro parameter names, mismatched the name used for r1. For me, this resulted in user space built for EABI with -march=armv4t -mtune=arm920t -mthumb-interwork -mthumb broken on my OMAP1510 based Amstrad Delta (old ABI and no thumb still worked for me though). Fix this by using correct parameter name fsr instead of mismatched psr, used by callers for another purpose. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-09-10Merge branches 'cns3xxx/fixes', 'omap/fixes' and 'davinci/fixes' into fixesArnd Bergmann
2011-09-09ARM: cns3xxx: Fix newly introduced warnings in the PCIe codeAnton Vorontsov
commit d5341942d784134f2997b3ff82cd63cf71d1f932 ("PCI: Make the struct pci_dev * argument of pci_fixup_irqs const") did not change argument of pdev_to_cnspci(), and thus introduced the following warnings: CHECK arch/arm/mach-cns3xxx/pcie.c pcie.c:177:60: warning: incorrect type in argument 1 (different modifiers) pcie.c:177:60: expected struct pci_dev *dev pcie.c:177:60: got struct pci_dev const *dev CC arch/arm/mach-cns3xxx/pcie.o pcie.c: In function 'cns3xxx_pcie_map_irq': pcie.c:177: warning: passing argument 1 of 'pdev_to_cnspci' discards qualifiers from pointer target type pcie.c:52: note: expected 'struct pci_dev *' but argument is of type 'const struct pci_dev *' This patch fixes the issue. Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2011-09-09ARM: cns3xxx: Fix compile error caused by hardware.h removedTommy Lin
Commit c9d95fbe59e426eed7f16e7cac812e46ac4772d0 "ARM: convert PCI defines to variables" deleted cns3xxx' hardware.h, but didn't remove references for it, so do it now. This patch removes lines that refer to hardware.h. Signed-off-by: Tommy Lin <tommy.lin.1101@gmail.com> Signed-off-by: Imre Kaloz <kaloz@openwrt.org> Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
2011-09-07ARM: davinci: fix cache flush build errorLinus Walleij
The TNET variant of DaVinci compiles some code that it shares with other DaVinci variants, however it has a V6 CPU rather than an ARM926T, thus the hardcoded call to arm926_flush_kern_cache_all() in sleep.S will obviously fail, and we need to build with the v6_flush_kern_cache_all() call instead. This was triggered by manually altering the DaVinci config to build the TNET version. Cc: Dave Martin <dave.martin@linaro.org> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Cc: stable@kernel.org
2011-09-07ARM: davinci: correct MDSTAT_STATE_MASKSergei Shtylyov
MDSTAT.STATE occupies bits 0..5 according to all available documentation, so fix the #define MDSTAT_STATE_MASK at last. Using the wrong value seems to have been harmless though... Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2011-09-07ARM: davinci: da850 EVM: read mac address from SPI flashRajashekhara, Sudhakar
DA850/OMAP-L138 EMAC driver uses random mac address instead of a fixed one because the mac address is not stuffed into EMAC platform data. This patch provides a function which reads the mac address stored in SPI flash (registered as MTD device) and populates the EMAC platform data. The function which reads the mac address is registered as a callback which gets called upon addition of MTD device. NOTE: In case the MAC address stored in SPI flash is erased, follow the instructions at [1] to restore it. [1] http://processors.wiki.ti.com/index.php/GSG:_OMAP-L138_DVEVM_Additional_Procedures#Restoring_MAC_address_on_SPI_Flash Modifications in v2: Guarded registering the mtd_notifier only when MTD is enabled. Earlier this was handled using mtd_has_partitions() call, but this has been removed in Linux v3.0. Modifications in v3: a. Guarded da850_evm_m25p80_notify_add() function and da850evm_spi_notifier structure with CONFIG_MTD macros. b. Renamed da850_evm_register_mtd_user() function to da850_evm_setup_mac_addr() and removed the struct mtd_notifier argument to this function. c. Passed the da850evm_spi_notifier structure to register_mtd_user() function. Modifications in v4: Moved the da850_evm_setup_mac_addr() function within the first CONFIG_MTD ifdef construct. Signed-off-by: Rajashekhara, Sudhakar <sudhakar.raj@ti.com> Signed-off-by: Sekhar Nori <nsekhar@ti.com> Cc: stable@kernel.org
2011-09-06ARM: 7080/1: l2x0: make sure I&D are not locked down on initLinus Walleij
Fighting unfixed U-Boots and other beasts that may the cache in a locked-down state when starting the kernel, we make sure to disable all cache lock-down when initializing the l2x0 so we are in a known state. Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: Rabin Vincent <rabin.vincent@stericsson.com> Cc: Adrian Bunk <adrian.bunk@movial.com> Cc: Rob Herring <robherring2@gmail.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reported-by: Jan Rinze <janrinze@gmail.com> Tested-by: Robert Marklund <robert.marklund@stericsson.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-09-06ARM: 7081/1: mach-integrator: fix the clocksourceLinus Walleij
I was intrigued by the fact that the clock stood still on the Integrator, but it wasn't strange at all, because the timer was set up all wrong and probably has been for a while. With this patch the clock starts ticking again: make the timer periodic (reload), |= on the divisor bit and load the timer before starting it. Cc: stable@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2011-09-06OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlersKevin Hilman
The suspend/resume _noirq handlers were #ifdef'd out in the !CONFIG_SUSPEND case, but were still assigned to the dev_pm_ops struct. Fix by defining them to NULL in the !CONFIG_SUSPEND case. Reported-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-09-05Merge branches 'non_hwmod_compliant_fix_3.1rc', 'omap3_clock_fixes_3.1rc', ↵Paul Walmsley
'omap4_clock_fixes_3.1rc', 'missing_2430_musb_adds_terminator_fix_3.1rc' and 'pwrdm_clkdm_fixes_3.1rc' into prcm-fixes-a-3.1rc
2011-09-05OMAP2430: hwmod: musb: add missing terminator to omap2430_usbhsotg_addrs[]Paul Walmsley
Add a missing array terminator to omap2430_usbhsotg_addrs[]. Without this terminator, the omap_hwmod resource building code runs off the end of the array, resulting in at least this error -- if not worse behavior: [ 0.578002] musb-omap2430: failed to claim resource 4 [ 0.583465] omap_device: musb-omap2430: build failed (-16) [ 0.589294] Could not build omap_device for musb-omap2430 usb_otg_hs This should have been part of commit 78183f3fdf76f422431a81852468be01b36db325 ("omap_hwmod: use a null structure record to terminate omap_hwmod_addr_space arrays") but was evidently missed. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2011-09-04ARM: 7067/1: mm: keep significant bits in pfn_validMark Rutland
When ARCH_HAS_HOLES_MEMORYMODEL is selected, pfn_valid calls memblock_is_memory to test validity of a pfn: > memblock_is_memory(pfn << PAGE_SHIFT); On LPAE systems this cuts off the top bits, as the shift occurs before the value is promoted to a phys_addr_t. This patch replaces the shift with a call to __pfn_to_phys (which casts pfn to phys_addr_t before shifting), preventing the loss of significant bits. Signed-off-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>