[参考译文] AM625：AM625：循环模式 UDMA 问题已存在于 11.01.05.03 中

尊敬的 Han：

但是、SDK 11 中的问题已发生更改。 在 SDK 10 中、我在音频播放和捕获期间都遇到了显著的 DMA 延迟。 在 SDK 11 中、此问题仅在捕获期间发生、特别是在 DMA dev to MEM 模式下。

您能详细介绍一下捕捉时会发生什么情况吗？ 故障记录或音频录制不正确？

此外、您是否认为随着上述变化、延迟有所改善、但播放和录制用例无法正常工作？

此外、我们发布了 11.2 SDK、您能否在此 SDK 上尝试和验证它、并告诉我们是否安装了补丁（删除或注释  period_csf = CPPI5_TR_CSF_EOP)

仍是 11.2 SDK 所必需的。

此致、

Suren

您好、Suren、

首先、使用录制音频将导致 EIO 错误。 跟踪此错误、它出现在 SDK 11 的 Linux 目录中`sound/core/pcm_lib.c`文件的第 2027 行、具体而言位于`wait_for_avail`函数的下方。 进一步跟踪发现、`snd_pcm_avail`函数未能获得足够大的`avail`值。 代码如下：

1949 static int wait_for_avail(struct snd_pcm_substream *substream,
1950                               snd_pcm_uframes_t *availp)
1951 {
......
1980         for (;;) {       
1981                 if (signal_pending(current)) {
1982                         err = -ERESTARTSYS;
1983                         break;
1984                 }        
1985                          
1986                 /*            
1987                 ┊* We need to check if space became available already
1988                 ┊* (and thus the wakeup happened already) first to close
1989                 ┊* the race of space already having become available.
1990                 ┊* This check must happen after been added to the waitqueue
1991                 ┊* and having current state be INTERRUPTIBLE.
1992                 ┊*/           
1993                 avail = snd_pcm_avail(substream);
1994                 if (avail >= runtime->twake)
1995                         break;
......
2023                 if (!tout) {  
2024                         pcm_dbg(substream->pcm,
2025                                 "%s timeout (DMA or IRQ trouble?)\n",
2026                                 is_playback ? "playback write" : "capture read");
2027                         err = -EIO;
2028                         break;
2029                 }
2030         }     
......
2036 }

午餐后继续。 谢谢你。

您好、Suren、

让我们继续。 从上面回答的代码中、我发现问题是`snd_pcm_avail`函数无法获得足够大的`avail`值。 如果我们继续检查`snd_pcm_avail`函数、我们可以看到`hw_ptr`未更新。 我`s了它的`s方法:在第 286 行的` nd_pcm_update_hw_ptr0` in `ound/core/pcm_lib.c`,`shw_ptr`通过 ubstream->ops->pointer (Substream) 更新。 后来,通过一系列的方法,我发现这个指针的值来自`snd_dmaengine_pcm_pointer`函数的计算。

此函数使用`dmake_tx_status``s一个状态、此状态存储两个值：μ` tate.remaining μ`s和 μ tate.in_flight_bytes`。

249 snd_pcm_uframes_t snd_dmaengine_pcm_pointer(struct snd_pcm_substream *substream)
250 {                               
251         struct dmaengine_pcm_runtime_data *prtd = substream_to_prtd(substream);
252         struct snd_pcm_runtime *runtime = substream->runtime;
253         struct dma_tx_state state;
254         enum dma_status status; 
255         unsigned int buf_size;  
256         unsigned int pos = 0;   
257                                 
258         status = dmaengine_tx_status(prtd->dma_chan, prtd->cookie, &state);
259         if (status == DMA_IN_PROGRESS || status == DMA_PAUSED) {
260                 buf_size = snd_pcm_lib_buffer_bytes(substream);
261                 if (state.residue > 0 && state.residue <= buf_size)
262                         pos = buf_size - state.residue;
263                                 
264                 runtime->delay = bytes_to_frames(runtime,
265                                                 ┊state.in_flight_bytes);                                                                                                                                                                           
266         }                       
267                                 
268         return bytes_to_frames(runtime, pos);
269 }                               
270 EXPORT_SYMBOL_GPL(snd_dmaengine_pcm_pointer);

