你好！这里是风筝的博客，
欢迎和我一起交流。
很久没写kernel相关的东西了，主要是来到手机厂之后，大部分还是在Android上，Kernel虽然也有涉及，但毕竟只是有所涉及，主要业务逻辑还是在HAL之上，kernel的修改除了项目bringup，之后基本甚少修改。
最近倒是碰到一个Kernel的问题，简单记录下~
【前提条件】【Prerequistes】手机录入指纹 声音与振动——触感与提示音开启指纹动画音， 指纹样式选择旋涡样式
【操作步骤】【Operation steps】播放QQ音乐，按power键息屏亮屏指纹解锁
【实际结果】【Actual results】指纹动画声音响起有卡顿声
【期望结果】【Expected results】不应该有卡顿声音
【对比的上个版本编号】【Number of previous version for comparison】低概率问题
以我多年工作经验来看，外放问题是最好解决的了，相对好处理些。
查看AudioDspStreamManager.xx.TaskPlayback_ivdump.pcm文件，这是PA的VI反馈信号，可以反馈出喇叭的真实状态。从频谱上看，确实出现了卡顿，在解锁动画提示音响起的时候。
同样查看AudioDspStreamManager.xx.TaskPlayback_datain.pcm，发现确实Kernel里的数据就有问题了，但是查看streamout.pcm.xx.AudioALSAPlaybackHandlerDsp.flag8.xx.48000.8_24bit.2ch_20230411_092109.wav
是没有问题的，说明问题出现在了Kernel底层，没有出现在HAL。
因为提示音是短音，走的fast通路，buf又小，确实容易出现问题。
查看kernel log：
<6>[83150.878119][T600541] mtk_dsp_check_exception() deep adsp underflow
<6>[83150.926100][T516896] snd_audio_dsp snd_audio_dsp: mtk_dsp_start() deep just underflow
<6>[83178.409440][T700541] mtk_dsp_check_exception() fast adsp underflow
<6>[83178.419408][T712585] snd_audio_dsp snd_audio_dsp: mtk_dsp_start() fast just underflow
确实发现了异常，出现了underflow，这表明写数据慢了，没有数据可以播放，所以出现了underflow！
同步查看ADSP的log：
[83137.343]<A-22>[D]audio_dsp_hw_write_op(), HW_STATE_UNDERFLOW, return
[83157.758]<A-11>[D] enter_write_cond, underflow, written_size[2048] datacount[0] task_name[fast_playback]
[83157.758]<A-11>[W] write_data_loop() ADSP_DL_CONSUME_UNDERFLOW
[83166.654]<A-11>[D] enter_write_cond, underflow, written_size[2048] datacount[0] task_name[fast_playback]
[83166.654]<A-11>[W] write_data_loop() ADSP_DL_CONSUME_UNDERFLOW
确实同样可以看到underflow。
因为underflow是没有数据可播，属于写数据不及时，所以修改增大buffer size是没有用的。
所以我们只能另想它法！
这里简单描述下MTK的播放：
灵魂画手，嘿嘿，按照理解自己画了下图~
Hal往kernel写数据之后，会通过ipi核间通信，将数据送往DSP做处理，DSP上会跑我们用到的算法，处理完的数据就通过iis送到codec进行播放，kernel里面只负责管理对codec的control。
源码解析：
drivers/misc/mediatek/audio_ipi/common/adsp_ipi.c
static int __init audio_ipi_init(void)
{
ipi_queue_init();
audio_task_manager_init();
audio_messenger_ipi_init();
init_audio_ipi_dma();
#if IS_ENABLED(CONFIG_MTK_AUDIODSP_SUPPORT)
adsp_register_notify(&audio_ctrl_notifier);
#endif
for (task_id = 0; task_id < TASK_SCENE_SIZE; task_id++) {
task_info = &g_audio_task_info[task_id];
dsp_id = audio_get_dsp_id(task_id);
task_info->dsp_id = dsp_id;
task_info->is_dsp_support = is_audio_dsp_support(dsp_id);
task_info->is_adsp = is_audio_use_adsp(dsp_id);
task_info->is_scp = is_audio_use_scp(dsp_id);
task_info->task_ctrl = get_audio_controller_task(dsp_id);
}
ret = misc_register(&audio_ipi_device);
}
drivers/misc/mediatek/audio_ipi/common/adsp_ipi_queue.c
void ipi_queue_init(void)
{
for (dsp_id = 0; dsp_id < NUM_OPENDSP_TYPE; dsp_id++) {
if (is_audio_dsp_support(dsp_id))
ipi_queue_init_by_dsp(dsp_id);
}
#if IS_ENABLED(CONFIG_MTK_AUDIODSP_SUPPORT)
hook_ipi_queue_send_msg_handler(dsp_send_msg_to_queue_wrap);
hook_ipi_queue_recv_msg_hanlder(dsp_dispatch_ipi_hanlder_to_queue_wrap);
#endif
}
hook_ipi_queue_send_msg_handler和hook_ipi_queue_recv_msg_hanlder主要是给ipi_queue_send_msg_handler和ipi_queue_recv_msg_handler这两个函数指针赋值的，在给dsp发送msg和接受msg的时候会用，这里没啥好说的，主要是：ipi_queue_init_by_dsp，这里会针对DSP做初始化：
int ipi_queue_init_by_dsp(uint32_t dsp_id)
{
for (dsp_path = 0; dsp_path < DSP_NUM_PATH; dsp_path++) {
msg_queue = &g_dsp_msg_queue[dsp_id][dsp_path];
ret = dsp_init_single_msg_queue(msg_queue, dsp_id, dsp_path);
if (ret != 0)
WARN_ON(1);
}
}
这里会循环两次：0是AP to DSP，1是DSP to AP。
static int dsp_init_single_msg_queue(
struct dsp_msg_queue_t *msg_queue,
const uint32_t dsp_id,
const uint32_t dsp_path)
{
if (dsp_path == DSP_PATH_A2D) {
msg_queue->dsp_process_msg_func = dsp_send_msg_to_dsp;
} else if (dsp_path == DSP_PATH_D2A) {
msg_queue->dsp_process_msg_func = dsp_process_msg_from_dsp;
} else
WARN_ON(1);
/* lunch thread */
msg_queue->dsp_thread_task = kthread_create(
dsp_process_msg_thread,
msg_queue,
"%s",
thread_name);
if (IS_ERR(msg_queue->dsp_thread_task)) {
pr_info("can not create %s kthread", thread_name);
WARN_ON(1);
msg_queue->thread_enable = false;
} else {
msg_queue->thread_enable = true;
dsb(SY);
wake_up_process(msg_queue->dsp_thread_task);
}
}
重点看下这里面就好了，针对不同的情况，AP to DSP 还是 DSP to AP，会赋值不同的处理函数到dsp_process_msg_func。然后会创建线程：dsp_process_msg_thread，并启动：wake_up_process
static int dsp_process_msg_thread(void *data)
{
while (msg_queue->thread_enable && !kthread_should_stop()) {
/* wait until element pushed */
retval = dsp_get_queue_element(msg_queue, &p_dsp_msg, &idx_msg);
p_element = &msg_queue->element[idx_msg];
/* send to dsp */
retval = msg_queue->dsp_process_msg_func(msg_queue, p_dsp_msg);
/* notify element if need */
spin_lock_irqsave(&p_element->element_lock, flags);
if (p_element->wait_in_thread == true) {
p_element->send_retval = retval;
p_element->signal_arrival = true;
dsb(SY);
wake_up_interruptible(&p_element->element_wq);
}
spin_unlock_irqrestore(&p_element->element_lock, flags);
/* pop message from queue */
spin_lock_irqsave(&msg_queue->queue_lock, flags);
dsp_pop_msg(msg_queue);
spin_unlock_irqrestore(&msg_queue->queue_lock, flags);
}
return 0;
}
线程里面处理还是比较简单的，就是等待有数据到queue里，如果有就通过之前填充的dsp_process_msg_func钩子函数，发给DSP处理即可。
好，扯了这么一大堆，回归本题，如果出现了underflow，说明写数据不及时，写数据就是通过dsp_process_msg_thread这个线程里面写到DSP的，所以，我们只需要保证这个线程的正常调度运行即可。
如何保证呢？自然是提升线程优先级！
为了使得用户能有良好的用户体验，dsp_init_single_msg_queue这里在创建线程的时候，这里直接将线程加入RT线程，RT （Real Thread）实时线程。
kthread_create线程创建之后，通过这个API：
struct sched_param param = { .sched_priority = 3 };
sched_setscheduler_nocheck(msg_queue->dsp_thread_task, SCHED_FIFO, ¶m);
即可加入RT线程。
加入RT线程之后，压测问题场景，没有再出现underflow的情况，卡顿问题也没有再复现了，问题完美解决~
最开始的audio_ipi_init函数里，还有一些内容就不多阐述了，DSP这块资料比较少，还是比较难去了解的，非本文重点。
audio_ipi_init后面就是配置DMA和TASK这些，每个scene占用一个Task：
/* scene for library */
TASK_SCENE_PHONE_CALL = 0,
TASK_SCENE_VOICE_ULTRASOUND = 1,
TASK_SCENE_PLAYBACK_MP3 = 2,
TASK_SCENE_RECORD = 3,
TASK_SCENE_VOIP = 4,
TASK_SCENE_SPEAKER_PROTECTION = 5,
TASK_SCENE_VOW = 6,
TASK_SCENE_PRIMARY = 7,
TASK_SCENE_DEEPBUFFER = 8,
TASK_SCENE_AUDPLAYBACK = 9,
TASK_SCENE_CAPTURE_UL1 = 10,
TASK_SCENE_A2DP = 11,
//......
OK，后面就不表了，以后再说吧~
