This reverts commit c045256d14.
It breaks build when CONFIG_PPC_SUBPAGE_PROT is not set. I will
commit a fixed version separately
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
The zero page is read-only, and has its cache state cleared during
boot. No further maintanence for this page is required.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
page_address() is a function call rather than a macro, and so:
if (page_address(page))
do_something(page_address(page));
results in two calls to this function. This is unnecessary; remove
the duplication.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
We had two copies of the wrapper code for VIVT cache flushing - one in
asm/cacheflush.h and one in arch/arm/mm/flush.c. Reduce this down to
one common copy.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
MIPS: Loongson: Switch from flatmem to sparsemem
MIPS: Loongson: Disallow 4kB pages
MIPS: Add missing definition for MADV_HWPOISON.
MIPS: Fix build error if __xchg() is not getting inlined.
MIPS: IP22/IP28 Disable early printk to fix boot problems on some systems.
Currently, with PAGE_SIZE_4KB, the kernel for loongson will hang on:
Kernel panic - not syncing: Attempted to kill init!
The possible reason is the cache aliases problem:
Loongson 2F has 64kb, 4 way L1 Cache, the way size is 16kb, which is bigger
then 4kb. so, If using 4kb page size, there is cache aliases problem.
To avoid this kind of problem, extra cache flushing. The 2nd possible
solution is 16kb page size which avoids cache aliases without the need for
extra cache flushes. So we disable 4kB pages until the aliasing issue is
solved.
Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Patchwork: http://patchwork.linux-mips.org/patch/736/
Cc: linux-mips@linux-mips.org
Cc: zhangfx@lemote.com
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
If __xchg() is not getting inlined the outline version of the function
will have a reference to __xchg_called_with_bad_pointer() which does not
exist remaining. Fixed by using BUILD_BUG_ON() to check for allowable
operand sizes.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Patchwork: http://patchwork.linux-mips.org/patch/705/
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha-2.6:
alpha: Fixup last users of irq_chip->typename
Alpha: Rearrange thread info flags fixing two regressions
arch/alpha/kernel: Add kmalloc NULL tests
arch/alpha/kernel/sys_ruffian.c: Use DIV_ROUND_CLOSEST
The semantics the PAT code expect of is_untracked_pat_range() is "is
this range completely contained inside the untracked region." This
means that checkin 8a27138924 was
technically wrong, because the implementation needlessly confusing.
The sane interface is for it to take a semiclosed range like just
about everything else (as evidenced by the sheer number of "- 1"'s
removed by that patch) so change the actual implementation to match.
Reported-by: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Jack Steiner <steiner@sgi.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
LKML-Reference: <20091119202341.GA4420@sgi.com>
The removal of the TIF_NOTIFY_RESUME flag, commit a583f1b542
"remove unused TIF_NOTIFY_RESUME flag," resulted in incorrect
setting of the unaligned access control flags by the prctl syscall.
The re-addition of the TIF_NOTIFY_RESUME flag, commit d0420c83f3
"KEYS: Extend TIF_NOTIFY_RESUME to (almost) all architectures [try #6]"
further caused problems, namely incorrect operands to assembler code
as evidenced by:
AS arch/alpha/kernel/entry.o
arch/alpha/kernel/entry.S: Assembler messages:
arch/alpha/kernel/entry.S:326: Warning: operand out of range
(0x0000000000000406 is not between 0x0000000000000000 and
0x00000000000000ff)
Both regressions fixed by (1) rearranging TIF_NOTIFY_RESUME flag to be
in lower 8 bits of the thread info flags, and (2) making sure that
ALPHA_UAC_SHIFT matches the rearrangement of the thread info flags.
Signed-off-by: Michael Cree <mcree@orcon.net.nz>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: David Howells <dhowells@redhat.com>,
Signed-off-by: Matt Turner <mattst88@gmail.com>
The documentation for the S3C6410 CPU voltage scaling is rather
unclear, with omitted values for several speed settings. Originally
the code was using only quoted values, resulting in some fairly odd
settings. The S3C6410 is also unusual in that the both the maximum
and minimum voltages quoted scale as the frequency rises, rather
than just the minimum voltage.
Clean this up a bit by always using the specified typical settings
as the minimum voltage (ignoring any specified minimum voltage) in
order to avoid running near the edge of the processor capabilities.
Also use the next quoted maximum voltages rather than the typical
voltages where no maximum voltage is quoted, allowing operation on
a greater range of systems.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Currently the transition latency reported by the S3C64xx cpufreq
driver includes both the time for the CPU to reclock itself and
the time for a regulator to change voltage. This means that if
a regulator is not in use then the transition latency reported
is excessively high.
In future the regulator API will be extended to report latencies
so the driver will be able to query the performance of a given
regulator.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
DVDD is supplied by supplies derived from the PMIC, AVDD and PVDD are
supplied from the main wall supply on the base board which runs at
5V. No option is currently supported for running without a PMIC card,
the assumption is that the regulator API will be built out when no
soft PMIC card is in use.
To ease merge issues since this uses the newly added dev_name supply
configuration from the regulator API (currently in -next only) the
fixed voltage regulator is ifdefed out when the regulator API is not
enabled.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Add lcd and backlight device definition. The pwm backlight stuff does
not allow to really set maximum pwm as with my custom driver but it's
better to use standard driver instead of out of tree driver.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
[ben-linux@fluff.org: tidy header]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Fix mach-n30.c to use the s3c_i2c0_set_platdata() call to register the
platform data with the system to get rid of any reliance on having a real
device structure available in memory.
Since s3c_i2c0_set_platdata() copies the data, mark the original as
__initdata so it is thrown away.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
The AT2440EVB should not be changing the s3c_device_sdi.name as this is
part of the initialisation process done by the CPU detection process
and actually present in arch/arm/plat-s3c24xx/s3c24xx.c.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
The mach-h1940.c file was using s3c_device_ where it really should be
calling these local definitions h1940_device to ensure they are not
mistaken for real s3c_devices when the device change is done.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Add documentation for the platform data structure in the SD/MMC driver
header file arch/arm/plat-s3c24xx/include/plat/mci.h.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Add a driver to provide DVS for the Simtec Osiris module to reduce
the power consumption whilst idling.
The DVS driver alters the voltage supplied to the ARM core depending
on the frequency it is running at. The driver itself does not do any
of the frequency alteration, which is left up to the cpufreq driver.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Add the platform/machine support for the audio devices fitted to
the Simtec range of boards since the move to ASoC.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Add required machine definitions for SDHCI controller 0, 1 and 2. SMDKC100
has 2 SDHCI/MMC ports. Port 1 is directly connected to controller 0. Port
1 can be conntected to controler 1 or 2, depending on jumper setup.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Samsung S5PC100 has 3 SDHCI controllers compatible with the one known from
previous SoCs series. Add required platform setup and support code that
the devices can be used with sdhci-s3c driver.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Samsung S5PC100 has I2C bus controller compatible with the one known from
previous SoCs series. Add required platform setup and support code that
it can be used with s3c2410-i2c driver.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Add required machine definitions for s3c-fb device.
A 800x480 lcd device (simmilar to the one known from SMDK6410 boards) has
been defined. The lcd controller is attached to GPIO lines and can be
enabled/disabled with platform-lcd driver.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Samsung S5PC100 has LCD-controller compatible with the one known from
previous SoCs series. Add required platform setup and support code that
it can be used with s3c-fb driver.
Signed-off-by: Pawel Osciak <p.osciak@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
S5PC1xx Samsung SOC series has very similar frame buffer hardware, so a lot
of the code can be shared. Moved s3c64xx-specific s3c-fb register
definitions from mach-s3c6400 to common platform directory as regs-fb-v4.h.
The new v4 file will be common for S3C6400, S3C6410, S5PC100 and possibly
others. Some s3c64xx series specific defines (palette handling) were left
in s3c-6400/mach/regs-fb.h, because it is handled differently in S5PC1xx
series.
Signed-off-by: Pawel Osciak <p.osciak@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Add CPU idle support by a call to SoC build-in power management core.
Add system reset support by a simple write to system controll register.
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
