I stumbled over two small things regarding the .index field assignment
in the dynamically created cpu frequency tables for pxa2xx and pxa3xx.

Even though that doesn't currently cause any problem, it should still be
fixed in case the logic in the CPUFREQ core changes.
Signed-off-by: NDaniel Mack <daniel@caiaq.de>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

PXA27x Errata #37 implies system will hang when switching into or out of
half turbo (HT bit in CLKCFG) mode, workaround this by not using it.
Signed-off-by: NDennis O'Brien <dennis.obrien@eqware.net>
Cc: stable-2.6.31 <stable@kernel.org>
Signed-off-by: NEric Miao <eric.y.miao@gmail.com>

Add voltage regulation capability to pxa2xx cpufreq
driver. The cpufreq will ask for a "vcc_core" regulator to
the regulator framework.

If a regulator is found at probe time, it will be used with
values specified in PXA270 Electrical, Mechanical, and
Thermal Specifications.

If not, it will be assumed for now that frequency change
will work without voltage control. This assumes that the
IPL/SPL installs sane values to an existing voltage
regulator (ie. voltage high enough to support the full
range).
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Considering the header mess ATM, it is not always possible to include
the correct header files within board code. Let's keep this simple:

  <mach/pxa25x.h>  - for pxa25x based platforms
  <mach/pxa27x.h>  - for pxa27x based platforms
  <mach/pxa300.h>  - for pxa300 based platforms
  <mach/pxa320.h>  - for pxa320 based platforms
  <mach/pxa930.h>  - for pxa930 based platforms

NOTE:

1. one header one board file, they are not compatible (i.e. they have
   conflicting definitions which won't compile if included together).

2. Unless strictly necessary, the following header files are considered
   to be SoC files use _only_, and is not recommended to be included in
   board code:

    <mach/hardware.h>
    <mach/pxa-regs.h>
    <mach/pxa2xx-regs.h>
    <mach/pxa3xx-regs.h>
    <mach/mfp.h>
    <mach/mfp-pxa2xx.h>
    <mach/mfp-pxa25x.h>
    <mach/mfp-pxa27x.h>
    <mach/mfp-pxa3xx.h>
    <mach/mfp-pxa300.h>
    <mach/mfp-pxa320.h>
    <mach/mfp-pxa930.h>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

This patch implements Eric Miao's idea to detect the correct value of
sdram_rows by inspecting the MDCNFG register settings.
It is only tested on two pxa27x devices with 64MB RAM (magician and
hx4700) so far.
Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

Following the removal of the "->policy" usage for PXA255 in patch
459fc208 (cpufreq: remove
policy->governor setting in drivers initialization), this patch
introduces an option (called "pxa255_turbo_table") to select either
the "run" or "turbo" frequency table.

It also cures the runtime warning that was printed each time the
frequency was changed.

Got rid of all references to CPUFREQ_POLICY_* for pxa255, and sticked
with the run/turbo thing.

Tested on an Arcom/Eurotech Viper.
Signed-off-by: NMarc Zyngier <maz@misterjones.org>
Acked-by: NDominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: NEric Miao <eric.miao@marvell.com>

As policy->governor is already set to CPUFREQ_DEFAULT_GOVERNOR in the
(always built-in) cpufreq core, we do not need to set it in the drivers.
This fixes the sparc64 allmodconfig build failure.

Also, remove a totally useles setting of ->policy in cpufreq-pxa3xx.c.
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
Acked-by: NDavid S. Miller <davem@davemloft.net>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NEric Miao <eric.miao@marvell.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This just leaves include/asm-arm/plat-* to deal with.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Remove includes of asm/hardware.h in addition to asm/arch/hardware.h.
Then, since asm/hardware.h only exists to include asm/arch/hardware.h,
update everything to directly include asm/arch/hardware.h and remove
asm/hardware.h.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

PXA cpus maximum frequency depends on the cpu (624 for
pxa270, 520 for pxa272, 416 for pxa271). It should be
provided on kernel or module start (cpu-pxa
pxa27x_maxfreq parameter).

Make use of cpufreq_frequency_table_cpuinfo (patch by Bill
Reese provided by Philipp Zabel).

Some additionnal fixes from Philipp Zabel include :
 * rename PXA cpufreq driver to reflect added PXA27x support
 * remove unused variable ramstart from PXA cpufreq driver
Signed-off-by: NPhilipp Zabel <philipp.zabel@gmail.com>
Signed-off-by: NRobert Jarzmik <rjarzmik@free.fr>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

These indentation corrections prepare the pxa27x support.
Signed-off-by: NRobert Jarzmik <rjarzmik@free.fr>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Convert debug-only (and removed) MODULE_PARM() to module_param().
Compiles cleanly (with DEBUG=1).
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

The .get method is needed for suspend/resume. Otherwise you
get this in dmesg:

cpufreq: suspend failed to assert current frequency is what timing core thinks it is.
cpufreq: resume failed to assert current frequency is what timing core thinks it is.
Signed-off-by: NHolger Schurig <hs4233@mail.mn-solutions.de>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

PXA3 has a different memory controller from PXA2 platforms.  Avoid
clashing definitions by moving the PXA2 definitions to pxa2xx-regs.h
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

There have been patches hanging around for ages to add support for
cpufreq to PXA255 processors.  It's about time we applied one.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>