[参考译文] AM62A7：SPI 可以在循环模式下使用 BCDMA 吗？

您好、Victor、

我正在查看您的查询,你可能会期待在一两天内回复.

此致、

Anil.

你好、Victor、

如果我们使用 MCSPI + BCDMA 通道、BCDMA 通道可以处理无限 TR 支持、并且 PKTDMA 中不支持无限 TR 加载、则实现循环模式。

但是、根据 SOC 的不同、任一用户都可以使用 PKTDMA 或 BCDMA、因此没有问题。

 上述要求是  您使用哪个内核 A53或 DM R5F 或 MCU R5F 内核以及使用哪个操作系统？

在 MCU+SDK 和 Linux 中、所有外设都可以使用 PKTDMA 通道在外  设和存储器之间传输数据、或者将存储器传输到外设。

Linux SDK 和 MCU SDK 都不支持具有 BCDMA 通道的 SPI。

此致、

Anil.

您好、Victor、

在下面链接的 e2e 帖子中、您提到了在 AM437x SPI 接口上使用了循环模式、您能否提供一些有关此用例的详细信息？ 哪个内核版本使用哪个内核驱动程序？ 对使用 DMA 循环模式进行了哪些修改？ 据我所知、内核 SPI 框架不适合 DMA 循环模式。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1476789/sk-am62-dma-has-corrupt-data-reading-using-ospi-controller/5671628#5671628

我们基于 AM437x 的系统 不使用 Linux。  我自己编写了 EDMA 驱动程序来执行循环模式。

好的、这是合理的。

在 Linux 中、由于 SPI 框架中的设计、它无法在 AM62Ax McSPI 接口上使用 DMA 循环模式。 在循环模式下、RX 缓冲区是固定的、并且在通道初始化期间已编程到 DMA 控制器中。 但是、内核 SPI 内核驱动程序在每个 SPI RX 请求中将不同的 RX 缓冲区传递给 SPI 控制器驱动程序。

这对于当前实现是正确的、因为内核只能对 SPI 使用 PKTDMA。  但 SPI 是否可以使用 BCDMA、因为 BCDMA 似乎支持循环模式？

如果 SPI 内核仍为每个 RX 请求提供不同的 RX 缓冲区、BCDMA 如何解决问题？

您好、Victor、

您能给我发送完整的驱动程序代码吗？ 我首先想了解它如何适应内核 SPI 框架、以及什么是 dst 缓冲区(s_priv->dma_phys_data)。

什么事件会触发每次循环传输？ DMA 完成回调有什么作用？

我会私下向您发送驱动程序代码。

iMX6中的 DMA 将在环形缓冲器中的每个缓冲区完成后发送中断。  与 AM4376和 AM62A7中的 SPI 没有不同。

DMA 完成回调会唤醒线程以处理最近填充的缓冲区。  现在、AM62A7中的驱动器做了相同的事情、并且还会开始下一次 DMA 传输、因为没有循环模式。

您好、Victor、

我不知道您是如何在 AM62Ax McSPI 上尝试循环模式的、但我想这里。

AM62Ax 上的 McSPI 和 McASP 具有类似的 DMA 架构。 请参阅 k3-am62a-main.dtsi 中 McASP0器件树节点内的 BCDMA 通道配置：

mcasp0: audio-controller@2b00000 {
    ...
    dmas = <&main_bcdma 0 0xc500 0>, <&main_bcdma 0 0x4500 0>;
    dma-names = "tx", "rx";
    ...
};

McSPI 需要类似的配置。 McSPI BCDMA 通道 ID 在下面链接的 TISCI 文档中提供。

https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62ax/psil_cfg.html

在这种情况下、不需要边带 GPIO 触发器。 McSPI 有一个内部事件、每当 RXFIFO 达到其配置的水线时、触发 DMA 开始传输。

请告诉我这样的信息是否足以让您在 McSPI 用例中启用循环模式。

您好：

我执行了您建议的操作、并在器件树中更改了以下内容：

-               DMA =<&main_pktdma 0x4304 0>；
+               DMA =<&main_bcdma 1 0x4304 0>；
 

我将驱动程序更改为调用 dmaengine_prep_dma_cycloy()、而不是 dmaengine_prep_slave_sg()。   我已将 k3-UDMA.c 更改为您在 GPMC 上 DMA 的另一个帖子中建议的更改、因为我正在使用 DMA 传输数据时使用 GPMC 、我将私下向您发送我的 k3-UDMA.c 副本

