summaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)Author
2012-09-24Merge branch 'pci/yinghai-misc' into nextBjorn Helgaas
2012-09-24Merge git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tileLinus Torvalds
Pull tile gxio ABI fix from Chris Metcalf: "This fixes a last-minute change in the Tilera hypervisor ABI for TRIO (PCI root complex) support. We've locked in this ABI going forward and will make sure no further ABI changes like this occur." * git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: tile: gxio iorpc numbering change for TRIO interface
2012-09-24Merge tag 'stable/for-linus-3.6-rc7-tag' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen Pull a Xen fix from Konrad Rzeszutek Wilk: "It is a bug-fix when we run the initial PV guest on a AMD K8 machine and have CONFIG_AMD_NUMA enabled and detect the NUMA topology from the Northbridge. We end up in the situation where the initial domain gets too much information and gets confused and crashes - the fix is to restrict the domain to get the information - and we do it by just disabling NUMA on the PV guest (the hypervisor is still able to do its proper NUMA allocations of guests). It is OK to disable the PV guest from accessing NUMA data as right now we do not inject any NUMA node information to the PV guests. When we do get to that point, then this patch will have to be reverted." * Disable PV NUMA support as we do not do anything with it (yet) and it can cause bootup crashes on certain AMD machines. * tag 'stable/for-linus-3.6-rc7-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: xen/boot: Disable NUMA for PV guests.
2012-09-24x86: bpf_jit_comp: add XOR instruction for BPF JITDaniel Borkmann
This patch is a follow-up for patch "filter: add XOR instruction for use with X/K" that implements BPF x86 JIT parts for the BPF XOR operation. Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-24phy/micrel: Rename KS80xx to KSZ80xxMarek Vasut
There is no such part as KS8001, KS8041 or KS8051. There are only KSZ8001, KSZ8041 and KSZ8051. Rename these parts as such to match the Micrel naming. Signed-off-by: Marek Vasut <marex@denx.de> Cc: David J. Choi <david.choi@micrel.com> Cc: David S. Miller <davem@davemloft.net> Cc: Nobuhiro Iwamatsu <nobuhiro.iwamatsu.yj@renesas.com> Cc: Linux ARM kernel <linux-arm-kernel@lists.infradead.org> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-09-24tile: gxio iorpc numbering change for TRIO interfaceChris Metcalf
An ABI numbering change was made in the hypervisor for Tilera's 4.1 MDE release (just shipped). It's incompatible with the previous 4.0 release ABI numbering, so we track the new numbering going forward. We plan to avoid modifying ABI numbering for these interfaces again. Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
2012-09-24Merge tag 'perf-core-for-mingo' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: * Convert the trace builtins to use the growing evsel/evlist tracepoint infrastructure, removing several open coded constructs like switch like series of strcmp to dispatch events, etc. Basically what had already been showcased in 'perf sched'. * Add evsel constructor for tracepoints, that uses libtraceevent just to parse the /format events file, use it in a new 'perf test' to make sure the libtraceevent format parsing regressions can be more readily caught. * Some strange errors were happening in some builds, but not on the next, reported by several people, problem was some parser related files, generated during the build, didn't had proper make deps, fix from Eric Sandeen. * Fix some compiling errors on 32-bit, from Feng Tang. * Don't use sscanf extension %as, not available on bionic, reimplementation by Irina Tirdea. * Fix bfd.h/libbfd detection with recent binutils, from Markus Trippelsdorf. * Introduce struct and cache information about the environment where a perf.data file was captured, from Namhyung Kim. * Fix several error paths in libtraceevent, from Namhyung Kim. Print event causing perf_event_open() to fail in 'perf record', from Stephane Eranian. * New 'kvm' analysis tool, from Xiao Guangrong. Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
2012-09-24c6x: use asm-generic/barrier.hMark Salter
A recent patch in the linux-next tree caused a build failure on C6X because C6X didn't define a read_barrier_depends() macro. C6X does not support SMP and the architecture doesn't provide any special memory ordering instructions, so it makes sense to just use the generic barrier.h rather than patching the existing c6x specific header. Signed-off-by: Mark Salter <msalter@redhat.com>
2012-09-24ARM: OMAP2+: serial: Change MAX_HSUART_PORTS to 6AnilKumar Ch
Extends the maximum number of UART ports to 6 from 4 because AM335X device have six UART ports. Signed-off-by: AnilKumar Ch <anilkumar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-09-24ARM: OMAP4: twl-common: Support for additional devices on i2c1 busPeter Ujfalusi
On OMAP4 the i2c1 bus is dedicated for the PMIC and audio related devices. Manufacturers can opt to use different codec than twl6040 and also can add audio related IC to the bus (external amplifier for example on SDP4430). Make it possible to add different set of additional devices to i2c1 bus on OMAP4 boards. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> [tony@atomide.com: updated for removal of irqs.h] Signed-off-by: Tony Lindgren <tony@atomide.com>
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>