2016-12-18 01:26:40 +08:00
|
|
|
#
|
|
|
|
|
# Copyright (c) 2014-2015 Wind River Systems, Inc.
|
|
|
|
|
# Copyright (c) 2016 Intel Corporation
|
|
|
|
|
#
|
2017-01-19 09:01:01 +08:00
|
|
|
# SPDX-License-Identifier: Apache-2.0
|
2016-12-18 01:26:40 +08:00
|
|
|
#
|
|
|
|
|
|
|
|
|
|
menuconfig SYS_POWER_MANAGEMENT
|
|
|
|
|
bool
|
|
|
|
|
prompt "Power management"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option enables the board to implement extra power management
|
|
|
|
|
policies whenever the kernel becomes idle. The kernel informs the
|
|
|
|
|
power management subsystem of the number of ticks until the next kernel
|
|
|
|
|
timer is due to expire.
|
|
|
|
|
|
|
|
|
|
if SYS_POWER_MANAGEMENT
|
|
|
|
|
config SYS_POWER_LOW_POWER_STATE
|
|
|
|
|
bool
|
|
|
|
|
prompt "Low power state"
|
|
|
|
|
default n
|
|
|
|
|
depends on SYS_POWER_LOW_POWER_STATE_SUPPORTED
|
|
|
|
|
help
|
|
|
|
|
This option enables the kernel to interface with a power manager
|
|
|
|
|
application. This permits the system to enter a custom CPU low power
|
|
|
|
|
state when the kernel becomes idle. The low power state could be any of
|
|
|
|
|
the CPU low power states supported by the processor. Generally the one
|
|
|
|
|
saving most power.
|
|
|
|
|
|
|
|
|
|
config SYS_POWER_DEEP_SLEEP
|
|
|
|
|
bool
|
|
|
|
|
prompt "Deep sleep state"
|
|
|
|
|
default n
|
|
|
|
|
depends on SYS_POWER_DEEP_SLEEP_SUPPORTED
|
|
|
|
|
help
|
|
|
|
|
This option enables the kernel to interface with a power manager
|
|
|
|
|
application. This permits the system to enter a Deep sleep state
|
|
|
|
|
supported by the SOC where the system clock is turned off while RAM is
|
|
|
|
|
retained. This state would be entered when the kernel becomes idle for
|
|
|
|
|
extended periods and would have a high wake latency. Resume would be
|
|
|
|
|
from the reset vector same as cold boot. The interface allows
|
|
|
|
|
restoration of states that were saved at the time of suspend.
|
|
|
|
|
|
|
|
|
|
config DEVICE_POWER_MANAGEMENT
|
|
|
|
|
bool
|
|
|
|
|
prompt "Device power management"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
This option enables the device power management interface. The
|
|
|
|
|
interface consists of hook functions implemented by device drivers
|
|
|
|
|
that get called by the power manager application when the system
|
|
|
|
|
is going to suspend state or resuming from suspend state. This allows
|
|
|
|
|
device drivers to do any necessary power management operations
|
|
|
|
|
like turning off device clocks and peripherals. The device drivers
|
|
|
|
|
may also save and restore states in these hook functions.
|
|
|
|
|
|
|
|
|
|
config TICKLESS_IDLE
|
|
|
|
|
bool
|
|
|
|
|
prompt "Tickless idle"
|
2017-02-07 07:46:11 +08:00
|
|
|
default y
|
2016-12-18 01:26:40 +08:00
|
|
|
help
|
|
|
|
|
This option suppresses periodic system clock interrupts whenever the
|
|
|
|
|
kernel becomes idle. This permits the system to remain in a power
|
|
|
|
|
saving state for extended periods without having to wake up to
|
|
|
|
|
service each tick as it occurs.
|
|
|
|
|
|
|
|
|
|
config TICKLESS_IDLE_THRESH
|
|
|
|
|
int
|
|
|
|
|
prompt "Tickless idle threshold"
|
|
|
|
|
default 3
|
|
|
|
|
depends on TICKLESS_IDLE
|
|
|
|
|
help
|
|
|
|
|
This option enables clock interrupt suppression when the kernel idles
|
|
|
|
|
for only a short period of time. It specifies the minimum number of
|
|
|
|
|
ticks that must occur before the next kernel timer expires in order
|
|
|
|
|
for suppression to happen.
|
|
|
|
|
|
kernel: tickless: Add tickless kernel support
Adds event based scheduling logic to the kernel. Updates
management of timeouts, timers, idling etc. based on
time tracked at events rather than periodic ticks. Provides
interfaces for timers to announce and get next timer expiry
based on kernel scheduling decisions involving time slicing
of threads, timeouts and idling. Uses wall time units instead
of ticks in all scheduling activities.
The implementation involves changes in the following areas
1. Management of time in wall units like ms/us instead of ticks
The existing implementation already had an option to configure
number of ticks in a second. The new implementation builds on
top of that feature and provides option to set the size of the
scheduling granurality to mili seconds or micro seconds. This
allows most of the current implementation to be reused. Due to
this re-use and co-existence with tick based kernel, the names
of variables may contain the word "tick". However, in the
tickless kernel implementation, it represents the currently
configured time unit, which would be be mili seconds or
micro seconds. The APIs that take time as a parameter are not
impacted and they continue to pass time in mili seconds.
2. Timers would not be programmed in periodic mode
generating ticks. Instead they would be programmed in one
shot mode to generate events at the time the kernel scheduler
needs to gain control for its scheduling activities like
timers, timeouts, time slicing, idling etc.
3. The scheduler provides interfaces that the timer drivers
use to announce elapsed time and get the next time the scheduler
needs a timer event. It is possible that the scheduler may not
need another timer event, in which case the system would wait
for a non-timer event to wake it up if it is idling.
4. New APIs are defined to be implemented by timer drivers. Also
they need to handler timer events differently. These changes
have been done in the HPET timer driver. In future other timers
that support tickles kernel should implement these APIs as well.
These APIs are to re-program the timer, update and announce
elapsed time.
5. Philosopher and timer_api applications have been enabled to
test tickless kernel. Separate configuration files are created
which define the necessary CONFIG flags. Run these apps using
following command
make pristine && make BOARD=qemu_x86 CONF_FILE=prj_tickless.conf qemu
Jira: ZEP-339 ZEP-1946 ZEP-948
Change-Id: I7d950c31bf1ff929a9066fad42c2f0559a2e5983
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
2017-02-06 11:37:19 +08:00
|
|
|
config TICKLESS_KERNEL
|
|
|
|
|
bool
|
|
|
|
|
prompt "Tickless kernel"
|
|
|
|
|
default n
|
|
|
|
|
depends on TICKLESS_IDLE
|
|
|
|
|
help
|
|
|
|
|
This option enables a fully event driven kernel. Periodic system
|
|
|
|
|
clock interrupt generation would be stopped at all times. This option
|
|
|
|
|
requires Tickless Idle option to be enabled.
|
|
|
|
|
|
|
|
|
|
config TICKLESS_KERNEL_TIME_UNIT_IN_MICRO_SECS
|
|
|
|
|
int
|
|
|
|
|
prompt "Tickless kernel time unit in micro seconds"
|
|
|
|
|
default 1000
|
|
|
|
|
depends on TICKLESS_KERNEL
|
|
|
|
|
help
|
2017-05-06 06:37:53 +08:00
|
|
|
This option makes the system clock and scheduling granularity.
|
2017-06-13 06:48:38 +08:00
|
|
|
The default will be one millisecond. This option also determines
|
kernel: tickless: Add tickless kernel support
Adds event based scheduling logic to the kernel. Updates
management of timeouts, timers, idling etc. based on
time tracked at events rather than periodic ticks. Provides
interfaces for timers to announce and get next timer expiry
based on kernel scheduling decisions involving time slicing
of threads, timeouts and idling. Uses wall time units instead
of ticks in all scheduling activities.
The implementation involves changes in the following areas
1. Management of time in wall units like ms/us instead of ticks
The existing implementation already had an option to configure
number of ticks in a second. The new implementation builds on
top of that feature and provides option to set the size of the
scheduling granurality to mili seconds or micro seconds. This
allows most of the current implementation to be reused. Due to
this re-use and co-existence with tick based kernel, the names
of variables may contain the word "tick". However, in the
tickless kernel implementation, it represents the currently
configured time unit, which would be be mili seconds or
micro seconds. The APIs that take time as a parameter are not
impacted and they continue to pass time in mili seconds.
2. Timers would not be programmed in periodic mode
generating ticks. Instead they would be programmed in one
shot mode to generate events at the time the kernel scheduler
needs to gain control for its scheduling activities like
timers, timeouts, time slicing, idling etc.
3. The scheduler provides interfaces that the timer drivers
use to announce elapsed time and get the next time the scheduler
needs a timer event. It is possible that the scheduler may not
need another timer event, in which case the system would wait
for a non-timer event to wake it up if it is idling.
4. New APIs are defined to be implemented by timer drivers. Also
they need to handler timer events differently. These changes
have been done in the HPET timer driver. In future other timers
that support tickles kernel should implement these APIs as well.
These APIs are to re-program the timer, update and announce
elapsed time.
5. Philosopher and timer_api applications have been enabled to
test tickless kernel. Separate configuration files are created
which define the necessary CONFIG flags. Run these apps using
following command
make pristine && make BOARD=qemu_x86 CONF_FILE=prj_tickless.conf qemu
Jira: ZEP-339 ZEP-1946 ZEP-948
Change-Id: I7d950c31bf1ff929a9066fad42c2f0559a2e5983
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
2017-02-06 11:37:19 +08:00
|
|
|
the time unit passed in functions like _sys_soc_suspend. The
|
|
|
|
|
value should be determined based what the timer hardware and driver
|
2017-05-06 06:37:53 +08:00
|
|
|
can support. Specifying too small a time unit than what the overall
|
kernel: tickless: Add tickless kernel support
Adds event based scheduling logic to the kernel. Updates
management of timeouts, timers, idling etc. based on
time tracked at events rather than periodic ticks. Provides
interfaces for timers to announce and get next timer expiry
based on kernel scheduling decisions involving time slicing
of threads, timeouts and idling. Uses wall time units instead
of ticks in all scheduling activities.
The implementation involves changes in the following areas
1. Management of time in wall units like ms/us instead of ticks
The existing implementation already had an option to configure
number of ticks in a second. The new implementation builds on
top of that feature and provides option to set the size of the
scheduling granurality to mili seconds or micro seconds. This
allows most of the current implementation to be reused. Due to
this re-use and co-existence with tick based kernel, the names
of variables may contain the word "tick". However, in the
tickless kernel implementation, it represents the currently
configured time unit, which would be be mili seconds or
micro seconds. The APIs that take time as a parameter are not
impacted and they continue to pass time in mili seconds.
2. Timers would not be programmed in periodic mode
generating ticks. Instead they would be programmed in one
shot mode to generate events at the time the kernel scheduler
needs to gain control for its scheduling activities like
timers, timeouts, time slicing, idling etc.
3. The scheduler provides interfaces that the timer drivers
use to announce elapsed time and get the next time the scheduler
needs a timer event. It is possible that the scheduler may not
need another timer event, in which case the system would wait
for a non-timer event to wake it up if it is idling.
4. New APIs are defined to be implemented by timer drivers. Also
they need to handler timer events differently. These changes
have been done in the HPET timer driver. In future other timers
that support tickles kernel should implement these APIs as well.
These APIs are to re-program the timer, update and announce
elapsed time.
5. Philosopher and timer_api applications have been enabled to
test tickless kernel. Separate configuration files are created
which define the necessary CONFIG flags. Run these apps using
following command
make pristine && make BOARD=qemu_x86 CONF_FILE=prj_tickless.conf qemu
Jira: ZEP-339 ZEP-1946 ZEP-948
Change-Id: I7d950c31bf1ff929a9066fad42c2f0559a2e5983
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
2017-02-06 11:37:19 +08:00
|
|
|
system speed can support would cause scheduling errors.
|
|
|
|
|
|
|
|
|
|
config BUSY_WAIT_USES_ALTERNATE_CLOCK
|
|
|
|
|
bool
|
|
|
|
|
prompt "Busy wait uses alternate clock in tickless kernel mode"
|
|
|
|
|
default n
|
|
|
|
|
help
|
|
|
|
|
In tickless kernel mode, the system clock will be stopped when
|
|
|
|
|
there are no timer events programmed. If the system clock is to
|
2017-05-06 06:37:53 +08:00
|
|
|
be used to keep time e.g. to get a delta of time cycles then it
|
kernel: tickless: Add tickless kernel support
Adds event based scheduling logic to the kernel. Updates
management of timeouts, timers, idling etc. based on
time tracked at events rather than periodic ticks. Provides
interfaces for timers to announce and get next timer expiry
based on kernel scheduling decisions involving time slicing
of threads, timeouts and idling. Uses wall time units instead
of ticks in all scheduling activities.
The implementation involves changes in the following areas
1. Management of time in wall units like ms/us instead of ticks
The existing implementation already had an option to configure
number of ticks in a second. The new implementation builds on
top of that feature and provides option to set the size of the
scheduling granurality to mili seconds or micro seconds. This
allows most of the current implementation to be reused. Due to
this re-use and co-existence with tick based kernel, the names
of variables may contain the word "tick". However, in the
tickless kernel implementation, it represents the currently
configured time unit, which would be be mili seconds or
micro seconds. The APIs that take time as a parameter are not
impacted and they continue to pass time in mili seconds.
2. Timers would not be programmed in periodic mode
generating ticks. Instead they would be programmed in one
shot mode to generate events at the time the kernel scheduler
needs to gain control for its scheduling activities like
timers, timeouts, time slicing, idling etc.
3. The scheduler provides interfaces that the timer drivers
use to announce elapsed time and get the next time the scheduler
needs a timer event. It is possible that the scheduler may not
need another timer event, in which case the system would wait
for a non-timer event to wake it up if it is idling.
4. New APIs are defined to be implemented by timer drivers. Also
they need to handler timer events differently. These changes
have been done in the HPET timer driver. In future other timers
that support tickles kernel should implement these APIs as well.
These APIs are to re-program the timer, update and announce
elapsed time.
5. Philosopher and timer_api applications have been enabled to
test tickless kernel. Separate configuration files are created
which define the necessary CONFIG flags. Run these apps using
following command
make pristine && make BOARD=qemu_x86 CONF_FILE=prj_tickless.conf qemu
Jira: ZEP-339 ZEP-1946 ZEP-948
Change-Id: I7d950c31bf1ff929a9066fad42c2f0559a2e5983
Signed-off-by: Ramesh Thomas <ramesh.thomas@intel.com>
2017-02-06 11:37:19 +08:00
|
|
|
needs to be turned on using provided APIs. Some platforms have
|
|
|
|
|
alternate clocks which can be used instead. In that case this flag
|
|
|
|
|
would be set to true. This flag would be checked before turning
|
|
|
|
|
on the system clock in APIs that do busy wait reading clock
|
|
|
|
|
cycles.
|
2016-12-18 01:26:40 +08:00
|
|
|
endif
|