摘要

OpenHarmony系統(tǒng)中使用了liteos-m、liteos-a、linux三種內(nèi)核，工作隊(duì)列是linux內(nèi)核引入的一種異步處理機(jī)制。本文對(duì)liteos-a內(nèi)核下工作隊(duì)列的實(shí)現(xiàn)原理進(jìn)行分析，并對(duì)芯?？萍?/u>的PPG芯片CS1262接入OpenHarmony過程中對(duì)工作隊(duì)列的使用方法進(jìn)行總結(jié)分享。

工作隊(duì)列工作隊(duì)列(Workqueue)是linux內(nèi)核引入的一種異步進(jìn)程調(diào)用的機(jī)制，允許內(nèi)核代碼請(qǐng)求在將來某個(gè)時(shí)間調(diào)用一個(gè)函數(shù)。在內(nèi)核源碼的documentation中也有對(duì)workqueue的說明，路徑為Documentation/core-api/workqueue.rst。網(wǎng)絡(luò)上也有很多對(duì)工作隊(duì)列機(jī)制的總結(jié)文章可以學(xué)習(xí)，《Linux workqueue工作原理》講解的就比較詳細(xì)。簡(jiǎn)單理解就是先創(chuàng)建一個(gè)隊(duì)列用于存放work，并創(chuàng)建一個(gè)處理線程叫worker；用戶進(jìn)程通過調(diào)用接口往隊(duì)列里面添加work驅(qū)動(dòng)著worker來處理，如下：

而OpenHarmony系統(tǒng)根據(jù)不同的使用場(chǎng)景使用了liteos-m/liteos-a/linux三種內(nèi)核。

這里通過CS1262驅(qū)動(dòng)的實(shí)現(xiàn)，對(duì)liteos-a內(nèi)核中工作隊(duì)列的使用及實(shí)現(xiàn)做一下分析。

工作隊(duì)列的使用方法

Sensor設(shè)備作為外接設(shè)備重要組成模塊，Sensor驅(qū)動(dòng)模型為上層Sensor服務(wù)系統(tǒng)提供穩(wěn)定的Sensor基礎(chǔ)能力接口，包括Sensor列表查詢、Sensor啟停、Sensor訂閱及去訂閱，Sensor參數(shù)配置等功能。傳感器驅(qū)動(dòng)模型總體框架如圖1所示。

OpenHarmony系統(tǒng)對(duì)workqueue提供了幾個(gè)接口，以方便用戶的使用。

1. 調(diào)用HdfWorkQueueInit，傳入queue名稱，創(chuàng)建并初始化一個(gè)workqueue

2. 調(diào)用HdfWorkInit，可以理解為初始化一個(gè)work的模板，主要記錄處理這個(gè)queue里面work的回調(diào)函數(shù)func以及參數(shù)para信息，類似于linux的work_struct

3. 通過調(diào)用HdfAddWork往workqueue中添加work，觸發(fā)調(diào)用與此queue關(guān)聯(lián)的回調(diào)函數(shù)func

步驟1~2可以在CS1262驅(qū)動(dòng)HdfDriverEntry對(duì)象的Init接口中看到

int32_t InitPpgDriver(struct HdfDeviceObject *device)

{

    CHECK_NULL_PTR_RETURN_VALUE(device, HDF_ERR_INVALID_PARAM);

    struct PpgDrvData *drvData = (struct PpgDrvData *)device->service;

    CHECK_NULL_PTR_RETURN_VALUE(drvData, HDF_ERR_INVALID_PARAM);

    if (HdfWorkQueueInit(&drvData->ppgWorkQueue, HDF_PPG_WORK_QUEUE) != HDF_SUCCESS) {

        HDF_LOGE("%s: Ppg init work queue failed", __func__);

        return HDF_FAILURE;

    }

    if (HdfWorkInit(&drvData->ppgWork, PpgDataWorkEntry, drvData) != HDF_SUCCESS) {

        HDF_LOGE("%s: Ppg create thread failed", __func__);

        return HDF_FAILURE;

    }

    drvData->initStatus = true;

    drvData->enable = false;

    drvData->detectFlag = false;

    HDF_LOGI("%s: init Ppg driver success", __func__);

    return HDF_SUCCESS;

}

