[参考译文] Linux/AM3357：Linux 内核4.1-中断中的 MMC 驱动程序

您好 Shankar、

[引用 USER="Shankar SM"]我们使用的是基于 Beagle Bone 的定制板，它运行 Linux 4.1.18

您是否使用 AM335x TI PSDK 2.00.02.11？

[引用 USER="Shankar SM"]我们有一个连接到 MMC0端口的 Wifi 芯片。

WL12xx？ Wl18xx？

[引用 USER="Shankar SM]我们最初使用的是内核3.12，我们正在尝试迁移到4.1.18。 其中一个主要原因是、在内核3.12中、MMC 驱动程序没有中断支持、而只是轮询、这导致我们在 Wi-Fi 上获得的吞吐量非常低

我看到那里有 DMA 支持。 你试过吗？

processors.wiki.ti.com/.../SD_Driver's_Guide

以下 wiki 页面对内核4.1.18附带的 PSDK 2.0.02.11有效：

processors.wiki.ti.com/index.php/Linux_Core_MMC/SD_User's_Guide

此致、
帕维尔

您好、Pavel、

感谢您的回答。 我的答案如下。

[引用用户="Pavel Bodev"]

Shankar SM

我们使用的是运行 Linux 4.1.18的基于 Beagle Bone 的定制板

您是否使用 AM335x TI PSDK 2.00.02.11？

[/报价]

我们通过 Timesys 使用2.00.02 TI SDK。 我不确定最新版本。 但我认为 MMC 驱动程序没有发生任何变化。 在内核4.4中、这些更改看起来也是一样的。

[引用用户="Pavel Bodev"]

我们有一个连接到 MMC0端口的 Wifi 芯片。

WL12xx？ Wl18xx？

[/报价]

Marvell 88w8801 WiFi 芯片

[引用用户="Pavel Bodev"]

Shankar SM

我们最初使用的是内核3.12、我们正在尝试迁移到4.1.18。 其中一个主要原因是、在内核3.12中、MMC 驱动程序没有中断支持、而只是轮询、导致我们在 Wi-Fi 上获得的吞吐量非常低

我看到那里有 DMA 支持。 你试过吗？

[/报价]

我还没有尝试过 DMA 支持。 我将给它一个机会。 但是、我想了解什么是错误的。 如果 DMA 是引脚配置等一些基本问题或其他问题、我不想在同一个位置结束 DMA。

我相信、了解驱动程序中的中断标志(如 IRQF_TRIGGER_LOW 等)集将会在其上投射一些光。 请您向我指出完成此操作的驱动程序代码吗？
以上一点的一些背景是我了解到在 omap_hsmmc_probe ()中有如下代码。 第4个参数为0、对应于 IRQF_TRIGGER_NONE。 是这样吗？ 如果这是真的、我不理解代码中的哪个位置会更改为 IRQF_TRIGGER_LOW 等

RET = devm_request_IRQ (&pdev->dev、host->IRQ、omap_hsmmc_IRQ、0、
MMC_hostname (MMC)、host)； 

[引用 user="Shankar SM"]我们已将 MMC 设置为在中断模式下运行，并且设备树中的配置与 ti-omap-hsmmc.txt[/quot]中的内核文档中的配置相同/非常相似

我建议也尝试配置 am33xx.dtsi 文件

linux-kernel/arch/arm/boot/dts/am33xx.dtsi

mmc1：MMC@48060000｛
         兼容="ti、omAP4-hsmmc"；
         ti、hwmds ="mmc1"；
         TI、双电压；
         TI,需要特殊重置;
         TI、需要特殊处理；
         DMA =<&EDMA_Xbar 24 0
            EDMA_Xbar 25 0 0>；
         dma-names ="TX"、"Rx"；
         中断=<64>；
         interrupt-parent =<&INTc>；
         REG =<0x48060000 0x1000>；
         STATUS ="禁用"；
      }；

[引用 USER="Shankar SM"]       中断扩展=<&INTC 64 &GPIO2 28 0>；

您确切在哪个 AM335x 引脚上接收中断请求？ 它是某些 MMC 引脚还是 GPIO2_28引脚？

Pavel、

感谢您的回答。

我发现 IRQF_TRIGGER_LOW 可能可以通过下面的器件树给出、但这并没有解决我所面临的问题。
中断扩展=<&INTC 64 &GPIO2 28 IRQ_TYPE_LEVEL_LOW>；

起初我以为问题是在挂起模式下、会引发 GPIO 配置不正确的问题、但看起来不正确。 我看到线路上有一个 Cirq 中断事件不会变为低电平。
根据我的理解、如果在启用中断后 MMC_cmd 线路变为低电平、则会生成 Cirq 中断。 我使用逻辑分析仪检查了波形、似乎命令行未被拉低。 不确定中断是如何触发的。

