在调试Openharmony的时候，发现开机logo的图层并没有消失，故分析drmModeSet的api，发现了一个关于atomic modestting相关的宏可以workaround解决此问题，但是后面找到根本原因了，故此修改无效，仅作知识了解储备，此文章总结一下这两个宏的区别和联系
一、drmModeAtomicCommit
关于drmModeAtomicCommit的函数，其来源于libdrm库，参考kwin的实现，可以查到具体描述如下：
参考如下
https://github.com/KDE/kwin/blob/master/src/backends/drm/overview.md?plain=1
可以知道，drmModeAtomicCommit会提交atomic property change给内核drm框架
对于DRM_MODE_ATOMIC_NONBLOCK，代表这次提交的值不会block
对于DRM_MODE_ATOMIC_ALLOW_MODESET，
其会提交所有modeset的改变，与DRM_MODE_ATOMIC_NONBLOCK不同的是，他会阻塞直到内核drm完成modeset的property完成改变
二、调用关系
drmModeAtomicCommit最终会调用到内核的ioctl判断，流程如下：
drmModeAtomicCommit----> DRM_IOCTL(fd, DRM_IOCTL_MODE_ATOMIC, &atomic);----> drm_ioctl---->DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATOMIC, drm_mode_atomic_ioctl, DRM_MASTER),--→drm_mode_atomic_ioctl
此时可以观察如下代码：
if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) { ret = drm_atomic_check_only(state); } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) { ret = drm_atomic_nonblocking_commit(state); } else { if (drm_debug_enabled(DRM_UT_STATE)) drm_atomic_print_state(state); ret = drm_atomic_commit(state); }
这里可以发现，如果设置DRM_MODE_ATOMIC_NONBLOCK和不设置DRM_MODE_ATOMIC_NONBLOCK，代码调用函数不一样，如下：
int drm_atomic_nonblocking_commit(struct drm_atomic_state *state) { struct drm_mode_config *config = &state->dev->mode_config; int ret; ret = drm_atomic_check_only(state); if (ret) return ret; DRM_DEBUG_ATOMIC("committing %p nonblocking\n", state); return config->funcs->atomic_commit(state->dev, state, true); } int drm_atomic_commit(struct drm_atomic_state *state) { struct drm_mode_config *config = &state->dev->mode_config; int ret; ret = drm_atomic_check_only(state); if (ret) return ret; DRM_DEBUG_ATOMIC("committing %p\n", state); return config->funcs->atomic_commit(state->dev, state, false); }
对于回调函数atomic_commit，rockchip平台如下设置
static const struct drm_mode_config_funcs rockchip_drm_mode_config_funcs = { .fb_create = rockchip_fb_create, .output_poll_changed = rockchip_drm_output_poll_changed, .atomic_check = drm_atomic_helper_check, .atomic_commit = drm_atomic_helper_commit, };
所以我们重点留意drm_atomic_helper_commit内的判断如下：
if (!nonblock) { ret = drm_atomic_helper_wait_for_fences(dev, state, true); if (ret) goto err; } if (nonblock) queue_work(system_unbound_wq, &state->commit_work); else commit_tail(state);
这里可以发现，如果是不是nonblock commit，则先会drm_atomic_helper_wait_for_fences，这里会调用dma_fence_wait，用于睡眠等待fence（sleep until the fence gets signaled），如果fence信号触发，则直接提交到尾 commit_tail(state) 直接渲染
而如果是nonblock commit，则直接将这个事件通过queue_work发送到wq上，这个wq的函数如下：
static void commit_work(struct work_struct *work) { struct drm_atomic_state *state = container_of(work, struct drm_atomic_state, commit_work); commit_tail(state); }
这里可以看到如果wq工作时，才调用commit_tail提交到尾
三、Openharmony的使用
在Openharmony的代码中可以知道，只有在更新DrmMode的时候才执行阻塞提交DRM_MODE_ATOMIC_ALLOW_MODESET，而对于每一帧Composition的时候，只是DRM_MODE_ATOMIC_NONBLOCK非阻塞提交。鉴于此，我们可以在每一帧Composition执DRM_MODE_ATOMIC_ALLOW_MODESET，但根据上述代码分析，可能带来图形的性能损失，故不可行。
四、调试方向
根据如上，了解到了drm在atomic commit的时候，可以选择block和nonblock，如果我都设置block，则开机logo的问题确实解决了，鉴于分析代码的时候发现，此方法可能带来性能损失，故仍继续寻找根因。
出现开机后开机logo的图层没消失的主要原因是应该是openharmony图层设置存在问题，故应该从Plane查起。
整个openharmony的ADM基本已经解析完成，如果我们了解过ALSA的话，我们知道整个ALSA中，DAPM关于控件设计的精髓，ADM为了不抛弃这么一个精髓，于是设计了SAPM，虽然我在编写es8388的时候不太敢用，但是这里还是有必要通过对比的方式解析一下ADM对的SAPM
一、简单介绍DAPM
在之前的文章提到过DAPM：内核alsa框架解析
这里简单的，通俗的理解一下DAPM。
DAPM是动态电源管理，我们知道codec有一个概念是音频路由，也就意味着如果我要声音能播放，我需要将codec内部的组件打开，这里可以在Openharmony audio(七) es8388的register说明找到
如果我们直接将寄存器打开关闭，那么就没必要设计一个所谓的DAPM的概念了。
那么DAPM的作用是什么呢。
- 将音频路由抽象成一根链条，音频信号是链条上的一个组件，此时音频组件和路由的关系可以形象化了
- 将每个组件抽象成了电源域，这样每个组件的状态可以通过DAPM来控制，而不是直接写寄存器了
- 音频的所有通路都是不同的链条，当有一个链条打开了，其他没打开的链条会自动关闭，这样更节能，不需要人为的设置这，设置那
- 每个组件都有概念，例如mux是类似单刀多掷开关，而mixer可以将组件多路合并一路，有形象的概念，理解音频路由就不困难了
我再说简单点，就是设计了一个能够让普通人能理解的概念，告诉大家，打开音频需要把某一路开关打开，其他开关就关闭，就跟开灯的开关一样。
这个思想好吗，我认为非常好，即使一个不懂得电子电路的人，他只需要知道打开开关就打开一条通路，然后声音就播放了。
二、ADM的SAPM
2.1 power on/down sequence
模仿dapm的dapm_up_seq/dapm_down_seq，sapm实现了如下：
/* power up sequences */ static int32_t g_audioSapmPowerUpSeq[] = { [AUDIO_SAPM_PRE] = 0, /* 0 is audio sapm power up sequences */ [AUDIO_SAPM_SUPPLY] = 1, /* 1 is audio sapm power up sequences */ [AUDIO_SAPM_MICBIAS] = 2, /* 2 is audio sapm power up sequences */ [AUDIO_SAPM_AIF_IN] = 3, /* 3 is audio sapm power up sequences */ [AUDIO_SAPM_AIF_OUT] = 3, /* 3 is audio sapm power up sequences */ [AUDIO_SAPM_MIC] = 4, /* 4 is audio sapm power up sequences */ [AUDIO_SAPM_MUX] = 5, /* 5 is audio sapm power up sequences */ [AUDIO_SAPM_VIRT_MUX] = 5, /* 5 is audio sapm power up sequences */ [AUDIO_SAPM_VALUE_MUX] = 5, /* 5 is audio sapm power up sequences */ [AUDIO_SAPM_DAC] = 6, /* 6 is audio sapm power up sequences */ [AUDIO_SAPM_MIXER] = 7, /* 7 is audio sapm power up sequences */ [AUDIO_SAPM_MIXER_NAMED_CTRL] = 7, /* 7 is audio sapm power up sequences */ [AUDIO_SAPM_PGA] = 8, /* 8 is audio sapm power up sequences */ [AUDIO_SAPM_ADC] = 9, /* 9 is audio sapm power up sequences */ [AUDIO_SAPM_OUT_DRV] = 10, /* 10 is audio sapm power up sequences */ [AUDIO_SAPM_HP] = 10, /* 10 is audio sapm power up sequences */ [AUDIO_SAPM_SPK] = 10, /* 10 is audio sapm power up sequences */ [AUDIO_SAPM_POST] = 11, /* 11 is audio sapm power up sequences */ }; /* power down sequences */ static int32_t g_audioSapmPowerDownSeq[] = { [AUDIO_SAPM_PRE] = 0, /* 0 is audio sapm power down sequences */ [AUDIO_SAPM_ADC] = 1, /* 1 is audio sapm power down sequences */ [AUDIO_SAPM_HP] = 2, /* 2 is audio sapm power down sequences */ [AUDIO_SAPM_SPK] = 2, /* 2 is audio sapm power down sequences */ [AUDIO_SAPM_OUT_DRV] = 2, /* 2 is audio sapm power down sequences */ [AUDIO_SAPM_PGA] = 4, /* 4 is audio sapm power down sequences */ [AUDIO_SAPM_MIXER_NAMED_CTRL] = 5, /* 5 is audio sapm power down sequences */ [AUDIO_SAPM_MIXER] = 5, /* 5 is audio sapm power down sequences */ [AUDIO_SAPM_DAC] = 6, /* 6 is audio sapm power down sequences */ [AUDIO_SAPM_MIC] = 7, /* 7 is audio sapm power down sequences */ [AUDIO_SAPM_MICBIAS] = 8, /* 8 is audio sapm power down sequences */ [AUDIO_SAPM_MUX] = 9, /* 9 is audio sapm power down sequences */ [AUDIO_SAPM_VIRT_MUX] = 9, /* 9 is audio sapm power down sequences */ [AUDIO_SAPM_VALUE_MUX] = 9, /* 9 is audio sapm power down sequences */ [AUDIO_SAPM_AIF_IN] = 10, /* 10 is audio sapm power down sequences */ [AUDIO_SAPM_AIF_OUT] = 10, /* 10 is audio sapm power down sequences */ [AUDIO_SAPM_SUPPLY] = 11, /* 11 is audio sapm power down sequences */ [AUDIO_SAPM_POST] = 12, /* 12 is audio sapm power down sequences */ };
2.1 检查通路
我们知道dapm会检查是否有一个链路通，如果通，则根据这条链路打开组件电源，这里dapm实现如下：
static int dapm_generic_check_power(struct snd_soc_dapm_widget *w) { int in, out; DAPM_UPDATE_STAT(w, power_checks); in = is_connected_input_ep(w, NULL, NULL); out = is_connected_output_ep(w, NULL, NULL); return out != 0 && in != 0; }
ADM也一样去实现了，实现如下
static int32_t AudioSapmGenericCheckPower(const struct AudioSapmComponent *sapmComponent) { int32_t input; int32_t output; if (sapmComponent == NULL) { ADM_LOG_ERR("input param cpt is NULL."); return HDF_FAILURE; } input = ConnectedInputEndPoint(sapmComponent); if (input == HDF_FAILURE) { ADM_LOG_ERR("input endpoint fail!"); return HDF_FAILURE; } output = ConnectedOutputEndPoint(sapmComponent); if (output == HDF_FAILURE) { ADM_LOG_ERR("output endpoint fail!"); return HDF_FAILURE; } if ((input == 0) || (output == 0)) { ADM_LOG_DEBUG("component %s is not in a complete path.", sapmComponent->componentName); return SAPM_POWER_DOWN; } return SAPM_POWER_UP; }
2.2 组件
对于dapm，每个组件是widget，这个widget应该是codec注册，因为codec知道自己需要多少组件，所以有函数
snd_soc_dapm_new_widgets
对应驱动如下编写：
static const struct snd_soc_dapm_widget es8323_dapm_widgets[] = { SND_SOC_DAPM_INPUT("LINPUT1"), SND_SOC_DAPM_INPUT("LINPUT2"), SND_SOC_DAPM_INPUT("RINPUT1"), SND_SOC_DAPM_INPUT("RINPUT2"), SND_SOC_DAPM_MUX("Left PGA Mux", SND_SOC_NOPM, 0, 0, &es8323_left_dac_mux_controls), SND_SOC_DAPM_MUX("Right PGA Mux",SND_SOC_NOPM , 0, 0, &es8323_right_dac_mux_controls), SND_SOC_DAPM_MICBIAS("Mic Bias", ES8323_ADCPOWER, 3, 1), .... }
这样驱动就很灵活的定义widget，如下：
static struct snd_soc_component_driver soc_codec_dev_es8323 = { .dapm_widgets = es8323_dapm_widgets, .num_dapm_widgets = ARRAY_SIZE(es8323_dapm_widgets), };
这时候ADM不这么想了，他说我知道所有的组件，我定义了数组g_audioSapmCompNameList，如下
static char *g_audioSapmCompNameList[AUDIO_SAPM_COMP_NAME_LIST_MAX] = { "ADCL", "ADCR", "DACL", "DACR", // [0], [1] [2], [3] "LPGA", "RPGA", "SPKL", "SPKR", // [4], [5] [6], [7] "MIC", "LOUT", "HPL", "HPR", // [8], [9] [10], [11] "Stereo Mixer", "Line Mix", "Input Mixer", "Speaker Mix", // [12], [13] [14], [15] "Input Mux", "AuxOut Mux", "SPKL Mux", "SPKR Mux", // [16], [17] [18], [19] "AUXOUTL", "AUXOUTR", "LINEINL", "LINEINR", // [20], [21] [22], [23] "AUXINL", "AUXINR", "I2S Mix", "AuxI Mix", // [24], [25] [26], [27] "CaptureL Mix", "CaptureR Mix", "Mono1 Mixer", "Mono2 Mixer", // [28], [29] [30], [31] "DAC1", "DAC2", "DAC3", "DAC4", // [32], [33] [34], [35] "ADC1", "ADC2", "ADC3", "ADC4", // [36], [37] [38], [39] "MIC1", "MIC2", "MIC3", "MIC4", // [40], [41],[42], [43], "SPK1", "SPK2", "SPK3", "SPK4", // [44], [45],[46], [47], "DAC Mix", "DAC Mux", "ADC Mix", "ADC Mux", // [48], [49],[50], [51], "SPKL PGA", "SPKR PGA", "HPL PGA", "HPR PGA", // [52], [53],[54], [55], };
然后呢，你按照这个数组下标数字去注册，也就是在hcs中写数字
sapmComponent = [ 10, 0, 0xFFFF, 0x1, 7, 1, 0, 0, //ADCL 10, 1, 0xFFFF, 0x1, 6, 1, 0, 0, //ADCR 11, 32, 0xFFFF, 0xFFFF, 0, 0, 0, 0, //DAC1 11, 33, 0xFFFF, 0xFFFF, 0, 0, 0, 0, //DAC2 11, 34, 0xFFFF, 0xFFFF, 0, 0, 0, 0, //DAC3 6, 52, 0xFFFF, 0xFFFF, 0, 0, 3, 1, //SPKL PGA 6, 54, 0xFFFF, 0xFFFF, 0, 0, 4, 1, //HPL PGA 6, 55, 0xFFFF, 0xFFFF, 0, 0, 5, 1, //HPR PGA 15, 6, 0xFFFF, 0xFFFF, 0, 0, 0, 0, //SPK 14, 10, 0xFFFF, 0xFFFF, 0, 0, 0, 0, //HPL 14, 11, 0xFFFF, 0xFFFF, 0, 0, 0, 0, //HPR 6, 4, 0xFFFF, 0xFFFF, 6, 0, 1, 1, //LPGA 6, 5, 0xFFFF, 0xFFFF, 6, 0, 2, 1, //RPGA 13, 40, 0xFFFF, 0xFFFF, 6, 0, 0, 0, //MIC1 13, 41, 0xFFFF, 0x1, 1, 0, 0, 0 //MIC2 ];
也就是说，ADM认为不管未来还是现在，Codec永远就只有这些组件了，如果再多，那就是你Codec的问题了。
此时我们需要主动调用AudioSapmNewComponents函数来注册上面的数字的组件，如下：
if (AudioSapmNewComponents(audioCard, device->devData->sapmComponents, device->devData->numSapmComponent) != HDF_SUCCESS) { AUDIO_DRIVER_LOG_ERR("new components failed."); return HDF_FAILURE; }
所以此时dapm更灵活，它的widget是自己codec定义的，此时widgete可多可少，想怎么扩展怎么扩展。
2.3 路由
我们知道alsa的框架下，路由也是通过驱动注册，如下：
.dapm_routes = audio_map, .num_dapm_routes = ARRAY_SIZE(audio_map),
这里的audio_map告诉你上面的组件的路由情况，和widget一致，需要在驱动中写明白你自己注册的组件，你需要怎么连接，具体可以参考内核alsa框架解析的第六章音频路由分析，如下：
static const struct snd_soc_dapm_route audio_map[] = { {"Left PGA Mux", "Line 1L", "LINPUT1"}, {"Left PGA Mux", "Line 2L", "LINPUT2"}, {"Left PGA Mux", "DifferentialL", "Differential Mux"}, {"Right PGA Mux", "Line 1R", "RINPUT1"}, {"Right PGA Mux", "Line 2R", "RINPUT2"}, {"Right PGA Mux", "DifferentialR", "Differential Mux"} }
这非常合乎常理，也很自然。
我们的ADM，它实现了函数AudioSapmAddRoutes，仿照了alsa的概念，实现了sink和source，如下：
struct AudioSapmRoute { const char *sink; const char *control; const char *source; /* Note: currently only supported for links where source is a supply */ uint32_t (*Connected)(struct AudioSapmComponent *source, struct AudioSapmComponent *sink); };
所以在codec的hdf的driver中，需要定义如下：
static const struct AudioSapmRoute g_audioRoutes[] = { { "SPKL", NULL, "SPKL PGA"}, { "HPL", NULL, "HPL PGA"}, { "HPR", NULL, "HPR PGA"}, { "SPKL PGA", "Speaker1 Switch", "DAC1"}, { "HPL PGA", "Headphone1 Switch", "DAC2"}, { "HPR PGA", "Headphone2 Switch", "DAC3"}, { "ADCL", NULL, "LPGA"}, { "ADCR", NULL, "RPGA"}, { "LPGA", "LPGA MIC Switch", "MIC1"}, { "RPGA", "RPGA MIC Switch", "MIC2"}, };
然后添加如下：
if (AudioSapmAddRoutes(audioCard, g_audioRoutes, HDF_ARRAY_SIZE(g_audioRoutes)) != HDF_SUCCESS) { AUDIO_DRIVER_LOG_ERR("add route failed."); return HDF_FAILURE; }
这里ADM使用了sapmcfg，也就是变量g_audioSapmCfgNameList，作为route的control，它对于hcs的如下：
/*array index, iface, mixer/mux, enable (g_audioSapmCfgNameList)*/ sapmConfig = [ 0, 2, 0, 1, 1, 2, 0, 0, 24, 2, 0, 1, 28, 2, 0, 0, 29, 2, 0, 1 ];
于是仿照了alsa的snd_soc_dapm_add_route实现了AudioSapmAddRoute如下：
static int32_t AudioSapmAddRoute(struct AudioCard *audioCard, const struct AudioSapmRoute *route) { struct AudioSapmpath *path = NULL; struct AudioSapmComponent *cptSource = NULL; struct AudioSapmComponent *cptSink = NULL; struct AudioSapmComponent *sapmComponent = NULL; int32_t ret; DLIST_FOR_EACH_ENTRY(sapmComponent, &audioCard->components, struct AudioSapmComponent, list) { if (sapmComponent->componentName == NULL) { continue; } if ((cptSource == NULL) && (strcmp(sapmComponent->componentName, route->source) == 0)) { cptSource = sapmComponent; continue; } if ((cptSink == NULL) && (strcmp(sapmComponent->componentName, route->sink) == 0)) { cptSink = sapmComponent; } if ((cptSource != NULL) && (cptSink != NULL)) { break; } } path = (struct AudioSapmpath *)OsalMemCalloc(sizeof(struct AudioSapmpath)); if (path == NULL) { ADM_LOG_ERR("malloc path fail!"); return HDF_FAILURE; } path->source = cptSource; path->sink = cptSink; DListHeadInit(&path->list); DListHeadInit(&path->listSink); DListHeadInit(&path->listSource); /* check for external components */ AudioSampExtComponentsCheck(cptSource, cptSink); ret = AudioSampStaticOrDynamicPath(audioCard, cptSource, cptSink, path, route); if (ret != HDF_SUCCESS) { OsalMemFree(path); ADM_LOG_ERR("static or dynamic path fail!"); return HDF_FAILURE; } return HDF_SUCCESS; }
同样的，仿照alsa的snd_soc_dapm_add_path，实现了AudioSampStaticOrDynamicPath，如下：
static int32_t AudioSampStaticOrDynamicPath(struct AudioCard *audioCard, struct AudioSapmComponent *source, struct AudioSapmComponent *sink, struct AudioSapmpath *path, const struct AudioSapmRoute *route) { int32_t ret; if (route->control == NULL) { DListInsertHead(&path->list, &audioCard->paths); DListInsertHead(&path->listSink, &sink->sources); DListInsertHead(&path->listSource, &source->sinks); path->connect = CONNECT_SINK_AND_SOURCE; return HDF_SUCCESS; } switch (sink->sapmType) { case AUDIO_SAPM_MUX: case AUDIO_SAPM_VIRT_MUX: case AUDIO_SAPM_VALUE_MUX: ret = AudioSapmConnectMux(audioCard, source, sink, path, route->control); if (ret != HDF_SUCCESS) { ADM_LOG_ERR("connect mux fail!"); return HDF_FAILURE; } break; case AUDIO_SAPM_ANALOG_SWITCH: case AUDIO_SAPM_MIXER: case AUDIO_SAPM_MIXER_NAMED_CTRL: case AUDIO_SAPM_PGA: case AUDIO_SAPM_SPK: ret = AudioSapmConnectMixer(audioCard, source, sink, path, route->control); if (ret != HDF_SUCCESS) { ADM_LOG_ERR("connect mixer fail!"); return HDF_FAILURE; } break; case AUDIO_SAPM_HP: case AUDIO_SAPM_MIC: case AUDIO_SAPM_LINE: DListInsertHead(&path->list, &audioCard->paths); DListInsertHead(&path->listSink, &sink->sources); DListInsertHead(&path->listSource, &source->sinks); path->connect = CONNECT_SINK_AND_SOURCE; break; default: DListInsertHead(&path->list, &audioCard->paths); DListInsertHead(&path->listSink, &sink->sources); DListInsertHead(&path->listSource, &source->sinks); path->connect = CONNECT_SINK_AND_SOURCE; break; } return HDF_SUCCESS; }
至此，我们可以发现，SAPM和DAPM本质是一样的，相当于重复根据DAPM的设计思路造了一个SAPM的轮子。
三、结论
根据上面的代码分析，我们可以发现sapm和dapm实现是类似的，但是根据我调试时发现，sapm定义是强制的，也就是
- 如果驱动不定义sapm，驱动会报错
- 如果sapm设置的g_audioRoutes不在g_audioSapmCompNameList中，驱动会报错
- 如果hcs设置的sapmComponent和g_audioRoutes以及g_audioSapmCompNameList不匹配，则驱动报错
所以，只有完全了解sapm的玩法，并且按照ADM的规则，死死的配置，并按照数字的方式配置正确，你的驱动才能正常。
为了避免这个问题，我在ControlHostElemWrite中直接返回了，这样ADM就不走SAPM的control设置了。
虽然现在分析了sapm，它和DAPM完全一致，我应该也可以通过sapm的配置完成正确的声卡设置，但是我认为也没必要了。因为sapm目前还不是很成熟。
对于声卡的播放和录制，数据搬运到i2s上去发送是通过dma处理的，应用的数据通过stream dispatch下来，这时候，我们需要将其发送在dma的通道上，然后dma附在i2s的接收寄存器地址上，从而使得i2s直接可以发送音频数据，所以需要一个dma的hdf driver，这里分析这个驱动
一、Rk3568DmaSubmit,代码目录
对于dma的驱动，代码路径如下：
device/board/hihope/rk3568/audio_drivers/soc/src/
相应文件如下：
rk3568_dma_adapter.c rk3568_dma_ops.c
二、代码解析
2.1 rk3568_dma_adapter.c
这里注册HDF driver，如下
/* HdfDriverEntry definitions */ struct HdfDriverEntry g_platformDriverEntry = { .moduleVersion = 1, .moduleName = "DMA_RK3568", .Bind = PlatformDriverBind, .Init = PlatformDriverInit, .Release = PlatformDriverRelease, }; HDF_INIT(g_platformDriverEntry);
这里Bind提供服务，Init开始初始化，咱们关注Init，它提供ADM注册codec时的回调，并注册platform设备，如下：
static int32_t PlatformDriverInit(struct HdfDeviceObject *device) { int32_t ret; struct PlatformData *platformData = NULL; struct PlatformHost *platformHost = NULL; if (device == NULL) { AUDIO_DEVICE_LOG_ERR("device is NULL."); return HDF_ERR_INVALID_OBJECT; } platformHost = (struct PlatformHost *)device->service; if (platformHost == NULL) { AUDIO_DEVICE_LOG_ERR("platformHost is NULL"); return HDF_FAILURE; } platformData = (struct PlatformData *)OsalMemCalloc(sizeof(*platformData)); if (platformData == NULL) { AUDIO_DEVICE_LOG_ERR("malloc PlatformData fail!"); return HDF_FAILURE; } ret = PlatformGetServiceName(device, platformData); if (ret != HDF_SUCCESS) { OsalMemFree(platformData); return ret; } platformData->PlatformInit = AudioDmaDeviceInit; platformData->ops = &g_dmaDeviceOps; if (AudioDmaGetConfigInfo(device, platformData) != HDF_SUCCESS) { OsalMemFree(platformData); return HDF_FAILURE; } OsalMutexInit(&platformData->renderBufInfo.buffMutex); OsalMutexInit(&platformData->captureBufInfo.buffMutex); ret = AudioSocRegisterPlatform(device, platformData); if (ret != HDF_SUCCESS) { OsalMemFree(platformData); return ret; } platformHost->priv = platformData; AUDIO_DEVICE_LOG_DEBUG("success.\n"); return HDF_SUCCESS; }
这里需要提供ops回调，如下
struct AudioDmaOps g_dmaDeviceOps = { .DmaBufAlloc = Rk3568DmaBufAlloc, .DmaBufFree = Rk3568DmaBufFree, .DmaRequestChannel = Rk3568DmaRequestChannel, .DmaConfigChannel = Rk3568DmaConfigChannel, .DmaPrep = Rk3568DmaPrep, .DmaSubmit = Rk3568DmaSubmit, .DmaPending = Rk3568DmaPending, .DmaPause = Rk3568DmaPause, .DmaResume = Rk3568DmaResume, .DmaPointer = Rk3568PcmPointer, };
2.2 rk3568_dma_ops.c
这个文件主要实现上述AudioDmaOps 需要填充的函数回调，以及实现ADM Platform driver的Init回调。
对于Init回调，主要解析hcs的配置中dma_config.hcs对dma的配置。主要如下：
idInfo { chipName = "/i2s@fe410000"; chipIdRegister = 0xfe410000; chipIdSize = 0x1000; }
这种情况下，我们通过chipIdRegister+offset就能找到i2s的搬运地址。这样dma就能直接处理
而对于dma的通道，还是基于dts的设置来通过内核dma的api来申请dma，如下
static int32_t GetDmaChannel(struct PlatformData *data) { struct DmaRuntimeData *dmaRtd = NULL; struct device_node *dmaOfNode = NULL; struct device *dmaDevice = NULL; struct property *dma_names = NULL; const char *dma_name = NULL; bool hasRender = false; bool hasCapture = false; static const char * const dmaChannelNames[] = { [DMA_TX_CHANNEL] = "tx", [DMA_RX_CHANNEL] = "rx", }; dmaRtd = (struct DmaRuntimeData *)data->dmaPrv; if (dmaRtd == NULL) { AUDIO_DEVICE_LOG_ERR("dmaRtd is null."); return HDF_FAILURE; } dmaOfNode = dmaRtd->dmaOfNode; if (dmaOfNode == NULL) { AUDIO_DEVICE_LOG_ERR("dmaOfNode is null."); return HDF_FAILURE; } of_property_for_each_string(dmaOfNode, "dma-names", dma_names, dma_name) { if (strcmp(dma_name, "rx") == 0) { hasCapture = true; } if (strcmp(dma_name, "tx") == 0) { hasRender = true; } } dmaDevice = dmaRtd->dmaDev; if (dmaDevice == NULL) { AUDIO_DEVICE_LOG_ERR("dmaDevice is null."); return HDF_FAILURE; } if (hasRender) { dmaRtd->dmaChn[DMA_TX_CHANNEL] = dma_request_slave_channel(dmaDevice, dmaChannelNames[DMA_TX_CHANNEL]); if (dmaRtd->dmaChn[DMA_TX_CHANNEL] == NULL) { AUDIO_DEVICE_LOG_ERR("dma_request_slave_channel DMA_TX_CHANNEL failed"); return HDF_FAILURE; } } if (hasCapture) { dmaRtd->dmaChn[DMA_RX_CHANNEL] = dma_request_slave_channel(dmaDevice, dmaChannelNames[DMA_RX_CHANNEL]); if (dmaRtd->dmaChn[DMA_RX_CHANNEL] == NULL) { AUDIO_DEVICE_LOG_ERR("dma_request_slave_channel DMA_RX_CHANNEL failed"); return HDF_FAILURE; } } return HDF_SUCCESS; }
这里要求了dts的dma配置如下：
i2s1_8ch: i2s@fe410000 { compatible = "rockchip,rk3568-i2s-tdm"; reg = <0x0 0xfe410000 0x0 0x1000>; interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cru MCLK_I2S1_8CH_TX>, <&cru MCLK_I2S1_8CH_RX>, <&cru HCLK_I2S1_8CH>; clock-names = "mclk_tx", "mclk_rx", "hclk"; dmas = <&dmac1 2>, <&dmac1 3>; dma-names = "tx", "rx"; ........ }
这时候就有疑问了，为什么dts描述的很清楚（reg = <0x0 0xfe410000 0x0 0x1000>;），还需要hcs重复写一遍dma搬运地址和大小，直接从dts拿reg属性和node name就行了？这里我给出的结论就是：
-
对于Rk3568DmaBufAlloc，就是内核的dma_alloc_wc
-
对于Rk3568DmaBufFree，就是内核的dma_free_wc
-
对于Rk3568DmaRequestChannel，空的设计
-
对于Rk3568DmaConfigChannel，就是内核的dmaengine_slave_config
-
对于Rk3568DmaPrep，空的设计
-
对于Rk3568DmaSubmit，就是内核的dmaengine_prep_dma_cyclic
-
对于Rk3568DmaPause，就是内核的dmaengine_terminate_async
-
对于Rk3568PcmPointer，根据声卡的设计，将byte转换成audio的frame，如下
static int32_t BytesToFrames(uint32_t frameBits, uint32_t size, uint32_t *pointer) { if (pointer == NULL || frameBits == 0) { AUDIO_DEVICE_LOG_ERR("input para is error."); return HDF_FAILURE; } *pointer = size / frameBits; return HDF_SUCCESS; }
对于上述的设计，我们可以发现，其思想借鉴于ALSA的pcm_dmaengine.c。
与pcm_dmaengine.c不同的是，pcm_dmaengine.c实现了更通用的dmaengine，对于dai来说注册devm_snd_dmaengine_pcm_register即可，pcm_dmaengine.c只做audio的抽象。分层使得代码更健壮。
而这里的rk3568_dma_ops.c是直接指定了dma，并简化了pcm_dmaengine.c的实现。相当于将一个良好的，通用的，成熟的方案，写成了一个固定的，不灵活的，残缺的方案。
三、结论
我们根据分析dma的hdf driver，可以知道openharmony通过直接了当的方式，将数据通过dma在i2s上搬运进出。同时也知道了，目前的dma驱动实现的非常简陋，而且十分固定，不过代码能跑就是福。
对于声卡的dai部分，因为i2s是rk3568侧的通讯总线，所以我们对于i2s的控制器这侧也需要配置正确，这样rk3568的i2s发送音频数据的时候，es8388能够正常的接收，所以有必要介绍一下rk侧的i2s的驱动，也就是dai驱动
一、代码目录
对于i2s的驱动，代码路径如下：
device/board/hihope/rk3568/audio_drivers/dai/
相应文件如下：
rk3568_dai_adapter.c rk3568_dai_linux_driver.c rk3568_dai_ops.c
二、代码解析
2.1 rk3568_dai_linux_driver.c
此驱动主要注册platfrom设备，读取dts的配置，设置时钟和分频，大致如下
static struct platform_driver rockchip_i2s_tdm_driver = { .probe = rockchip_i2s_tdm_probe, .remove = rockchip_i2s_tdm_remove, .driver = { .name = DRV_NAME, .of_match_table = of_match_ptr(rockchip_i2s_tdm_match), .pm = NULL, }, }; module_platform_driver(rockchip_i2s_tdm_driver); static int rockchip_i2s_tdm_probe(struct platform_device *pdev) { struct device_node *node = pdev->dev.of_node; const struct of_device_id *of_id; struct rk3568_i2s_tdm_dev *i2s_tdm; struct resource *res; struct device *temp_i2s_dev; ...... i2s_tdm->bclk_fs = 64; // default-freq div factor is 64 if (!of_property_read_u32(node, "rockchip,bclk-fs", &val)) { if ((val >= 32) && (val % 2 == 0)) // min-freq div factor is 32, and it is an integer multiple of 2 i2s_tdm->bclk_fs = val; } ...... i2s_tdm->mclk_tx = devm_clk_get(&pdev->dev, "mclk_tx"); if (IS_ERR(i2s_tdm->mclk_tx)) { return PTR_ERR(i2s_tdm->mclk_tx); } i2s_tdm->mclk_rx = devm_clk_get(&pdev->dev, "mclk_rx"); if (IS_ERR(i2s_tdm->mclk_rx)) { return PTR_ERR(i2s_tdm->mclk_rx); } res = platform_get_resource(pdev, IORESOURCE_MEM, 0); i2s_tdm->regmap = devm_regmap_init_mmio(&pdev->dev, devm_ioremap_resource(&pdev->dev, res), &rockchip_i2s_tdm_regmap_config); if (IS_ERR(i2s_tdm->regmap)) { return PTR_ERR(i2s_tdm->regmap); } ...... }
2.2 rk3568_dai_adapter.c
这份驱动是hdf的驱动程序，它通过HDF_INIT(g_daiDriverEntry);来注册一个hdf的驱动
/* HdfDriverEntry definitions */ struct HdfDriverEntry g_daiDriverEntry = { .moduleVersion = 1, .moduleName = "DAI_RK3568", .Bind = DaiDriverBind, .Init = DaiDriverInit, .Release = DaiDriverRelease, }; HDF_INIT(g_daiDriverEntry);
对于Bind回调，绑定服务，对于Init，用作注册dai，如下
daiData = (struct DaiData *)OsalMemCalloc(sizeof(*daiData)); if (daiData == NULL) { AUDIO_DEVICE_LOG_ERR("malloc DaiData fail!"); return HDF_FAILURE; } daiData->Read = Rk3568DeviceReadReg, daiData->Write = Rk3568DeviceWriteReg, daiData->DaiInit = Rk3568DaiDeviceInit, daiData->ops = &g_daiDeviceOps, daiData->daiInitFlag = false; OsalMutexInit(&daiData->mutex); daiHost->priv = daiData; if (DaiGetConfigInfo(device, daiData) != HDF_SUCCESS) { AUDIO_DEVICE_LOG_ERR("get dai data fail."); OsalMemFree(daiData); return HDF_FAILURE; } if (DaiGetServiceName(device, daiData) != HDF_SUCCESS) { AUDIO_DEVICE_LOG_ERR("get service name fail."); OsalMemFree(daiData); return HDF_FAILURE; } ret = AudioSocRegisterDai(device, (void *)daiData);
所以这里涉及一个dai的结构体，用于触发startup和hwparams以及trigger时的i2s的寄存器设置，如下：
struct AudioDaiOps g_daiDeviceOps = { .Startup = Rk3568DaiStartup, .HwParams = Rk3568DaiHwParams, .Trigger = Rk3568NormalTrigger, };
2.3 rk3568_dai_ops.c
对于startup回调，这里i2s不需要做任何事情
对于hwparams回调，这里需要根据实际的参数，设置i2s的寄存器，时钟，如下：
int32_t Rk3568DaiHwParams(const struct AudioCard *card, const struct AudioPcmHwParams *param) { int ret; uint32_t bitWidth; struct DaiDevice *dai = NULL; struct DaiData *data = DaiDataFromCard(card); struct platform_device *platformdev = NULL; struct rk3568_i2s_tdm_dev *i2sTdm = NULL; if (card == NULL || card->rtd == NULL || param == NULL || param->cardServiceName == NULL) { AUDIO_DEVICE_LOG_ERR("input para is NULL."); return HDF_ERR_INVALID_PARAM; } if (data == NULL) { AUDIO_DEVICE_LOG_ERR("data is nullptr."); return HDF_FAILURE; } dai = card->rtd->cpuDai; platformdev = GetPlatformDev(dai); if (platformdev == NULL) { AUDIO_DEVICE_LOG_ERR("platformdev is NULL."); return HDF_FAILURE; } data->pcmInfo.channels = param->channels; AUDIO_DEVICE_LOG_DEBUG("channels count : %d .", param->channels); if (AudioFormatToBitWidth(param->format, &bitWidth) != HDF_SUCCESS) { AUDIO_DEVICE_LOG_ERR("AudioFormatToBitWidth error"); return HDF_FAILURE; } data->pcmInfo.bitWidth = bitWidth; data->pcmInfo.rate = param->rate; data->pcmInfo.streamType = param->streamType; i2sTdm = dev_get_drvdata(&platformdev->dev); if (i2sTdm == NULL) { AUDIO_DEVICE_LOG_ERR("i2sTdm is null"); return HDF_FAILURE; } ret = RK3568I2sTdmSetSysClk(i2sTdm, param); if (ret != HDF_SUCCESS) { AUDIO_DEVICE_LOG_ERR("RK3568I2sTdmSetSysClk error"); return HDF_FAILURE; } ret = RK3568I2sTdmSetMclk(i2sTdm, param); if (ret != HDF_SUCCESS) { AUDIO_DEVICE_LOG_ERR("RK3568I2sTdmSetMclk error"); return HDF_FAILURE; } AUDIO_DEVICE_LOG_DEBUG("success"); return HDF_SUCCESS; }
对于trigger回调，判断是否是stop/pause，start/resume，来控制i2s的寄存器，如下
static int32_t Rk3568TxAndRxSetReg(struct rk3568_i2s_tdm_dev *i2sTdm, enum AudioStreamType streamType, int on) { int ret; if (i2sTdm == NULL || i2sTdm->regmap == NULL) { AUDIO_DEVICE_LOG_ERR("i2sTdm is null"); return HDF_FAILURE; } if (on) { // when start/resume ret = Rk3568TxAndRxStart(i2sTdm, streamType); if (ret != HDF_SUCCESS) { AUDIO_DEVICE_LOG_ERR("Rk3568TxAndRxStart is failed"); return HDF_FAILURE; } } else { // when stop/pause ret = Rk3568TxAndRxStop(i2sTdm, streamType); if (ret != HDF_SUCCESS) { AUDIO_DEVICE_LOG_ERR("Rk3568TxAndRxStop is failed"); return HDF_FAILURE; } } AUDIO_DEVICE_LOG_DEBUG("success"); return HDF_SUCCESS; }
三、总结
至此，rk3568的i2s的hdf驱动解析完成，我们可以知道，对于i2s，我们应该在合适的时候对其设置rk3568这侧的寄存器，让其按照指定的方式和codec进行通讯，所以需要这么一个hdf driver。
根据Openharmony audio(六) es8388的hcs配置中的配置，我们需要填写大量针对es8388寄存器的设置，所以这块需要我们对es8388的寄存器配置说明有一个描述文档，然后针对此文档进行驱动的设计和开发，如下是具体过程
一、es8388 datasheet
es8388的datashell可以从其官网查阅，如下是链接
二、音频通路
我们能够拿到codec的datasheet后，第一件事就可以了解如何让其工作，也就是音频通路，我们可以参考我的文章《内核alsa框架解析》
根据datasheet我们可以发现es8388是音频设计十分简单，我重新贴图如下：
此图片可以从《ES8388 User Guide》找到，此文档贴心的给出了声音输出的设置方式，如下
三、寄存器说明
根据一中的文档，我们可以找到所有寄存器的设置说明，如下我们贴出来大致情况，方便查阅
3.1 reset寄存器说明
我们在hcs设置和hdf driver的开发的时候，需要进行software reset，这个对应寄存器是0x00 0x80，如下：
resetSeqConfig = [ 0x00, 0x80, 0x00, 0x00, ];
这里的寄存器说明如下：
我们留意bit7，这里是SCPReset，如果写1则重置codec
3.2 startup寄存器说明
在hcs设置时，需要在dai startup时设置寄存器，如下：
/* reg, rreg, shift, rshift, min, max, mask, invert, value */ daiStartupSeqConfig = [ 0x03, 0x03, 0, 0, 0x0, 0xFF, 0xFF, 0, 0xf9, // es8388 adc power standby 0x04, 0x04, 0, 0, 0x0, 0xFF, 0xFF, 0, 0x3c, // es8388 dac power prepare 0x0f, 0x0f, 0, 0, 0x0, 0xFF, 0xFF, 0, 0x20, // es8316_adc_mute(capture unmute) 0x19, 0x19, 0, 0, 0x0, 0xFF, 0xFF, 0, 0x02 // es8388 dac unmute (DACCONTROL3) ];
对于0x3，设置0xf9，关掉adc的power，寄存器描述如下
对于0x4，设置0x3c，将L/R OUT都打开，寄存器描述如下：
对于0xf，设置0x20，将麦克风禁音，寄存器描述如下：
对于0x19，设置0x2，将DAC Mute关闭，也就是打开喇叭，寄存器描述如下：
3.3 音频位数
不同的音频音乐，通过设置不同的bit来播放，这个寄存器是0x17，假设音频是16位的，那么设置为0x18，如下：
3.4 其他参数
音频还有其他参数，例如mclk的分屏倍数，i2s的格式，声音的增益等等，这里就不一一列举了。都可以根据datasheet的描述，将其通过寄存器的方式设置进去
四、调试I2C
根据上面的介绍，我们知道了如何根据寄存器设置codec的状态，这里为了调试i2c，可以通过i2cdump命令来直接调试i2c设备，从而准确的知道每时每刻的codec寄存器的状态，如下：
# i2cdump -fy 2 0x10 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 32 50 00 f9 3c 00 00 7c 00 88 f0 02 00 02 30 20 2P.?<..|.???.?0 10: 00 00 ea a2 32 06 00 00 02 02 00 00 08 00 1f f7 ..??2?..??..?.?? 20: fd ff 1f f7 fd ff 00 b8 28 28 b8 80 00 00 1e 1e ??????.?((??..?? 30: 1c 1c 00 aa aa 00 08 00 00 00 00 40 84 84 00 00 ??.??.?....@??.. 40: 32 50 00 f9 3c 00 00 7c 00 88 f0 02 00 02 30 20 2P.?<..|.???.?0 50: 00 00 ea a2 32 06 00 00 02 02 00 00 08 00 1f f7 ..??2?..??..?.?? 60: fd ff 1f f7 fd ff 00 b8 28 28 b8 80 00 00 1e 1e ??????.?((??..?? 70: 1c 1c 00 aa aa 00 08 00 00 00 00 40 84 84 00 00 ??.??.?....@??.. 80: 32 50 00 f9 3c 00 00 7c 00 88 f0 02 00 02 30 20 2P.?<..|.???.?0 90: 00 00 ea a2 32 06 00 00 02 02 00 00 08 00 1f f7 ..??2?..??..?.?? a0: fd ff 1f f7 fd ff 00 b8 28 28 b8 80 00 00 1e 1e ??????.?((??..?? b0: 1c 1c 00 aa aa 00 08 00 00 00 00 40 84 84 00 00 ??.??.?....@??.. c0: 32 50 00 f9 3c 00 00 7c 00 88 f0 02 00 02 30 20 2P.?<..|.???.?0 d0: 00 00 ea a2 32 06 00 00 02 02 00 00 08 00 1f f7 ..??2?..??..?.?? e0: fd ff 1f f7 fd ff 00 b8 28 28 b8 80 00 00 1e 1e ??????.?((??..?? f0: 1c 1c 00 aa aa 00 08 00 00 00 00 40 84 84 00 00 ??.??.?....@??..
根据上面可以知道es8388的寄存器所有状态，此时我们对照datasheet去排查是否存在异常即可。对照寄存器是否异常的事情需要比较细心。
五、结论
至此，我们可以通过es8388的datasheet和user guide来控制codec的工作了。只要codec正常上电，声音参数配置正确，音频通路设置正确，那么声卡就能够正常工作。