步驟3在CS1262的中斷處理函數(shù)中，有數(shù)據(jù)需要上報(bào)時(shí)會(huì)產(chǎn)生一個(gè)中斷，中斷處理中添加一個(gè)work通過工作隊(duì)列機(jī)制來實(shí)現(xiàn)數(shù)據(jù)的上報(bào)。

static int32_t PpgReadInt(uint16_t gpio, void *data)

{

    struct PpgDrvData *drvData = PpgGetDrvData();

    CHECK_PPG_INIT_RETURN_VALUE(drvData, HDF_ERR_NOT_SUPPORT);

    if (!drvData->enable) {

        HDF_LOGE("%s: ppg not enabled", __func__);

        return HDF_SUCCESS;

    }

    if (!HdfAddWork(&drvData->ppgWorkQueue, &drvData->ppgWork)) {

        HDF_LOGE("%s: Ppg add work queue failed", __func__);

        return HDF_FAILURE;

    }

    return HDF_SUCCESS;

}

CS1262工作對(duì)列中work的回調(diào)接口實(shí)現(xiàn)，兩個(gè)主要功能：獲取數(shù)據(jù)，數(shù)據(jù)上報(bào)。

static void PpgDataWorkEntry(void *arg)

{

    int32_t ret;

    struct PpgDrvData *drvData = (struct PpgDrvData *)arg;

    uint16_t readLen = 0;

    CHECK_NULL_PTR_RETURN(drvData);

    CHECK_NULL_PTR_RETURN(drvData->chipData.opsCall.ReadData);

    ret = drvData->chipData.opsCall.ReadData(g_fifoBuf, sizeof(g_fifoBuf), &readLen);

    if ((ret != HDF_SUCCESS) || (readLen > sizeof(g_fifoBuf))) {

        HDF_LOGE("%s: Ppg read data failed", __func__);

        return;

    }

    if (PpgReportInt(g_fifoBuf, readLen) != HDF_SUCCESS) {

        HDF_LOGE("%s: Cs1262ReportInt fail", __func__);

    }

}

說明：當(dāng)前CS1262驅(qū)動(dòng)已提交PR，還未正式上庫

Liteos-a內(nèi)核中工作隊(duì)列的實(shí)現(xiàn)

1.HdfWorkQueueInit接口

(1)在liteos-a系統(tǒng)源碼中搜索，接口定義如下：

源文件：drivers/adapter/khdf/liteos/osal/src/osal_workqueue.c

代碼如下：

int32_t HdfWorkQueueInit(HdfWorkQueue *queue, char *name)

{

......

    queue->realWorkQueue = create_singlethread_workqueue(name);

......

    return HDF_SUCCESS;

}

(2)create_singlethread_workqueue接口實(shí)現(xiàn)如下

源文件：kernel/liteos_a/bsd/compat/linuxkpi/include/linux/workqueue.h

宏定義：

#define create_singlethread_workqueue(name) \

    linux_create_singlethread_workqueue(name)

源文件：kernel/liteos_a/bsd/compat/linuxkpi/src/linux_workqueue.c

代碼如下：

struct workqueue_struct *linux_create_singlethread_workqueue(char *name)

{

    return __create_workqueue_key(name, 1, 0, 0, NULL, NULL);

}

(3)__create_workqueue_key中初始化化了一個(gè)event后面會(huì)用；創(chuàng)建一個(gè)workqueueThread線程用來處理這個(gè)workqueue里的所有work

源文件：kernel/liteos_a/bsd/compat/linuxkpi/src/linux_workqueue.c

代碼如下：

struct workqueue_struct *__create_workqueue_key(char *name,

                                                int singleThread,

                                                int freezeable,

                                                int rt,

                                                struct lock_class_key *key,

                                                const char *lockName)

{

......

    (VOID)LOS_EventInit(&wq->wq_event);

    if (singleThread) {

        cwq = InitCpuWorkqueue(wq, singleThread);

        ret = CreateWorkqueueThread(cwq, singleThread);

    } else {

        LOS_MemFree(m_aucSysMem0, wq->cpu_wq);

        LOS_MemFree(m_aucSysMem0, wq);

        return NULL;

    }

    if (ret) {

        destroy_workqueue(wq);

        wq = NULL;

    }

    return wq;

}

(4)LOS_EventInit就是liteos系統(tǒng)的task之間通信的事件機(jī)制實(shí)現(xiàn)

