summaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)Author
2012-09-24arm64: Do not set the SMP/nAMP processor bitCatalin Marinas
If such bit exists on a given CPU, it must be set by the firmware or boot-loader prior to starting the kernel (see Documentation/arm64/booting.txt). Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2012-09-24arm: introduce a DTS for Xen unprivileged virtual machinesStefano Stabellini
Given that the xenvm machine is based on vexpress but with an extremely limited selection of peripherals (the guest is supposed to use virtual devices instead), add "xen,xenvm" to the list of compatible machines in mach-vexpress. Changes in v3: - add comments to mark fields that are likely to be changed by the hypervisor. Changes in v2: - remove include skeleton; - use #address-cells = <2> and #size-cells = <2>; - remove the debug bootargs; - use memory@80000000 instead of memory; - remove the ranges and interrupt-map from the motherboard node; - set the machine compatible to "xen,xenvm-4.2", "xen,xenvm"; - rename the dts file to xenvm-4.2.dts; - add "xen,xenvm" to the list of compatible DT strings to mach-vexpress. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Pawel Moll <pawel.moll@arm.com> (v2m changes)
2012-09-24time: Convert x86_64 to using new update_vsyscallJohn Stultz
Switch x86_64 to using sub-ns precise vsyscall Cc: Tony Luck <tony.luck@intel.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Paul Turner <pjt@google.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: John Stultz <john.stultz@linaro.org>
2012-09-24time: Convert CONFIG_GENERIC_TIME_VSYSCALL to CONFIG_GENERIC_TIME_VSYSCALL_OLDJohn Stultz
To help migrate archtectures over to the new update_vsyscall method, redfine CONFIG_GENERIC_TIME_VSYSCALL as CONFIG_GENERIC_TIME_VSYSCALL_OLD Cc: Tony Luck <tony.luck@intel.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Paul Turner <pjt@google.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: John Stultz <john.stultz@linaro.org>
2012-09-24time: Move update_vsyscall definitions to timekeeper_internal.hJohn Stultz
Since users will need to include timekeeper_internal.h, move update_vsyscall definitions to timekeeper_internal.h. Cc: Tony Luck <tony.luck@intel.com> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Paul Turner <pjt@google.com> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: John Stultz <john.stultz@linaro.org>
2012-09-24jiffies: Remove compile time assumptions about CLOCK_TICK_RATEJohn Stultz
CLOCK_TICK_RATE is used to accurately caclulate exactly how a tick will be at a given HZ. This is useful, because while we'd expect NSEC_PER_SEC/HZ, the underlying hardware will have some granularity limit, so we won't be able to have exactly HZ ticks per second. This slight error can cause timekeeping quality problems when using the jiffies or other jiffies driven clocksources. Thus we currently use compile time CLOCK_TICK_RATE value to generate SHIFTED_HZ and NSEC_PER_JIFFIES, which we then use to adjust the jiffies clocksource to correct this error. Unfortunately though, since CLOCK_TICK_RATE is a compile time value, and the jiffies clocksource is registered very early during boot, there are a number of cases where there are different possible hardware timers that have different tick rates. This causes problems in cases like ARM where there are numerous different types of hardware, each having their own compile-time CLOCK_TICK_RATE, making it hard to accurately support different hardware with a single kernel. For the most part, this doesn't matter all that much, as not too many systems actually utilize the jiffies or jiffies driven clocksource. Usually there are other highres clocksources who's granularity error is negligable. Even so, we have some complicated calcualtions that we do everywhere to handle these edge cases. This patch removes the compile time SHIFTED_HZ value, and introduces a register_refined_jiffies() function. This results in the default jiffies clock as being assumed a perfect HZ freq, and allows archtectures that care about jiffies accuracy to call register_refined_jiffies() with the tick rate, specified dynamically at boot. This allows us, where necessary, to not have a compile time CLOCK_TICK_RATE constant, simplifies the jiffies code, and still provides a way to have an accurate jiffies clock. NOTE: Since this patch does not add register_refinied_jiffies() calls for every arch, it may cause time quality regressions in some cases. Its likely these will not be noticable, but if they are an issue, adding the following to the end of setup_arch() should resolve the regression: register_refinied_jiffies(CLOCK_TICK_RATE) Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: John Stultz <john.stultz@linaro.org>
2012-09-24ARM: SAMSUNG: dma-ops: Fix dmaengine_prep_dma_cyclic() parameter listPeter Ujfalusi
There is a new flags parameter for the function. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Acked-by: Vinod Koul <vinod.koul@linux.intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2012-09-24xen/vga: add the xen EFI video mode supportJan Beulich
In order to add xen EFI frambebuffer video support, it is required to add xen-efi's new video type (XEN_VGATYPE_EFI_LFB) case and handle it in the function xen_init_vga and set the video type to VIDEO_TYPE_EFI to enable efi video mode. The original patch from which this was broken out from: http://marc.info/?i=4E099AA6020000780004A4C6@nat28.tlf.novell.com Signed-off-by: Jan Beulich <JBeulich@novell.com> Signed-off-by: Tang Liang <liang.tang@oracle.com> [v2: The original author is Jan Beulich and Liang Tang ported it to upstream] Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2012-09-24xen/x86: retrieve keyboard shift status flags from hypervisor.Konrad Rzeszutek Wilk
The xen c/s 25873 allows the hypervisor to retrieve the NUMLOCK flag. With this patch, the Linux kernel can get the state according to the data in the BIOS. Acked-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2012-09-24xen/boot: Disable NUMA for PV guests.Konrad Rzeszutek Wilk
The hypervisor is in charge of allocating the proper "NUMA" memory and dealing with the CPU scheduler to keep them bound to the proper NUMA node. The PV guests (and PVHVM) have no inkling of where they run and do not need to know that right now. In the future we will need to inject NUMA configuration data (if a guest spans two or more NUMA nodes) so that the kernel can make the right choices. But those patches are not yet present. In the meantime, disable the NUMA capability in the PV guest, which also fixes a bootup issue. Andre says: "we see Dom0 crashes due to the kernel detecting the NUMA topology not by ACPI, but directly from the northbridge (CONFIG_AMD_NUMA). This will detect the actual NUMA config of the physical machine, but will crash about the mismatch with Dom0's virtual memory. Variation of the theme: Dom0 sees what it's not supposed to see. This happens with the said config option enabled and on a machine where this scanning is still enabled (K8 and Fam10h, not Bulldozer class) We have this dump then: NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10 Scanning NUMA topology in Northbridge 24 Number of physical nodes 4 Node 0 MemBase 0000000000000000 Limit 0000000040000000 Node 1 MemBase 0000000040000000 Limit 0000000138000000 Node 2 MemBase 0000000138000000 Limit 00000001f8000000 Node 3 MemBase 00000001f8000000 Limit 0000000238000000 Initmem setup node 0 0000000000000000-0000000040000000 NODE_DATA [000000003ffd9000 - 000000003fffffff] Initmem setup node 1 0000000040000000-0000000138000000 NODE_DATA [0000000137fd9000 - 0000000137ffffff] Initmem setup node 2 0000000138000000-00000001f8000000 NODE_DATA [00000001f095e000 - 00000001f0984fff] Initmem setup node 3 00000001f8000000-0000000238000000 Cannot find 159744 bytes in node 3 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96 Pid: 0, comm: swapper Not tainted 3.3.6 #1 AMD Dinar/Dinar RIP: e030:[<ffffffff81d220e6>] [<ffffffff81d220e6>] __alloc_bootmem_node+0x43/0x96 .. snip.. [<ffffffff81d23024>] sparse_early_usemaps_alloc_node+0x64/0x178 [<ffffffff81d23348>] sparse_init+0xe4/0x25a [<ffffffff81d16840>] paging_init+0x13/0x22 [<ffffffff81d07fbb>] setup_arch+0x9c6/0xa9b [<ffffffff81683954>] ? printk+0x3c/0x3e [<ffffffff81d01a38>] start_kernel+0xe5/0x468 [<ffffffff81d012cf>] x86_64_start_reservations+0xba/0xc1 [<ffffffff81007153>] ? xen_setup_runstate_info+0x2c/0x36 [<ffffffff81d050ee>] xen_start_kernel+0x565/0x56c " so we just disable NUMA scanning by setting numa_off=1. CC: stable@vger.kernel.org Reported-and-Tested-by: Andre Przywara <andre.przywara@amd.com> Acked-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
2012-09-24ARM: dma-mapping: Fix potential memory leak in atomic_pool_init()Sachin Kamat
When either of __alloc_from_contiguous or __alloc_remap_buffer fails to provide a valid pointer, allocated memory is freed up and an error is returned. 'pages' was however not freed before returning error. Cc: Arnd Bergmann <arnd@arndb.de> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
2012-09-23Merge tag 'vt8500-for-next' of git://git.code.sf.net/p/linuxwmt/code into ↵Olof Johansson
next/dt From Tony Prisk: Update arch-vt8500 and drivers to device tree and remove existing non-dt code. * tag 'vt8500-for-next' of git://git.code.sf.net/p/linuxwmt/code: arm: vt8500: Update arch-vt8500 to devicetree support. arm: vt8500: gpio: Devicetree support for arch-vt8500 arm: vt8500: doc: Add device tree bindings for arch-vt8500 devices arm: vt8500: clk: Add Common Clock Framework support video: vt8500: Add devicetree support for vt8500-fb and wm8505-fb serial: vt8500: Add devicetree support for vt8500-serial rtc: vt8500: Add devicetree support for vt8500-rtc arm: vt8500: Add device tree files for VIA/Wondermedia SoC's Resolved add/change conflict in drivers/clk/Makefile. Signed-off-by: Olof Johansson <olof@lixom.net>
2012-09-23hwmon: (sht15) move header to linux/platform_data/Vivien Didelot
This patch moves the sht15.h header from include/linux to include/linux/platform_data, and update existing support (stargate2 platform) accordingly. Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2012-09-23ARM: OMAP4460/4470: PMU: Enable PMU for OMAP4460/70Jon Hunter
OMAP4460 and OMAP4470 devices have dedicated PMU interrupts and so add these interrupts to the MPU HWMOD so we can use these for PMU events on these devices. The PMU interrupts need to be the first interrupts in the array of interrupts as the ARM PMU driver assumes this. By using these dedicated interrupts we only need to enable the MPU and DEBUG sub-systems for PMU to work. This is different to OMAP4430 that did not have dedicated interrupts and required other power domains in addition to the DEBUG sub-system to be enabled so we could route the PMU events to the CTI interrupts. Hence, OMAP4460 and OMAP4470 devices can use the same list of HWMODs to create the PMU device that is using by OMAP3. Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: updated to apply] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP2+: PMU: Add runtime PM supportJon Hunter
The original implementation of this patch was done by Ming Lei for PMU on OMAP4 [1]. Since then the PM runtime calls have been moved into the ARM PMU code and this greatly simplifies the changes. The another differnce since the original version, is that it is no longer necessary to call pm_runtime_get/put during the PMU initialisation was we are no longer accessing the hardware at this stage. By adding runtime PM support, we can ensure that the appropriate power and clock domains are kept on while PMU is being used. [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-November/074153.html Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP4430: PMU: prepare to create PMU device via HWMODMing Lei
For OMAP4430 PMU events are routed to the CPU via the cross trigger interface (CTI) because there are no dedicated interrupts. In order to route the PMU events via the CTI IRQs, the following modules must be enabled: l3_instr, l3_main_3, debugss Therefore, build the arm-pmu device via these three HWMODs. However, the CTI support for this platform still needs some work. Until that's finished, temporarily disable the PMU on OMAP4430. Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Ming Lei <ming.lei@canonical.com> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: temporarily disabled OMAP4430 PMU support until a better CTI interface can be implemented; added patch description note] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP2+: PMU: Convert OMAP2/3 devices to use HWMODJon Hunter
Convert OMAP2/3 devices to use HWMOD for creating a PMU device. To support PMU on OMAP2 devices we only need to use MPU sub-system and so we can simply use the MPU HWMOD to create the PMU device. To support PMU on OMAP3 devices, we need to use the MPU and DEBUG sub-systems and so use these HWMODs to create the PMU device for OMAP3. The MPU HWMOD for OMAP2/3 devices is currently missing the PMU interrupt and so add the PMU interrupt to the MPU HWMOD for these devices. This change also moves the PMU code out of the mach-omap2/devices.c files into its own pmu.c file as suggested by Kevin Hilman to de-clutter devices.c. Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Benoit Cousson <b-cousson@ti.com> Cc: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: fixed checkpatch messages; updated to apply; dropped old-style initial filename line in header comments] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP3: hwmod data: Add debugss HWMOD dataJon Hunter
To enable PMU with runtime PM support on OMAP3 devices we need to be able to dynamically enable and disable the debug sub-system at runtime. By adding HWMOD data for the debug sub-system for OMAP3, we can build the PMU device using the debug sub-system HWMOD and control this power domain using runtime PM. Reviewed-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: updated to apply; added L4-EMU address space] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP2+: clockdomain/hwmod: add workaround for EMU clockdomain idle problemsPaul Walmsley
The idle status of the IP blocks and clocks inside the EMU clockdomain isn't taken into account by the PRCM hardware when deciding whether the clockdomain is idle. Add a workaround flag in the clockdomain code, CLKDM_MISSING_IDLE_REPORTING, to deal with this problem, and add the code necessary to support it. If CLKDM_MISSING_IDLE_REPORTING is set on a clockdomain, the clockdomain will be forced active whenever an IP block inside that clockdomain is in use, even if the clockdomain supports hardware-supervised idle. When the kernel indicates that the last active IP block inside the clockdomain is no longer used, the clockdomain will be forced idle, or, if that mode is not supported in the hardware, it will be placed into hardware-supervised idle. This patch is an equal collaboration with Jon Hunter <jon-hunter@ti.com>. Ming Lei <ming.lei@canonical.com>, Will Deacon <will.deacon@arm.com>, Madhav Vij <mvij@ti.com>, Kevin Hilman <khilman@ti.com>, Benoît Cousson <b-cousson@ti.com>, and Santosh Shilimkar <santosh.shilimkar@ti.com> all made essential contributions to the understanding of EMU clockdomain power management on OMAP. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Jon Hunter <jon-hunter@ti.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Madhav Vij <mvij@ti.com> Cc: Kevin Hilman <khilman@ti.com> Cc: Benoît Cousson <b-cousson@ti.com> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com> Tested-by: Jon Hunter <jon-hunter@ti.com>
2012-09-23ARM: OMAP: Add a timer attribute for timers that can interrupt the DSPJon Hunter
Some instances of the DMTIMER peripheral on OMAP devices have the ability to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER attribute to indicate which timers can interrupt the DSP. By using the omap_dm_timer_request_by_cap() API, driver will now be able to allocate a DMTIMER that can interrupt the DSP based upon this attribute and not require the driver to know which instance has this capability. DMTIMERs that have the ability to interrupt the DSP on OMAP devices are as follows ... - OMAP1 (OMAP5912/16xx/17xx) devices - All 8 DMTIMERs - OMAP2/3/4 devices - DMTIMERs 5-8 Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and generate a PWM output. Signed-off-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23hwrng: OMAP: remove SoC restrictions from driver registrationPaul Walmsley
Remove the SoC restriction code from the OMAP RNG driver. The integration code in arch/arm/*omap* should handle this. The device shouldn't be created if it doesn't exist on the currently-booted SoC. This allows us to remove some OMAP-specific cpu_is_omap*() calls from the driver. Also, if other OMAP chips have RNGs that can be used by Linux, there will be no need to modify the driver. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-09-23ARM: OMAP: split OMAP1, OMAP2+ RNG device registrationPaul Walmsley
Move the OMAP1-specific RNG device creation off to mach-omap1/devices.c, and create a omap_device-backed registration function for OMAP2+ devices in mach-omap2/devices.c. As a nice side-benefit, we can also get rid of arch/arm/plat-omap/devices.c, thanks to some recent changes from Tony. One change from the previous behavior is that the RNG devices are now registered unconditionally. This should allow the RNG drivers to be loaded as modules, even if the original kernel was not built that way. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP2xxx: hwmod/CM: add RNG integration dataPaul Walmsley
Add integration data for the hardware random number generator IP block on some OMAP SoCs. This appears to be present on at least OMAP2xxx and OMAP3xxx SoCs, although it is not so easy to tell. It may also be present on other OMAP2+ SoCs. Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP2+: gpmc: minimal driver supportAfzal Mohammed
Create a minimal driver out of gpmc code. Responsibilities handled by earlier gpmc initialization is now achieved in probe. Signed-off-by: Afzal Mohammed <afzal@ti.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> [paul@pwsan.com: fixed some checkpatch messages] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP2+: gpmc: Adapt to HWMODAfzal Mohammed
Create API for platforms to adapt GPMC to HWMOD Signed-off-by: Afzal Mohammed <afzal@ti.com> Reviewed-by: Jon Hunter <jon-hunter@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP2/3: hwmod data: add gpmcAfzal Mohammed
Add gpmc hwmod and associated interconnect data Signed-off-by: Afzal Mohammed <afzal@ti.com> [paul@pwsan.com: added comments to the use of HWMOD_INIT_NO_RESET] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP4: hwmod data: add mmu hwmod for ipu and dspOmar Ramirez Luna
Add mmu hwmod data for ipu and dsp. Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> Acked-by: Benoit Cousson <b-cousson@ti.com> [paul@pwsan.com: cleaned up whitespace] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP3: hwmod data: add mmu data for iva and ispPaul Walmsley
Add mmu hwmod data for iva and isp. Due to compatibility an ifdef CONFIG_OMAP_IOMMU_IVA2 needs to be propagated (previously on iommu resource info) to hwmod data in OMAP3, so users of iommu and tidspbridge can avoid issues of two modules managing mmu data/irqs/resets; this until tidspbridge can be migrated to iommu framework. Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> [paul@pwsan.com: fixed some kerneldoc and whitespace; ISP MMUs not present on AM35xx so restricted these hwmods to 34xx/36xx] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP: iommu: fix including iommu.h without IOMMU_API selectedOmar Ramirez Luna
If included without IOMMU_API being selected it will break compilation: arch/arm/plat-omap/include/plat/iommu.h: In function 'dev_to_omap_iommu': arch/arm/plat-omap/include/plat/iommu.h:148: error: 'struct dev_archdata' has no member named 'iommu' This will be seen when hwmod includes iommu.h to get the structure for attributes. Also needed for tidspbridge incremental migration to use iommu code. Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP4: hwmod data: add missing HWMOD_NO_IDLEST flags to some PRCM IP blocksPaul Walmsley
Some struct omap_hwmod records belonging to PRCM IP blocks are missing HWMOD_NO_IDLEST flags; add them. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-09-23ARM: OMAP4: hwmod data: make *phy_48m* as the main_clk of ocp2scpKishon Vijay Abraham I
Made *ocp2scp_usb_phy_phy_48m* as the main_clk for ocp2scp. Since this ocp2scp module does not have any fck but does have a single opt_clock, it is added as the main_clk for ocp2scp. Also removed phy_48m as the optional clock since it is now made as the main clock. By this the driver need not enable/disable phy_48m clk separately and runtime_get/runtime_put will take care of that. Cc: Benoît Cousson <b-cousson@ti.com> Reviewed-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Benoît Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP4: hwmod data: Fix ocp2scp_usb_phy and usb_host_hs entriesBenoit Cousson
ocp2scp_usb_phy was missing the address space data and thus the sysconfig was not populated either. The usb_host_hs address space was wrong. Fix both of them and add the missing sysconfig entry. Reported-by: Kishon Vijay Abraham <kishon@ti.com> Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP3: hwmod data: add sad2d hwmodTero Kristo
SAD2D stands for the die to die interface, and is used for communicating with the optional stacked modem. This hwmod is added in preparation for the d2d_idle move from pm34xx.c to hwmod data. Signed-off-by: Tero Kristo <t-kristo@ti.com> [paul@pwsan.com: SAD2D presumably doesn't exist on non-OMAP34xx/OMAP36xx, so only add it to the OMAP34xx/OMAP36xx lists] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP: hwmod: revise deassert sequenceOmar Ramirez Luna
For a reset sequence to complete cleanly, a module needs its associated clocks to be enabled, otherwise the timeout check in prcm code can print a false failure (failed to hardreset) that occurs because the clocks aren't powered ON and the status bit checked can't transition without them. Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP: hwmod: partially un-reset hwmods might not be properly enabledOmar Ramirez Luna
Some IP blocks might not be using/controlling more than one reset line, this check loosens the restriction to fully use hwmod framework for those drivers. E.g.: ipu has reset lines: mmu_cache, cpu0 and cpu1. - As of now cpu1 is not used and hence (with previous check) the IP block isn't fully enabled by hwmod code. - Usually ipu and dsp processors configure their mmu module first and then enable the processors, this involves: * Deasserting mmu reset line, and enabling the module. * Deasserting cpu0 reset line, and enabling the processor. The ones portrayed in this example are controlled through rproc_fw_boot in drivers/remoteproc/remoteproc_core.c While at it, prevent _omap4_module_disable if all the hardreset lines on an IP block are not under reset. This will allow the driver to: a. Deassert the reset line. b. Enable the hwmod through runtime PM default callbacks. c. Do its usecase. d. Disable hwmod through runtime PM. e. Assert the reset line. Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> [paul@pwsan.com: updated to apply] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP4: hwmod: flag hwmods/modules not supporting module level context ↵Tero Kristo
status On OMAP4 most modules/hwmods support module level context status. On OMAP3 and earlier, we relied on the power domain level context status. Identify all modules that don't support 'context_offs' by adding a flag bit, HWMOD_OMAP4_NO_CONTEXT_LOSS_BIT. Rest have a valid 'context_offs' populated in .prcm structure already. Signed-off-by: Tero Kristo <t-kristo@ti.com> [paul@pwsan.com: add flag bit rather than overloading .context_offs; update changelog message] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP4: hwmod data: add support for lostcontext_maskTero Kristo
Currently hwmod only provides the offset for the context lose register, and if we attempt to share the same register between two or more hwmods, the resulting context loss counts get wrong. Thus, we need a way to specify which bits are used for the context loss information for each. This is accomplished by adding a new field to the omap4 prcm struct, 'lostcontext_mask', which specifies a bit-mask to use for filtering the register. Mark the affected hwmods appropriately. 'l4_abe' hwmod uses the LOSTMEM_AESSMEM bit of RM_ABE_AESS_CONTEXT register, as l4_abe doesn't have its own dedicated register for this purpose. This register is shared with 'aess' hwmod, thus both hwmods must also specify which bits of the register are used for them. This patch only adds the hwmod data, but a future patch should add code support such that only the specified bits are read and cleared by the context lose counter update code. If a hwmod doesn't specify 'lostcontext_mask' (default behavior), the whole contents of the context register should be used without any filtering. Signed-off-by: Tero Kristo <t-kristo@ti.com> [paul@pwsan.com: updated to apply after conversion to use flag bit for missing module context-loss register; combined data and code patches; dropped code change due to serial driver breakage] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP4: powerdomain: add support for reading prev logic and mem statesTero Kristo
On OMAP4, there is no support to read previous logic state or previous memory state achieved when a power domain transitions to RET. Instead there are module level context registers. In order to support the powerdomain level logic/mem_off_counters on OMAP4, instead use the previous power state achieved (RET) and the *programmed* logic/mem RET state to derive if a powerdomain lost logic or did not. If the powerdomain is programmed to enter RET state and lose logic in RET state, knowing that the powerdomain entered RET is good enough to derive that the logic was lost as well, in such cases. Signed-off-by: Tero Kristo <t-kristo@ti.com> [paul@pwsan.com: removed dependency on functional power state series for now; bumped copyright date] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP2+: hwmod code: convert missing clockdomain warnings to debug messagesPaul Walmsley
The decision was made a few months ago to allow struct omap_hwmod records and struct clk records to omit clockdomain information if the clockdomain is not software-controllable. See for example commit 868c157df9721675c19729eed2c96bac6c3f1d01 ("ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods to have no clockdomain"). So convert an existing pr_warning() to a pr_debug() (regarding missing clockdomains in clocks), and add a pr_debug() for missing hwmod clockdomains. It's still useful to enable these messages for debugging, since missing clockdomains can cause hard-to-debug problems with power management; see for example commit 6c4a057bffe9823221eab547e11fac181dc18a2b ("ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock"). Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-09-23ARM: OMAP4+: hwmod code: remove clkdm requirement in _omap4_wait_target_*()Paul Walmsley
We're no longer requiring struct omap_hwmod records to contain a clockdomain. So we shouldn't return -EINVAL any more from _omap4_wait_target_disable() or _omap4_wait_target_ready() if there's no clockdomain defined, since that just gets passed back to the caller. This can result in pointless warnings under the relaxed data format. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Benoît Cousson <b-cousson@ti.com>
2012-09-23ARM: OMAP2+: omap_device: expose hwmod assert/deassert to omap devicesOmar Ramirez Luna
This API is meant to be an interface to hwmod assert/deassert function, omap devices can call them through their platform data to control their reset lines, they are expected to know the name of the reset line they are trying to control. Signed-off-by: Omar Ramirez Luna <omar.luna@linaro.org> [paul@pwsan.com: tweaked some documentation; fixed CodingStyle issue] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23ARM: OMAP: hwmod code: remove unused hwmod function prototypesIgor Grinberg
Several hwmod function prototypes appear to not have an implementation because the corresponding functions were removed or renamed. Those prototypes are unneeded anymore - remove them. Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> [paul@pwsan.com: tweaked subject] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-09-23Merge branch 'clock_devel_3.7' into hwmod_prcm_clock_a_3.7Paul Walmsley
Conflicts: arch/arm/mach-omap2/clkt34xx_dpll3m2.c arch/arm/mach-omap2/clkt_clksel.c arch/arm/mach-omap2/clock.c
2012-09-23Merge tag 'omap-devel-am33xx-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7Paul Walmsley
From Paul Walmsley <paul@pwsan.com>: AM33xx hwmod data and miscellaneous clock and hwmod fixes. AM33xx should now boot on mainline after this is applied, according to Vaibhav.
2012-09-23Merge tag 'cleanup-fixes-for-v3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7Paul Walmsley
These fixes are needed to fix non-omap build breakage for twl-core driver and to fix omap1_defconfig compile when led driver changes and omap sparse IRQ changes are merged together. Also fix warnings for omaps not using pinctrl framework yet.
2012-09-23Merge tag 'omap-cleanup-b-for-3.7' into test_v3.6-rc6_ocb3.7_cff3.7_odaf3.7Paul Walmsley
smatch and string-wrapping cleanups for the OMAP subarch code. These changes fix some of the more meaningful warnings that smatch returns for the OMAP subarch code, and unwraps strings that are wrapped at the 80-column boundary, to conform with the current practice. Basic build, boot, and PM logs are available here: http://www.pwsan.com/omap/testlogs/warnings_a_cleanup_3.7/20120912025927/
2012-09-23Merge branch 'rc-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild Pull kbuild fixes from Michal Marek: "There are two more kbuild fixes for 3.6. One fixes a race between x86's archscripts target and the rule (re)building scripts/basic/fixdep. The second is a fix for the previous attempt at fixing make firmware_install with make 3.82. This new solution should work with any version of GNU make" * 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild: x86/kbuild: archscripts depends on scripts_basic firmware: fix directory creation rule matching with make 3.80
2012-09-23ia64: Add missing RCU idle APIs on idle loopPaul E. McKenney
Traditionally, the entire idle task served as an RCU quiescent state. But when RCU read side critical sections started appearing within the idle loop, this traditional strategy became untenable. The fix was to create new RCU APIs named rcu_idle_enter() and rcu_idle_exit(), which must be called by each architecture's idle loop so that RCU can tell when it is safe to ignore a given idle CPU. Unfortunately, this fix was never applied to ia64, a shortcoming remedied by this commit. Reported by: Tony Luck <tony.luck@intel.com> Signed-off-by: Paul E. McKenney <paul.mckenney@linaro.org> Cc: <stable@vger.kernel.org> # 3.3+ Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Tested by: Tony Luck <tony.luck@intel.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
2012-09-23xtensa: Add missing RCU idle APIs on idle loopFrederic Weisbecker
In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in the xtensa's idle loop. Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Chris Zankel <chris@zankel.net> Cc: <stable@vger.kernel.org> # 3.3+ Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org>
2012-09-23score: Add missing RCU idle APIs on idle loopFrederic Weisbecker
In the old times, the whole idle task was considered as an RCU quiescent state. But as RCU became more and more successful overtime, some RCU read side critical section have been added even in the code of some architectures idle tasks, for tracing for example. So nowadays, rcu_idle_enter() and rcu_idle_exit() must be called by the architecture to tell RCU about the part in the idle loop that doesn't make use of rcu read side critical sections, typically the part that puts the CPU in low power mode. This is necessary for RCU to find the quiescent states in idle in order to complete grace periods. Add this missing pair of calls in scores's idle loop. Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Chen Liqin <liqin.chen@sunplusct.com> Cc: Lennox Wu <lennox.wu@gmail.com> Cc: <stable@vger.kernel.org> # 3.3+ Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org>