这些更改导致控制台上出现此错误。

[  10.118599] ti-UDMA 485c01.dma-控制器：UDMA_PREP_DMA_CYCLYCLE：通道0用于 MEM_TO_MEM、不支持 DEV_TO_MEM

我相信您在 GPMC 上为 DMA 开发代码时也看到了此错误。  您能告诉我如何修改我的 k3-uDMa.c 版本以获得通过此错误吗？

谢谢、

Victor

您好、Victor、

在详细介绍之前、该主题的标题是关于 SPI (McSPI)、但是

jian Xu10 说：

我已将 k3-UDMA.c 更改为您在 GPMC 上 DMA 的另一帖子中建议的更改、因为我使用 DMA 来使用 GPMC

您现在是否要转向 GPMC？

几周前、我收到了4个关于 DMA 支持的离线请求列表、明天我们将讨论这些请求、但 GPMC 不在列表中。

即使您确实有使用 GPMC 的工程并需要 DMA 支持、您是否可以为其创建单独的 e2e 主题？ 我想保留该主题仅用于 SPI DMA 讨论。

您好：

否、对 k3-UDMA.c 所做的更改是为了支持从 GPMC 进行 DMA 传输、该 GPMC 在我们的系统中运行良好。  我之所以提到它、是因为我使用的是修改版本的 k3-UDMA.c、是因为我进行了更改以支持 GPMC 上的 DMA。

基本上、我不知道 GPMC 上针对 DMA 所做的更改是否可能导致 SPI 尝试使用 BCDMA 时出现此 MEM_TO_MEM 问题。

谢谢、

Victor

jian Xu10 说：

不是、对 k3-UDMA.c 所做的更改是为了支持从 GPMC 进行的 DMA 传输、该传输在我们的系统中运行良好。  我之所以提到它、是因为我使用的是修改版本的 k3-UDMA.c、是因为我进行了更改以支持 GPMC 上的 DMA。

我懂了。 感谢您的澄清。

jian Xu10 说：

+               DMA =<&MAIN_bcdma 1 0x4304 0>；

对于 McSPI、第二个参数"1"应为"0"、因为 McSPI 模块具有 PDMA、它不对 DMA 使用全局触发。

请告诉我、此更改是否仍出现"chan0 is for MEM_TO_MEM"错误。

Victor

jian Xu10 说：

[10.118599]  ti-UDMA 485c0100.dma 控制器：uDMA_PREP_DMA_Cyclic：通道0用于 MEM_TO_MEM、不支持 DEV_TO_MEM

在您的驱动程序 spot_spi_imx6.c init_sdma ()中、请同时添加

DMA_CAP_SET (DMA_CYCLIC、MASK)；

之后

DMA_CAP_SET (DMA_SLAVE、MASK)；

以查看这是否修复了 DMA 通道类型错误。 我看到 dmaengine_dmaengine_pcm_request_channel ()中也设置了 dma_cyclic 标志,内核声音框架 pcm_damengine.c 中也设置了 dmaengine_cyclic 标志

您好：  

我做了上述两处更改：.dts 文件中的"DMA =<&main_bcdma 0 0x4304 0>；"以及对 DMA_CAP_SET (dma_cyclic、maks)的调用；

我现在得到了另一个错误。  总共有48个。

 [ 4.881017] ti-UDMA 485c0100.dma-controller：仅支持 TR 模式(psi-l 线程0x4304)
[   4.889479] ti-UDMA 485c0100.dma-controller：仅支持 TR 模式(psi-l 线程0x4304)
[   4.897940] ti-UDMA 485c0100.dma-controller：仅支持 TR 模式(psi-l 线程0x4304)

然后是这个。

[   5.285961] ti-UDMA 485c0100.dma-controller：获取 UDMA_of_xlate 中的通道故障。

对如何解决此问题有任何建议？

谢谢、

Victor

Victor

jian Xu10 说：

 [ 4.881017] ti-UDMA 485c0100.dma-controller：仅支持 TR 模式(psi-l 线程0x4304)

请应用以下内核补丁、看看它是否修复了此错误。