(5)CreateWorkqueueThread就是調(diào)用的liteos的LOS_TaskCreate來創(chuàng)建一個(gè)Task(也即thread)，處理函數(shù)為WorkerThread，如下

源文件：kernel/liteos_a/bsd/compat/linuxkpi/src/linux_workqueue.c

代碼如下：

STATIC UINT32 CreateWorkqueueThread(cpu_workqueue_struct *cwq, INT32 cpu)

{

    ......

    taskInitParam.pfnTaskEntry = (TSK_ENTRY_FUNC)WorkerThread;

    ......

    ret = LOS_TaskCreate(&cwq->wq->wq_id, &taskInitParam);

    ......

    return LOS_OK;

}

STATIC VOID WorkerThread(cpu_workqueue_struct *cwqParam)

{

    cpu_workqueue_struct *cwq = cwqParam;

    for (;;) {

        if (WorkqueueIsEmpty(cwq)) {

(VOID)LOS_EventRead(&(cwq->wq->wq_event),0x01,LOS_WAITMODE_OR|LOS_WAITMODE_CLR,LOS_WAIT_FOREVER);

        }

        RunWorkqueue(cwq);

    }

}

線程處理函數(shù)里面就是一個(gè)死循環(huán)，當(dāng)workqueue中為空時(shí)，代碼會(huì)阻塞在LOS_EventRead處，讀一個(gè)還未發(fā)生的事件時(shí)，代碼就會(huì)在此處一直阻塞，直到事件發(fā)生；

(6)在事件發(fā)生(有work可以處理)時(shí)，就會(huì)調(diào)用真正的處理接口RunWorkqueue，對(duì)work調(diào)用回調(diào)函數(shù)（例如上面CS1262中的PpgDataWorkEntry）

源文件：kernel/liteos_a/bsd/compat/linuxkpi/src/linux_workqueue.c

代碼如下：

STATIC VOID RunWorkqueue(cpu_workqueue_struct *cwq)

{

    ......

    if (!WorkqueueIsEmpty(cwq)) {

        ......

        func = work->func;

        func(work);

        ......

    }

    LOS_SpinUnlockRestore(&g_workqueueSpin, intSave);

}

2.HdfWorkInit接口

(1)接口實(shí)現(xiàn)如下

源文件：drivers/adapter/khdf/liteos/osal/src/osal_workqueue.c

代碼如下：

int32_t HdfWorkInit(HdfWork *work, HdfWorkFunc func, void *para)

{

    ......

    wrapper = (struct WorkWrapper *)OsalMemCalloc(sizeof(*wrapper));

    if (wrapper == NULL) {

        HDF_LOGE("%s malloc fail", __func__);

        return HDF_ERR_MALLOC_FAIL;

    }

    realWork = &(wrapper->work.work);

    wrapper->workFunc = func;

    wrapper->para = para;

    INIT_WORK(realWork, WorkEntry);

    work->realWork = wrapper;

    return HDF_SUCCESS;

}

(2)從這里看這個(gè)處理函數(shù)func賦值給了wrapper->workFunc，而在INIT_WORK中將WorkEntry接口賦值給了work的func

源文件：drivers/adapter/khdf/liteos/osal/src/osal_workqueue.c

代碼如下：

#ifdef WORKQUEUE_SUPPORT_PRIORITY

#define INIT_WORK(work, callbackFunc)  do {      \

    INIT_LIST_HEAD(&((work)->entry));            \

    (work)->func = (callbackFunc);               \

    (work)->data = (atomic_long_t)(0);           \

    (work)->work_status = 0;                     \

    (work)->work_pri = OS_WORK_PRIORITY_DEFAULT; \

} while (0)

#else

#define INIT_WORK(work, callbackFunc)  do { \

    INIT_LIST_HEAD(&((work)->entry));       \

    (work)->func = (callbackFunc);          \

    (work)->data = (atomic_long_t)(0);      \

    (work)->work_status = 0;                \

} while (0)

#endif

(3)從前面分析，有work需要處理時(shí)調(diào)用的就是這個(gè)(work)->func；而這里看這個(gè)接口的值是WorkEntry，怎么跟驅(qū)動(dòng)側(cè)輸入的處理接口聯(lián)系的呢？就是這個(gè)WorkEntry實(shí)現(xiàn)的

源文件：drivers/adapter/khdf/liteos/osal/src/osal_workqueue.c

