作者   [email protected]

沒想到這篇隨意記錄的筆記成為老夫部落格裡閱讀量最多的。看來這的確是兄弟們關注較多的地方，待老夫抽時間把這個部分重新整理下，寫一個從核心到應用API的更新吧。

這裡簡單說一下android系統定時的原理。

首先，萬佛歸宗，在ARM SOC硬體體系中，通常會提供幾個硬體計數器，輸入為PLL過來的脈衝，計數到一定數量產生中斷。這就是硬體時鐘，可見其精度可以達到PLL的脈衝週期。

但是這個時鐘只能被核心感知，而且由於核心有時會關閉中斷，所以這個時鐘中斷有時不能被及時收到，產生偏移。但這不要緊，這只是脈衝週期級別的偏移，精度依然可以接受。

再扯遠一點，以前核心的定時機制是以tick為單位，而tick通常是1ms到數十ms產生一次，這依據具體的硬體系統而變。這樣其精度就只能以tick為單位，所以早期的核心裡tick就以為可控制的時間精度。

再往後人們希望更精確的定時，於是希望依據硬體時鐘精度來控制定時，於是就有了一個核心patch，在tick之間插入時候時鐘，再往後隨著linux架構的不斷完善，出現的hrtimer，這是不管三七二十一，以硬體時鐘作為定時的依據，而ticker只是其中的一種情況。

但是，hrtimer並不意味著依據此定時的應用就能真正的或者其精度（拋去中斷不能及時接受而產生的偏移）。這是因為作為一個分時系統（基於linux核心的android系統完全遵循其規律），即使到了觸發時刻如果對應的執行緒不能被及時排程，時鐘到來沒有意義。所以排程是另外一個最大的影響。

上面說的定時是基於硬體時鐘的定時機制，其前提是系統正常工作，其特點是精度高，但是系統休眠時這個機制就沒法工作。這時就是另外一個時鐘RTC的任務了。

所謂RTC即實時時鐘，在 ARM SOC硬體體系中有一塊區域非常特殊，由單獨的電路供電，而且有一個單獨的晶振為其提供脈衝，及時休眠也不例外，這就是RTC時鐘。

RTC不停地對晶振脈衝計數，用來長時間的定時，它有著喚醒處理器的作用，在Andorid系統中使用的定時通常是基於RTC工作的。

/****************************************原筆記*****************************************************/

android手機核心時鐘整體架構分為上下兩層，下層理解為物理時鐘的操控，即按照上層時鐘邏輯的要求產生物理時鐘中斷、程式設計產生下一次時鐘中斷、切換時鐘中斷產生的模式、初始、關閉物理時鐘。而上層時鐘的作用是根據核心執行時的要求對下層下發各種命令，並根據下層送上來的時鐘事件驅動核心的high resolution timer，schedule tick，tickless sleep等機制的執行。

1 初始化

Linux核心用struct clock_event_device;來管理時鐘裝置。
舉例來看：對於PXA系列SOC上，用於核心時鐘的定時器，就用了一個如下的結構來管理：


static struct clock_event_device ckevt_pxa_osmr0 = {
.name= "osmr0",
.features = CLOCK_EVT_FEAT_ONESHOT,
.shift = 32,
.rating = 200,
.cpumask = CPU_MASK_CPU0,
.set_next_event= pxa_osmr0_set_next_event,// 對物理暫存器程式設計以產生下一次時鐘中斷
.set_mode = pxa_osmr0_set_mode,//根據核心抽象邏輯的時鐘產生要求，實現物理晶片的操作
};


PXA 板級支援包在初始化的時候將這個核心時鐘設備註冊到核心。在核心原始碼樹下$SRC_ROOT/kernel/time裡的檔案是在核心邏輯層面管理時鐘的程式碼。PXA 板級支援包註冊的ckevt_pxa_osmr0會在這裡被近一步初始化：
當一個時鐘裝置被註冊到核心後，核心通過notify機制啟用時鐘相關管理程式碼，對於註冊新的時鐘裝置tick_check_new_device函式將初始化這個時鐘


/*
 * Check, if the new registered device should be used.
 */
static int tick_check_new_device(struct clock_event_device *newdev)
{

tick_setup_device(td, newdev, cpu, cpumask);//初始化該裝置
if (newdev->features & CLOCK_EVT_FEAT_ONESHOT)
tick_oneshot_notify();


spin_unlock_irqrestore(&tick_device_lock, flags);
return NOTIFY_STOP;
…


return ret;
}


