24 Jun, 2020
1 commit
-
The Energy Model framework supports not only CPU devices. Drop the CPU
specific interface with cpumask and add struct device. Add also a return
value, user might use it. This new interface provides easy way to create
a simple Energy Model, which then might be used by e.g. thermal subsystem.Acked-by: Daniel Lezcano
Signed-off-by: Lukasz Luba
Signed-off-by: Rafael J. Wysocki
18 Jul, 2019
1 commit
-
* pm-cpufreq:
cpufreq: Make cpufreq_generic_init() return void
cpufreq: imx-cpufreq-dt: Add i.MX8MN support
cpufreq: Add QoS requests for userspace constraints
cpufreq: intel_pstate: Reuse refresh_frequency_limits()
cpufreq: Register notifiers with the PM QoS framework
PM / QoS: Add support for MIN/MAX frequency constraints
PM / QOS: Pass request type to dev_pm_qos_read_value()
PM / QOS: Rename __dev_pm_qos_read_value() and dev_pm_qos_raw_read_value()
PM / QOS: Pass request type to dev_pm_qos_{add|remove}_notifier()
16 Jul, 2019
1 commit
-
It always returns 0 (success) and its return type should really be void.
Over that, many drivers have added error handling code based on its
return value, which is not required at all.Change its return type to void and update all the callers.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
19 Jun, 2019
1 commit
-
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundationthis program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Enrico Weigelt
Reviewed-by: Kate Stewart
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman
07 Feb, 2019
1 commit
-
Try and register an Energy Model from omap-cpufreq.c to allow
interested subsystems like the task scheduler to use the provided
information.Signed-off-by: Yangtao Li
Signed-off-by: Viresh Kumar
30 Jan, 2017
1 commit
-
This patch updates dev_pm_opp_find_freq_*() routines to get a reference
to the OPPs returned by them.Also updates the users of dev_pm_opp_find_freq_*() routines to call
dev_pm_opp_put() after they are done using the OPPs.As it is guaranteed the that OPPs wouldn't get freed while being used,
the RCU read side locking present with the users isn't required anymore.
Drop it as well.This patch also updates all users of devfreq_recommended_opp() which was
returning an OPP received from the OPP core.Note that some of the OPP core routines have gained
rcu_read_{lock|unlock}() calls, as those still use RCU specific APIs
within them.Signed-off-by: Viresh Kumar
Reviewed-by: Chanwoo Choi [Devfreq]
Signed-off-by: Rafael J. Wysocki
28 May, 2016
1 commit
-
Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.I was using this definition for testing:
#define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.[ Updated the 9p parts as per Al Viro - Linus ]
Signed-off-by: Arnd Bergmann
Cc: Andrzej Hajda
Cc: Andrew Morton
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla # For nvmem part
Signed-off-by: Linus Torvalds
09 Apr, 2016
2 commits
-
Use the more common kernel style adding a define for pr_fmt.
Miscellanea:
o Remove now unused PFX defines
Signed-off-by: Joe Perches
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Use the more common logging style.
Miscellanea:
o Coalesce formats
o Realign arguments
o Add a missing space between a coalesced formatSigned-off-by: Joe Perches
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
20 Oct, 2014
1 commit
-
A platform_driver does not need to set an owner, it will be populated by the
driver core.Signed-off-by: Wolfram Sang
12 Mar, 2014
1 commit
-
freq table is not per CPU but per policy, so it makes more sense to
keep it within struct cpufreq_policy instead of a per-cpu variable.This patch does it. Over that, there is no need to set policy->freq_table
to NULL in ->exit(), as policy structure is going to be freed soon.Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
17 Jan, 2014
1 commit
-
CPUFreq drivers that use clock frameworks interface,i.e. clk_get_rate(),
to get CPUs clk rate, have similar sort of code used in most of them.This patch adds a generic ->get() which will do the same thing for them.
All those drivers are required to now is to set .get to cpufreq_generic_get()
and set their clk pointer in policy->clk during ->init().Acked-by: Hans-Christian Egtvedt
Acked-by: Shawn Guo
Acked-by: Linus Walleij
Acked-by: Shawn Guo
Acked-by: Stephen Warren
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
06 Jan, 2014
1 commit
-
Sometimes boot loaders set CPU frequency to a value outside of frequency table
present with cpufreq core. In such cases CPU might be unstable if it has to run
on that frequency for long duration of time and so its better to set it to a
frequency which is specified in frequency table.On some systems we can't really say what frequency we're running at the moment
and so for these we shouldn't check if we are running at a frequency present in
frequency table. And so we really can't force this for all the cpufreq drivers.Hence we are created another flag here: CPUFREQ_NEED_INITIAL_FREQ_CHECK that
will be marked by platforms which want to go for this check at boot time.Initially this is done for all ARM platforms but others may follow if required.
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
14 Nov, 2013
1 commit
-
With a recent change "d4019f0 cpufreq: move freq change notifications to cpufreq
core" few variables (r & ret) are removed by mistake and hence these warnings:drivers/cpufreq/omap-cpufreq.c: In function omap_target:
drivers/cpufreq/omap-cpufreq.c:64:2: error: ret undeclared (first use in this function)
drivers/cpufreq/omap-cpufreq.c:64:2: note: each undeclared identifier is reported only once for each function it appears in
drivers/cpufreq/omap-cpufreq.c:94:3: error: r undeclared (first use in this function)
drivers/cpufreq/omap-cpufreq.c:116:1: warning: control reaches end of non-void function [-Wreturn-type]Lets fix them by declaring those variables again.
Fixes: d4019f0a92ab (cpufreq: move freq change notifications to cpufreq core)
Reported-by: Sebastian Capella
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
31 Oct, 2013
1 commit
-
Most of the drivers do following in their ->target_index() routines:
struct cpufreq_freqs freqs;
freqs.old = old freq...
freqs.new = new freq...cpufreq_notify_transition(policy, &freqs, CPUFREQ_PRECHANGE);
/* Change rate here */
cpufreq_notify_transition(policy, &freqs, CPUFREQ_POSTCHANGE);
This is replicated over all cpufreq drivers today and there doesn't exists a
good enough reason why this shouldn't be moved to cpufreq core instead.There are few special cases though, like exynos5440, which doesn't do everything
on the call to ->target_index() routine and call some kind of bottom halves for
doing this work, work/tasklet/etc..They may continue doing notification from their own code as flag:
CPUFREQ_ASYNC_NOTIFICATION is already set for them.All drivers are also modified in this patch to avoid breaking 'git bisect', as
double notification would happen otherwise.Acked-by: Hans-Christian Egtvedt
Acked-by: Jesper Nilsson
Acked-by: Linus Walleij
Acked-by: Russell King
Acked-by: Stephen Warren
Tested-by: Andrew Lunn
Tested-by: Nicolas Pitre
Reviewed-by: Lan Tianyu
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
26 Oct, 2013
5 commits
-
Currently, the prototype of cpufreq_drivers target routines is:
int target(struct cpufreq_policy *policy, unsigned int target_freq,
unsigned int relation);And most of the drivers call cpufreq_frequency_table_target() to get a valid
index of their frequency table which is closest to the target_freq. And they
don't use target_freq and relation after that.So, it makes sense to just do this work in cpufreq core before calling
cpufreq_frequency_table_target() and simply pass index instead. But this can be
done only with drivers which expose their frequency table with cpufreq core. For
others we need to stick with the old prototype of target() until those drivers
are converted to expose frequency tables.This patch implements the new light weight prototype for target_index() routine.
It looks like this:int target_index(struct cpufreq_policy *policy, unsigned int index);
CPUFreq core will call cpufreq_frequency_table_target() before calling this
routine and pass index to it. Because CPUFreq core now requires to call routines
present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time.This also marks target() interface as deprecated. So, that new drivers avoid
using it. And Documentation is updated accordingly.It also converts existing .target() to newly defined light weight
.target_index() routine for many driver.Acked-by: Hans-Christian Egtvedt
Acked-by: Jesper Nilsson
Acked-by: Linus Walleij
Acked-by: Russell King
Acked-by: David S. Miller
Tested-by: Andrew Lunn
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Conflicts:
drivers/cpufreq/omap-cpufreq.c -
Since Operating Performance Points (OPP) functions are specific
to device specific power management, be specific and rename opp.h
to pm_opp.hReported-by: Randy Dunlap
Signed-off-by: Nishanth Menon
Signed-off-by: Rafael J. Wysocki -
Since Operating Performance Points (OPP) data structures are specific
to device specific power management, be specific and rename opp_* data
structures in OPP library with dev_pm_opp_* equivalent.Affected structures are:
struct opp
enum opp_eventMinor checkpatch warning resulting of this change was fixed as well.
Reported-by: Randy Dunlap
Signed-off-by: Nishanth Menon
Signed-off-by: Rafael J. Wysocki -
Since Operating Performance Points (OPP) functions are specific to
device specific power management, be specific and rename opp_*
accessors in OPP library with dev_pm_opp_* equivalent.Affected functions are:
opp_get_voltage
opp_get_freq
opp_get_opp_count
opp_find_freq_exact
opp_find_freq_floor
opp_find_freq_ceil
opp_add
opp_enable
opp_disable
opp_get_notifier
opp_init_cpufreq_table
opp_free_cpufreq_tableReported-by: Randy Dunlap
Signed-off-by: Nishanth Menon
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
16 Oct, 2013
3 commits
-
Use generic cpufreq_generic_init() routine instead of replicating the same code
here.This also rearranges the code a bit to make it more sensible. Also removes some
unnecessary checks.Cc: Santosh Shilimkar
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Many common initializations of struct policy are moved to core now and hence
this driver doesn't need to do it. This patch removes such code.Most recent of those changes is to call ->get() in the core after calling
->init().Cc: Santosh Shilimkar
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Most of the CPUFreq drivers do similar things in .exit() and .verify() routines
and .attr. So its better if we have generic routines for them which can be used
by cpufreq drivers then.This patch uses these generic routines in the OMAP driver.
Cc: Santosh Shilimkar
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
01 Oct, 2013
2 commits
-
Drivers which have an exit path must call cpufreq_frequency_table_put_attr() if
they have called cpufreq_frequency_table_get_attr() in their init path.This driver was missing this part and is fixed with this patch.
Cc: Santosh Shilimkar
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki -
Lets use cpufreq_table_validate_and_show() instead of calling
cpufreq_frequency_table_cpuinfo() and cpufreq_frequency_table_get_attr().Acked-by: Santosh Shilimkar
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
15 Jul, 2013
1 commit
-
The __cpuinit type of throwaway sections might have made sense
some time ago when RAM was more constrained, but now the savings
do not offset the cost and complications. For example, the fix in
commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time")
is a good example of the nasty type of bugs that can be created
with improper use of the various __init prefixes.After a discussion on LKML[1] it was decided that cpuinit should go
the way of devinit and be phased out. Once all the users are gone,
we can then finally remove the macros themselves from linux/init.h.This removes all the drivers/cpufreq uses of the __cpuinit macros
from all C files.[1] https://lkml.org/lkml/2013/5/20/589
[v2: leave 2nd lines of args misaligned as requested by Viresh]
Cc: "Rafael J. Wysocki"
Cc: Viresh Kumar
Cc: cpufreq@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Acked-by: Dirk Brandewie
Acked-by: Viresh Kumar
Signed-off-by: Paul Gortmaker
24 Jun, 2013
1 commit
-
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both
should be called or both shouldn't be.In case we have started PRECHANGE notifier and found an error, we must call
POSTCHANGE notifier with freqs.new = freqs.old to guarantee that sequence of
calling notifiers is complete.Omap driver was taking care of it well, but wasn't restoring freqs.new to
freqs.old in some cases. I wasn't required to add code for it as moving
PRECHANGE notifier down was a better option, so that we call it just before
starting frequency transition.Acked-by: Santosh Shilimkar
Signed-off-by: Viresh Kumar
10 Apr, 2013
1 commit
-
As multi-platform build is being adopted by more and more ARM platforms,
initcall function should be used very carefully. For example, when
CONFIG_ARM_OMAP2PLUS_CPUFREQ is built in the kernel, omap_cpufreq_init()
will be called on all the platforms to initialize omap-cpufreq driver.Further, on OMAP, we now use Soc generic cpufreq-cpu0 driver using device
tree entries. To allow cpufreq-cpu0 and omap-cpufreq drivers to co-exist
for OMAP in a single image, we need to ensure the following:
1. With device tree boot, we use cpufreq-cpu0
2. With non device tree boot, we use omap-cpufreqIn the case of (1), we will have cpu OPPs and regulator registered
as part of the device tree nodes, to ensure that omap-cpufreq
and cpufreq-cpu0 don't conflict in managing the frequency of the
same CPU, we should not permit omap-cpufreq to be probed.In the case of (2), we will not have the cpufreq-cpu0 device, hence
only omap-cpufreq will be active.To eliminate this undesired these effects, we change omap-cpufreq
driver to have it instantiated as a platform_driver and register
"omap-cpufreq" device only when booted without device tree nodes on
OMAP platforms.This allows the following:
a) Will only run on platforms that create the platform_device
"omap-cpufreq".
b) Since the platform_device is registered only when device tree nodes
are *not* populated, omap-cpufreq driver does not conflict with
the usage of cpufreq-cpu0 driver which is used on OMAP platforms when
device tree nodes are present.Inspired by commit 5553f9e26f6f49a93ba732fd222eac6973a4cf35
(cpufreq: instantiate cpufreq-cpu0 as a platform_driver)[robherring2@gmail.com: reported conflict of omap-cpufreq vs other
driver in an non-device tree supported boot]
Reported-by: Rob Herring
Signed-off-by: Nishanth Menon
Acked-by: Viresh Kumar
Signed-off-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
02 Apr, 2013
2 commits
-
Some assignments of policy-> min/max/cur/cpuinfo.min_freq/cpuinfo.max_freq
aren't required as part of it is done by cpufreq driver or cpufreq core.Remove them.
At some places we merge multiple lines together too.
Signed-off-by: Viresh Kumar
Acked-by: Sekhar Nori
Signed-off-by: Rafael J. Wysocki -
policy->cpus contains all online cpus that have single shared clock line. And
their frequencies are always updated together.Many SMP system's cpufreq drivers take care of this in individual drivers but
the best place for this code is in cpufreq core.This patch modifies cpufreq_notify_transition() to notify frequency change for
all cpus in policy->cpus and hence updates all users of this API.Signed-off-by: Viresh Kumar
Acked-by: Stephen Warren
Tested-by: Stephen Warren
Signed-off-by: Rafael J. Wysocki
02 Feb, 2013
1 commit
-
policy->shared_type field was added only for SoCs with ACPI support:
commit 3b2d99429e3386b6e2ac949fc72486509c8bbe36
Author: Venkatesh Pallipadi
Date: Wed Dec 14 15:05:00 2005 -0500P-state software coordination for ACPI core
http://bugzilla.kernel.org/show_bug.cgi?id=5737
Many non-ACPI systems are filling this field by mistake, which makes its usage
confusing. Lets clean it.Signed-off-by: Viresh Kumar
Acked-by: Santosh Shilimkar
Signed-off-by: Rafael J. Wysocki
22 Jan, 2013
1 commit
-
OPP pointer is RCU protected, hence after finding it, de-reference
also should be protected with the same RCU context else the OPP
pointer may become invalid.Reported-by: Alexander Holler
Tested-by: Alexander Holler
Acked-by: Alexander Holler
Signed-off-by: Nishanth Menon
Signed-off-by: Rafael J. Wysocki
09 Oct, 2012
4 commits
-
OMAP PM core code has moved to using the existing, generic CPU devices
for attaching OPPs, so the CPUfreq driver can now use the generic
get_cpu_device() API instead of the OMAP-specific omap_device API.This allows us to remove the last include from this driver.
Cc: Paul Walmsley
Acked-by: Rafael J. Wysocki
Signed-off-by: Kevin Hilman -
OMAP core code now has SoC-independent clock alias for the scalable
CPU clock. Using it means driver is SoC independent and will work for
AM3xxx SoCs as well as OMAP1/3/4.While here, remove some unnecessary plat/ includes that are
interfering with multi-subarch ARM kernels.Signed-off-by: Paul Walmsley
[tony@atomide.com: updated already changed clock aliases]
Signed-off-by: Tony Lindgren
[khilman@ti.com: minor shortlog/changelog updates]
Acked-by: Rafael J. Wysocki
Signed-off-by: Kevin Hilman -
The headers are going away, and this one is not used. remove it.
Acked-by: Rafael J. Wysocki
Signed-off-by: Kevin Hilman -
Ensure the clock rate that will be used is a valid one before
attempting to scale the voltage. Currently the driver assumes it has
a valid frequency from the OPP table, but boards using different
system oscillators might not have exact matches with the OPP table,
and result in a failing call to clk_set_rate().This is particularily bad because the voltage may be scaled even
though the frequency is not. This will obviously lead to some
unpredictable behavior, especially if the frequency is high and
the voltage is dropped.Thanks to Joni Lapilainen for reporting crashes seen on 3430/n900.
Reported-by: Joni Lapilainen
Acked-by: Rafael J. Wysocki
Signed-off-by: Kevin Hilman
20 Sep, 2012
1 commit
-
omap_device_get_by_hwmod_name() returns ERR_PTR on error.
Signed-off-by: Axel Lin
Acked-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
15 Sep, 2012
1 commit
-
With ARM smp common code recalculating loops_per_jiffy in a cpufreq
transiton notifier call, the loops_per_jiffy recalculate in omap-cpufreq
driver becomes redundant. Remove it.Signed-off-by: Richard Zhao
Acked-by: Santosh Shilimkar
Signed-off-by: Shawn Guo
Acked-by: Kevin Hilman
Signed-off-by: Rafael J. Wysocki
09 Aug, 2012
1 commit
-
On OMAP4, if the first CPU fails to get a valid frequency table (this
could happen if the platform does not register any OPP table), the
subsequent CPU instances end up dealing with a NULL freq_table and
crash.Check for an already existing freq_table, before trying to create one,
and increment the freq_table_users only if the table is sucessfully
created.Signed-off-by: Rajendra Nayak
Signed-off-by: Santosh Shilimkar
Cc:
Signed-off-by: Kevin Hilman
29 Mar, 2012
1 commit
-
…m/linux/kernel/git/dhowells/linux-asm_system
Pull "Disintegrate and delete asm/system.h" from David Howells:
"Here are a bunch of patches to disintegrate asm/system.h into a set of
separate bits to relieve the problem of circular inclusion
dependencies.I've built all the working defconfigs from all the arches that I can
and made sure that they don't break.The reason for these patches is that I recently encountered a circular
dependency problem that came about when I produced some patches to
optimise get_order() by rewriting it to use ilog2().This uses bitops - and on the SH arch asm/bitops.h drags in
asm-generic/get_order.h by a circuituous route involving asm/system.h.The main difficulty seems to be asm/system.h. It holds a number of
low level bits with no/few dependencies that are commonly used (eg.
memory barriers) and a number of bits with more dependencies that
aren't used in many places (eg. switch_to()).These patches break asm/system.h up into the following core pieces:
(1) asm/barrier.h
Move memory barriers here. This already done for MIPS and Alpha.
(2) asm/switch_to.h
Move switch_to() and related stuff here.
(3) asm/exec.h
Move arch_align_stack() here. Other process execution related bits
could perhaps go here from asm/processor.h.(4) asm/cmpxchg.h
Move xchg() and cmpxchg() here as they're full word atomic ops and
frequently used by atomic_xchg() and atomic_cmpxchg().(5) asm/bug.h
Move die() and related bits.
(6) asm/auxvec.h
Move AT_VECTOR_SIZE_ARCH here.
Other arch headers are created as needed on a per-arch basis."
Fixed up some conflicts from other header file cleanups and moving code
around that has happened in the meantime, so David's testing is somewhat
weakened by that. We'll find out anything that got broken and fix it..* tag 'split-asm_system_h-for-linus-20120328' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-asm_system: (38 commits)
Delete all instances of asm/system.h
Remove all #inclusions of asm/system.h
Add #includes needed to permit the removal of asm/system.h
Move all declarations of free_initmem() to linux/mm.h
Disintegrate asm/system.h for OpenRISC
Split arch_align_stack() out from asm-generic/system.h
Split the switch_to() wrapper out of asm-generic/system.h
Move the asm-generic/system.h xchg() implementation to asm-generic/cmpxchg.h
Create asm-generic/barrier.h
Make asm-generic/cmpxchg.h #include asm-generic/cmpxchg-local.h
Disintegrate asm/system.h for Xtensa
Disintegrate asm/system.h for Unicore32 [based on ver #3, changed by gxt]
Disintegrate asm/system.h for Tile
Disintegrate asm/system.h for Sparc
Disintegrate asm/system.h for SH
Disintegrate asm/system.h for Score
Disintegrate asm/system.h for S390
Disintegrate asm/system.h for PowerPC
Disintegrate asm/system.h for PA-RISC
Disintegrate asm/system.h for MN10300
...
