[参考译文] AM6422：CPSW ICSSG 复位引脚

我发现 udelay 函数不准确。 我在器件树中给出的参数是2us、但实际示波器测量结果是10ms、而且每次都不相等、是在 ms 级别。 是这样吗？

您好、Wanglili、

对这里的延迟答复深表歉意。 您是否仍需要帮助？

此致、

Nick

您好、

   目前仍然存在这个问题、可以实现硬复位、但低电平的时间与1us 的实际设置不一致。 您能解释一下为什么会这样吗？

您好、Wanglili、

RESET 引脚是否会始终最终更改值、但问题是延迟可能是几毫秒而不是几微秒？

或者、是否存在 RESET 引脚从不更改值的情况？

此致、

Nick

您好！

  复位时间与器件树的定义不匹配。 给定的值为1us、但实际上位于 ms 级别。

这是最小复位延迟、对吧？ 而不是最大值？

我需要查看代码、但如果复位信号由 Linux 软件触发(而不是由基于某种状态条件的硬件电路触发)、那么有时需要看到几毫秒后 Linux 调度程序才会运行实际发送复位信号的代码。

您使用的是 Linux 还是 RT Linux？

如果复位信号由软件触发、那么 RT Linux 应能够提供更确定的响应时间。 但您仍然无法让 Linux 在2微秒内做出响应。 这需要真正的 RTOS、就像在 R5F 上一样。

此致、

Nick

您好！

   感谢您的答复！ 我们使用的是 Linux、它目前符合我们的要求。 我正在考虑 Linux 在运行时出现延迟是否正常。 是这样吗？

您好、Wanglili、

嗯。 我不太清楚这个延迟值是否在 PHY 已注册并连接到 MII 总线的时间之外使用：

ti-processor-sdk-linux-am64xx-evm-10.01.10.04/board-support/ti-linux-kernel-6.6.58+git-ti/drivers/net$ grep -r 'reset-delay-us'
mdio/of_mdio.c: of_property_read_u32(np, "reset-delay-us", &mdio->reset_delay_us);

ti-processor-sdk-linux-am64xx-evm-10.01.10.04/board-support/ti-linux-kernel-6.6.58+git-ti/drivers/net$ grep -r 'reset_delay_us'
phy/mdio_bus.c:         fsleep(bus->reset_delay_us);
ethernet/intel/igc/igc_base.c:  phy->reset_delay_us     = 100;
ethernet/intel/igc/igc_phy.c:   udelay(phy->reset_delay_us);
ethernet/intel/igc/igc_hw.h:    u32 reset_delay_us; /* in usec */
ethernet/intel/igb/e1000_82575.c:       phy->reset_delay_us     = 100;
ethernet/intel/igb/e1000_phy.c: udelay(phy->reset_delay_us);
ethernet/intel/igb/e1000_hw.h:  u32 reset_delay_us; /* in usec */
ethernet/intel/e1000e/80003es2lan.c:    phy->reset_delay_us = 100;
ethernet/intel/e1000e/82571.c:  phy->reset_delay_us = 100;
ethernet/intel/e1000e/ich8lan.c:        phy->reset_delay_us = 100;
ethernet/intel/e1000e/ich8lan.c:        phy->reset_delay_us = 100;
ethernet/intel/e1000e/phy.c:    udelay(phy->reset_delay_us);
ethernet/intel/e1000e/hw.h:     u32 reset_delay_us;     /* in usec */
ethernet/oki-semi/pch_gbe/pch_gbe.h: * @reset_delay_us: HW reset delay time[us]
ethernet/oki-semi/pch_gbe/pch_gbe.h:    u32 reset_delay_us;
ethernet/oki-semi/pch_gbe/pch_gbe_main.c:       hw->phy.reset_delay_us = PCH_GBE_PHY_RESET_DELAY_US;
mdio/of_mdio.c: mdio->reset_delay_us = DEFAULT_GPIO_RESET_DELAY;
mdio/of_mdio.c: of_property_read_u32(np, "reset-delay-us", &mdio->reset_delay_us);

$ vi phy/mdio_bus.c
/**
 * __mdiobus_register - bring up all the PHYs on a given bus and attach them to bus
 * @bus: target mii_bus
 * @owner: module containing bus accessor functions
 *
 * Description: Called by a bus driver to bring up all the PHYs
 *   on a given bus, and attach them to the bus. Drivers should use
 *   mdiobus_register() rather than __mdiobus_register() unless they
 *   need to pass a specific owner module. MDIO devices which are not
 *   PHYs will not be brought up by this function. They are expected
 *   to be explicitly listed in DT and instantiated by of_mdiobus_register().
 *
 * Returns 0 on success or < 0 on error.
 */
int __mdiobus_register(struct mii_bus *bus, struct module *owner)
{
...
        /* assert bus level PHY GPIO reset */
        gpiod = devm_gpiod_get_optional(&bus->dev, "reset", GPIOD_OUT_HIGH);
        if (IS_ERR(gpiod)) {
...
        } else  if (gpiod) {
                bus->reset_gpiod = gpiod;
                fsleep(bus->reset_delay_us);
                gpiod_set_value_cansleep(gpiod, 0);
                if (bus->reset_post_delay_us > 0)
                        fsleep(bus->reset_post_delay_us);
        }

请注意、当该函数调用 fsleep 时、它会使处理器执行另一个任务。 因此、代码肯定不会在2usec 内运行、但在2usec 过后、如果另一个任务仍在使用处理器、该任务将在 Linux 调度程序允许 MDIO 函数再次运行之前完成其时间片。

Linux 偶尔出现毫秒延迟绝对是正常现象。 您将从 google 搜索中得到更好的解释、但常规的 Linux 调度程序基本上是经过优化的、以便以最佳性能运行最多数量的代码。  这意味着、整个系统应该能相当有效地运行、但也意味着不能保证特定代码段能在特定的时间内运行。

对于具有实时需求的系统(其中"实时"意味着某个任务必须在特定的时间内完成)、我们通常建议使用 RT Linux (比常规 Linux 更实时)或真正的实时操作系统(RTOS)。 RT Linux 允许特定代码几乎在所需的时间范围内一直运行、但由于某些代码段具有更高的优先级、因此总体系统性能可能会稍慢一些。

此致、

Nick

您好、

  我理解这个过程,非常感谢!