由于我们使用 UDMA、因此很容易找到`dmaengine_TX_status`函数。

它位于`drivers/dma/ti/k3-UDMA.c`第 1581 行的`UDMA_TX_STATUS`函数中。 观察代码可以发现、​​从寄存器中读取`residue`和`in_flight_bytes`值并使用常量计算得出。

我的`的症状是` peer_bcnt `不断增加、而` bcnt 保持不变。 `` bcnt `计算残留值、而使用` peer_bcnt `计算延迟、即 Δ t IN_FLIGHT_Bytes`μ s。 我将在下面粘贴代码。

static enum dma_status udma_tx_status(struct dma_chan *chan,
                                ┊     dma_cookie_t cookie,
                                ┊     struct dma_tx_state *txstate)
{
...
                } else if (uc->desc->dir == DMA_DEV_TO_MEM) {
                        bcnt = udma_rchanrt_read(uc, UDMA_CHAN_RT_BCNT_REG);
                     
                        if (uc->config.ep_type != PSIL_EP_NATIVE) {
                                peer_bcnt = udma_rchanrt_read(uc,
                                                UDMA_CHAN_RT_PEER_BCNT_REG);
                     
                                if (peer_bcnt > bcnt)
                                        delay = peer_bcnt - bcnt;
                        }
                } else {
...
                if (bcnt && !(bcnt % uc->desc->residue))
                        residue = 0;
                else
                        residue -= bcnt % uc->desc->residue;
       
                if (!residue && (uc->config.dir == DMA_DEV_TO_MEM || !delay)) {
                        ret = DMA_COMPLETE;
                        delay = 0;
                }
       
                dma_set_residue(txstate, residue);
                dma_set_in_flight_bytes(txstate, delay);
...
}

的下一个答案  

`您`说、随着上述变化、延迟有所改善、但播放和录制用例都无法正常工作？

在新的 SDK 11 中,播放的声音作品非常好,但错误仍然存在于声音捕获中。

关于 SDK 11.2、我之前检查了 SDK 11.2 中的 UDMA 错误修复。 我发现、与我使用的 SDK 11 相比、只有一个与循环长数据包传输相关的额外错误修复提交。 我已经将此代码修补到当前 SDK 的 UDMA 驱动程序部分中、但问题仍然存在。

我检查了日志、Sound's PCM 使用短数据包进行循环传输、这意味着每个传输段小于 64KB。  因此、这两个提交似乎对该错误没有影响；我仍然需要删除 period_csf = CPPI5_TR_CSF_EOP 以消除延迟。

我应用的补丁：

5b37c96ee1c865edd28f69f3c7ac637a93a3b068

待处理：dmaengine：TI：k3-UDMA：修复具有静态配置的大型 BCDMA 传输

f35d6babd47c31439e64ab73b6ff9faeaf582553

待处理：dmaengine：TI：k3-UDMA：修复用于非循环传输的 UDMA_GET_TR_COUNTER

另外,因为我的英语不是很好,我正在使用谷歌翻译与你沟通. 所以,如果你发现任何我说的奇怪,请随时直接联系我,我们可以详细讨论.

此致、

Han

尊敬的 Han：

新年快乐！

请告诉我们一种在我这边重现问题的方法。 这将有助于我的开发团队循环分析问题。

感谢您的耐心。

此致

Suren  

您好、Suren、

新年快乐！

关于重现此问题、我只使用了 TI Linux SDK 11。 我的电路板在音频采集端只有一个 Si476x 编解码器。 我没有修改 Si476x 编解码器驱动程序、您可以在`sound/scodecs/si476x.c soc`中找到此文件。 但是、我修改了 Si476x 的 I2C 和 Media V4L 部分、但我认为它不会影响 DMA 端。 如果您需要我修改过的代码、我会将其发送给您。

我只探测了 Si476x 编解码器驱动程序、这个问题发生在我最后。我之前提到的情况是、`peer_bcnt`会持续增加、而` bcnt `会在 DMA 过程中保持不变。

