Merge branch 'master' into sh/hw-breakpoints
This commit is contained in:
commit
fa94ddea2b
|
@ -21,25 +21,27 @@ Contact: Alan Stern <stern@rowland.harvard.edu>
|
||||||
Description:
|
Description:
|
||||||
Each USB device directory will contain a file named
|
Each USB device directory will contain a file named
|
||||||
power/level. This file holds a power-level setting for
|
power/level. This file holds a power-level setting for
|
||||||
the device, one of "on", "auto", or "suspend".
|
the device, either "on" or "auto".
|
||||||
|
|
||||||
"on" means that the device is not allowed to autosuspend,
|
"on" means that the device is not allowed to autosuspend,
|
||||||
although normal suspends for system sleep will still
|
although normal suspends for system sleep will still
|
||||||
be honored. "auto" means the device will autosuspend
|
be honored. "auto" means the device will autosuspend
|
||||||
and autoresume in the usual manner, according to the
|
and autoresume in the usual manner, according to the
|
||||||
capabilities of its driver. "suspend" means the device
|
capabilities of its driver.
|
||||||
is forced into a suspended state and it will not autoresume
|
|
||||||
in response to I/O requests. However remote-wakeup requests
|
|
||||||
from the device may still be enabled (the remote-wakeup
|
|
||||||
setting is controlled separately by the power/wakeup
|
|
||||||
attribute).
|
|
||||||
|
|
||||||
During normal use, devices should be left in the "auto"
|
During normal use, devices should be left in the "auto"
|
||||||
level. The other levels are meant for administrative uses.
|
level. The "on" level is meant for administrative uses.
|
||||||
If you want to suspend a device immediately but leave it
|
If you want to suspend a device immediately but leave it
|
||||||
free to wake up in response to I/O requests, you should
|
free to wake up in response to I/O requests, you should
|
||||||
write "0" to power/autosuspend.
|
write "0" to power/autosuspend.
|
||||||
|
|
||||||
|
Device not capable of proper suspend and resume should be
|
||||||
|
left in the "on" level. Although the USB spec requires
|
||||||
|
devices to support suspend/resume, many of them do not.
|
||||||
|
In fact so many don't that by default, the USB core
|
||||||
|
initializes all non-hub devices in the "on" level. Some
|
||||||
|
drivers may change this setting when they are bound.
|
||||||
|
|
||||||
What: /sys/bus/usb/devices/.../power/persist
|
What: /sys/bus/usb/devices/.../power/persist
|
||||||
Date: May 2007
|
Date: May 2007
|
||||||
KernelVersion: 2.6.23
|
KernelVersion: 2.6.23
|
||||||
|
|
|
@ -226,5 +226,5 @@ struct driver_attribute driver_attr_debug;
|
||||||
This can then be used to add and remove the attribute from the
|
This can then be used to add and remove the attribute from the
|
||||||
driver's directory using:
|
driver's directory using:
|
||||||
|
|
||||||
int driver_create_file(struct device_driver *, struct driver_attribute *);
|
int driver_create_file(struct device_driver *, const struct driver_attribute *);
|
||||||
void driver_remove_file(struct device_driver *, struct driver_attribute *);
|
void driver_remove_file(struct device_driver *, const struct driver_attribute *);
|
||||||
|
|
|
@ -91,8 +91,8 @@ struct device_attribute {
|
||||||
const char *buf, size_t count);
|
const char *buf, size_t count);
|
||||||
};
|
};
|
||||||
|
|
||||||
int device_create_file(struct device *, struct device_attribute *);
|
int device_create_file(struct device *, const struct device_attribute *);
|
||||||
void device_remove_file(struct device *, struct device_attribute *);
|
void device_remove_file(struct device *, const struct device_attribute *);
|
||||||
|
|
||||||
It also defines this helper for defining device attributes:
|
It also defines this helper for defining device attributes:
|
||||||
|
|
||||||
|
@ -316,8 +316,8 @@ DEVICE_ATTR(_name, _mode, _show, _store);
|
||||||
|
|
||||||
Creation/Removal:
|
Creation/Removal:
|
||||||
|
|
||||||
int device_create_file(struct device *device, struct device_attribute * attr);
|
int device_create_file(struct device *dev, const struct device_attribute * attr);
|
||||||
void device_remove_file(struct device * dev, struct device_attribute * attr);
|
void device_remove_file(struct device *dev, const struct device_attribute * attr);
|
||||||
|
|
||||||
|
|
||||||
- bus drivers (include/linux/device.h)
|
- bus drivers (include/linux/device.h)
|
||||||
|
@ -358,7 +358,7 @@ DRIVER_ATTR(_name, _mode, _show, _store)
|
||||||
|
|
||||||
Creation/Removal:
|
Creation/Removal:
|
||||||
|
|
||||||
int driver_create_file(struct device_driver *, struct driver_attribute *);
|
int driver_create_file(struct device_driver *, const struct driver_attribute *);
|
||||||
void driver_remove_file(struct device_driver *, struct driver_attribute *);
|
void driver_remove_file(struct device_driver *, const struct driver_attribute *);
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -42,80 +42,81 @@ struct dev_pm_ops {
|
||||||
...
|
...
|
||||||
};
|
};
|
||||||
|
|
||||||
The ->runtime_suspend() callback is executed by the PM core for the bus type of
|
The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks are
|
||||||
the device being suspended. The bus type's callback is then _entirely_
|
executed by the PM core for either the bus type, or device type (if the bus
|
||||||
_responsible_ for handling the device as appropriate, which may, but need not
|
type's callback is not defined), or device class (if the bus type's and device
|
||||||
include executing the device driver's own ->runtime_suspend() callback (from the
|
type's callbacks are not defined) of given device. The bus type, device type
|
||||||
PM core's point of view it is not necessary to implement a ->runtime_suspend()
|
and device class callbacks are referred to as subsystem-level callbacks in what
|
||||||
callback in a device driver as long as the bus type's ->runtime_suspend() knows
|
follows.
|
||||||
what to do to handle the device).
|
|
||||||
|
|
||||||
* Once the bus type's ->runtime_suspend() callback has completed successfully
|
The subsystem-level suspend callback is _entirely_ _responsible_ for handling
|
||||||
|
the suspend of the device as appropriate, which may, but need not include
|
||||||
|
executing the device driver's own ->runtime_suspend() callback (from the
|
||||||
|
PM core's point of view it is not necessary to implement a ->runtime_suspend()
|
||||||
|
callback in a device driver as long as the subsystem-level suspend callback
|
||||||
|
knows what to do to handle the device).
|
||||||
|
|
||||||
|
* Once the subsystem-level suspend callback has completed successfully
|
||||||
for given device, the PM core regards the device as suspended, which need
|
for given device, the PM core regards the device as suspended, which need
|
||||||
not mean that the device has been put into a low power state. It is
|
not mean that the device has been put into a low power state. It is
|
||||||
supposed to mean, however, that the device will not process data and will
|
supposed to mean, however, that the device will not process data and will
|
||||||
not communicate with the CPU(s) and RAM until its bus type's
|
not communicate with the CPU(s) and RAM until the subsystem-level resume
|
||||||
->runtime_resume() callback is executed for it. The run-time PM status of
|
callback is executed for it. The run-time PM status of a device after
|
||||||
a device after successful execution of its bus type's ->runtime_suspend()
|
successful execution of the subsystem-level suspend callback is 'suspended'.
|
||||||
callback is 'suspended'.
|
|
||||||
|
|
||||||
* If the bus type's ->runtime_suspend() callback returns -EBUSY or -EAGAIN,
|
* If the subsystem-level suspend callback returns -EBUSY or -EAGAIN,
|
||||||
the device's run-time PM status is supposed to be 'active', which means that
|
the device's run-time PM status is 'active', which means that the device
|
||||||
the device _must_ be fully operational afterwards.
|
_must_ be fully operational afterwards.
|
||||||
|
|
||||||
* If the bus type's ->runtime_suspend() callback returns an error code
|
* If the subsystem-level suspend callback returns an error code different
|
||||||
different from -EBUSY or -EAGAIN, the PM core regards this as a fatal
|
from -EBUSY or -EAGAIN, the PM core regards this as a fatal error and will
|
||||||
error and will refuse to run the helper functions described in Section 4
|
refuse to run the helper functions described in Section 4 for the device,
|
||||||
for the device, until the status of it is directly set either to 'active'
|
until the status of it is directly set either to 'active', or to 'suspended'
|
||||||
or to 'suspended' (the PM core provides special helper functions for this
|
(the PM core provides special helper functions for this purpose).
|
||||||
purpose).
|
|
||||||
|
|
||||||
In particular, if the driver requires remote wakeup capability for proper
|
In particular, if the driver requires remote wake-up capability (i.e. hardware
|
||||||
functioning and device_run_wake() returns 'false' for the device, then
|
mechanism allowing the device to request a change of its power state, such as
|
||||||
->runtime_suspend() should return -EBUSY. On the other hand, if
|
PCI PME) for proper functioning and device_run_wake() returns 'false' for the
|
||||||
device_run_wake() returns 'true' for the device and the device is put
|
device, then ->runtime_suspend() should return -EBUSY. On the other hand, if
|
||||||
into a low power state during the execution of its bus type's
|
device_run_wake() returns 'true' for the device and the device is put into a low
|
||||||
->runtime_suspend(), it is expected that remote wake-up (i.e. hardware mechanism
|
power state during the execution of the subsystem-level suspend callback, it is
|
||||||
allowing the device to request a change of its power state, such as PCI PME)
|
expected that remote wake-up will be enabled for the device. Generally, remote
|
||||||
will be enabled for the device. Generally, remote wake-up should be enabled
|
wake-up should be enabled for all input devices put into a low power state at
|
||||||
for all input devices put into a low power state at run time.
|
run time.
|
||||||
|
|
||||||
The ->runtime_resume() callback is executed by the PM core for the bus type of
|
The subsystem-level resume callback is _entirely_ _responsible_ for handling the
|
||||||
the device being woken up. The bus type's callback is then _entirely_
|
resume of the device as appropriate, which may, but need not include executing
|
||||||
_responsible_ for handling the device as appropriate, which may, but need not
|
the device driver's own ->runtime_resume() callback (from the PM core's point of
|
||||||
include executing the device driver's own ->runtime_resume() callback (from the
|
view it is not necessary to implement a ->runtime_resume() callback in a device
|
||||||
PM core's point of view it is not necessary to implement a ->runtime_resume()
|
driver as long as the subsystem-level resume callback knows what to do to handle
|
||||||
callback in a device driver as long as the bus type's ->runtime_resume() knows
|
the device).
|
||||||
what to do to handle the device).
|
|
||||||
|
|
||||||
* Once the bus type's ->runtime_resume() callback has completed successfully,
|
* Once the subsystem-level resume callback has completed successfully, the PM
|
||||||
the PM core regards the device as fully operational, which means that the
|
core regards the device as fully operational, which means that the device
|
||||||
device _must_ be able to complete I/O operations as needed. The run-time
|
_must_ be able to complete I/O operations as needed. The run-time PM status
|
||||||
PM status of the device is then 'active'.
|
of the device is then 'active'.
|
||||||
|
|
||||||
* If the bus type's ->runtime_resume() callback returns an error code, the PM
|
* If the subsystem-level resume callback returns an error code, the PM core
|
||||||
core regards this as a fatal error and will refuse to run the helper
|
regards this as a fatal error and will refuse to run the helper functions
|
||||||
functions described in Section 4 for the device, until its status is
|
described in Section 4 for the device, until its status is directly set
|
||||||
directly set either to 'active' or to 'suspended' (the PM core provides
|
either to 'active' or to 'suspended' (the PM core provides special helper
|
||||||
special helper functions for this purpose).
|
functions for this purpose).
|
||||||
|
|
||||||
The ->runtime_idle() callback is executed by the PM core for the bus type of
|
The subsystem-level idle callback is executed by the PM core whenever the device
|
||||||
given device whenever the device appears to be idle, which is indicated to the
|
appears to be idle, which is indicated to the PM core by two counters, the
|
||||||
PM core by two counters, the device's usage counter and the counter of 'active'
|
device's usage counter and the counter of 'active' children of the device.
|
||||||
children of the device.
|
|
||||||
|
|
||||||
* If any of these counters is decreased using a helper function provided by
|
* If any of these counters is decreased using a helper function provided by
|
||||||
the PM core and it turns out to be equal to zero, the other counter is
|
the PM core and it turns out to be equal to zero, the other counter is
|
||||||
checked. If that counter also is equal to zero, the PM core executes the
|
checked. If that counter also is equal to zero, the PM core executes the
|
||||||
device bus type's ->runtime_idle() callback (with the device as an
|
subsystem-level idle callback with the device as an argument.
|
||||||
argument).
|
|
||||||
|
|
||||||
The action performed by a bus type's ->runtime_idle() callback is totally
|
The action performed by a subsystem-level idle callback is totally dependent on
|
||||||
dependent on the bus type in question, but the expected and recommended action
|
the subsystem in question, but the expected and recommended action is to check
|
||||||
is to check if the device can be suspended (i.e. if all of the conditions
|
if the device can be suspended (i.e. if all of the conditions necessary for
|
||||||
necessary for suspending the device are satisfied) and to queue up a suspend
|
suspending the device are satisfied) and to queue up a suspend request for the
|
||||||
request for the device in that case. The value returned by this callback is
|
device in that case. The value returned by this callback is ignored by the PM
|
||||||
ignored by the PM core.
|
core.
|
||||||
|
|
||||||
The helper functions provided by the PM core, described in Section 4, guarantee
|
The helper functions provided by the PM core, described in Section 4, guarantee
|
||||||
that the following constraints are met with respect to the bus type's run-time
|
that the following constraints are met with respect to the bus type's run-time
|
||||||
|
@ -238,41 +239,41 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
|
||||||
removing the device from device hierarchy
|
removing the device from device hierarchy
|
||||||
|
|
||||||
int pm_runtime_idle(struct device *dev);
|
int pm_runtime_idle(struct device *dev);
|
||||||
- execute ->runtime_idle() for the device's bus type; returns 0 on success
|
- execute the subsystem-level idle callback for the device; returns 0 on
|
||||||
or error code on failure, where -EINPROGRESS means that ->runtime_idle()
|
success or error code on failure, where -EINPROGRESS means that
|
||||||
is already being executed
|
->runtime_idle() is already being executed
|
||||||
|
|
||||||
int pm_runtime_suspend(struct device *dev);
|
int pm_runtime_suspend(struct device *dev);
|
||||||
- execute ->runtime_suspend() for the device's bus type; returns 0 on
|
- execute the subsystem-level suspend callback for the device; returns 0 on
|
||||||
success, 1 if the device's run-time PM status was already 'suspended', or
|
success, 1 if the device's run-time PM status was already 'suspended', or
|
||||||
error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt
|
error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt
|
||||||
to suspend the device again in future
|
to suspend the device again in future
|
||||||
|
|
||||||
int pm_runtime_resume(struct device *dev);
|
int pm_runtime_resume(struct device *dev);
|
||||||
- execute ->runtime_resume() for the device's bus type; returns 0 on
|
- execute the subsystem-leve resume callback for the device; returns 0 on
|
||||||
success, 1 if the device's run-time PM status was already 'active' or
|
success, 1 if the device's run-time PM status was already 'active' or
|
||||||
error code on failure, where -EAGAIN means it may be safe to attempt to
|
error code on failure, where -EAGAIN means it may be safe to attempt to
|
||||||
resume the device again in future, but 'power.runtime_error' should be
|
resume the device again in future, but 'power.runtime_error' should be
|
||||||
checked additionally
|
checked additionally
|
||||||
|
|
||||||
int pm_request_idle(struct device *dev);
|
int pm_request_idle(struct device *dev);
|
||||||
- submit a request to execute ->runtime_idle() for the device's bus type
|
- submit a request to execute the subsystem-level idle callback for the
|
||||||
(the request is represented by a work item in pm_wq); returns 0 on success
|
device (the request is represented by a work item in pm_wq); returns 0 on
|
||||||
or error code if the request has not been queued up
|
success or error code if the request has not been queued up
|
||||||
|
|
||||||
int pm_schedule_suspend(struct device *dev, unsigned int delay);
|
int pm_schedule_suspend(struct device *dev, unsigned int delay);
|
||||||
- schedule the execution of ->runtime_suspend() for the device's bus type
|
- schedule the execution of the subsystem-level suspend callback for the
|
||||||
in future, where 'delay' is the time to wait before queuing up a suspend
|
device in future, where 'delay' is the time to wait before queuing up a
|
||||||
work item in pm_wq, in milliseconds (if 'delay' is zero, the work item is
|
suspend work item in pm_wq, in milliseconds (if 'delay' is zero, the work
|
||||||
queued up immediately); returns 0 on success, 1 if the device's PM
|
item is queued up immediately); returns 0 on success, 1 if the device's PM
|
||||||
run-time status was already 'suspended', or error code if the request
|
run-time status was already 'suspended', or error code if the request
|
||||||
hasn't been scheduled (or queued up if 'delay' is 0); if the execution of
|
hasn't been scheduled (or queued up if 'delay' is 0); if the execution of
|
||||||
->runtime_suspend() is already scheduled and not yet expired, the new
|
->runtime_suspend() is already scheduled and not yet expired, the new
|
||||||
value of 'delay' will be used as the time to wait
|
value of 'delay' will be used as the time to wait
|
||||||
|
|
||||||
int pm_request_resume(struct device *dev);
|
int pm_request_resume(struct device *dev);
|
||||||
- submit a request to execute ->runtime_resume() for the device's bus type
|
- submit a request to execute the subsystem-level resume callback for the
|
||||||
(the request is represented by a work item in pm_wq); returns 0 on
|
device (the request is represented by a work item in pm_wq); returns 0 on
|
||||||
success, 1 if the device's run-time PM status was already 'active', or
|
success, 1 if the device's run-time PM status was already 'active', or
|
||||||
error code if the request hasn't been queued up
|
error code if the request hasn't been queued up
|
||||||
|
|
||||||
|
@ -303,12 +304,12 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
|
||||||
run-time PM callbacks described in Section 2
|
run-time PM callbacks described in Section 2
|
||||||
|
|
||||||
int pm_runtime_disable(struct device *dev);
|
int pm_runtime_disable(struct device *dev);
|
||||||
- prevent the run-time PM helper functions from running the device bus
|
- prevent the run-time PM helper functions from running subsystem-level
|
||||||
type's run-time PM callbacks, make sure that all of the pending run-time
|
run-time PM callbacks for the device, make sure that all of the pending
|
||||||
PM operations on the device are either completed or canceled; returns
|
run-time PM operations on the device are either completed or canceled;
|
||||||
1 if there was a resume request pending and it was necessary to execute
|
returns 1 if there was a resume request pending and it was necessary to
|
||||||
->runtime_resume() for the device's bus type to satisfy that request,
|
execute the subsystem-level resume callback for the device to satisfy that
|
||||||
otherwise 0 is returned
|
request, otherwise 0 is returned
|
||||||
|
|
||||||
void pm_suspend_ignore_children(struct device *dev, bool enable);
|
void pm_suspend_ignore_children(struct device *dev, bool enable);
|
||||||
- set/unset the power.ignore_children flag of the device
|
- set/unset the power.ignore_children flag of the device
|
||||||
|
@ -378,5 +379,55 @@ pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts,
|
||||||
they will fail returning -EAGAIN, because the device's usage counter is
|
they will fail returning -EAGAIN, because the device's usage counter is
|
||||||
incremented by the core before executing ->probe() and ->remove(). Still, it
|
incremented by the core before executing ->probe() and ->remove(). Still, it
|
||||||
may be desirable to suspend the device as soon as ->probe() or ->remove() has
|
may be desirable to suspend the device as soon as ->probe() or ->remove() has
|
||||||
finished, so the PM core uses pm_runtime_idle_sync() to invoke the device bus
|
finished, so the PM core uses pm_runtime_idle_sync() to invoke the
|
||||||
type's ->runtime_idle() callback at that time.
|
subsystem-level idle callback for the device at that time.
|
||||||
|
|
||||||
|
6. Run-time PM and System Sleep
|
||||||
|
|
||||||
|
Run-time PM and system sleep (i.e., system suspend and hibernation, also known
|
||||||
|
as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of
|
||||||
|
ways. If a device is active when a system sleep starts, everything is
|
||||||
|
straightforward. But what should happen if the device is already suspended?
|
||||||
|
|
||||||
|
The device may have different wake-up settings for run-time PM and system sleep.
|
||||||
|
For example, remote wake-up may be enabled for run-time suspend but disallowed
|
||||||
|
for system sleep (device_may_wakeup(dev) returns 'false'). When this happens,
|
||||||
|
the subsystem-level system suspend callback is responsible for changing the
|
||||||
|
device's wake-up setting (it may leave that to the device driver's system
|
||||||
|
suspend routine). It may be necessary to resume the device and suspend it again
|
||||||
|
in order to do so. The same is true if the driver uses different power levels
|
||||||
|
or other settings for run-time suspend and system sleep.
|
||||||
|
|
||||||
|
During system resume, devices generally should be brought back to full power,
|
||||||
|
even if they were suspended before the system sleep began. There are several
|
||||||
|
reasons for this, including:
|
||||||
|
|
||||||
|
* The device might need to switch power levels, wake-up settings, etc.
|
||||||
|
|
||||||
|
* Remote wake-up events might have been lost by the firmware.
|
||||||
|
|
||||||
|
* The device's children may need the device to be at full power in order
|
||||||
|
to resume themselves.
|
||||||
|
|
||||||
|
* The driver's idea of the device state may not agree with the device's
|
||||||
|
physical state. This can happen during resume from hibernation.
|
||||||
|
|
||||||
|
* The device might need to be reset.
|
||||||
|
|
||||||
|
* Even though the device was suspended, if its usage counter was > 0 then most
|
||||||
|
likely it would need a run-time resume in the near future anyway.
|
||||||
|
|
||||||
|
* Always going back to full power is simplest.
|
||||||
|
|
||||||
|
If the device was suspended before the sleep began, then its run-time PM status
|
||||||
|
will have to be updated to reflect the actual post-system sleep status. The way
|
||||||
|
to do this is:
|
||||||
|
|
||||||
|
pm_runtime_disable(dev);
|
||||||
|
pm_runtime_set_active(dev);
|
||||||
|
pm_runtime_enable(dev);
|
||||||
|
|
||||||
|
The PM core always increments the run-time usage counter before calling the
|
||||||
|
->prepare() callback and decrements it after calling the ->complete() callback.
|
||||||
|
Hence disabling run-time PM temporarily like this will not cause any run-time
|
||||||
|
suspend callbacks to be lost.
|
||||||
|
|
|
@ -0,0 +1,42 @@
|
||||||
|
* OpenPIC and its interrupt numbers on Freescale's e500/e600 cores
|
||||||
|
|
||||||
|
The OpenPIC specification does not specify which interrupt source has to
|
||||||
|
become which interrupt number. This is up to the software implementation
|
||||||
|
of the interrupt controller. The only requirement is that every
|
||||||
|
interrupt source has to have an unique interrupt number / vector number.
|
||||||
|
To accomplish this the current implementation assigns the number zero to
|
||||||
|
the first source, the number one to the second source and so on until
|
||||||
|
all interrupt sources have their unique number.
|
||||||
|
Usually the assigned vector number equals the interrupt number mentioned
|
||||||
|
in the documentation for a given core / CPU. This is however not true
|
||||||
|
for the e500 cores (MPC85XX CPUs) where the documentation distinguishes
|
||||||
|
between internal and external interrupt sources and starts counting at
|
||||||
|
zero for both of them.
|
||||||
|
|
||||||
|
So what to write for external interrupt source X or internal interrupt
|
||||||
|
source Y into the device tree? Here is an example:
|
||||||
|
|
||||||
|
The memory map for the interrupt controller in the MPC8544[0] shows,
|
||||||
|
that the first interrupt source starts at 0x5_0000 (PIC Register Address
|
||||||
|
Map-Interrupt Source Configuration Registers). This source becomes the
|
||||||
|
number zero therefore:
|
||||||
|
External interrupt 0 = interrupt number 0
|
||||||
|
External interrupt 1 = interrupt number 1
|
||||||
|
External interrupt 2 = interrupt number 2
|
||||||
|
...
|
||||||
|
Every interrupt number allocates 0x20 bytes register space. So to get
|
||||||
|
its number it is sufficient to shift the lower 16bits to right by five.
|
||||||
|
So for the external interrupt 10 we have:
|
||||||
|
0x0140 >> 5 = 10
|
||||||
|
|
||||||
|
After the external sources, the internal sources follow. The in core I2C
|
||||||
|
controller on the MPC8544 for instance has the internal source number
|
||||||
|
27. Oo obtain its interrupt number we take the lower 16bits of its memory
|
||||||
|
address (0x5_0560) and shift it right:
|
||||||
|
0x0560 >> 5 = 43
|
||||||
|
|
||||||
|
Therefore the I2C device node for the MPC8544 CPU has to have the
|
||||||
|
interrupt number 43 specified in the device tree.
|
||||||
|
|
||||||
|
[0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual
|
||||||
|
MPC8544ERM Rev. 1 10/2007
|
|
@ -403,4 +403,5 @@ STAC9872
|
||||||
Cirrus Logic CS4206/4207
|
Cirrus Logic CS4206/4207
|
||||||
========================
|
========================
|
||||||
mbp55 MacBook Pro 5,5
|
mbp55 MacBook Pro 5,5
|
||||||
|
imac27 IMac 27 Inch
|
||||||
auto BIOS setup (default)
|
auto BIOS setup (default)
|
||||||
|
|
|
@ -26,13 +26,33 @@ Procedure for submitting patches to the -stable tree:
|
||||||
|
|
||||||
- Send the patch, after verifying that it follows the above rules, to
|
- Send the patch, after verifying that it follows the above rules, to
|
||||||
stable@kernel.org.
|
stable@kernel.org.
|
||||||
|
- To have the patch automatically included in the stable tree, add the
|
||||||
|
the tag
|
||||||
|
Cc: stable@kernel.org
|
||||||
|
in the sign-off area. Once the patch is merged it will be applied to
|
||||||
|
the stable tree without anything else needing to be done by the author
|
||||||
|
or subsystem maintainer.
|
||||||
|
- If the patch requires other patches as prerequisites which can be
|
||||||
|
cherry-picked than this can be specified in the following format in
|
||||||
|
the sign-off area:
|
||||||
|
|
||||||
|
Cc: <stable@kernel.org> # .32.x: a1f84a3: sched: Check for idle
|
||||||
|
Cc: <stable@kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
|
||||||
|
Cc: <stable@kernel.org> # .32.x: fd21073: sched: Fix affinity logic
|
||||||
|
Cc: <stable@kernel.org> # .32.x
|
||||||
|
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
||||||
|
|
||||||
|
The tag sequence has the meaning of:
|
||||||
|
git cherry-pick a1f84a3
|
||||||
|
git cherry-pick 1b9508f
|
||||||
|
git cherry-pick fd21073
|
||||||
|
git cherry-pick <this commit>
|
||||||
|
|
||||||
- The sender will receive an ACK when the patch has been accepted into the
|
- The sender will receive an ACK when the patch has been accepted into the
|
||||||
queue, or a NAK if the patch is rejected. This response might take a few
|
queue, or a NAK if the patch is rejected. This response might take a few
|
||||||
days, according to the developer's schedules.
|
days, according to the developer's schedules.
|
||||||
- If accepted, the patch will be added to the -stable queue, for review by
|
- If accepted, the patch will be added to the -stable queue, for review by
|
||||||
other developers and by the relevant subsystem maintainer.
|
other developers and by the relevant subsystem maintainer.
|
||||||
- If the stable@kernel.org address is added to a patch, when it goes into
|
|
||||||
Linus's tree it will automatically be emailed to the stable team.
|
|
||||||
- Security patches should not be sent to this alias, but instead to the
|
- Security patches should not be sent to this alias, but instead to the
|
||||||
documented security@kernel.org address.
|
documented security@kernel.org address.
|
||||||
|
|
||||||
|
|
|
@ -1,7 +1,7 @@
|
||||||
Subsystem Trace Points: kmem
|
Subsystem Trace Points: kmem
|
||||||
|
|
||||||
The tracing system kmem captures events related to object and page allocation
|
The kmem tracing system captures events related to object and page allocation
|
||||||
within the kernel. Broadly speaking there are four major subheadings.
|
within the kernel. Broadly speaking there are five major subheadings.
|
||||||
|
|
||||||
o Slab allocation of small objects of unknown type (kmalloc)
|
o Slab allocation of small objects of unknown type (kmalloc)
|
||||||
o Slab allocation of small objects of known type
|
o Slab allocation of small objects of known type
|
||||||
|
@ -9,7 +9,7 @@ within the kernel. Broadly speaking there are four major subheadings.
|
||||||
o Per-CPU Allocator Activity
|
o Per-CPU Allocator Activity
|
||||||
o External Fragmentation
|
o External Fragmentation
|
||||||
|
|
||||||
This document will describe what each of the tracepoints are and why they
|
This document describes what each of the tracepoints is and why they
|
||||||
might be useful.
|
might be useful.
|
||||||
|
|
||||||
1. Slab allocation of small objects of unknown type
|
1. Slab allocation of small objects of unknown type
|
||||||
|
@ -34,7 +34,7 @@ kmem_cache_free call_site=%lx ptr=%p
|
||||||
These events are similar in usage to the kmalloc-related events except that
|
These events are similar in usage to the kmalloc-related events except that
|
||||||
it is likely easier to pin the event down to a specific cache. At the time
|
it is likely easier to pin the event down to a specific cache. At the time
|
||||||
of writing, no information is available on what slab is being allocated from,
|
of writing, no information is available on what slab is being allocated from,
|
||||||
but the call_site can usually be used to extrapolate that information
|
but the call_site can usually be used to extrapolate that information.
|
||||||
|
|
||||||
3. Page allocation
|
3. Page allocation
|
||||||
==================
|
==================
|
||||||
|
@ -80,9 +80,9 @@ event indicating whether it is for a percpu_refill or not.
|
||||||
When the per-CPU list is too full, a number of pages are freed, each one
|
When the per-CPU list is too full, a number of pages are freed, each one
|
||||||
which triggers a mm_page_pcpu_drain event.
|
which triggers a mm_page_pcpu_drain event.
|
||||||
|
|
||||||
The individual nature of the events are so that pages can be tracked
|
The individual nature of the events is so that pages can be tracked
|
||||||
between allocation and freeing. A number of drain or refill pages that occur
|
between allocation and freeing. A number of drain or refill pages that occur
|
||||||
consecutively imply the zone->lock being taken once. Large amounts of PCP
|
consecutively imply the zone->lock being taken once. Large amounts of per-CPU
|
||||||
refills and drains could imply an imbalance between CPUs where too much work
|
refills and drains could imply an imbalance between CPUs where too much work
|
||||||
is being concentrated in one place. It could also indicate that the per-CPU
|
is being concentrated in one place. It could also indicate that the per-CPU
|
||||||
lists should be a larger size. Finally, large amounts of refills on one CPU
|
lists should be a larger size. Finally, large amounts of refills on one CPU
|
||||||
|
@ -102,6 +102,6 @@ is important.
|
||||||
|
|
||||||
Large numbers of this event implies that memory is fragmenting and
|
Large numbers of this event implies that memory is fragmenting and
|
||||||
high-order allocations will start failing at some time in the future. One
|
high-order allocations will start failing at some time in the future. One
|
||||||
means of reducing the occurange of this event is to increase the size of
|
means of reducing the occurrence of this event is to increase the size of
|
||||||
min_free_kbytes in increments of 3*pageblock_size*nr_online_nodes where
|
min_free_kbytes in increments of 3*pageblock_size*nr_online_nodes where
|
||||||
pageblock_size is usually the size of the default hugepage size.
|
pageblock_size is usually the size of the default hugepage size.
|
||||||
|
|
|
@ -71,12 +71,10 @@ being accessed through sysfs, then it definitely is idle.
|
||||||
Forms of dynamic PM
|
Forms of dynamic PM
|
||||||
-------------------
|
-------------------
|
||||||
|
|
||||||
Dynamic suspends can occur in two ways: manual and automatic.
|
Dynamic suspends occur when the kernel decides to suspend an idle
|
||||||
"Manual" means that the user has told the kernel to suspend a device,
|
device. This is called "autosuspend" for short. In general, a device
|
||||||
whereas "automatic" means that the kernel has decided all by itself to
|
won't be autosuspended unless it has been idle for some minimum period
|
||||||
suspend a device. Automatic suspend is called "autosuspend" for
|
of time, the so-called idle-delay time.
|
||||||
short. In general, a device won't be autosuspended unless it has been
|
|
||||||
idle for some minimum period of time, the so-called idle-delay time.
|
|
||||||
|
|
||||||
Of course, nothing the kernel does on its own initiative should
|
Of course, nothing the kernel does on its own initiative should
|
||||||
prevent the computer or its devices from working properly. If a
|
prevent the computer or its devices from working properly. If a
|
||||||
|
@ -96,10 +94,11 @@ idle.
|
||||||
We can categorize power management events in two broad classes:
|
We can categorize power management events in two broad classes:
|
||||||
external and internal. External events are those triggered by some
|
external and internal. External events are those triggered by some
|
||||||
agent outside the USB stack: system suspend/resume (triggered by
|
agent outside the USB stack: system suspend/resume (triggered by
|
||||||
userspace), manual dynamic suspend/resume (also triggered by
|
userspace), manual dynamic resume (also triggered by userspace), and
|
||||||
userspace), and remote wakeup (triggered by the device). Internal
|
remote wakeup (triggered by the device). Internal events are those
|
||||||
events are those triggered within the USB stack: autosuspend and
|
triggered within the USB stack: autosuspend and autoresume. Note that
|
||||||
autoresume.
|
all dynamic suspend events are internal; external agents are not
|
||||||
|
allowed to issue dynamic suspends.
|
||||||
|
|
||||||
|
|
||||||
The user interface for dynamic PM
|
The user interface for dynamic PM
|
||||||
|
@ -145,9 +144,9 @@ relevant attribute files are: wakeup, level, and autosuspend.
|
||||||
number of seconds the device should remain idle before
|
number of seconds the device should remain idle before
|
||||||
the kernel will autosuspend it (the idle-delay time).
|
the kernel will autosuspend it (the idle-delay time).
|
||||||
The default is 2. 0 means to autosuspend as soon as
|
The default is 2. 0 means to autosuspend as soon as
|
||||||
the device becomes idle, and -1 means never to
|
the device becomes idle, and negative values mean
|
||||||
autosuspend. You can write a number to the file to
|
never to autosuspend. You can write a number to the
|
||||||
change the autosuspend idle-delay time.
|
file to change the autosuspend idle-delay time.
|
||||||
|
|
||||||
Writing "-1" to power/autosuspend and writing "on" to power/level do
|
Writing "-1" to power/autosuspend and writing "on" to power/level do
|
||||||
essentially the same thing -- they both prevent the device from being
|
essentially the same thing -- they both prevent the device from being
|
||||||
|
@ -377,9 +376,9 @@ the device hasn't been idle for long enough, a delayed workqueue
|
||||||
routine is automatically set up to carry out the operation when the
|
routine is automatically set up to carry out the operation when the
|
||||||
autosuspend idle-delay has expired.
|
autosuspend idle-delay has expired.
|
||||||
|
|
||||||
Autoresume attempts also can fail. This will happen if power/level is
|
Autoresume attempts also can fail, although failure would mean that
|
||||||
set to "suspend" or if the device doesn't manage to resume properly.
|
the device is no longer present or operating properly. Unlike
|
||||||
Unlike autosuspend, there's no delay for an autoresume.
|
autosuspend, there's no delay for an autoresume.
|
||||||
|
|
||||||
|
|
||||||
Other parts of the driver interface
|
Other parts of the driver interface
|
||||||
|
@ -527,13 +526,3 @@ succeed, it may still remain active and thus cause the system to
|
||||||
resume as soon as the system suspend is complete. Or the remote
|
resume as soon as the system suspend is complete. Or the remote
|
||||||
wakeup may fail and get lost. Which outcome occurs depends on timing
|
wakeup may fail and get lost. Which outcome occurs depends on timing
|
||||||
and on the hardware and firmware design.
|
and on the hardware and firmware design.
|
||||||
|
|
||||||
More interestingly, a device might undergo a manual resume or
|
|
||||||
autoresume during system suspend. With current kernels this shouldn't
|
|
||||||
happen, because manual resumes must be initiated by userspace and
|
|
||||||
autoresumes happen in response to I/O requests, but all user processes
|
|
||||||
and I/O should be quiescent during a system suspend -- thanks to the
|
|
||||||
freezer. However there are plans to do away with the freezer, which
|
|
||||||
would mean these things would become possible. If and when this comes
|
|
||||||
about, the USB core will carefully arrange matters so that either type
|
|
||||||
of resume will block until the entire system has resumed.
|
|
||||||
|
|
23
MAINTAINERS
23
MAINTAINERS
|
@ -1402,6 +1402,8 @@ L: linux-usb@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: Documentation/usb/WUSB-Design-overview.txt
|
F: Documentation/usb/WUSB-Design-overview.txt
|
||||||
F: Documentation/usb/wusb-cbaf
|
F: Documentation/usb/wusb-cbaf
|
||||||
|
F: drivers/usb/host/hwa-hc.c
|
||||||
|
F: drivers/usb/host/whci/
|
||||||
F: drivers/usb/wusbcore/
|
F: drivers/usb/wusbcore/
|
||||||
F: include/linux/usb/wusb*
|
F: include/linux/usb/wusb*
|
||||||
|
|
||||||
|
@ -1470,6 +1472,12 @@ L: linux-scsi@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: drivers/scsi/fnic/
|
F: drivers/scsi/fnic/
|
||||||
|
|
||||||
|
CMPC ACPI DRIVER
|
||||||
|
M: Thadeu Lima de Souza Cascardo <cascardo@holoscopio.com>
|
||||||
|
M: Daniel Oliveira Nascimento <don@syst.com.br>
|
||||||
|
S: Supported
|
||||||
|
F: drivers/platform/x86/classmate-laptop.c
|
||||||
|
|
||||||
CODA FILE SYSTEM
|
CODA FILE SYSTEM
|
||||||
M: Jan Harkes <jaharkes@cs.cmu.edu>
|
M: Jan Harkes <jaharkes@cs.cmu.edu>
|
||||||
M: coda@cs.cmu.edu
|
M: coda@cs.cmu.edu
|
||||||
|
@ -3644,6 +3652,11 @@ W: http://0pointer.de/lennart/tchibo.html
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/platform/x86/msi-laptop.c
|
F: drivers/platform/x86/msi-laptop.c
|
||||||
|
|
||||||
|
MSI WMI SUPPORT
|
||||||
|
M: Anisse Astier <anisse@astier.eu>
|
||||||
|
S: Supported
|
||||||
|
F: drivers/platform/x86/msi-wmi.c
|
||||||
|
|
||||||
MULTIFUNCTION DEVICES (MFD)
|
MULTIFUNCTION DEVICES (MFD)
|
||||||
M: Samuel Ortiz <sameo@linux.intel.com>
|
M: Samuel Ortiz <sameo@linux.intel.com>
|
||||||
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git
|
T: git git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git
|
||||||
|
@ -3677,7 +3690,7 @@ F: include/linux/isicom.h
|
||||||
MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER
|
MUSB MULTIPOINT HIGH SPEED DUAL-ROLE CONTROLLER
|
||||||
M: Felipe Balbi <felipe.balbi@nokia.com>
|
M: Felipe Balbi <felipe.balbi@nokia.com>
|
||||||
L: linux-usb@vger.kernel.org
|
L: linux-usb@vger.kernel.org
|
||||||
T: git git://gitorious.org/musb/mainline.git
|
T: git git://gitorious.org/usb/usb.git
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: drivers/usb/musb/
|
F: drivers/usb/musb/
|
||||||
|
|
||||||
|
@ -5430,7 +5443,10 @@ ULTRA-WIDEBAND (UWB) SUBSYSTEM:
|
||||||
M: David Vrabel <david.vrabel@csr.com>
|
M: David Vrabel <david.vrabel@csr.com>
|
||||||
L: linux-usb@vger.kernel.org
|
L: linux-usb@vger.kernel.org
|
||||||
S: Supported
|
S: Supported
|
||||||
F: drivers/uwb/*
|
F: drivers/uwb/
|
||||||
|
X: drivers/uwb/wlp/
|
||||||
|
X: drivers/uwb/i1480/i1480u-wlp/
|
||||||
|
X: drivers/uwb/i1480/i1480-wlp.h
|
||||||
F: include/linux/uwb.h
|
F: include/linux/uwb.h
|
||||||
F: include/linux/uwb/
|
F: include/linux/uwb/
|
||||||
|
|
||||||
|
@ -5943,9 +5959,12 @@ W: http://linuxwimax.org
|
||||||
|
|
||||||
WIMEDIA LLC PROTOCOL (WLP) SUBSYSTEM
|
WIMEDIA LLC PROTOCOL (WLP) SUBSYSTEM
|
||||||
M: David Vrabel <david.vrabel@csr.com>
|
M: David Vrabel <david.vrabel@csr.com>
|
||||||
|
L: netdev@vger.kernel.org
|
||||||
S: Maintained
|
S: Maintained
|
||||||
F: include/linux/wlp.h
|
F: include/linux/wlp.h
|
||||||
F: drivers/uwb/wlp/
|
F: drivers/uwb/wlp/
|
||||||
|
F: drivers/uwb/i1480/i1480u-wlp/
|
||||||
|
F: drivers/uwb/i1480/i1480-wlp.h
|
||||||
|
|
||||||
WISTRON LAPTOP BUTTON DRIVER
|
WISTRON LAPTOP BUTTON DRIVER
|
||||||
M: Miloslav Trmac <mitr@volny.cz>
|
M: Miloslav Trmac <mitr@volny.cz>
|
||||||
|
|
2
Makefile
2
Makefile
|
@ -1,7 +1,7 @@
|
||||||
VERSION = 2
|
VERSION = 2
|
||||||
PATCHLEVEL = 6
|
PATCHLEVEL = 6
|
||||||
SUBLEVEL = 33
|
SUBLEVEL = 33
|
||||||
EXTRAVERSION = -rc1
|
EXTRAVERSION = -rc2
|
||||||
NAME = Man-Eating Seals of Antiquity
|
NAME = Man-Eating Seals of Antiquity
|
||||||
|
|
||||||
# *DOCUMENTATION*
|
# *DOCUMENTATION*
|
||||||
|
|
|
@ -312,7 +312,7 @@ static inline void unmap_single(struct device *dev, dma_addr_t dma_addr,
|
||||||
* we need to ensure that the data will be coherent
|
* we need to ensure that the data will be coherent
|
||||||
* with user mappings.
|
* with user mappings.
|
||||||
*/
|
*/
|
||||||
__cpuc_flush_kernel_dcache_area(ptr, size);
|
__cpuc_flush_dcache_area(ptr, size);
|
||||||
}
|
}
|
||||||
free_safe_buffer(dev->archdata.dmabounce, buf);
|
free_safe_buffer(dev->archdata.dmabounce, buf);
|
||||||
}
|
}
|
||||||
|
|
|
@ -187,7 +187,6 @@ CONFIG_MACH_ACS5K=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM922T=y
|
CONFIG_CPU_ARM922T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -186,7 +186,6 @@ CONFIG_MACH_ACS5K=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM922T=y
|
CONFIG_CPU_ARM922T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -227,7 +227,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -189,7 +189,6 @@ CONFIG_PXA25x=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -233,7 +233,6 @@ CONFIG_MACH_OMAP3517EVM=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_32v6K=y
|
CONFIG_CPU_32v6K=y
|
||||||
CONFIG_CPU_V7=y
|
CONFIG_CPU_V7=y
|
||||||
CONFIG_CPU_32v7=y
|
CONFIG_CPU_32v7=y
|
||||||
|
|
|
@ -210,7 +210,6 @@ CONFIG_OMAP_ARM_150MHZ=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM925T=y
|
CONFIG_CPU_ARM925T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -101,7 +101,6 @@ CONFIG_SA1100_ASSABET=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA1100=y
|
CONFIG_CPU_SA1100=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -181,7 +181,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -130,7 +130,6 @@ CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -129,7 +129,6 @@ CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -188,7 +188,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -181,7 +181,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -181,7 +181,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -187,7 +187,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -179,7 +179,6 @@ CONFIG_AT91_TIMER_HZ=100
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -132,7 +132,6 @@ CONFIG_MACH_ATEB9200=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -103,7 +103,6 @@ CONFIG_SA1100_BADGE4=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA1100=y
|
CONFIG_CPU_SA1100=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -181,7 +181,6 @@ CONFIG_BCM_ZRELADDR=0x8000
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_V6=y
|
CONFIG_CPU_V6=y
|
||||||
CONFIG_CPU_32v6K=y
|
CONFIG_CPU_32v6K=y
|
||||||
CONFIG_CPU_32v6=y
|
CONFIG_CPU_32v6=y
|
||||||
|
|
|
@ -196,7 +196,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -97,7 +97,6 @@ CONFIG_MACH_CARMEVA=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -105,7 +105,6 @@ CONFIG_SA1100_CERF_FLASH_16MB=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA1100=y
|
CONFIG_CPU_SA1100=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -236,7 +236,6 @@ CONFIG_MACH_CM_T35=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_32v6K=y
|
CONFIG_CPU_32v6K=y
|
||||||
CONFIG_CPU_V7=y
|
CONFIG_CPU_V7=y
|
||||||
CONFIG_CPU_32v7=y
|
CONFIG_CPU_32v7=y
|
||||||
|
|
|
@ -205,7 +205,6 @@ CONFIG_PXA_SSP=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -247,7 +247,6 @@ CONFIG_PLAT_PXA=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSC3=y
|
CONFIG_CPU_XSC3=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -204,7 +204,6 @@ CONFIG_PXA27x=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -212,7 +212,6 @@ CONFIG_PXA3xx=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSC3=y
|
CONFIG_CPU_XSC3=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -125,7 +125,6 @@ CONFIG_SA1100_COLLIE=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA1100=y
|
CONFIG_CPU_SA1100=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -214,7 +214,6 @@ CONFIG_PXA_HAVE_BOARD_IRQS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -229,7 +229,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -219,7 +219,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -230,7 +230,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -193,7 +193,6 @@ CONFIG_AT91_TIMER_HZ=128
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -215,7 +215,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -225,7 +225,6 @@ CONFIG_DAVINCI_RESET_CLOCKS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -223,7 +223,6 @@ CONFIG_DAVINCI_RESET_CLOCKS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -186,7 +186,6 @@ CONFIG_PLAT_ORION=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_V6=y
|
CONFIG_CPU_V6=y
|
||||||
CONFIG_CPU_32v6K=y
|
CONFIG_CPU_32v6K=y
|
||||||
CONFIG_CPU_32v6=y
|
CONFIG_CPU_32v6=y
|
||||||
|
|
|
@ -83,7 +83,6 @@ CONFIG_ARCH_EBSA110=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA110=y
|
CONFIG_CPU_SA110=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -186,7 +186,6 @@ CONFIG_AT91_PROGRAMMABLE_CLOCKS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -90,7 +90,6 @@ CONFIG_ARCH_EP7211=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM720T=y
|
CONFIG_CPU_ARM720T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_LV4T=y
|
CONFIG_CPU_ABRT_LV4T=y
|
||||||
|
|
|
@ -202,7 +202,6 @@ CONFIG_PXA_SSP=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -198,7 +198,6 @@ CONFIG_EP93XX_EARLY_UART1=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -203,7 +203,6 @@ CONFIG_PXA_HAVE_BOARD_IRQS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -240,7 +240,6 @@ CONFIG_PLAT_PXA=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -95,7 +95,6 @@ CONFIG_ARCH_EBSA285=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA110=y
|
CONFIG_CPU_SA110=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -88,7 +88,6 @@ CONFIG_ARCH_FORTUNET=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM720T=y
|
CONFIG_CPU_ARM720T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_LV4T=y
|
CONFIG_CPU_ABRT_LV4T=y
|
||||||
|
|
|
@ -205,7 +205,6 @@ CONFIG_SA1100_H3600=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA1100=y
|
CONFIG_CPU_SA1100=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -206,7 +206,6 @@ CONFIG_PXA25x=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -87,7 +87,6 @@ CONFIG_CPU_H7201=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM720T=y
|
CONFIG_CPU_ARM720T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_LV4T=y
|
CONFIG_CPU_ABRT_LV4T=y
|
||||||
|
|
|
@ -91,7 +91,6 @@ CONFIG_CPU_H7202=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM720T=y
|
CONFIG_CPU_ARM720T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_LV4T=y
|
CONFIG_CPU_ABRT_LV4T=y
|
||||||
|
|
|
@ -103,7 +103,6 @@ CONFIG_SA1100_HACKKIT=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA1100=y
|
CONFIG_CPU_SA1100=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -241,7 +241,6 @@ CONFIG_OMAP_ARM_195MHZ=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM925T=y
|
CONFIG_CPU_ARM925T=y
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
|
|
|
@ -238,7 +238,6 @@ CONFIG_MACH_IGEP0020=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_32v6K=y
|
CONFIG_CPU_32v6K=y
|
||||||
CONFIG_CPU_V7=y
|
CONFIG_CPU_V7=y
|
||||||
CONFIG_CPU_32v7=y
|
CONFIG_CPU_32v7=y
|
||||||
|
|
|
@ -92,7 +92,6 @@ CONFIG_ARCH_INTEGRATOR_AP=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM720T=y
|
CONFIG_CPU_ARM720T=y
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
# CONFIG_CPU_ARM922T is not set
|
# CONFIG_CPU_ARM922T is not set
|
||||||
|
|
|
@ -163,7 +163,6 @@ CONFIG_PLAT_IOP=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSC3=y
|
CONFIG_CPU_XSC3=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -168,7 +168,6 @@ CONFIG_PLAT_IOP=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -198,7 +198,6 @@ CONFIG_PLAT_IOP=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -151,7 +151,6 @@ CONFIG_ARCH_IXDP2X01=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -145,7 +145,6 @@ CONFIG_MACH_ROADRUNNER=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSC3=y
|
CONFIG_CPU_XSC3=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -189,7 +189,6 @@ CONFIG_IXP4XX_NPE=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -202,7 +202,6 @@ CONFIG_SA1100_SSP=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA1100=y
|
CONFIG_CPU_SA1100=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -132,7 +132,6 @@ CONFIG_MACH_KAFA=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -230,7 +230,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -201,7 +201,6 @@ CONFIG_PLAT_ORION=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_FEROCEON=y
|
CONFIG_CPU_FEROCEON=y
|
||||||
# CONFIG_CPU_FEROCEON_OLD_ID is not set
|
# CONFIG_CPU_FEROCEON_OLD_ID is not set
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
|
|
|
@ -186,7 +186,6 @@ CONFIG_MACH_DSM320=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM922T=y
|
CONFIG_CPU_ARM922T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -99,7 +99,6 @@ CONFIG_SA1100_LART=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA1100=y
|
CONFIG_CPU_SA1100=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -174,7 +174,6 @@ CONFIG_PLAT_ORION=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_FEROCEON=y
|
CONFIG_CPU_FEROCEON=y
|
||||||
# CONFIG_CPU_FEROCEON_OLD_ID is not set
|
# CONFIG_CPU_FEROCEON_OLD_ID is not set
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
|
|
|
@ -143,7 +143,6 @@ CONFIG_PXA27x=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -95,7 +95,6 @@ CONFIG_LPD7A40X_CPLD_SSP=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM922T=y
|
CONFIG_CPU_ARM922T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -117,7 +117,6 @@ CONFIG_ARCH_LH7A404=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM922T=y
|
CONFIG_CPU_ARM922T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -92,7 +92,6 @@ CONFIG_PXA25x=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -82,7 +82,6 @@ CONFIG_ARCH_L7200=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM720T=y
|
CONFIG_CPU_ARM720T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_LV4T=y
|
CONFIG_CPU_ABRT_LV4T=y
|
||||||
|
|
|
@ -204,7 +204,6 @@ CONFIG_PXA_HAVE_BOARD_IRQS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -93,7 +93,6 @@ CONFIG_IWMMXT=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_XSCALE=y
|
CONFIG_CPU_XSCALE=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5T=y
|
CONFIG_CPU_ABRT_EV5T=y
|
||||||
|
|
|
@ -256,7 +256,6 @@ CONFIG_MACH_MINI2440=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -155,7 +155,6 @@ CONFIG_MSM_SMD=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_V6=y
|
CONFIG_CPU_V6=y
|
||||||
# CONFIG_CPU_32v6K is not set
|
# CONFIG_CPU_32v6K is not set
|
||||||
CONFIG_CPU_32v6=y
|
CONFIG_CPU_32v6=y
|
||||||
|
|
|
@ -181,7 +181,6 @@ CONFIG_PLAT_ORION=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_FEROCEON=y
|
CONFIG_CPU_FEROCEON=y
|
||||||
CONFIG_CPU_FEROCEON_OLD_ID=y
|
CONFIG_CPU_FEROCEON_OLD_ID=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
|
|
|
@ -190,7 +190,6 @@ CONFIG_MXC_IRQ_PRIOR=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4T=y
|
CONFIG_CPU_32v4T=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -88,7 +88,6 @@ CONFIG_ARCH_MX1ADS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM920T=y
|
CONFIG_CPU_ARM920T=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4T=y
|
CONFIG_CPU_ABRT_EV4T=y
|
||||||
|
|
|
@ -185,7 +185,6 @@ CONFIG_MXC_PWM=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -207,7 +207,6 @@ CONFIG_MXC_PWM=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -173,7 +173,6 @@ CONFIG_MACH_MX31_3DS=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_V6=y
|
CONFIG_CPU_V6=y
|
||||||
# CONFIG_CPU_32v6K is not set
|
# CONFIG_CPU_32v6K is not set
|
||||||
CONFIG_CPU_32v6=y
|
CONFIG_CPU_32v6=y
|
||||||
|
|
|
@ -218,7 +218,6 @@ CONFIG_ARCH_MXC_IOMUX_V3=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_V6=y
|
CONFIG_CPU_V6=y
|
||||||
# CONFIG_CPU_32v6K is not set
|
# CONFIG_CPU_32v6K is not set
|
||||||
CONFIG_CPU_32v6=y
|
CONFIG_CPU_32v6=y
|
||||||
|
|
|
@ -210,7 +210,6 @@ CONFIG_OMAP_ARM_216MHZ=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -232,7 +232,6 @@ CONFIG_MACH_NOKIA_N8X0=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_V6=y
|
CONFIG_CPU_V6=y
|
||||||
# CONFIG_CPU_32v6K is not set
|
# CONFIG_CPU_32v6K is not set
|
||||||
CONFIG_CPU_32v6=y
|
CONFIG_CPU_32v6=y
|
||||||
|
|
|
@ -218,7 +218,6 @@ CONFIG_AT91_EARLY_DBGU=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
|
@ -103,7 +103,6 @@ CONFIG_ASSABET_NEPONSET=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA1100=y
|
CONFIG_CPU_SA1100=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -89,7 +89,6 @@ CONFIG_FOOTBRIDGE_HOST=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_SA110=y
|
CONFIG_CPU_SA110=y
|
||||||
CONFIG_CPU_32v4=y
|
CONFIG_CPU_32v4=y
|
||||||
CONFIG_CPU_ABRT_EV4=y
|
CONFIG_CPU_ABRT_EV4=y
|
||||||
|
|
|
@ -122,7 +122,6 @@ CONFIG_MACH_NXEB500HMI=y
|
||||||
#
|
#
|
||||||
# Processor Type
|
# Processor Type
|
||||||
#
|
#
|
||||||
CONFIG_CPU_32=y
|
|
||||||
CONFIG_CPU_ARM926T=y
|
CONFIG_CPU_ARM926T=y
|
||||||
CONFIG_CPU_32v5=y
|
CONFIG_CPU_32v5=y
|
||||||
CONFIG_CPU_ABRT_EV5TJ=y
|
CONFIG_CPU_ABRT_EV5TJ=y
|
||||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue