云社区 > 云博客 > 博客详情
云社区 > 云博客 > 博客详情

NVDLA软件架构和源码解析 第一章—内核驱动

lurayvis 发表于 2017-12-23 11:40:3612-23 11:40
lurayvis 发表于 2017-12-23 11:40:3612-23 11:40
213
0
0

【摘要】 驱动整体设计介绍不同的processor Nvidia DLA的内核驱动KMD(Kernel mode driver)中,并不是把DLA当成一个设备来控制,而是把不同的功能模块当做不同的processor,分别进行任务的管理和控制。在相同processor里分先后,不同队列靠依赖关系控制。当前分了6个processor,代码中如下定义。#define DLA_OP_BDMA ...

image.png

驱动整体设计介绍

不同的processor

       Nvidia DLA的内核驱动KMD(Kernel mode driver)中,并不是把DLA当成一个设备来控制,而是把不同的功能模块当做不同的processor,分别进行任务的管理和控制。在相同processor里分先后,不同队列靠依赖关系控制。当前分了6个processor,代码中如下定义。


#define DLA_OP_BDMA                 0

#define DLA_OP_CONV                  1

#define DLA_OP_SDP                     2

#define DLA_OP_PDP                     3

#define DLA_OP_CDP                     4

#define DLA_OP_RUBIK                  5

对应的芯片架构如下

12.jpg

Headless控制模式

架构上分为高端的headed和低端的headless方案。差别就是是否有MCU来承担IPU的逻辑控制功能。如果有host CPU和MCU两种角色,就是headed方案,否则就是headless。

NVDLA的初始开源版本将仅提供headless模式的软件解决方案。本次运行的场景是在linux下,但是是按照CPU直接操控DLA的寄存器来实现的,也就是headless模式。好处是很容易从无头模式看到核心的IPU控制逻辑。

主要的流程思路

除了初始化,驱动主要处理对上对下两个接口。对上是来和用户态的IOCTL,对下是处理中断。两者最终都是调用或者激活nvdal_task_submit,清理task之间的dependency关系,将合适的task放入processor执行。

66.JPG

图表 1 KMD的主流程

 

特殊的group寄存器

每个子模块processor有两套寄存器,也就是2个group寄存器。这种乒乓思路类似于队列和shadow寄存器的意图,方便一个任务完成后紧接着处理另外一个group寄存器配置的任务,而不是需要完成产生中断后软件才配置下一个任务,以此保持硬件逻辑的全速运行。

软件里定义如下:

/**

 * @ingroup Processors

 * @name Number of groups

 * @brief Each processor has 2 groups of registers

 * @{

 */

#define DLA_NUM_GROUPS       2


struct dla_processor_group {

              uint8_t id;

              uint8_t rdma_id;

              uint8_t active;

              uint8_t events;

              uint8_t roi_index;

              uint8_t is_rdma_needed;

              uint8_t pending;

              int32_t lut_index;

              uint8_t programming;

              uint64_t start_time;


              struct dla_common_op_desc *op_desc;

              struct dla_common_op_desc *consumers[DLA_OP_NUM];

              struct dla_common_op_desc *fused_parent;

              union dla_operation_container *operation_desc;

              union dla_surface_container *surface_desc;

};

 

驱动的注册和初始化

NVDLA驱动以Platform device driver的形式注册到内核。依靠name = "NVDLA”来进行match。重要的函数为nvdla_probe。

module_platform_driver(nvdla_driver);

static struct platform_driver nvdla_driver = {

              .probe = nvdla_probe,

              .remove = __exit_p(nvdla_remove),

              .driver = {

                             .owner = THIS_MODULE,

                             .name = "NVDLA",

                             .of_match_table = nvdla_of_match,

              },

};


Probe函数nvdla_probe

Step1:

申请nvdla_dev并使用platform_set_drvdata挂载到如参pdev上。

Step2:

用devm_ioremap_resource映射内存,用devm_request_irq注册中断。

Step3:

调用dla_register_driver将全局变量engine关联到nvdla_dev->engine_context,Engine包含了device的各种能力,如DMA, CONV。这个就说明engine的含义是各个DLA中模块独立的处理能力。

 

把desc_cache和desc_refcount设置全0。最后调用nvdla_drm_probe注册了drm(Direct Rendering Manager)驱动设备。Nvdla使用drm的主要目的是利用了drm的内存分配机制和ioctl。其实和drm的功能没什么关系。Nvdia作为GPU厂商,借用drm更轻车熟路。

 

中断处理

中断处理nvdla_engine_isr

Step1

 dla_isr_handler(nvdla_dev->engine_context);

主要是根据读取S_INTR_STATUS寄存器得到的值,设置对应engine->processors的group->events标记。比如如果是GLB_S_INTR_STATUS_0就设置engine->processors[DLA_OP_CONV].groups[0].events= (1 << DLA_EVENT_OP_COMPLETED)

step2

complete(&nvdla_dev->event_notifier);

这个会唤醒nvdla_task_submit,调用dla_process_events来处理event。因为中断里可能表示有任务完成,那么就可能消除dependency,可能放入新的任务执行。