[引用 USER="Pavel Botev"]我是说 SD_STAT (OMAP-HSMMC_STAT)寄存器中的任何位自动设置为1？[/QUERES]

否、寄存器值如下所示、供参考。
OMAP-hsmmc_enable_SDIO_IRQ ()内部
STAT=00
ISE=0x100
IE=0x100
CON=0x10E00

在 OMAP-hsmmc_IRQ 内的中断处理程序中
STAT=0x100
ISE=0x100
IE=0x100
CON=0x10E00

Shankar、

您能否检查内核4.1.8中的轮询模式是否正常工作？

为了启用中断模式、第一步应该是在 MMC/SD 模块中接收有效的中断、该中断应该记录在 STAT 寄存器中。 在那里获得有效中断后、该中断将进入 Cortex-A8中断控制器。

在这两种情况下(轮询和中断)、应设置 STAT 寄存器。 请参阅 AM335x TRM 第18.2.4节"中断请求"

此致、
帕维尔

Pavel、

[报价 USER="Pavel Bodev"]您能否检查内核4.1.8中的轮询模式是否正常工作？[/quot]

我已验证它在轮询模式下工作、没有任何问题。

轮询模式的器件树配置如下所示。

mmc1｛(&M)
兼容="ti、am33xx-hsmmc"；
VMMC-SUPPLY =<&vmmcsd_fixed>；
总线宽度=<4>；
pinctrl-names ="default"；
pinctrl-0 =<&mmc1_PINS_DEFAULT>；
状态="确定"；
｝； 

我会再浏览一下18.2.4部分、看看我是否遗漏了任何东西。

谢谢
Shankar