static void tick_setup_device(struct tick_device *td,
     struct clock_event_device *newdev, int cpu,
     cpumask_t cpumask)
{


…


//注意在這裡，核心根據該時鐘的模式，將其設定為固定週期的核心時鐘中斷，還是非固定週期的核心時鐘中斷


if (td->mode == TICKDEV_MODE_PERIODIC)
tick_setup_periodic(newdev, 0);
else
tick_setup_oneshot(newdev, handler, next_event);
…
}


這裡關鍵的操作是對於固定週期的核心時鐘將其struct clock_event_device 的成員函式event_handler設定為tick_handle_periodic；


void tick_handle_periodic(struct clock_event_device *dev)
{
…
next = ktime_add(dev->next_event, tick_period);//確定下一次時鐘中斷的時間，注意這裡是tick_period，即為傳統unix作業系統下的tick時間。
for (;;) {
if (!clockevents_program_event(dev, next, ktime_get()))
return;
tick_periodic(cpu);
next = ktime_add(next, tick_period);
}
}


2 執行時分析
首先從核心中斷體系來看，核心時鐘中斷機制是其一個常規的中斷。PXA BSP包將
static struct irqaction pxa_ost0_irq = {
.name= "ost0",
.flags = IRQF_DISABLED | IRQF_TIMER | IRQF_IRQPOLL,
.handler = pxa_ost0_interrupt,
.dev_id = &ckevt_pxa_osmr0,
};
中斷處理單元，在初始化時通過static void __init pxa_timer_init(void)掛入核心中斷處理連結串列，當硬體時鐘中斷到來時，核心找到pxa_ost0_irq的handler成員函式執行。而該中斷處理函式只做了2件事：關了時鐘中斷；將中斷時間送給struct clock_event_device的event_handler成員函式來執行。
static irqreturn_t
pxa_ost0_interrupt(int irq, void *dev_id)
{
struct clock_event_device *c = dev_id;


/* Disarm the compare/match, signal the event. */
OIER &= ~OIER_E0;
OSSR = OSSR_M0;
c->event_handler(c);


return IRQ_HANDLED;
}
這裡的event_handle即為我們上文看到的tick_handle_periodic函式


3 切換


為什麼要切換，其實如果linux核心沒有加入這一部分，無論timer這部分程式碼改動多大，都只是表面的形式的變化，其核心工作機理和原先的是一樣。


但是核心加入的這個新功能，使得linux向前進化了一大步。我們可以分析一下，既然時鐘中斷的週期是固定的，那麼我們能夠獲得的最小定時粒度，就決定於這個系統時鐘中斷週期，這個值如果太小就會使系統中時鐘中斷過於密集，如果太大系統的最小定時粒度就會過大，嚴重影響實時性。所以對於大部分處理器架構這個值在1~10MS之間。但是對於一些實時應用來說1MS實在是太長的時間的。而現代處理器無論是基於X86-64、IA32、IA64的PC、伺服器系統，還是基於的ARM低功耗嵌入式處理器，其硬體定時間隔的能力都遠遠小於1MS。另一方面，有些嵌入式晶片在sleep狀態下，不希望被時鐘中斷頻繁打斷，因為如果中斷到來這些晶片會切換到normal狀態下，造成不必要的耗電。所以基於以上情況，核心社群大幅度修改了linux核心時鐘架構，使得核心時候以我們需要的時間間隔到來。其具體做法如下：




首先要將固定週期的cpu時鐘中斷，改成非固定週期的cpu時鐘中斷。


$SRC_ROOT/kernel/time/tick-oneshot.c
int tick_switch_to_oneshot(void (*handler)(struct clock_event_device *))
{
struct tick_device *td = &__get_cpu_var(tick_cpu_device);
struct clock_event_device *dev = td->evtdev;


if (!dev || !(dev->features & CLOCK_EVT_FEAT_ONESHOT) ||
   !tick_device_is_functional(dev)) {


printk(KERN_INFO "Clockevents: "
      "could not switch to one-shot mode:");
if (!dev) {
printk(" no tick device\n");
} else {
if (!tick_device_is_functional(dev))
printk(" %s is not functional.\n", dev->name);
else
printk(" %s does not support one-shot mode.\n",
      dev->name);
}
return -EINVAL;
}
//這個本來是0
td->mode = TICKDEV_MODE_ONESHOT;
dev->event_handler = handler;
clockevents_set_mode(dev, CLOCK_EVT_MODE_ONESHOT);
tick_broadcast_switch_to_oneshot();
return 0;
}






#ifdef CONFIG_HIGH_RES_TIMERS
/**
 * tick_init_highres - switch to high resolution mode
 *
 * Called with interrupts disabled.
 */
int tick_init_highres(void)
{
return tick_switch_to_oneshot(hrtimer_interrupt);
}
#endif