summaryrefslogtreecommitdiffstats
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* ARM: OMAP: dmtimer: platform driverTarun Kanti DebBarma2011-09-222-6/+135
| | | | | | | | | | | | | Add dmtimer platform driver functions which include: (1) platform driver initialization (2) driver probe function (3) driver remove function Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Thara Gopinath <thara@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: dmtimer: convert to platform devicesTarun Kanti DebBarma2011-09-226-1/+240
| | | | | | | | | | | | | | Add routines to converts dmtimers to platform devices. The device data is obtained from hwmod database of respective platform and is registered to device model after successful binding to driver. In addition, capability attribute of each of the timers is added in hwmod database. Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Thara Gopinath <thara@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP1: dmtimer: conversion to platform devicesTarun Kanti DebBarma2011-09-224-45/+194
| | | | | | | | | | | Convert OMAP1 dmtimers into a platform devices and then registers with device model framework so that it can be bound to corresponding driver. Signed-off-by: Thara Gopinath <thara@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP2+: dmtimer: add device names to flck nodesTarun Kanti DebBarma2011-09-224-0/+165
| | | | | | | | | | | | | Add device name to OMAP2 dmtimer fclk nodes so that the fclk nodes can be retrieved by doing a clk_get with the corresponding device pointers or device names. Reviewed-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com> Signed-off-by: Thara Gopinath <thara@ti.com> Acked-by: Cousson, Benoit <b-cousson@ti.com> [tony@atomide.com: fixed typo in email address] Signed-off-by: Tony Lindgren <tony@atomide.com>
* ARM: OMAP: Add support for dmtimer v2 ipTony Lindgren2011-09-193-76/+123
| | | | | | | | | | | | | | | | The registers are slightly different between v1 and v2 ip that is available in omap4 and later for some timers. Add support for v2 ip by mapping the interrupt related registers separately and adding func_base for the functional registers. Also disable dmtimer driver features on omap4 for now as those need the hwmod conversion series to deal with enabling the timers properly in omap_dm_timer_init. Signed-off-by: Afzal Mohammed <afzal@ti.com> Tested-by: Hemant Pedanekar <hemantp@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
* Merge branch 'omap_chip_remove_cleanup_3.2' of git://git.pwsan.com/linux-2.6 ↵Tony Lindgren2011-09-1684-2097/+1825Star
|\ | | | | | | into cleanup
| * OMAP: id: remove OMAP_CHIP declarations, codePaul Walmsley2011-09-153-119/+0Star
| | | | | | | | | | | | | | | | | | | | 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>
| * OMAP2+: hwmod: remove OMAP_CHIP*Paul Walmsley2011-09-156-253/+85Star
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAP: powerdomain: remove omap_chip bitmasksPaul Walmsley2011-09-158-96/+79Star
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAP: powerdomain: split pwrdm_init() into two functionsPaul Walmsley2011-09-155-26/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAP: clockdomain code/data: remove omap_chip bitmask from struct clockdomainPaul Walmsley2011-09-1511-1156/+842Star
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAP: clockdomain: split clkdm_init()Paul Walmsley2011-09-154-34/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAP2+: id: remove OMAP_REVBITS_* macrosPaul Walmsley2011-09-141-23/+10Star
| | | | | | | | | | | | | | | | | | 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>
| * OMAP3: id: remove duplicate code for testing SoC ES levelPaul Walmsley2011-09-141-57/+23Star
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAP3: id: add fallthrough warning; fix some CodingStyle issuesPaul Walmsley2011-09-141-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAP3: id: use explicit omap_revision codes for 3505/3517 ES levelsPaul Walmsley2011-09-142-2/+11
| | | | | | | | | | | | | | | | | | | | | | 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>
| * OMAP3: id: remove useless strcpy()sPaul Walmsley2011-09-141-26/+22Star
| | | | | | | | | | | | | | | | | | 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>
| * OMAP3: id: remove identification codes that only correspond to marketing namesPaul Walmsley2011-09-143-22/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| *-----. Merge branches 'non_hwmod_compliant_fix_3.1rc', 'omap3_clock_fixes_3.1rc', ↵Paul Walmsley2011-09-0565-332/+582
| |\ \ \ \ | | | | | | | | | | | | | | | | | | '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
| | | | | * OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain ↵Santosh Shilimkar2011-08-202-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | force wakeup While using clockdomain force wakeup method, not waiting for powerdomain to be effectively ON may end up locking the clockdomain FSM until a next wakeup event occurs. One such issue was seen on OMAP4430, where L4_PER was periodically getting stuck in in-transition state when transitioning from from OSWR to ON. This issue was reported and investigated by Patrick Titiano <p-titiano@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Reported-by: Patrick Titiano <p-titiano@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> [paul@pwsan.com: updated to apply; added transition wait on clkdm_deny_idle(); remove two superfluous pwrdm_wait_transition() calls] Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | | | | * OMAP: powerdomains: Make all powerdomain target states as ON at initRajendra Nayak2011-08-201-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Program all powerdomain target state as ON; this is to prevent domains from hitting low power states (if bootloader has target states set to something other than ON) and potentially even losing context while PM is not fully initialized, which can cause the system to crash. The PM late init code can then program the desired target state for all the power domains. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [paul@pwsan.com: dropped comment typo hunk; fixed comment indent and moved to kerneldoc; moved code to pwrdm_init(); changed pwrdm_init() argument name to prevent clash; cleaned up patch description] Signed-off-by: Paul Walmsley <paul@pwsan.com>
| | | | * | OMAP2430: hwmod: musb: add missing terminator to omap2430_usbhsotg_addrs[]Paul Walmsley2011-09-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| | | | * | Merge branch 'pm-fixes' of ↵Linus Torvalds2011-08-284-1/+6
| | | | |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm * 'pm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2 (incremental) OMAP: omap_device: only override _noirq methods, not normal suspend/resume PM / Runtime: Correct documentation of pm_runtime_irq_safe() ARM: mach-shmobile: sh7372 LCDC1 suspend fix sh-sci / PM: Use power.irq_safe PM: Use spinlock instead of mutex in clock management functions
| | | | | * | ARM: mach-shmobile: sh7372 LCDC1 suspend fix V2 (incremental)Magnus Damm2011-08-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch updates the recently submitted "Associate the HDMI clock together with LCDC1 on sh7372" to V2 with the following change: - Use lcdc1_device on AP4EVB to build properly. Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
| | | | | * | OMAP: omap_device: only override _noirq methods, not normal suspend/resumeKevin Hilman2011-08-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit c03f007a8bf0e092caeb6856a5c8a850df10b974 (OMAP: PM: omap_device: add system PM methods for PM domain handling) mistakenly used SET_SYSTEM_SLEEP_PM_OPS() when trying to configure custom methods for the PM domains noirq methods. Fix that by setting only the suspend_noirq and resume_noirq methods with custom versions. Note that all other PM domain methods (including the "normal" suspend/resume methods) are populated using USE_PLATFORM_PM_SLEEP_OPS, which configures them all to the default subsystem (platform_bus) methods. Reported-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
| | | | | * | ARM: mach-shmobile: sh7372 LCDC1 suspend fixMagnus Damm2011-08-243-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Associate the HDMI clock together with LCDC1 on sh7372. Without this patch Suspend-to-RAM hangs on the boards AP4EVB and Mackerel. The code hangs in the LCDC driver where the software is waiting forever for the hardware to power down. By explicitly associating the HDMI clock with LCDC1 we can make sure the HDMI clock is enabled using Runtime PM whenever the driver is accessing the hardware. This HDMI and LCDC1 dependency is documented in the sh7372 data sheet. Older kernels did work as expected but the recently merged (3.1-rc) 794d78f drivers: sh: late disabling of clocks V2 introduced code to turn off clocks lacking software reference which happens to include the HDMI clock that is needed by LCDC1 to operate as expected. Signed-off-by: Magnus Damm <damm@opensource.se> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
| | | | * | | All Arch: remove linkage for sys_nfsservctl system callNeilBrown2011-08-2728-33/+26Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The nfsservctl system call is now gone, so we should remove all linkage for it. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | | | * | | Merge branch 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6Linus Torvalds2011-08-262-9/+12
| | | | |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6: [S390] memory hotplug: only unassign assigned increments [S390] Change default action from reipl to stop for on_restart [S390] arch/s390/kernel/ipl.c: correct error detection check [S390] drivers/s390/block/dasd_ioctl.c: add missing kfree [S390] nss,initrd: kernel image and initrd must be in different segments
| | | | | * | | [S390] Change default action from reipl to stop for on_restartMichael Holzheu2011-08-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main purpose for PSW restart will be kdump. Therefore customers will issue "system restart" for creating a dump. If kdump is not enabled, currently "PSW restart" will reboot the system and then no dump can be created any more. In order to still allow a manual stand-alone dump in the case a user issues "PSW restart" on a system that has not enabled kdump we now stop the system. Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| | | | | * | | [S390] arch/s390/kernel/ipl.c: correct error detection checkJulia Lawall2011-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reipl_fcp_kset was just initialized, so it appears that it should be tested instead of reipl_kset. Signed-off-by: Julia Lawall <julia@diku.dk> Reported-by: Suman Saha <sumsaha@gmail.com> Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| | | | | * | | [S390] nss,initrd: kernel image and initrd must be in different segmentsHeiko Carstens2011-08-241-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When IPL'ing from a block device and an NSS should be created we must make sure that the kernel image and the initrd are in different 1MB segments. Otherwise creating the NSS will fail. So we make sure the initrd is 4MB behind the end of the kernel image like we do already when IPL via the VM reader is performed. Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com> Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
| | | | * | | | sfi: table irq 0xFF means 'no interrupt'Kirill A. Shutemov2011-08-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to the SFI specification irq number 0xFF means device has no interrupt or interrupt attached via GPIO. Currently, we don't handle this special case and set irq field in *_board_info structs to 255. It leads to confusion in some drivers. Accelerometer driver tries to register interrupt 255, fails and prints "Cannot get IRQ" to dmesg. Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | | | * | | | arch/powerpc/sysdev/fsl_rio.c: correct IECSR register clear valueLiu Gang-B341822011-08-261-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug causes the IECSR register clear failure. In this case, the RETE (retry error threshold exceeded) interrupt will be generated and cannot be cleared. So the related ISR may be called persistently. The RETE bit in IECSR is cleared by writing a 1 to it. Signed-off-by: Liu Gang <Gang.Liu@freescale.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Kumar Gala <galak@kernel.crashing.org> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | | | * | | | cris: add arch/cris/include/asm/serial.hWANG Cong2011-08-261-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following build errors: drivers/tty/serial/8250_early.c:160: error: 'BASE_BAUD' undeclared (first use in this function): 1 errors in 1 logs drivers/tty/serial/8250_early.c:37:24: error: asm/serial.h: No such file or directory: 1 errors in 1 logs I am not sure if (1843200 / 16) is suitable for cris, but most other arch's define it as this value. Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | | | * | | | alpha: unbreak osf_setsysinfo(SSI_NVPAIRS, [SSIN_UACPROC, UAC_SIGBUS])Sergei Trofimovich2011-08-263-18/+11Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug was accidentally found by the following program: #include <asm/sysinfo.h> #include <asm/unistd.h> #include <sys/syscall.h> static int setsysinfo(unsigned long op, void *buffer, unsigned long size, int *start, void *arg, unsigned long flag) { return syscall(__NR_osf_setsysinfo, op, buffer, size, start, arg, flag); } int main(int argc, char **argv) { short x[10]; unsigned int buf[2] = { SSIN_UACPROC, UAC_SIGBUS, }; setsysinfo(SSI_NVPAIRS, buf, 1, 0, 0, 0); int *y = (int*) (x+1); *y = 0; return 0; } The program shoud fail on SIGBUS, but didn't. The patch is a second part of userspace flag fix (commit 745dd2405e28 "Alpha: Rearrange thread info flags fixing two regressions"). Deleted outdated out-of-sync 'UAC_SHIFT' (the cause of bug) in favour of 'ALPHA_UAC_SHIFT'. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Acked-by: Michael Cree <mcree@orcon.net.nz> Cc: Richard Henderson <rth@twiddle.net> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Matt Turner <mattst88@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | | | * | | | x86-32: Fix boot with CONFIG_X86_INVD_BUGAndy Lutomirski2011-08-251-6/+2Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | entry_32.S contained a hardcoded alternative instruction entry, and the format changed in commit 59e97e4d6fbc ("x86: Make alternative instruction pointers relative"). Replace the hardcoded entry with the altinstruction_entry macro. This fixes the 32-bit boot with CONFIG_X86_INVD_BUG=y. Reported-and-tested-by: Arnaud Lacombe <lacombar@gmail.com> Signed-off-by: Andy Lutomirski <luto@mit.edu> Cc: Peter Anvin <hpa@zytor.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | | | * | | | mtrr: fix UP breakage caused during switch to stop_machineTejun Heo2011-08-251-2/+0Star
| | | | | |/ / | | | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While removing custom rendezvous code and switching to stop_machine, commit 192d8857427d ("x86, mtrr: use stop_machine APIs for doing MTRR rendezvous") completely dropped mtrr setting code on !CONFIG_SMP breaking MTRR settting on UP. Fix it by removing the incorrect CONFIG_SMP. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Anders Eriksson <aeriksson@fastmail.fm> Tested-and-acked-by: Suresh Siddha <suresh.b.siddha@intel.com> Acked-by: H. Peter Anvin <hpa@zytor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | | | * | | Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds2011-08-248-233/+468
| | | | |\ \ \ | | | | | |/ / | | | | |/| | | | | | | | | | | | | | | | * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sparc: Allow handling signals when stack is corrupted.
| | | | | * | sparc: Allow handling signals when stack is corrupted.David S. Miller2011-08-218-233/+468
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we can't push the pending register windows onto the user's stack, we disallow signal delivery even if the signal would be delivered on a valid seperate signal stack. Add a register window save area in the signal frame, and store any unsavable windows there. On sigreturn, if any windows are still queued up in the signal frame, try to push them back onto the stack and if that fails we kill the process immediately. This allows the debug/tst-longjmp_chk2 glibc test case to pass. Signed-off-by: David S. Miller <davem@davemloft.net>
| | | | * | | Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds2011-08-243-4/+3Star
| | | | |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip: x86-32, vdso: On system call restart after SYSENTER, use int $0x80 x86, UV: Remove UV delay in starting slave cpus x86, olpc: Wait for last byte of EC command to be accepted
| | | | | * | | x86-32, vdso: On system call restart after SYSENTER, use int $0x80H. Peter Anvin2011-08-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we enter a 32-bit system call via SYSENTER or SYSCALL, we shuffle the arguments to match the int $0x80 calling convention. This was probably a design mistake, but it's what it is now. This causes errors if the system call as to be restarted. For SYSENTER, we have to invoke the instruction from the vdso as the return address is hardcoded. Accordingly, we can simply replace the jump in the vdso with an int $0x80 instruction and use the slower entry point for a post-restart. Suggested-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/CA%2B55aFztZ=r5wa0x26KJQxvZOaQq8s2v3u50wCyJcA-Sc4g8gQ@mail.gmail.com Cc: <stable@kernel.org>
| | | | | * | | x86, UV: Remove UV delay in starting slave cpusJack Steiner2011-08-051-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Delete the 10 msec delay between the INIT and SIPI when starting slave cpus. I can find no requirement for this delay. BIOS also has similar code sequences without the delay. Removing the delay reduces boot time by 40 sec. Every bit helps. Signed-off-by: Jack Steiner <steiner@sgi.com> Cc: <stable@kernel.org> Link: http://lkml.kernel.org/r/20110805140900.GA6774@sgi.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
| | | | | * | | x86, olpc: Wait for last byte of EC command to be acceptedPaul Fox2011-08-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When executing EC commands, only waiting when there are still more bytes to write is usually fine. However, if the system suspends very quickly after a call to olpc_ec_cmd(), the last data byte may not yet be transferred to the EC, and the command will not complete. This solves a bug where the SCI wakeup mask was not correctly written when going into suspend. It means that sometimes, on XO-1.5 (but not XO-1), the devices that were marked as wakeup sources can't wake up the system. e.g. you ask for wifi wakeups, suspend, but then incoming wifi frames don't wake up the system as they should. Signed-off-by: Paul Fox <pgf@laptop.org> Signed-off-by: Daniel Drake <dsd@laptop.org> Acked-by: Andres Salomon <dilinger@queued.net> Cc: <stable@kernel.org> Signed-off-by: Ingo Molnar <mingo@elte.hu>
| | | | * | | | m68k: fix __page_to_pfn for a const struct page argumentIan Campbell2011-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes fallout due to the removal of the cast in commit aa462abe8aaf ("mm: fix __page_to_pfn for a const struct page argument") Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Cc: Andrew Morton <akpm@linux-foundation.org> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-m68k@lists.linux-m68k.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
| | | * | | | | OMAP4: clock: fix compile warningPaul Walmsley2011-08-211-0/+2
| | | | |_|_|/ | | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix the following compile warning: arch/arm/mach-omap2/clock44xx_data.c: In function 'omap4xxx_clk_init': arch/arm/mach-omap2/clock44xx_data.c:3371:6: warning: 'cpu_clkflg' may be used uninitialized in this function The approach taken here is intended to work if omap4xxx_clk_init() is converted into an initcall. Thanks to Bjarne Steinsbo <bsteinsbo@gmail.com> for proposing another approach. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Bjarne Steinsbo <bsteinsbo@gmail.com>
| | * | | | | OMAP3: clock: indicate that gpt12_fck and wdt1_fck are in the WKUP clockdomainPaul Walmsley2011-08-231-0/+2
| | | |/ / / | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The oscillator that supplies GPT12_FCLK and WDT1_FCLK exists in the WKUP powerdomain[1]. This resolves at least one boot-time warning: omap_hwmod: gpt12_fck: missing clockdomain for gpt12_fck. 1. _OMAP34xx Multimedia High Security (HS) Device Silicon Revision 3.1.x Security Addendum Version K (SWPU119K)_ Figure 3-29. August 2010.
| * | | | | OMAP4: clock: re-enable previous clockdomain enable/disable sequencePaul Walmsley2011-08-201-1/+7
| | |/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After commit 665d001338b494d6d62810aa99b4c0fa1a0884b9 ("OMAP2+: hwmod: Follow the recommended PRCM module enable sequence"), device drivers for OMAP IP blocks that do not use runtime PM can cause oopses or kernel instability[1][2]. This is because those non-runtime PM drivers do not use the hwmod code, which implements the correct IP block enable and disable sequence. Several options for dealing with this problem have been proposed: 1. Add a new field to the OMAP struct clk to mark clocks that are currently used by non-runtime PM drivers. Modify the clock code to use the old clockdomain sequence for these marked clocks. As drivers are converted to use runtime PM, remove the annotation from the clocks. 2. Similar to #1, but associate the flag with the struct omap_clk instead. 3. Add IDLEST wait support to the OMAP4 clock code, similar to the way it is implemented for OMAP2/3, and enable it in each struct clk currently used by non-runtime PM drivers. As drivers are converted to use runtime PM, remove the annotation from the clocks. 4. Do nothing; leave the problem to those responsible for the unconverted drivers. 5. Re-enable clock-based clockdomain control in the OMAP4 clock code. This would revert back to the behavior of Linux 3.0, simply with a slightly longer module enable/disable latency. Unfortunately, no approach seemed particularly good. Options 1 through 3 seemed unwise due to the following reasons: A. The OMAP struct clks are intended primarily to describe hardware clock nodes, and the intention is that no driver-specific data should be stored there (applies to #1) B. The resulting patch would have been quite large for the -rc series (applies to #1, #2, #3) C. The patch would have been a new, yet temporary hack; and similar fixes have drawn negative comments in the recent past (see for example [3]) Option 4 is undesirable because commit 665d001338b494d6d62810aa99b4c0fa1a0884b9 ("OMAP2+: hwmod: Follow the recommended PRCM module enable sequence") has resulted in a less stable kernel; and kernel stability is more important than OMAP4 power management. Option 5 is the approach taken in this patch. This seemed to be the least intrusive approach for 3.1-rc. The approach in this patch was originally proposed by Ohad Ben-Cohen <ohad@wizery.com>. I'm simply writing the commit message and passing it along. ... Thanks to Luciano Coelho <coelho@ti.com> for reporting the problem. Thanks to Ohad Ben-Cohen <ohad@wizery.com> for tracking the problem down, generating a temporary workaround, and proposing a patch to deal with the problem. Thanks to Rajendra Nayak <rnayak@ti.com> for proposing another patch to deal with the problem. Thanks to Felipe Balbi <balbi@ti.com> for comments. 1. Coelho, Luciano <coelho@ti.com>. _Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda_. Tue, 09 Aug 2011 14:26:08 +0300. Posted to the <linux-omap@vger.kernel.org> mailing list. Available from (among others) http://www.spinics.net/linux/lists/linux-omap/msg55213.html 2. Munegowda, Keshava <keshava_mgowda@ti.com>. _Re: Oops on ehci_hcd when booting 3.0.0-rc2 on panda_. Thu, 11 Aug 2011 13:51:05 +0530. Posted to the <linux-omap@vger.kernel.org> mailing list. Available from (among others) http://www.spinics.net/linux/lists/linux-omap/msg55371.html 3. King, Russell <linux@arm.linux.org.uk>. _Re: [PATCH 5/8] OMAP4: PM: TEMP: Prevent l3init from idling/force sleep_. Thu, 23 Jun 2011 16:22:49 +0100. Posted to the <linux-omap@vger.kernel.org> mailing list. Available from (among others) http://www.mail-archive.com/linux-omap@vger.kernel.org/msg51392.html Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Luciano Coelho <coelho@ti.com> Cc: Ohad Ben-Cohen <ohad@wizery.com> Cc: Rajendra Nayak <rnayak@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
* | | | | ARM: OMAP: Introduce SoC specific early_initTony Lindgren2011-08-2427-156/+80Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce them for each omap variant and just make them all call omap2_init_common_infrastructure for now. Do this for each board-*.c file except for board-generic and board-omap3beagle as they use the same machine ID for multiple SoCs. No functional changes. Signed-off-by: Tony Lindgren <tony@atomide.com>
* | | | | ARM: OMAP: Move omap2_init_common_devices out of init_earlyTony Lindgren2011-08-2429-49/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's no need to call omap2_init_common_devices from init_early. It no longer does anything else except reprogram the memory timings for some boards, so it's better to do it later so we have a chance to get console messages if something goes wrong. Move it to happen after omap_serial_init gets called. And while patching it anyways, rename it to omap_sdrc_init as suggested by Benoit Cousson <b-cousson@ti.com>. Signed-off-by: Tony Lindgren <tony@atomide.com>
* | | | | omap2+: Use Kconfig symbol in Makefile instead of obj-yTony Lindgren2011-08-231-44/+32Star
| |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted by Grant Likely <grant.likely@secretlab.ca>, omap2+ Makefile unnecessarily repeats entries for common device init code instead of using Kconfig symbol. Remove references to hsmmc.o and board-flash.o. Also omap_phy_internal.o references can be removed once it has some Kconfig symbol to use. Signed-off-by: Tony Lindgren <tony@atomide.com>