我不确定我使用的编解码器是否导致了这种情况、但我实际上遇到了 SDK 10 中 ES8388 编解码器的类似、甚至更严重的现象。 此问题在播放和捕获期间发生、这是我之前提到的问题。 问题链接：

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1524372/am625-a-cyclic-mode-udma-issue-in-sdk-10-01-10-04

我不确定我的代码对 DMA 驱动程序的影响、因为它似乎不会影响 DMA。 但是、如果您需要代码、我可以随时提供。 另外、如果您需要确认​​DMA 驱动程序中某些属性的值、我可以提供日志测试、也可以修改用于测试的代码而不会有任何问题。

此致、

Han

您好、Suren、

我们的工作时间似乎没有太多重叠。 您能告诉我您的工作时间和时区吗？ 我目前在 UTC+8、我的工作时间为 UTC 凌晨 1：00 至上午 9：00。 如果时间不多,我可能会在下班后继续监测这个问题,因为它一直困扰着我很长时间。

此致

Han

尊敬的 Han：

我在美国德克萨斯州达拉斯工作。  

您的终端是否有 AM62 EVM 并在 EVM 上重现此问题？ 在我们的 EVM 上、我们有编解码器 TLV320AIC3106 连接到 SoC 上的 McASP1、编解码器是时钟启动器。  

仅运行  are纪录-dhw：0、0 -r 48000 -c 2 --period-size=64 -d 20 -f S16_LE | aplay -dhw：0、0  我是否能够在我们的 SDK 上重现问题？

此致、

Suren

您好、Suren、

抱歉、我们没有 AM62 EVM 和编解码器 TLV320AIC3106、所以我会在电路板上尝试您的命令。

好消息是现象发生了变化,我可以确认变化是由`--period-size=64`命令参数引起的,因为如果我不添加这个参数,现象和以前一样。

坏消息是,虽然`--period-size=64`参数似乎避免了录制的输入/输出错误,但 DMA 问题可能仍然存在,因为我使用了如下命令:  arecord -DHW：0、1 -r 48000 -c 2 -f S16_LE --period-size=64 -d 1 > test.wav

但是、此命令录制了完整的 32 秒、而录制的回放仅为正常的 1 秒。

 `：我尝试了`--period-size=n 、n = 1、2、4、8、 16、32、64。 在所有情况下、记录的时间几乎为 32 秒。

我们的电路板使用了两个 McASP、McASP1 和 mcasp2、测试后、我发现这两个的捕获部分都出现了此问题。

注意：使用两个 McASP、因为其中一个 McASP 用作对讲机的音频输入、因此连接到 McASP1 的对讲机编解码器没有输出。 另一个编解码器连接到 mcasp2、但只连接了扬声器、而不连接麦克风、尽管可以捕获空数据。

由于我没有 AM62 EVM 和 TLV320AIC3106 编解码器、因此我认为我们应该尝试从 DMA 方面解决问题。 是否有办法转储 DMA 控制器寄存器、然后将 DMA 寄存器值​​与您同步、以便检查是否存在问题？

而且,因为你在达拉斯,我们的工作时间似乎根本没有重叠,我很可能在你工作的时候睡觉。 遗憾的是、

此致

Han

尊敬的 Han：

对延迟深表歉意。

您能给我一种在我们的 EVM 上重现此问题的方法吗？ 您提到这发生在 11.2 SDK 上、我们已经使用您在上一次回复中提供的命令在 11.2 SDK 上成功录制了音频。

 如果您仍需要有关此主题的任何支持、请致电了解您的设置工作。 请告诉我。 我可以在本周晚些时候安排一个（达拉斯时间，最好是早上）

此致

Suren

您好、Suren、

很抱歉、我也忘了这个功能。 如果您有时间、我们可以安排会面吗？ 如果我们使用会议软件、我可以投影我的计算机屏幕并帮助翻译。 时间约为午夜、即达拉斯的早上。

您可以先打电话给我、然后讨论会议时间。

我的电话号码: 86（这是地区号码）184 4258 5931 .

如果您希望通过电子邮件与我联系、请将您的电子邮件发送至 hys@kaishang-tech.com。 这是我的工作电子邮件地址。

此致、

Han

嗨、Han

已向您发送电子邮件。 请检查并回复。

此致

Suren