对用户态的IOCTL接口

对用户态的接口nvdla_submit利用了drm框架的ioctl。

struct drm_driver nvdla_drm_driver里包含了nvdla_drm_ioctls。索引到nvdla_submit。其他几个ioctl是内存相关的。

DRM_IOCTL_DEF_DRV(NVDLA_SUBMIT, nvdla_submit, DRM_RENDER_ALLOW),

1.       用copy_from_user从ioctl接口复制一些用户态的task数据到内核。

2.       调用nvdla_fill_task_desc填充task结构体

3.       调用nvdla_task_submit。

 

主流程函数讲解

主流程入口函数nvdla_task_submit

Step1

调用dla_execute_task

Step2

等待wait_for_completion(&nvdla_dev->event_notifier),然后调用dla_process_events。


dla_process_events和dla_handle_events

dla_process_events遍历DLA_OP_NUM个processor调用dla_handle_events(processor)。

dla_handle_events遍历自己的processor->groups读取信息,先处理dma相关的event,调用dla_update_consumers来解除dependency_count。如果发现有operation的dependency_count降为0,就dla_enable_operation。这就等于是收到中断后,遍历所有类型的processor,遍历所有的group来解除dependency,找到能执行的下一个任务。

dla_handle_events最后调用了dla_op_completion来处理complete event。

dla_op_completion

1.       先调用dla_update_consumers清理dependency。

2.       如果(engine->network->num_operations == engine->num_proc_hwl)说明网络都算完了。如果还有任务接着调用dla_program_operation和dla_enable_operation来执行下一个任务,和dla_submit_operation的思路差不多。

dla_execute_task

/**

 * Execute task selected by task scheduler

 *

 * 1. Read network configuration for the task

 * 2. Initiate processors with head of list for same op

 * 3. Start processing events received

 */

 

Step1

dla_read_network_config:

1.       将网络的信息读取到network全局变量。注意这里通过DMA直接读取network descriptor的结构体,不是逐个成员复制。

2.       用DMA将operation descriptor,dependency读取过来。

3.       用DMA读取surface descriptor,LUT,ROI的信息。

 

Step2

dla_initiate_processors

1.       遍历DLA_OP_NUM调用dla_get_op_desc找到类型中第一个任务,调用dla_submit_operation提交。

2.       调用dla_put_op_desc。将提交后的dla_common_op_desc consumer在desc_refcount对应的count--,如果为0就删除。

3.       调用dla_dequeue_operation将同类型的下一个操作从取出来,使用的是dla_get_op_desc来取。Dequeue的含义就是取下一个,似乎用fetch更合适。如果有下个op需要执行就调用dla_submit_operation继续执行,否则返回。但是dla_dequeue_operation调用dla_submit_operation并不查看返回结果,所以相当于有空闲资源有任务就继续提交,没有就算了。

 dla_get_op_desc

1.       在desc_cache中找到当前task,以(desc->index == index && desc->roi_index == roi_index)判定相同。desc_refcount++

2.       如果没找到,在desc_cache取一个新entry,设置好,读取该task的对应的dependency_graph_addr的内容,设置desc_refcount为1。

 

dla_submit_operation

1.       调用dla_prepare_operation。看看有没有空闲的processor group,将任务描述放入空闲processor的group。没有空闲就返回错误。

2.       如果processor->is_ready,如果没有ready,就退出。

3.       如果ready,调用dla_program_operation。这里就开始设置对应操作类型的processor的寄存器了。也就是提交任务给硬件了。

4.       如果(op_desc->dependency_count == 0),就enable任务。这个问说明在上一步只是把所有运行的配置做好。任务是否能运行,dependency的关系是在AP的driver里完成的,而不是让DLA硬件来完成。另外,在任务的配置过程中,AP并不是通过某种命令发给DLA,而是DLA的各个子模块处理的processor的控制细节寄存器完全暴露出来,由AP直接配置各寄存器。

作者|lurayvis

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:huaweicloud.bbs@huawei.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。

上一篇:设计模式的C语言应用-表驱动模式

下一篇:【资料合集】设计模式的C语言应用——共十章

相关文章


kafka源码解析之一:源代码工程目录介绍

kafka源码解析之八:Broker分析

kafka源码解析之七:Delayed Request代码分析

kafka源码解析之三:Log模块读写源码分析——(一)

kafka源码解析之三:Log模块读写源码分析——(三)

kafka源码解析之三:Log模块读写源码分析——(二)

kafka源码解析之三:Log模块读写源码分析——(四)

软件测试方法汇总

kafka源码解析之五:New Producer源码分析

华为软件开发云:一站式研发利器

评论(0)


0/1000
评论

登录后可评论,请 登录注册

评论
温馨提示

您确认删除评论吗?

确定
取消
温馨提示

您确认删除评论吗?

删除操作无法恢复,请谨慎操作。

确定
取消
温馨提示

您确认删除博客吗?

确定
取消

确认删除

您确认删除博客吗?

确认删除

您确认删除评论吗?