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

你的名字 2023-06-27 08:55 8阅读 0赞

驱动整体设计介绍  
不同的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

对应的芯片架构如下：

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执行。

图表 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  
————————————————  
版权声明：本文为CSDN博主「华为云」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。  
原文链接：https://blog.csdn.net/devcloud/article/details/91523479