summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2011-12-09ia64: pcibr: Use kmemdup rather than duplicating its implementationThomas Meyer
The semantic patch that makes this change is available in scripts/coccinelle/api/memdup.cocci. Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-12-09ia64: sn: Use kmemdup rather than duplicating its implementationThomas Meyer
The semantic patch that makes this change is available in scripts/coccinelle/api/memdup.cocci. Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-12-09ia64: tioca: Use kmemdup rather than duplicating its implementationThomas Meyer
The semantic patch that makes this change is available in scripts/coccinelle/api/memdup.cocci. Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-12-09[IA64] Merge overlapping reserved regions at bootPetr Tesarik
While working on the upcoming SLES11 SP2, I ran into an issue with booting the panic kernel on a kernel crash. In the first iteration I found out that the initial register backing store gets overwritten with zeroes, causing a kernel crash shortly afterwards. Further investigation revealed that rsvd_region[] contains overlapping entries: find_memmap_space() returns a pointer which lies between KERNEL_START and _end. This is correct with the EFI memmap as patched by the kexec purgatory code. That code removes vmlinux LOAD segments from the usable map, but there is a pretty large hole between the gate section and the per-cpu section. This happens because reserve_memory() blindly marks [KERNEL_START, __end] as reserved, even though there is a free block in the middle in the kexec case because it noticed a large gap between sections and modified the efi_memory_map to account for this. Signed-off-by: Petr Tesarik <ptesarik@suse.cz> Signed-off-by: Tony Luck <tony.luck@intel.com>
2011-12-09Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86, efi: Calling __pa() with an ioremap()ed address is invalid x86, hpet: Immediately disable HPET timer 1 if rtc irq is masked x86/intel_mid: Kconfig select fix x86/intel_mid: Fix the Kconfig for MID selection
2011-12-09ARM: S3C64XX: Implement basic power domain supportMark Brown
The S3C64xx SoCs contain a set of gateable power domains which can be enabled and disabled at runtime in order to save power. Use the generic power domain code to implement support for these in software, enabling runtime control of most domains: - ETM (not supported in mainline). - Domain G: 3D acceleration (no mainline support). - Domain V: MFC (no mainline support). - Domain I: JPEG and camera interface (no mainline support). - Domain P: 2D acceleration, TV encoder and scaler (no mainline support) - Domain S: Security (no mainline support). - Domain F: LCD (driver already uses runtime PM), post processing and rotation (no mainline support). The IROM domain is marked as always enabled as we should arrange for it to be enabled when we suspend which will need a bit more work. Due to all the conditional device registration that the platform does wrap s3c_pm_init() with s3c64xx_pm_init() which actually puts the device into the power domain after the machines have registered, looking for platform data to tell if the device was registered. Since currently only Cragganmore actually sets up PM that is the only machine updated. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09PM / shmobile: Use common always on power domain governorMark Brown
Saves a tiny amount of code. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by: Magnus Damm <damm@opensource.se> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-12-09ARM: OMAP2+: DMA: Workaround for invalid destination positionPeter Ujfalusi
If the DMA destination position has been asked before the first actual data transfer has been done, the CDAC register still contains 0 (it is initialized to 0 at omsp_dma_start). If CDAC == 0, return the programmed start address. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09ARM: OMAP2+: DMA: Workaround for invalid source positionPeter Ujfalusi
If the DMA source position has been asked before the first actual data transfer has been done, the CSAC register does not contain valid information. We can identify this situation by checking the CDAC register: CDAC != 0 indicates that the DMA transfer on the channel has been started already. When CDAC == 0 we can not trust the CSAC value since it has not been updated, and can contain random number. Return the start address in case the DMA has not jet started. Note: The CDAC register has been initialized to 0 at dma_start time. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Jarkko Nikula <jarkko.nikula@bitmer.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09ARM: OMAP: hsmmc: Add support for AM3517EVM base-board MMC slotVaibhav Hiremath
Add support for base-board MMC slot Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Abhilash K V <abhilash.kv@ti.com> [tony@atomide.com: updated subject] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09ARM: OMAP: hsmmc: Support for AM3517 MMC1 voltagesAbhilash K V
This patch fixes the following error message which appears while intializing MMC1 on the AM3517 EVM base-board: mmc0: host doesn't support card's voltages mmc0: error -22 whilst initialising SD card The ocr_mask, which enumerates the volatges supported by the MMC card was not being indicated before, assuming that a separate Vcc regulator maybe another controllable regulator driver would be doing this. This patch statically specifies a subset of the voltages supported by the MMC driver, which are provided by the current fixed voltage regulator on AM3517 EVM. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Abhilash K V <abhilash.kv@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09ARM: OMAP: hsmmc: Add support for non-OMAP pinsThomas Weber
The Devkit8000 uses a TWL4030 pin for card detection. Thats why the error: _omap_mux_init_gpio: Could not set gpio192 occurs. This patch checks that the pin is on OMAP before calling omap_mux_init_gpio. Signed-off-by: Thomas Weber <weber@corscience.de> [tony@atomide.com: updated comments] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09ARM: OMAP: hsmmc: Add support for MMC 2 setup for AM35xIgor Grinberg
AM35x MMC 2 controller has internal clock loopback setting which cannot be utilized without this patch and thus SDIO devices connected to this controller and depend on this setting will fail to initialize. Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> [tony@atomide.com: updated comments] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09ARM: OMAP: hsmmc: board-sdp4430: declare support for MMC_PM_KEEP_POWEREliad Peller
Declare support for keeping the power of the wlan chip while suspended. this is needed for Wakeup-On-Wireless. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09x86, um: Fix typo in 32-bit system call modificationsH. Peter Anvin
We override sys_iopl(), not stub_iopl(); the latter is a 64-bitism that doesn't apply to i386 in the first place. Reported-by: Richard Weinberger <richard@nod.at> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2011-12-09um: Use $(srctree) not $(KBUILD_SRC)H. Peter Anvin
$(KBUILD_SRC) is not defined without O=, use $(srctree). Reported-and-tested-by: Richard Weinberger <richard@nod.at> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2011-12-09Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tileLinus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: arch/tile: use new generic {enable,disable}_percpu_irq() routines drivers/net/ethernet/tile: use skb_frag_page() API asm-generic/unistd.h: support new process_vm_{readv,write} syscalls arch/tile: fix double-free bug in homecache_free_pages() arch/tile: add a few #includes and an EXPORT to catch up with kernel changes.
2011-12-09Merge branch 'iommu/fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu * 'iommu/fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: MAINTAINERS: Update amd-iommu F: patterns iommu/amd: Fix typo in kernel-parameters.txt iommu/msm: Fix compile error in mach-msm/devices-iommu.c Fix comparison using wrong pointer variable in dma debug code
2011-12-09thp: add compound tail page _mapcount when mappedYouquan Song
With the 3.2-rc kernel, IOMMU 2M pages in KVM works. But when I tried to use IOMMU 1GB pages in KVM, I encountered an oops and the 1GB page failed to be used. The root cause is that 1GB page allocation calls gup_huge_pud() while 2M page calls gup_huge_pmd. If compound pages are used and the page is a tail page, gup_huge_pmd() increases _mapcount to record tail page are mapped while gup_huge_pud does not do that. So when the mapped page is relesed, it will result in kernel oops because the page is not marked mapped. This patch add tail process for compound page in 1GB huge page which keeps the same process as 2M page. Reproduce like: 1. Add grub boot option: hugepagesz=1G hugepages=8 2. mount -t hugetlbfs -o pagesize=1G hugetlbfs /dev/hugepages 3. qemu-kvm -m 2048 -hda os-kvm.img -cpu kvm64 -smp 4 -mem-path /dev/hugepages -net none -device pci-assign,host=07:00.1 kernel BUG at mm/swap.c:114! invalid opcode: 0000 [#1] SMP Call Trace: put_page+0x15/0x37 kvm_release_pfn_clean+0x31/0x36 kvm_iommu_put_pages+0x94/0xb1 kvm_iommu_unmap_memslots+0x80/0xb6 kvm_assign_device+0xba/0x117 kvm_vm_ioctl_assigned_device+0x301/0xa47 kvm_vm_ioctl+0x36c/0x3a2 do_vfs_ioctl+0x49e/0x4e4 sys_ioctl+0x5a/0x7c system_call_fastpath+0x16/0x1b RIP put_compound_page+0xd4/0x168 Signed-off-by: Youquan Song <youquan.song@intel.com> Reviewed-by: Andrea Arcangeli <aarcange@redhat.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-12-09typo fixes: aera -> area, exntension -> extensionWang YanQing
One printk and one comment typo fix. Signed-off-by: Wang YanQing <udknight@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-12-09powerpc/47x: Add support for the new IBM currituck platformTony Breeds
Based on original work by David 'Shaggy' Kleikamp. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-09powerpc/476fpe: Add 476fpe SoC codeTony Breeds
Based on original work by David 'Shaggy' Kleikamp. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-09powerpc/boot: Add mfdcrxTony Breeds
Needed for currituck support. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-09powerpc/boot: Add extended precision shifts to the boot wrapper.Tony Breeds
The upcomming currituck patches will need to do 64-bit shifts which will fail with undefined symbol without this patch. I looked at linking against libgcc but we can't guarantee that libgcc was compiled with soft-float. Also Using ../lib/div64.S or ../kernel/misc_32.S, this will break the build as the .o's need to be built with different flags for the bootwrapper vs the kernel. So for now the easyest option is to just copy code from arch/powerpc/kernel/misc_32.S I don't think this code changes too often ;P Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-09powerpc/44x: Removing dead CONFIG_PPC47xChristoph Egger
CONFIG_PPC47x doesn't exist in Kconfig and no 476 processor calls this function ppc44x_pin_tlb() as it has it's own ppc47x_pin_tlb(). This code is probably an artifact of the original 476 code that shouldn't have made it upstream. Signed-off-by: Christoph Egger <siccegge@cs.fau.de> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-09powerpc/44x: pci: Setup the dma_window properties for each pci_controllerTony Breeds
Needed if you want to use swiotlb, harmless otherwise. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-09powerpc/44x: pci: Add a want_sdr flag into ppc4xx_pciex_hwopsTony Breeds
Currituck doesn't need nor use SDR so aborting the pci setup if there is no sdr-base would be bad. Add a flag to ppc4xx_pciex_hwops for the backends to state if they need SDR and then only complain and abort if they do and it's not found in the device tree. Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-09powerpc/44x: pci: Use PCI_BASE_ADDRESS_MEM_PREFETCH rather than magic value.Tony Breeds
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com> Signed-off-by: Josh Boyer <jwboyer@gmail.com>
2011-12-09arm/imx: fix power button on imx51 babbage boardShawn Guo
Since commit 6571534 (plat-mxc: iomux-v3.h: implicitly enable pull-up/down when that's desired) was in, the power button on imx51 babbage board stopped working because it's pulled up by mistake. The patch removes the pull-up setting from the pad configuration for that gpio to make the power button back to work. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2011-12-09ARM: imx: fix cpufreq build errorsRichard Zhao
CC arch/arm/plat-mxc/cpufreq.o arch/arm/plat-mxc/cpufreq.c:203: error: expected declaration specifiers or '...' before string constant arch/arm/plat-mxc/cpufreq.c:203: warning: data definition has no type or storage class arch/arm/plat-mxc/cpufreq.c:203: warning: type defaults to 'int' in declaration of 'MODULE_AUTHOR' arch/arm/plat-mxc/cpufreq.c:203: warning: function declaration isn't a prototype arch/arm/plat-mxc/cpufreq.c:204: error: expected declaration specifiers or '...' before string constant arch/arm/plat-mxc/cpufreq.c:204: warning: data definition has no type or storage class arch/arm/plat-mxc/cpufreq.c:204: warning: type defaults to 'int' in declaration of 'MODULE_DESCRIPTION' arch/arm/plat-mxc/cpufreq.c:204: warning: function declaration isn't a prototype arch/arm/plat-mxc/cpufreq.c:205: error: expected declaration specifiers or '...' before string constant arch/arm/plat-mxc/cpufreq.c:205: warning: data definition has no type or storage class arch/arm/plat-mxc/cpufreq.c:205: warning: type defaults to 'int' in declaration of 'MODULE_LICENSE' arch/arm/plat-mxc/cpufreq.c:205: warning: function declaration isn't a prototype make[1]: *** [arch/arm/plat-mxc/cpufreq.o] Error 1 make: *** [arch/arm/plat-mxc] Error 2 Signed-off-by: Richard Zhao <richard.zhao@freescale.com> Signed-off-by: Richard Zhao <richard.zhao@linaro.org> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2011-12-09ARM: mx5: add __initconst for fec pdataDong Aisheng
Signed-off-by: Dong Aisheng <b29396@freescale.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2011-12-09MXC PWM: should active during DOZE/WAIT/DBG modeJason Chen
Signed-off-by: Jason Chen <jason.chen@linaro.org> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Cc: stable@kernel.org
2011-12-09Merge branches 'common/clkfwk', 'common/pfc' and 'common/serial-rework' into ↵Paul Mundt
sh-latest
2011-12-09x86, efi: Calling __pa() with an ioremap()ed address is invalidMatt Fleming
If we encounter an efi_memory_desc_t without EFI_MEMORY_WB set in ->attribute we currently call set_memory_uc(), which in turn calls __pa() on a potentially ioremap'd address. On CONFIG_X86_32 this is invalid, resulting in the following oops on some machines: BUG: unable to handle kernel paging request at f7f22280 IP: [<c10257b9>] reserve_ram_pages_type+0x89/0x210 [...] Call Trace: [<c104f8ca>] ? page_is_ram+0x1a/0x40 [<c1025aff>] reserve_memtype+0xdf/0x2f0 [<c1024dc9>] set_memory_uc+0x49/0xa0 [<c19334d0>] efi_enter_virtual_mode+0x1c2/0x3aa [<c19216d4>] start_kernel+0x291/0x2f2 [<c19211c7>] ? loglevel+0x1b/0x1b [<c19210bf>] i386_start_kernel+0xbf/0xc8 A better approach to this problem is to map the memory region with the correct attributes from the start, instead of modifying it after the fact. The uncached case can be handled by ioremap_nocache() and the cached by ioremap_cache(). Despite first impressions, it's not possible to use ioremap_cache() to map all cached memory regions on CONFIG_X86_64 because EFI_RUNTIME_SERVICES_DATA regions really don't like being mapped into the vmalloc space, as detailed in the following bug report, https://bugzilla.redhat.com/show_bug.cgi?id=748516 Therefore, we need to ensure that any EFI_RUNTIME_SERVICES_DATA regions are covered by the direct kernel mapping table on CONFIG_X86_64. To accomplish this we now map E820_RESERVED_EFI regions via the direct kernel mapping with the initial call to init_memory_mapping() in setup_arch(), whereas previously these regions wouldn't be mapped if they were after the last E820_RAM region until efi_ioremap() was called. Doing it this way allows us to delete efi_ioremap() completely. Signed-off-by: Matt Fleming <matt.fleming@intel.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Zhang Rui <rui.zhang@intel.com> Cc: Huang Ying <huang.ying.caritas@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console-pimps.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-09x86/numa: Add constraints check for nid parametersPetr Holasek
This patch adds constraint checks to the numa_set_distance() function. When the check triggers (this should not happen normally) it emits a warning and avoids a store to a negative index in numa_distance[] array - i.e. avoids memory corruption. Negative ids can be passed when the pxm-to-nids mapping is not properly filled while parsing the SRAT. Signed-off-by: Petr Holasek <pholasek@redhat.com> Acked-by: David Rientjes <rientjes@google.com> Cc: Anton Arapov <anton@redhat.com> Link: http://lkml.kernel.org/r/20111208121640.GA2229@dhcp-27-244.brq.redhat.com Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-09x86, CPU: Drop superfluous get_cpu_cap() prototypeBorislav Petkov
The get_cpu_cap() external function prototype was declared twice so lose one of them. Clean up the header guard while at it. Signed-off-by: Borislav Petkov <borislav.petkov@amd.com> Link: http://lkml.kernel.org/r/1322594083-14507-1-git-send-email-bp@amd64.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-12-08ARM: OMAP1: Always reprogram dpll1 rate at bootJanusz Krzysztofik
DPLL1 reprogramming to a different rate is actually blocked inside omap1_select_table_rate(). However, it is already forced at boot, for boards which boot at unusable clock rates, and this seems to work correctly. OTOH, we now have a fine, run time performed clock selection algorithm implemented, which prevents less powerfull SoCs from being overclocked unintentionally. Allow reprogramming of dpll1 by default, and use it for switching to the higest supported clock rate with all boards, including those already booting at a usable rate of 60 MHz or above. Created against linux-omap/master tip as of Thu Dec 1, commit f83c2a8cbb59981722d1ab610c79adfd034a2667. Requires the just submitted patch "ARM: OMAP1: Move dpll1 rates selection from config to runtime" to prevent from unintentional overclocking. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-08ARM: OMAP1: Update dpll1 default rate reprogramming methodJanusz Krzysztofik
According to comments in omap1_select_table_rate(), reprogramming dpll1 is tricky, and should always be done from SRAM. While being at it, move OMAP730 special case handling inside omap_sram_reprogram_clock(). Created on top of version 2 of the series "ARM: OMAP1: Fix dpll1 reprogramming related issues", which it depends on. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-08ARM: OMAP1: Move dpll1 rates selection from config to runtimeJanusz Krzysztofik
For still better multi-OMAP1 support, expand omap1_rate_table with flags for different SoC types and match them while selecting clock rates. The idea is stolen from current omap24xx clock rate selection algorithm. Since clkdev platform flag definitions are reused here, those had to be expanded with one extra entry for OMAP1710 subtype, as this is the only SoC for which we allow selection of the highest, 216 MHz rate. Once done, remove no longer needed clock rate configure time options. Tested on Amstrad Delta. Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> [tony@atomide.com: updated comments] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-08ARM: OMAP1: Set the omap1623 sram size to 16KTony Lindgren
Now that we're always reprogramming the core clock we must make sure SRAM works. It seems that neither omap1621 or omap1623 has 256K of SRAM. Set the SRAM size to safe value of 16K. Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-08ARM: OMAP: hsmmc: add pm_caps fieldEliad Peller
Add pm_caps field to omap2_hsmmc_info and omap_mmc_slot_data structs, so we will be able to indicate mmc pm capabilities in the board file. Signed-off-by: Eliad Peller <eliad@wizery.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-08Merge branch 'fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc * 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (28 commits) ARM: sa1100: fix build error ARM: OMAP1: recalculate loops per jiffy after dpll1 reprogram ARM: davinci: dm365 evm: align nand partition table to u-boot ARM: davinci: da850 evm: change audio edma event queue to EVENTQ_0 ARM: davinci: dm646x evm: wrong register used in setup_vpif_input_channel_mode ARM: davinci: dm646x does not have a DSP domain ARM: davinci: psc: fix incorrect offsets ARM: davinci: psc: fix incorrect mask ARM: mx28: LRADC macro rename arm: mx23: recognise stmp378x as mx23 ARM: mxs: fix machines' initializers order ARM: mxs/tx28: add __initconst for fec pdata ARM: S3C64XX: Staticise s3c6400_sysclass ARM: S3C64XX: Add linux/export.h to dev-spi.c ARM: S3C64XX: Remove extern from definition of framebuffer setup call MAINTAINERS: Extend Samsung patterns to cover SPI and ASoC drivers MAINTAINERS: Add linux-samsung-soc mailing list for Samsung MAINTAINERS: Consolidate Samsung MAINTAINERS ARM: CSR: PM: fix build error due to undeclared 'THIS_MODULE' ARM: CSR: fix build error due to new mdesc->dma_zone_size ...
2011-12-08x86, hpet: Immediately disable HPET timer 1 if rtc irq is maskedMark Langsdorf
When HPET is operating in RTC mode, the TN_ENABLE bit on timer1 controls whether the HPET or the RTC delivers interrupts to irq8. When the system goes into suspend, the RTC driver sends a signal to the HPET driver so that the HPET releases control of irq8, allowing the RTC to wake the system from suspend. The switchover is accomplished by a write to the HPET configuration registers which currently only occurs while servicing the HPET interrupt. On some systems, I have seen the system suspend before an HPET interrupt occurs, preventing the write to the HPET configuration register and leaving the HPET in control of the irq8. As the HPET is not active during suspend, it does not generate a wake signal and RTC alarms do not work. This patch forces the HPET driver to immediately transfer control of the irq8 channel to the RTC instead of waiting until the next interrupt event. Signed-off-by: Mark Langsdorf <mark.langsdorf@amd.com> Link: http://lkml.kernel.org/r/20111118153306.GB16319@alberich.amd.com Tested-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org
2011-12-08ARM: OMAP3: CPUidle: Make use of CPU PM notifiersSantosh Shilimkar
Save VFP CPU context using CPU PM notifier chain. VFP context is lost when CPU hits OFF state. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-08ARM: OMAP4: cpuidle: Switch to gptimer from twd in deeper C-states.Santosh Shilimkar
CPU local timer(TWD) stops when the CPU is transitioning into deeper C-States. Since these timers are not wakeup capable, we need the wakeup capable global timer to program the wakeup time depending on the next timer expiry. It can be handled by registering a global wakeup capable timer along with local timers marked with (mis)feature flag CLOCK_EVT_FEAT_C3STOP. Then notify the clock events layer from idle code using CLOCK_EVT_NOTIFY_BROADCAST_ENTER/EXIT). ARM local timers are already marked with C3STOP feature. Add the notifiers to OMAP4 CPU idle code for the broadcast entry and exit. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-08ARM: OMAP4: PM: Add CPUidle supportSantosh Shilimkar
Add OMAP4 CPUIDLE support. CPU1 is left with defualt idle and the low power state for it is managed via cpu-hotplug. This patch adds MPUSS low power states in cpuidle. C1 - CPU0 ON + CPU1 ON + MPU ON C2 - CPU0 OFF + CPU1 OFF + MPU CSWR C3 - CPU0 OFF + CPU1 OFF + MPU OSWR OMAP4460 onwards, MPUSS power domain doesn't support OFF state any more anymore just like CORE power domain. The deepest state supported is OSWr. Ofcourse when MPUSS and CORE PD transitions to OSWR along with device off mode, even the memory contemts are lost which is as good as the PD off state. On OMAP4 because of hardware constraints, no low power states are targeted when both CPUs are online and in SMP mode. The low power states are attempted only when secondary CPU gets offline to OFF through hotplug infrastructure. Thanks to Nicole Chalhoub <n-chalhoub@ti.com> for doing exhaustive C-state latency profiling. Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-08ARM: OMAP4: Fix errata i688 with MPU interconnect barriers.Santosh Shilimkar
On OMAP4 SOC, intecronnects has many write buffers in the async bridges and they need to be drained before CPU enters into standby state. Patch 'OMAP4: PM: Add CPUX OFF mode support' added CPU PM support but OMAP errata i688 (Async Bridge Corruption) needs to be taken care to avoid issues like system freeze, CPU deadlocks, random crashes with register accesses, synchronisation loss on initiators operating on both interconnect port simultaneously. As per the errata, if a data is stalled inside asynchronous bridge because of back pressure, it may be accepted multiple times, creating pointer misalignment that will corrupt next transfers on that data path until next reset of the system (No recovery procedure once the issue is hit, the path remains consistently broken). Async bridge can be found on path between MPU to EMIF and MPU to L3 interconnect. This situation can happen only when the idle is initiated by a Master Request Disconnection (which is trigged by software when executing WFI on CPU). The work-around for this errata needs all the initiators connected through async bridge must ensure that data path is properly drained before issuing WFI. This condition will be met if one Strongly ordered access is performed to the target right before executing the WFI. In MPU case, L3 T2ASYNC FIFO and DDR T2ASYNC FIFO needs to be drained. IO barrier ensure that there is no synchronisation loss on initiators operating on both interconnect port simultaneously. Thanks to Russell for a tip to conver assembly function to C fuction there by reducing 40 odd lines of code from the patch. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Richard Woodruff <r-woodruff2@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-08ARM: OMAP4: PM: Add power domain statistics supportSantosh Shilimkar
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-08ARM: OMAP4: PM: Add MPUSS power domain OSWR supportSantosh Shilimkar
This patch adds the MPUSS OSWR (Open Switch Retention) support. The MPUSS OSWR configuration is as below. - CPUx L1 and logic lost, MPUSS logic lost, L2 memory is retained OMAP4460 onwards, MPUSS power domain doesn't support OFF state any more anymore just like CORE power domain. The deepest state supported is OSWR. On OMAP4430 secure devices too, MPUSS off mode can't be used because of a bug which alters Ducati and Tesla states. Hence MPUSS off mode as an independent state isn't supported on OMAP44XX devices. Ofcourse when MPUSS power domain transitions to OSWR along with device off mode, it eventually hits off state since memory contents are lost. Hence the MPUSS off mode independent state is not attempted without device off mode. All the necessary infrastructure code for MPUSS off mode is in place as part of this series. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-12-08ARM: OMAP4: PM: Add L2X0 cache lowpower supportSantosh Shilimkar
When MPUSS hits off-mode, L2 cache is lost. This patch adds L2X0 necessary maintenance operations and context restoration in the low power code. Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Acked-by: Jean Pihet <j-pihet@ti.com> Reviewed-by: Kevin Hilman <khilman@ti.com> Tested-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>