aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq/Makefile (follow)
AgeCommit message (Collapse)AuthorFilesLines
2012-03-23Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds1-0/+3
Pull cpufreq updates for 3.4 from Dave Jones: new drivers and some fixes. * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq: provide disable_cpufreq() function to disable the API. EXYNOS5250: Add support cpufreq for EXYNOS5250 EXYNOS4X12: Add support cpufreq for EXYNOS4X12 [CPUFREQ] CPUfreq ondemand: update sampling rate without waiting for next sampling [CPUFREQ] Add S3C2416/S3C2450 cpufreq driver [CPUFREQ] Fix exposure of ARM_EXYNOS4210_CPUFREQ [CPUFREQ] EXYNOS4210: update the name of EXYNOS clock register [CPUFREQ] EXYNOS: Initialize locking_frequency with initial frequency [CPUFREQ] s3c64xx: Fix mis-cherry pick of VDDINT Fix up trivial conflicts in Kconfig and Makefile due to just changes next to each other (OMAP2PLUS changes vs some new EXYNOS cpufreq drivers).
2012-03-14EXYNOS5250: Add support cpufreq for EXYNOS5250Jaecheol Lee1-0/+1
This patch adds support cpufreq for EXYNOS5250 SoC. Basically, the exynos-cpufreq.c is used commonly and exynos5250-cpufreq.c is used for EXYNOS5250(two Cortex-A15 cores) SoC. Signed-off-by: Jaecheol Lee <jc.lee@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2012-03-14EXYNOS4X12: Add support cpufreq for EXYNOS4X12Jaecheol Lee1-0/+1
This patch adds support cpufreq for EXYNOS4X12 SoCs. Basically, the exynos-cpufreq.c is used commonly and exynos4x12-cpufreq.c is used for EXYNOS4212(two Cortex-A9 cores) and EXYNOS4412(four Cortex-A9 cores) SoCs. Signed-off-by: Jaecheol Lee <jc.lee@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2012-02-29[CPUFREQ] Add S3C2416/S3C2450 cpufreq driverHeiko Stübner1-0/+1
The S3C2416/S3C2450 SoCs support two sources for the armclk. The first source is the so called armdiv which divides the msysclk down to provide necessary cpu rates. In this mode the core voltage must be always at 1.3V. The frequency from the armdiv is not allowed to be lower than the hclk frequency. In the second mode the armclk can be sourced directly from the hclk in the so called "dynamic voltags scaling" (dvs) mode. Here the armdiv isn't used at all. Also in this mode the core voltage may be lowered. Existing hardware and tests with it suggest 1.0V as sufficient. When changing the clock source to the armdiv from the hclk, the SoC shows stability issues if the new frequency is higher than the current hclk frequency. Hence the driver always forces the armdiv to the hclk frequency before the source change and lets the cpufreq issue another set_target call for higher frequencies. To mark the hclk frequency as lower as the corresponding armdiv frequency it is set 1MHz below the real frequency. This lets the cpufreq framework change between 133MHz based on hclk and 133MHz based on armdiv at will. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Tested-by: Andrey Gusakov <dron0gus@gmail.com> Signed-off-by: Dave Jones <davej@redhat.com>
2012-02-21cpufreq: OMAP driver depends CPUfreq tablesRussell King1-1/+1
The OMAP driver depends on CPUfreq table support for creating a table of frequencies from the OPP layer. Ensure that it's build to avoid link-time errors. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> [khilman@ti.com: make user-selectable, but default y] Signed-off-by: Kevin Hilman <khilman@ti.com>
2012-01-08[CPUFREQ] EXYNOS: Make EXYNOS common cpufreq driverJaecheol Lee1-0/+1
To support various EXYNOS series SoCs commonly, added exynos common structure. exynos-cpufreq.c => EXYNOS series common cpufreq driver exynos4210-cpufreq.c => EXYNOS4210 support cpufreq driver Signed-off-by: Jaecheol Lee <jc.lee@samsung.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-11-08cpufreq: OMAP: cleanup for multi-SoC support, move into drivers/cpufreqSantosh Shilimkar1-0/+1
Move OMAP cpufreq driver from arch/arm/mach-omap2 into drivers/cpufreq, along with a few cleanups: - generalize support for better handling of different SoCs in the OMAP - use OPP layer instead of OMAP clock internals for frequency table init Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> [khilman@ti.com: move to drivers] Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-07-25Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpcLinus Torvalds1-0/+4
* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (99 commits) drivers/virt: add missing linux/interrupt.h to fsl_hypervisor.c powerpc/85xx: fix mpic configuration in CAMP mode powerpc: Copy back TIF flags on return from softirq stack powerpc/64: Make server perfmon only built on ppc64 server devices powerpc/pseries: Fix hvc_vio.c build due to recent changes powerpc: Exporting boot_cpuid_phys powerpc: Add CFAR to oops output hvc_console: Add kdb support powerpc/pseries: Fix hvterm_raw_get_chars to accept < 16 chars, fixing xmon powerpc/irq: Quieten irq mapping printks powerpc: Enable lockup and hung task detectors in pseries and ppc64 defeconfigs powerpc: Add mpt2sas driver to pseries and ppc64 defconfig powerpc: Disable IRQs off tracer in ppc64 defconfig powerpc: Sync pseries and ppc64 defconfigs powerpc/pseries/hvconsole: Fix dropped console output hvc_console: Improve tty/console put_chars handling powerpc/kdump: Fix timeout in crash_kexec_wait_realmode powerpc/mm: Fix output of total_ram. powerpc/cpufreq: Add cpufreq driver for Momentum Maple boards powerpc: Correct annotations of pmu registration functions ... Fix up trivial Kconfig/Makefile conflicts in arch/powerpc, drivers, and drivers/cpufreq
2011-07-19powerpc/cpufreq: Add cpufreq driver for Momentum Maple boardsDmitry Eremin-Solenikov1-0/+5
Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation kit and others). Driver is based on a cpufreq driver for 64-bit powermac boxes with all pmac-dependant features removed and simple cleanup applied. Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2011-07-13[CPUFREQ] Move compile for S3C64XX cpufreq to /drivers/cpufreqKukjin Kim1-1/+1
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ] Remove some vi noise that escaped into the Makefile.Dave Jones1-3/+2
2011-07-13[CPUFREQ] Move ARM Samsung cpufreq drivers to drivers/cpufreq/Kukjin Kim1-0/+2
According to discussion of the ARM arch subsystem migration, ARM cpufreq drivers move to drivers/cpufreq. So this patch adds Kconfig.arm for ARM like x86 and adds Samsung S5PV210 and EXYNOS4210 cpufreq driver compile in there. As a note, otherw will be moved. Cc: Dave Jones <davej@redhat.com> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-07-13[CPUFREQ/S3C64xx] Move S3C64xx CPUfreq driver into drivers/cpufreqMark Brown1-0/+1
This is a straight code motion patch, there are no changes to the driver itself. The Kconfig is left untouched as the ARM CPUfreq Kconfig is all in one big block in arm/Kconfig and should be moved en masse rather than being done piecemeal. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Dave Jones <davej@redhat.com>
2011-05-24cpufreq: make DB8500 cpufreq driver compileLinus Walleij1-0/+2
Concluding interface update and movement of the driver by making the DB8500 cpufreq driver compile in the cpufreq subsystem. Cc: Arnd Bergmann <arnd@arndb.de> Acked-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2011-05-19[CPUFREQ] Move x86 drivers to drivers/cpufreq/Dave Jones1-0/+26
Signed-off-by: Dave Jones <davej@redhat.com>
2005-05-31[CPUFREQ] Conservative cpufreq governerDave Jones1-0/+1
A new cpufreq module, based on the ondemand one with my additional patches just posted. This one is more suitable for battery environments where its probably more appealing to have the cpu freq gracefully increase and decrease rather than flip between the min and max freq's. N.B. Bruno Ducrot pointed out that the amd64's "do have unacceptable latency between min and max freq transition, due to the step-by-step requirements (200MHz IIRC)"; so AMD64 users would probably benefit from this too. Signed-off-by: Alexander Clouter <alex-kernel@digriz.org.uk> Signed-off-by: Dave Jones <davej@redhat.com>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+14
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!