[报价 USER="Shankar SM]我已经验证了它在轮询模式下的工作情况，没有任何问题。 [/报价]

应将 SD_STAT 寄存器用于轮询和中断模式。 在轮询模式和中断模式下、您能否共享 SD_STAT 寄存器中的值？

您能否解释一下您希望在 SD_STAT 中记录哪种类型的中断？ 是 Cirq、BWR、TC/CC 还是 else？

我还看到您提到了 GPIO2_28引脚。 您的设置中如何涉及此引脚？

此致、
帕维尔

您好、Pavel、

让我来告诉你整个故事。

我们使用 AM335x 定制板、Marvell 88W8801芯片连接到 mmc0引脚。 MMC0配置为在4位模式下运行。

轮询模式：
当我们如上述帖子中所述配置器件树时、轮询模式已启用、Wi-Fi 工作正常。 但是、吞吐量非常低(~1-4 Mbps)。 因此、我们开始考虑中断模式以获得更大的吞吐量。

中断模式：
如果使用上述 POST 中提到的器件树配置的中断模式、则似乎无法正常工作。 Marvell 驱动程序不断发送 CMD53。 在 Marvell 驱动程序上进行进一步调试后、我们看到只有在 SDIO 中断发生时才会发送特定的 CMD53。

我们通过 Marvell 检查了他们的驱动程序是否可以使用4.1.18内核，他们似乎声称他们在其他硬件上测试过这种情况，他们没有任何问题。
Marvell 摘录如下

我在运行内核4.1的系统上启用了完全调试、以突出显示固件下载的步骤
和 FW 就绪(请参阅随附的日志)、驱动程序使用轮询进行 FW 下载、并在 FW 处于活动状态时中断。

1.检测 SDIO 卡
2.禁用 SDIO 主机中断
3.启动 SDIO 探头
4.开始固件下载
5.每隔1毫秒轮询一次卡状态
6.固件已下载，~ 300毫秒
7.启用主机中断
8.固件处于活动状态，下载后为~ 200毫秒

当我尝试调试以查看中断模式和轮询的不同之处时、似乎只有在为 DAT1线路启用 GPIO 配置时才启用中断模式(这是为了避免在挂起模式下处于无限等待状态)。 我看到、当这个被启用时、中断被启用后、立即有一个恒定的 IRQ。 正如我在上述帖子中所提到的、stat 和其他寄存器(如 CON、ISE 等)似乎很好。

在中断模式下、有一个 dmesg 错误日志、表示发送 CMD53时失败、错误代码为-84、地址为0x10000040。 这在每次 CMD52 ARG 0x0a00之后立即发生、这恰好是一个 I/O 中止命令。 CMD52和 CMD53无限重复。 我已附加了相同的 dmesg 日志。

[引用 user="Pavel]我还看到您提到了 GPIO2_28引脚。 您的设置中如何涉及此引脚？[/QUERT]

对于 GPIO_28引脚、是 MMC 的多路复用 DAT1线路。 在挂起模式下、该线路将被拉低以唤醒 AM335x。 这与 Linux/Documentation/devicetree/bindings/sMMC/ti-omap-hsmmc.txt 下的器件树配置相同

谢谢
Shankar

e2e.ti.com/.../5811.dmesgLogs_5F00_with_5F00_extra_5F00_logging.txt

[引用 USER="Shankar SM]轮询模式：
当我们如上述帖子中所述配置器件树时、轮询模式已启用、Wi-Fi 工作正常。 但是、吞吐量非常低(~1-4 Mbps)。 因此、我们开始考虑中断模式以获得更高的吞吐量。[/quot]

借助 TI SDK7 (Linux 3.12)、我们可以获得更高的吞吐量(ARM 以1000MHz 的频率运行)：

我认为这些数字(在 ext2读取中为17.19Mbps)是在 EDMA 模式下实现的。

PSDK 2.00.02 (Linux 4.1.18)中的 MMC/SD 驱动程序性能稍好一些(例如、在 ext2读取中为21.21Mbps)：

我将检查其他要点、并在我对这些要点有任何了解时返回给您。

此致、
帕维尔

[报价用户="Shankar SM]我们使用的是 AM335x 定制板、Marvell 88W8801芯片连接到 mmc0引脚。 MMC0配置为在4位模式下运行。[/QUERT]

[引用 USER="Shankar SM]中断模式：
如果使用上述 POST 中提到的器件树配置的中断模式、则似乎无法正常工作。 Marvell 驱动程序不断发送 CMD53。 在 Marvell 驱动程序上进行进一步调试后、我们看到只有在 SDIO 中断发生时才会发送特定的 CMD53。[/QUERP]

让我确认我们迄今所拥有的东西。 您在 SDIO 4位模式下使用 MMC0控制器、并且您通过 mmc0_DAT1引脚(多路复用模式 GPIO2_28)接收中断、并且该中断已成功记录在 SD_STAT[8] Cirq 位中。 在轮询模式下、您将通过软件检查此[8] Cirq 位、因此您的性能较慢。 您需要启用中断模式、从而在[8] Cirq 位置位时、向 Cortex-A8 MPU 生成 MMCSD0INT (SIINTERRUPTN)(#63)信号、从而调用中断处理程序例程。 您能否确认我的理解是否正确？

问题是、您有许多意外的 Cirq 事件？

必须通过将 SD_IE[8] Cirq_enable 设置为0来清除控制器中断、然后主机驱动程序必须使用卡(清除卡中断状态)启动中断服务以删除卡中断源。 否则、一旦 SD_IE[8] Cirq_enable 设置为1、控制器中断就会重新置位。


此外、我们还提供了一些有关 OMAP35x Cirq 的信息、这些信息也可能在此处适用：

Marvell 8686需要 SDIO 时钟处于活动状态( 由 OMAP3530 SDIO 控制器驱动)  为了使 WLAN 能够在4位模式下生成中断、而 OMAP3530 旨在实现最佳低功耗、因此在总线未激活时(即在等待 SDIO 中断时)关闭 SDIO 时钟。  因此 ，在使用 Marvell 8686时，我们不能支持带有 IRQ 的4位模式。  使用 Marvell 8686时、SDIO 中断在1位模式下工作良好、因为 Marvell 端不需要激活时钟。

另请参阅以下 e2e 线程：

此致、
帕维尔

您好、Pavel、
   很抱歉、我在第二个选项卡上遗漏了您的回复、并假设您仍在查看。

[引用 user="Pavel]让我确认我们目前拥有的产品。 您在 SDIO 4位模式下使用 MMC0控制器、并且您通过 mmc0_DAT1引脚(多路复用模式 GPIO2_28)接收中断、并且该中断已成功记录在 SD_STAT[8] Cirq 位中。 在轮询模式下、您将通过软件检查此[8] Cirq 位、因此您的性能较慢。 您需要启用中断模式、从而在[8] Cirq 位置位时、向 Cortex-A8 MPU 生成 MMCSD0INT (SIINTERRUPTN)(#63)信号、从而调用中断处理程序例程。 您能否确认我的理解是否正确？[/引述]

一个小的变化是、在轮询模式下、不使用 Cirq 线路。 MMC 驱动程序在 SDIO_IRQ_THread 中休眠10ms (请参阅文件"drivers/MMC/core/SDIO_IRQ.c"中的以下代码)、在该超时后、它会查询芯片以查看是否有新数据。 因此、这10ms 的睡眠是导致吞吐量缓慢的原因。 减少此超时将增加吞吐量。 理解的其他部分是正确的。

静态 int SDIO_IRQ_thread (void *主机)
｛
struct mmc_host * host =_host；
struct sched_param param =｛.sched_priority = 1｝；
无符号长周期、IDLE_PERIOD；
内转台；

SCHED_setscheduler (current、SCHED_FIFO、param)；

/*
*我们希望 SDIO 卡即使在非 SDIO 上也能正常工作
*感知主机。 非 SDIO 主机不能做的一件事是
*挂起 SDIO 卡中断的异步通知
*因此我们在这种情况下轮询它们。
*
idle_period = mss_TO_jiffies (10)；

...} 

[引用 user="Pavel"]问题是您有许多意外的循环事件？
是的、这是以下第2点中提到的其中一个

---

   我们对此有一些更新。 TI FAE (Khayami、Mohsen)本周来到我们的办公室和
   我们一起调试了几天、取得了一些进展。 我们稍后会继续调查、目前的详细情况如下。

   我们目前似乎看到了2个问题

1. 
   
   1. 我们最初以为 Wifi 芯片无法正常工作的问题主要是由于 Cirq 中断。
   2. 但是、当我们使用 Lauterbach 调试器(Mohsen 随他带来)进行调试并查看寄存器时、我们发现 Dat1线路的引脚多路复用器没有从 GPIO (空闲模式)更改为 MMC 线路(正常模式) 也就是说、寄存器0x44E108F8是对应于 GPIO 的0x3F、而不是对应于 MMC 的0x30。
   3. 当我们将寄存器更改为0x30时、使用 Lauterbach 调试器、当它卡住时、它立即开始工作。
   4. 我们发现引脚多路复用发生在 OMAP-hsmmc_runtime_suspend ()和 OMAP-hsmmc_runtime_resume ()函数中的 OMAP MMC 驱动程序代码中。
   5. 在再运行几次 printk 之后，我们发现每次运行漫威驱动程序调用 request_firmware()时，都会出现问题。
   6. 此外、我们还看到在内核日志中、在调用 request_firmware 之前、omap_hsmmc_runtime_suspend 被调用了几个微秒、但我们看不到 omap_hsmmc_runtime_resume 调用。
   7. 我们在内核3.12上尝试了相同的 Marvell 软件、并使用了一个补丁来支持中断、它似乎可以正常工作。 在 request_firmware 调用之前、我们确实看到了一个 OMAP-hsmmc_runtime_resume。
   8. 目前、当调用 request_firmware 内核 API 时、问题似乎总是出现。 然而，我们不能确定谁是罪犯。 这意味着我们不知道 是否有任何其他内核线程或 Marvell 线程应该执行它不应该执行的操作。
2. 即使线路在空闲期间不会变为低电平、Cirq 中断也会持续触发、我们之前在上述帖子中已经讨论过这一点。 这样、WiFi 就可以工作、但是中断会导致驱动程序查询芯片的数据、即使芯片没有要发送的数据。

      我们目前正努力集中讨论问题1。 有几个关于这一点的问题
      1.从我从数据表中读出的内容来看、如果有任何 MMC 事务、PM 模块将使 MMC 模块从空闲模式转换为正常模式、这是正确的吗？
      2.如果第1点为 true，发送诸如 cmd52或 cmd53等 MMC 消息是否被视为事务？
      3.在 Marvell 驱动程序调用 request_firmware 内核 API 之前，它是否必须执行任何操作才能使 MMC 恢复正常模式，或者 request_firmware 是否处理它？
      4.您是否知道我们应该使用的 PM 模块是否有任何修补程序？
      

如果您有任何调试建议、或者您需要更多详细信息、请告诉我。
下面是包含一些额外 printk msg 的 dmesg 日志附件。

e2e.ti.com/.../6505.Wifi_5F00_Issue_5F00_4.1.18.txt

谢谢
Shankar

Shankar、

您是否仅在从活动/正常模式切换到低功耗模式以及恢复活动/正常模式时才观察到该问题？ 我的意思是、您是否仅在切换到低功耗模式时才观察到该问题？ 您如何切换到低功耗(空闲)模式、是否手动输入命令(回声测量、回声待机)？

IO 焊盘(引脚)具有"睡眠"状态和"运行时"状态、请参阅以下 wiki 页面以了解更多信息：

processors.wiki.ti.com/.../Linux_Core_Power_Management_User's_Guide_(v4.1)

另请参阅以下 wiki 页面是否将处于"帮助"中：

processors.wiki.ti.com/.../SD_User's_Guide
processors.wiki.ti.com/.../Debugging_AM335x_Suspend-Resume_Issues

此致、
帕维尔

Pavel、

是的、问题好像是在空闲模式和正常模式之间切换。 我们不会手动发送任何命令来在模式之间切换。 根据我的理解、这是由 PM 模块完成的(请参阅 MMCHS 引脚列表(18.2.3)下的 AM335x TRM)、有一个 MMC 电源管理部分介绍了从正常模式到智能空闲模式的转换)。 看起来、如果 MMC 模块上没有事务、则 PM 模块会在下一个时钟周期通知 MMC 模块进入空闲模式。 当有一个新命令要被发送时、MMC 模块被唤醒。 这是我的理解。

不太确定如何调试它。

谢谢、
Shankar