diff --git a/drivers/dma/ti/k3-psil-am62a.c b/drivers/dma/ti/k3-psil-am62a.c
index 4cf9123b0e93..c5777caebb8d 100644
--- a/drivers/dma/ti/k3-psil-am62a.c
+++ b/drivers/dma/ti/k3-psil-am62a.c
@@ -89,7 +89,7 @@ static struct psil_ep am62a_src_ep_map[] = {
        PSIL_PDMA_XY_PKT(0x4301),
        PSIL_PDMA_XY_PKT(0x4302),
        PSIL_PDMA_XY_PKT(0x4303),
-       PSIL_PDMA_XY_PKT(0x4304),
+       PSIL_PDMA_MCASP(0x4304),
        PSIL_PDMA_XY_PKT(0x4305),

您好：

最新更改修复了之前的错误、现在我收到了此错误。

[   4.939558] ti-UDMA 485c0000.dma-controller:描述符池分配失败
[   4.946994] ti-UDMA 485c0000.dma-controller：获取 UDMA_of_xlate 中的通道失败。

谢谢、

Victor

Victor

感谢所有测试。 似乎需要更改更多代码。 我来在电路板上测试一下、看看还有什么缺失。

Victor

我最终恢复了 DMA 调试设置、可以检查内核执行情况。

jian Xu10 说：

[4.939558]   ti-UDMA 485c0000.dma-controller：描述符池分配失败

我得到了一个不同的错误,但比执行这一点更进一步。 检查 k3-uDMa.c 函数 bcdma_alloc_chan_resources()时、打印的行显示此错误消息已打包

if (uC->config.dir == DMA_MEM_to_MEM &&!uC->config.tr_trigger_type){

在我们的 McSPI BCDMA 案例中、uC->config.dir 应为"2"(dma_dev_to_MEM)、因此不应执行此消息。 您能否检查您的代码执行情况以了解它如何运行到此"if"区段？

  2502         if (uc->config.dir == DMA_MEM_TO_MEM  && !uc->config.tr_trigger_type) { 
     1                 uc->config.hdesc_size = cppi5_trdesc_calc_size(                 
     2                                         sizeof(struct cppi5_tr_type15_t), 2);   
     3                                                                                 
     4                 uc->hdesc_pool = dma_pool_create(uc->name, ud->ddev.dev,        
     5                                                  uc->config.hdesc_size,                                                                                                                                                                                                                                                                                                                                                            
     6                                                  ud->desc_align,                                                                                                                                                                                                                                                                                                                                                                   
     7                                                  0);                                                                                                                                                                                                                                                                                                                                                                               
     8                 if (!uc->hdesc_pool) {                                                                                                                                                                                                                                                                                                                                                                                             
     9                         dev_err(ud->ddev.dev,                                                                                                                                                                                                                                                                                                                                                                                      
    10                                 "Descriptor pool allocation failed\n");

您好：

我必须重新构建内核,现在我能够使用 dmaengine_prep_dma_cyclic ()成功启动 dma。  但是、我没有收到 RX 完成回调。  有什么想法吗？

明天我将尝试转储 Rx 缓冲区、查看是否正在从 McSPI 读取数据。  希望这将告诉我们 DMA 传输的中断位置。

谢谢、

Victor

Victor

嗯,你得到比我做得更远。 在我的设置中、DMA 通道请求仍然失败、并出错：

[  26.042450] ti-UDMA 485c0100.dma-controller：获取环回 IRQ 失败(索引：12294)
[  26.050221] ti-UDMA 485c0100.dma-controller：获取 UDMA_of_xlate 中的通道故障。

jian Xu10 说：

但是、我没有收到 RX 完成回调。  有什么想法？

开发人员告诉我

+      PSIL_PDMA_MCASP (0x4304)、

可能不正确。 请尝试使用

+      PSIL_PDMA_XY_TR (0x4304)、

以查看它是否与 DMA 完成问题有关。

您好：

恢复到 PSIL_PDMA_XY_TR (0x4304)将导致"仅支持 TR 模式"错误。

我至少会尝试查看 DMA 是否正在从 SPI 控制器读取数据。

谢谢、

Victor

jian Xu10 说：

恢复到 PSIL_PDMA_XY_TR (0x4304)

正在恢复？ 原始模式为 PSIL_PDMA_XY_ pkt 。

哇、真是个好消息！

您好：

我遇到了一个小问题,我试图弄清楚,但我不知道 k3-UDMA.c 足以找出问题.

在执行引导序列时、循环模式效果很好。  问题是当我要在我的设备上运行 GDB 时。  所以,我的系统调用 dmaengine_terminate_async()来停止 DMA 传输。  这似乎是有效的。   因此、当 GDB 启动系统时、所有内容似乎都正常工作、没有错误消息。  但是、我没有得到 Rx 完成回调函数、这可能意味着 DMA 引擎没有启动。  我也尝试使用 dmaengine_terminate_sync()但同样的问题。

我知道这两个函数都调用 UDMA_RESET_CHAN (),并将硬输入参数设置为 FALSE。

有什么想法如何解决这个问题?

谢谢、

Victor

您好、Victor、

我不知道使用或不使用 GDB 时 dmaengine 流是否不同？

如果不使用 GDB、但通过调用 dmaengine_terminate_async()来停止应用程序以清理 DMA、然后再次启动应用程序、DMA 是否仍然有效？

BIN、

除非我们执行引导循环或 GDB、否则我们不会停止应用程序。  对于 GDB、我们不会经历引导周期。  我们只是终止应用程序,它涉及调用 dmaengine_terminate_async()。  函数似乎调用 UDMA_Terminal_all()。  在 GDB 中、我们随后重新启动应用、但启动 DMA 的代码似乎没有返回任何错误、但 DMA 没有启动。  因此,它看起来像 UDMA_terminal_all()没有清理循环的 bcdma。  我正在尝试将 dma_prep_dma_cyclic ()中执行的代码与正常工作启动和 GDB 不工作启动进行比较。

您好、Victor、

我想知道您是否需要以下内核补丁。 如果您可以手动将其应用到内核以及它是否解决了问题、请告诉我。

https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/?h=ti-linux-6.6.y-cicd&id=e0a0ce8c2684c13fab0e65be767d036dfa592ee1

Bing、

我手动应用了补丁程序、它确实修复了 GDB 问题。  在停止应用程序并在 GDB 中再次启动应用程序时、我的设备不会再冻结。  因此、该补丁确实解决了拆卸问题。

现在的问题是、处于 RX 模式的循环 DMA 传输不再读取正确的数据。  我认为 DMA 仅写入环形缓冲区的第一个缓冲区。

我编辑 UDMA_PREP_DMA_CYCLEAR_tr ()中的更改,将 CPPI5_TR_CSF_EOP 只设置为最后一个周期。  这解决了问题、因此当我启动设备时、它可以像以前一样正常工作。  然后,我通过启动 GDB 来终止应用程序,然后在 GDB 中重新启动应用程序。 它继续运行而不会锁定。  现在的问题是我的更改不能像从引导运行之前那样100%正常工作。 我的循环 DMA 传输似乎总是经常收到错误数据。

我可以非常确定这种更改在 TX 模式下不起作用、但不需要 TX 模式。

下面是我的更改。   您是否可以或让执行原始补丁的人员查看此情况？

谢谢、

Victor

@@-3495、6 +3508、7 @@ UDMA_PREP_DMA_CYCLIC_tr (结构 UDMA_CHAN *uC、DMA_addr_t buf_addr、
       U16 tr0_cnt0、tr0_cnt1、tr1_cnt0；
       unsigned int i；
       INT num_tr；
+      int tr_idx =-1；

       num_tr = UDMA_get_tr_counters (period_len、__FFS (buf_addr)、&tr0_cnt0、
                                     &tr0_cnt1、&tr1_cnt0)；
@@-3517、8 +3531、17 @@ UDMA_PREP_DMA_CYCLIC_tr (结构 UDMA_CHAN *uC、DMA_addr_t buf_addr、
               period_addr = buf_addr |
                       ((u64) uC->config.asel << k3_ADDRESS_ASEL_SHIFT)；

+/*       
+       *对于 BCDMA <->PDMA 传输、需要在上设置 EOP 标志
+       *描述符的最后一个 TR、将数据包标记为完成。
+       *这是获得拆卸完成消息的必要条件,以防万一
       TX 的+*、并避免在 RX 情况下出现短数据包错误。
+*        
+       *由于我们处于循环模式、我们 知道哪个周期可能是
+       *最后一个,所以设置每个周期的标志。
+       */
       对于(i = 0；i < periods；i++)｛
-              int tr_idx = i * num_tr；
+              tr_idx = i * num_tr；

               cppi5_tr_init (&tr_req[tr_idx].flags、CPPI5_TR_Type1、false、
                             FALSE、CPPI5_TR_EVENT_SIZE_FINITY、0)；
@@-3549、6 +3572、14 @@ UDMA_PREP_DMA_CYCLIC_tr (结构 UDMA_CHAN *uC、DMA_addr_t buf_addr、

               period_addr += period_len；
       }
+      if (uC->CONFIG.EP_TYPE == PSIL_EP_PDMA_XY &&
+              uC->ud->match_data->type == dma_type_bcdma &&
+              tr_idx >= 0)｛
+              IF (！(flags 和 DMA_PREP_INTERRUPT))
+                      cppi5_tr_csf_set (&tr_req[tr_idx].flags、CPPI5_TR_CSF_EOP|CPPI5_TR_CSF_supr_EVT)；
+              其他
+                      cppi5_tr_csf_set (&tr_req[tr_idx].flags、CPPI5_TR_CSF_EOP)；
+      }

       返回 d；
 }

Victor

jian Xu10 说：

现在的问题是、我的循环 DMA 传输处于 RX 模式、不再读取正确的数据。  [/报价]

DMA 是否在首次引导后正确读取数据、但在 GDB 停止应用程序并重新启动应用程序后发生数据损坏？ 因此、这意味着 DMA 在拆开再启动后无法正常工作？

jian Xu10 说：

您可以或让原始修补程序的执行人员查看此内容吗？

Jai 不再在 TI 工作、但我将查看您的更改以了解我是否能识别任何信息。

[/quote]

Bing、

是的、正确。  仅在拆开并重新启动后、DMA 才不能正常工作。

谢谢、

Victor

BIN、

我刚刚更新了我的内核、GDB 问题消失了。  现在一切都正常。  很抱歉错误的报警。

考虑到我对补丁的更改、我认为该补丁只允许循环模式仅与 TX 和 RX 振铃缓冲器中的第一个缓冲器一起工作。  遗憾的是、我无法测试 TX 模式。

谢谢、

Victor

您好、Victor、

jian Xu10 说：

I just updated my kernel and the GDB problem 消失了.  现在一切都正常。  抱歉误报。

很高兴听到它在工作。 但是、您是否仍需要应用所做的仅将 CPPI5_TR_CSF_EOP 设置为最后一个周期的更改？

jian Xu10 说：

现在考虑我对补丁的更改、

听起来您仍然需要进行此更改。

jian Xu10 说：

我认为该补丁只允许循环模式仅与环形缓冲区中的第一个缓冲区一起工作

我不确定振铃缓冲器的具体含义。 应用程序的配置

    desc_rx =
        dmaengine_prep_dma_cyclic(s_priv->dma_chan_rx,
        (dma_addr_t)s_priv->dma_phys_data,
        SPOT_BUF_LEN,
        SPOT_NOTIFY_LEN,
        DMA_DEV_TO_MEM,
        DMA_PREP_INTERRUPT);

它应该只有一个缓冲区"s_priv->dma_phy_data"、其大小为 spot_BUF_LEN、DMA 在每次 DMA 完成中断后填充整个缓冲区、不是吗？

jian Xu10 说：

不幸的是、我无法测试 TX 模式。

我提到的这个补丁仅适用于 dma_dev_to_MEM 模式、因此应该仅适用于 RX。 为什么您认为它也会影响 TX？

在这种情况下、参数 SPOT_BUF_LEN 的大小为 SPOT_NOTIFE_LEN 的32倍。 因此、您将有一个由32个缓冲区组成的环缓冲区、每个缓冲区为 SPOT_NOTIFIT_LEN 字节。  因此、原始补丁可能仅写入第一个缓冲区、因为为该缓冲区设置了 CPPI5_TR_CSF_EOP 位。

原始补丁中有注释、指出这适用于 TX 和 RX。  由于原始补丁不适用于 RX、我必须假设它也不适用于 TX。

使用原始补丁、在 DMA 完成回调中、您是否检查了第二个环形缓冲区是否具有有效数据？ 这将判断原始补丁是否只传输一个缓冲区。

我没有费心进行检查、因为我的上层软件显示正在读取的数据已损坏。  由于我对原始补丁的更改只是为了仅为最后一个缓冲区设置该位、因此您必须假设 DMA 只会写入第一个缓冲区。

原始补丁是为了修复 McASP 的 DMA 拆卸问题、有趣的是音频应用程序没有任何补丁问题。 我将与我们的开发团队谈论这一点。

不管怎样、只要更改(只将 EOP 标志设置为最后一个 TR)、McSPI 应用程序现在就可以正常运行、对吧？