Clockevents 框架简介
Last updated
Last updated
clockevents frameworkThis is fifth part of the which describes timers and time management related stuff in the Linux kernel. As you might noted from the title of this part, the clockevents framework will be discussed. We already saw one framework in the part of this chapter. It was clocksource framework. Both of these frameworks represent timekeeping abstractions in the Linux kernel.
At first let's refresh your memory and try to remember what is it clocksource framework and and what its purpose. The main goal of the clocksource framework is to provide timeline. As described in the :
For example issuing the command 'date' on a Linux system will eventually read the clock source to determine exactly what time it is.
The Linux kernel supports many different clock sources. You can find some of them in the . For example old good - with 1193182 Hz frequency, yet another one - timer with 3579545 Hz frequency. Besides the directory, each architecture may provide own architecture-specific clock sources. For example architecture provides , or for example provides access to the processor timer through timebase register.
Each clock source provides monotonic atomic counter. As I already wrote, the Linux kernel supports a huge set of different clock source and each clock source has own parameters like . The main goal of the clocksource framework is to provide to select best available clock source in the system i.e. a clock source with the highest frequency. Additional goal of the clocksource framework is to represent an atomic counter provided by a clock source in human units. In this time, nanoseconds are the favorite choice for the time value units of the given clock source in the Linux kernel.
The clocksource framework represented by the clocksource structure which is defined in the header code file which contains name of a clock source, rating of certain clock source in the system (a clock source with the higher frequency has the biggest rating in the system), list of all registered clock source in the system, enable and disable fields to enable and disable a clock source, pointer to the read function which must return an atomic counter of a clock source and etc.
Additionally the clocksource structure provides two fields: mult and shift which are needed for translation of an atomic counter which is provided by a certain clock source to the human units, i.e. . Translation occurs via following formula:
As we already know, besides the clocksource structure, the clocksource framework provides an API for registration of clock source with different frequency scale factor:
A clock source unregistration:
and etc.
Additionally to the clocksource framework, the Linux kernel provides clockevents framework. As described in the :
Clock events are the conceptual reverse of clock sources
clockevents frameworkAfter we considered part of the clock_event_device structure, time is to look at the API of the clockevents framework. To work with a clock event device, first of all we need to initialize clock_event_device structure and register a clock events device. The clockevents framework provides following API for registration of clock event devices:
address of a clock_event_device structure which represents a clock event device.
First of all let's look at initialization of the clock_event_device structure. This occurs in the at91sam926x_pit_common_init function:
After we finished with the initialization of the at91sam926x periodic timer, we can register it by the call of the following functions:
Actually, an event device may be in one of this states:
Where:
CLOCK_EVT_STATE_DETACHED - a clock event device is not not used by clockevents framework. Actually it is initial state of all clock event devices;
CLOCK_EVT_STATE_SHUTDOWN - a clock event device is powered-off;
CLOCK_EVT_STATE_PERIODIC - a clock event device may be programmed to generate event periodically;
CLOCK_EVT_STATE_ONESHOT - a clock event device may be programmed to generate event only once;
CLOCK_EVT_STATE_ONESHOT_STOPPED - a clock event device was programmed to generate event only once and now it is temporary stopped.
The implementation of the clock_event_set_state function is pretty easy:
As we can see, it just fills the state_use_accessors field of the given clock_event_device structure with the given value which is in our case is CLOCK_EVT_STATE_DETACHED. Actually all clock event devices has this initial state during registration. The state_use_accessors field of the clock_event_device structure provides current state of the clock event device.
After we have set initial state of the given clock_event_device structure we check that the cpumask of the given clock event device is not zero:
After this check we lock the actual code of the clock event device registration by the call following macros:
We can see following code of clock event device registration between the raw_spin_lock_irqsave and raw_spin_unlock_irqrestore macros:
First of all we add the given clock event device to the list of clock event devices which is represented by the clockevent_devices:
If the new registered clock event device is more preferred than old tick device, we exchange old and new registered devices and install new device:
The clockevents_exchange_device function releases or in other words deleted the old clock event device from the clockevent_devices list. The next function - tick_setup_device as we may understand from its name, setups new tick device. This function check the mode of the new registered clock event device and call the tick_setup_periodic function or the tick_setup_oneshot depends on the tick device mode:
Both of this functions calls the clockevents_switch_state to change state of the clock event device and the clockevents_program_event function to set next event of clock event device based on delta between the maximum and minimum difference current time and time for the next event. The tick_setup_periodic:
and the tick_setup_oneshot_periodic:
The clockevents_switch_state function checks that the clock event device is not in the given state and calls the __clockevents_switch_state function from the same source code file:
The __clockevents_switch_state function just makes a call of the certain callback depends on the given state:
In our case for at91sam926x periodic timer, the state is the CLOCK_EVT_FEAT_PERIODIC:
It looks like:
Where PIV or Periodic Interval Value - defines the value compared with the primary 20-bit counter of the Periodic Interval Timer. The PITEN or Period Interval Timer Enabled if the bit is 1 and the PITIEN or Periodic Interval Timer Interrupt Enable if the bit is 1. So, to set periodic mode, we need to set 24, 25 bits in the Periodic Interval Timer Mode Register. And we are doing it in the pit_clkevt_set_periodic function:
Where the AT91_PT_MR, AT91_PT_PITEN and the AT91_PIT_PITIEN are declared as:
After the setup of the new clock event device is finished, we can return to the clockevents_register_device function. The last function in the clockevents_register_device function is:
This function checks the clockevents_released list which contains released clock event devices (remember that they may occur after the call of the clockevents_exchange_device function). If this list is not empty, we go through clock event devices from the clock_events_released list and delete it from the clockevent_devices:
That's all.
Main goal of the is to manage clock event devices or in other words - to manage devices that allow to register an event or in other words that is going to happen at a defined point of time in the future.
Now we know a little about the clockevents framework in the Linux kernel, and now time is to see on it .
The main structure which described a clock event device is clock_event_device structure. This structure is defined in the header file and contains a huge set of fields. as well as the clocksource structure it has name fields which contains human readable name of a clock event device, for example timer:
Addresses of the event_handler, set_next_event, next_event functions for a certain clock event device which are an , setter of next event and local storage for next event respectively. Yet another field of the clock_event_device structure is - features field. Its value maybe on of the following generic features:
Where the CLOCK_EVT_FEAT_PERIODIC represents device which may be programmed to generate events periodically. The CLOCK_EVT_FEAT_ONESHOT represents device which may generate an event only once. Besides these two features, there are also architecture-specific features. For example supports two additional features:
The first CLOCK_EVT_FEAT_C3STOP means that a clock event device will be stopped in the state. Additionally the clock_event_device structure has mult and shift fields as well as clocksource structure. The clocksource structure also contains other fields, but we will consider it later.
This function defined in the source code file and as we may see, the clockevents_register_device function takes only one parameter:
So, to register a clock event device, at first we need to initialize clock_event_device structure with parameters of a certain clock event device. Let's take a look at one random clock event device in the Linux kernel source code. We can find one in the directory or try to take a look at an architecture-specific clock event device. Let's take for example - . You can find its implementation in the .
Here we can see that at91sam926x_pit_common_init takes one parameter - pointer to the pit_data structure which contains clock_event_device structure which will contain clock event related information of the at91sam926x . At the start we fill name of the timer device and its features. In our case we deal with periodic timer which as we already know may be programmed to generate events periodically.
The next two fields shift and mult are familiar to us. They will be used to translate counter of our timer to nanoseconds. After this we set rating of the timer to 100. This means if there will not be timers with higher rating in the system, this timer will be used for timekeeping. The next field - cpumask indicates for which processors in the system the device will work. In our case, the device will work for the first processor. The cpumask_of macro defined in the header file and just expands to the call of the:
Where the get_cpu_mask returns the cpumask containing just a given cpu number. More about cpumasks concept you may read in the part. In the last four lines of code we set callbacks for the clock event device suspend/resume, device shutdown and update of the clock event device state.
Now we can consider implementation of the clockevent_register_device function. As I already wrote above, this function is defined in the source code file and starts from the initialization of the initial event device state:
Remember that we have set the cpumask of the at91sam926x periodic timer to first processor. If the cpumask field is zero, we check the number of possible processors in the system and print warning message if it is less than on. Additionally we set the cpumask of the given clock event device to the current processor. If you are interested in how the smp_processor_id macro is implemented, you can read more about it in the fourth of the Linux kernel initialization process chapter.
Additionally the raw_spin_lock_irqsave and the raw_spin_unlock_irqrestore macros disable local interrupts, however interrupts on other processors still may occur. We need to do it to prevent potential if we adding new clock event device to the list of clock event devices and an interrupt occurs from other clock event device.
At the next step we call the tick_check_new_device function which is defined in the source code file and checks do the new registered clock event device should be used or not. The tick_check_new_device function checks the given clock_event_device gets the current registered tick device which is represented by the tick_device structure and compares their ratings and features. Actually CLOCK_EVT_STATE_ONESHOT is preferred:
So, for the pit_clkevt_set_periodic callback will be called. If we will read the documentation of the , we will see that there is Periodic Interval Timer Mode Register which allows us to control of periodic interval timer.
That's all. From this moment we have registered new clock event device. So the usage of the clockevents framework is simple and clear. Architectures registered their clock event devices, in the clock events core. Users of the clockevents core can get clock event devices for their use. The clockevents framework provides notification mechanisms for various clock related management events like a clock event device registered or unregistered, a processor is offlined in system which supports and etc.
We saw implementation only of the clockevents_register_device function. But generally, the clock event layer is small. Besides the API for clock event device registration, the clockevents framework provides functions to schedule the next event interrupt, clock event device notification service and support for suspend and resume for clock event devices.
If you want to know more about clockevents API you can start to research following source code and header files: , and .
This is the end of the fifth part of the that describes timers and timer management related stuff in the Linux kernel. In the previous part got acquainted with the timers concept. In this part we continued to learn time management related stuff in the Linux kernel and saw a little about yet another framework - clockevents.
If you have questions or suggestions, feel free to ping me in twitter , drop me or just create .
Please note that English is not my first language and I am really sorry for any inconvenience. If you found any mistakes please send me PR to .