代碼如下：

static void WorkEntry(struct work_struct *work)

{

    struct WorkWrapper *wrapper = NULL;

    if (work != NULL) {

        wrapper = (struct WorkWrapper *)work;

        if (wrapper->workFunc != NULL) {

            wrapper->workFunc(wrapper->para);

        } else {

            HDF_LOGE("%s routine null", __func__);

        }

    } else {

        HDF_LOGE("%s work null", __func__);

    }

}

從這里看就是調(diào)用的wrapper->workFunc，也即HdfWorkInit接口傳入的回調(diào)函數(shù)。

3.HdfAddWork接口

(1)接口定義如下

源文件：drivers/adapter/khdf/liteos/osal/src/osal_workqueue.c

代碼如下：

bool HdfAddWork(HdfWorkQueue *queue, HdfWork *work)

{

    ......

    return queue_work(queue->realWorkQueue, &((struct WorkWrapper *)work->realWork)->work.work);

}

(2)queue_work接口是一個(gè)宏，定義如下

源文件：drivers/adapter/khdf/liteos/osal/src/osal_workqueue.c

代碼如下：

#define queue_work(wq, work) \

    linux_queue_work(wq, work)

源文件：kernel/liteos_a/bsd/compat/linuxkpi/src/linux_workqueue.c

linux_queue_work最終調(diào)用的接口是InsertWork，中間的調(diào)用如下

linux_queue_work()

   |--> QueueWorkOn()

           |--> QueueWork()

                  |-->InsertWork()

接口實(shí)現(xiàn)：

STATIC VOID InsertWork(cpu_workqueue_struct *cwq, struct work_struct *work, 

struct list_head *head, UINT32 *intSave)

{

#ifdef WORKQUEUE_SUPPORT_PRIORITY

    WorkListAdd(&work->entry, head, work->work_pri);

#else

    WorkListAddTail(&work->entry, head);

#endif

    LOS_SpinUnlockRestore(&g_workqueueSpin, *intSave);

    (VOID)LOS_EventWrite(&(cwq->wq->wq_event), 0x01);

    LOS_SpinLockSave(&g_workqueueSpin, intSave);

}

從實(shí)現(xiàn)上看這里就是寫了一個(gè)Event，還記得前面在init里面一個(gè)阻塞在讀Event的嗎？這里的LOS_EventWrite就代表了事件發(fā)生，然后就可以正常處理work了

總結(jié)

OpenHarmony的liteos-a內(nèi)核中工作隊(duì)列的實(shí)現(xiàn)就是參照linux內(nèi)核的實(shí)現(xiàn)，只是底層使用的是嵌入式系統(tǒng)中事件處理機(jī)制。

OpenHarmony在內(nèi)核上層做了一層封裝(OSAL)，在使用linux和liteos-a內(nèi)核時(shí)工作隊(duì)列的使用方式統(tǒng)一，驅(qū)動(dòng)開發(fā)時(shí)無感知。

芯?？萍甲鳛镺penHarmony項(xiàng)目群B類捐贈(zèng)人，已加入DriverFramework SIG和DevBoard SIG。在DriverFramework SIG中負(fù)責(zé)心率傳感器PPG驅(qū)動(dòng)模型和HDI的實(shí)現(xiàn)。CS1262是芯海科技最新推出的一款用于光電血管容積圖（PPG）信號(hào)采集的高端模擬前端（AFE），通過SPI總線與主控通信。關(guān)鍵性能指標(biāo)達(dá)到業(yè)界一流水平：

◆ 高精度測(cè)量：最高PPG SNR高達(dá)110dB

◆ 超強(qiáng)抗干擾：PSRR ≥ 90dB（0.5Hz~10MHz 范圍內(nèi)的Boost噪聲）

◆ 低功耗：83uA@100Hz@4Ch@2階環(huán)境光

◆ 全膚色支持：?jiǎn)温稬ED Driver最大電流可達(dá)125mA，兩路合并后支持250mA

◆ 高可靠：支持過溫保護(hù)/關(guān)鍵寄存器保護(hù)/LED過流保護(hù)/SPI通訊可靠性check

◆ 易用性：支持1/2階環(huán)境光消減/硬件佩戴檢測(cè)/自動(dòng)調(diào)光/動(dòng)態(tài)配置刷新