• 状态
  • 已锁定 已锁定
  • 回复 7 回复
  • 订户 0 订户
  • 视图 12 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM62L：AM62L I2C OMAP：同一总线上两个支持目标的控制器在其中一个启动时超时

admin
Guru**** 2925100 points

Other Parts Discussed in Thread: AM62L

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1644932/am62l-am62l-i2c-omap-two-target-capable-controllers-on-same-bus-time-out-when-either-initiates

器件型号： AM62L

我正在开发基于 TI AM62L、使用 K3 供应商内核的 BeagleBadge 6.12.57-vendor-edge-k3。 我正在进行扩展 drivers/i2c/busses/i2c-omap.c 、因此 AM62L I2C 适配器可以注册 Linux I2C 从器件后端、并且仍然会暂时充当 I2C 主器件/启动器。

即时测试设置在同一电路板上使用两个 AM62L OMAP I2C 实例：

  • J6 是 /dev/i2c-1、控制器实例 20010000.i2c
  • J7 是 /dev/i2c-3、控制器实例 20020000.i2c
  • J6 和 J7 物理短接在一起
  • Linux i2c-slave-testunit 用作目标/从器件后端
  • 未连接用于该测试的外部 I2C 器件

经验证的工作案例：

  • J6 目标位于 0x30、J7 启动器：真 SMBus block-proc-call 工作正常
  • J7 target at 0x30、J6 initiator：true SMBus block-proc-call 工作正常
  • 重复启动版本读取在单目标反向拓扑情况下有效

剩余的故障情况是两个适配器同时支持目标：

  • J6 目标在处 0x30
  • J7 目标在处 0x31

在两个目标都注册并绑定后、任一启动方向都会超时：

i2ctransfer -f -y 3 W1@0x30 0x00
i2ctransfer -f -y 3 R1@0x30
i2ctransfer
-f -y 1 W1@0x31 0x00 i2ctransfer -f -y 1 R1@0x31
 

所有四个命令都超时、即使每个单目标拓扑都工作正常。

已测试的驱动程序更改：

  • 添加了 OMAP/ reg_slave unreg_slave 管道
  • 在返回到从器件监听模式之前清除过时的主器件状态
  • 当带有已注册从属后端的适配器启动主传输时、从从属 IRQ 掩码切换到正常主 IRQ 掩码
  • 在 AM62L/IP-v2 上、 I2C_IRQENABLE_CLR 由于 I2C_IRQENABLE_SET 仅设置位、因此在写入下一个角色所需的中断屏蔽之前清除

上次更改确实消除了以前的过时 IRQ 掩码问题：

  • 之前：失败的双侦听器日志显示已累积 ie=0x661f
  • 现在：日志显示已清除的掩码、如 ie=0x61f 和 ie=0x601f
  • Transmit underflow 不再观测到器件

但双重侦听器的情况仍然在两个方向上都超时。

相关的当前内核状态为：

  • components/ti-linux-kernel： eb09330dc065 Clear OMAP IRQ enables before role mask writes
  • components/armbian-build： b17e72e32 Add OMAP IRQENABLE clear patch
  • 已测试伪迹： 6.12.57-S22fb-D0000-Pb163-C2876Hb496-HK01ba-Vc222-Be8e3-R448a
  • 已引导的内核： Linux beaglebadge 6.12.57-vendor-edge-k3 #27 SMP PREEMPT Tue May 5 16:45:44 UTC 2026 aarch64 GNU/Linux

问题：

对于 AM62L OMAP I2C IP-v2、当同一物理 I2C 总线上的两个控制器都处于目标/从监听模式、但其中一个控制器可能暂时成为主器件时、是否还需要额外的序列？

具体来说：

  1. 当将支持目标的适配器从从从监听模式切换到主模式时、除了 I2C_IRQENABLE_CLR清除、清除状态、设置 MST和随后恢复从监听模式之外、是否还有另一个必须重置的寄存器或 FIFO 状态？
  2. 是否预计具有自身地址启用的 OMAP I2C 控制器会干扰另一个控制器对同一总线上不同目标地址的事务？
  3. OA 当适配器启动主传输时、应该禁用/目标寻址、然后再恢复？
  4. 将两个 OMAP I2C 实例用作同一物理总线上的多控制器参与者时、是否存在 AM62L 特定的限制？

附加/粘贴的复制日志包括：

  • 确切的命令
  • uname -a
  • 目标后端状态
  • 每个的退出状态 i2ctransfer
  • dmesg 包含 omap_i2c、、 Transmit underflow Arbitration lost、超时、、 slave irq isr-master、和 master-enter

目标不是调试 Linux 从设备测试单元后端本身。 单目标情况证明了目标模式和真 SMBus 块 proc-call 在两个方向上都有效。 只有当两个 OMAP 适配器同时在短接的 J6/J7 总线上注册为支持目标的侦听器时、才会出现此问题。

run.log 

dmesg.log 

内核补丁位于 https://github.com/just-kitting/ti-linux-kernel/tree/badge-snake

  • 0
    TI__Guru**** 2925100 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    尊敬的 Jason：

    我会将您的问题重定向至 I2C 硬件专家。

    尊敬的 Stan：  

    [报价 userid=“459402“ url=“~/support/processors-group/processors/f/processors-forum/1644932/am62l-am62l-i2c-omap-two-target-capable-controllers-on-same-bus-time-out-when-either-initiates

    对于 AM62L OMAP I2C IP-v2、当同一物理 I2C 总线上的两个控制器都处于目标/从监听模式、但其中一个控制器可能暂时成为主器件时、是否还需要额外的序列？

    [/报价]

    您可以查看该查询吗？

    此致、
    Vinu

  • 0
    TI__Guru**** 2925100 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Jason、

    如果两个或更多控制器发送器几乎同时在同一总线上开始传输、则调用仲裁程序。 仲裁程序使用由竞争发送器在串行总线上呈现的数据。 当发送器检测到其出现在总线上的高电平信号已被低电平信号覆盖时、它会切换到目标接收器模式、设置仲裁丢失 (I2C_IRQSTATUS_RAW[0] AL) 标志、并生成仲裁丢失中断。

    上图显示了控制器发送器之间的 I2C 仲裁。 它显示了两个器件之间的仲裁过程。 仲裁程序优先于以最低二进制值发送串行数据流的器件。 如果两个或更多器件发送相同的第一个字节、则仲裁将在后续字节上继续进行。

    请 参阅 AM62L TRM 文档中的 I2C 可编程多目标通道特性部分。  

    请查看 AM62L TRM 文档中 的第 12.2.3.4.1.1.3 点 编程流程图。

    此致、

    Borislav Lazarkov

  • 0
    TI__Guru**** 2925100 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    我还没有进展到测试仲裁。 我仍在测试阶段、可以从一个 I2C 发送到同一器件上的另一个 I2C、然后启动相反方向的传输。 这是完全同步的、因为在第一个传输完全完成之前、备用启动器中的传输不会开始。

    该查询涉及 TRM 似乎未涵盖的一种情况、即两个 AM62L I2C 同时设置为目标、但一次只要求一个作为控制器进行传输。 在这种情况下,仲裁损失是意外的,或者也许我误解了对它的预期反应。 控制器/发起方不应退避、因为此时只有 1 个控制器/发起方。

    也许有一个更好的方法可以问这个问题：“我是否需要做些什么才能退出目标模式才能进入控制器/发起者模式？“ “在这种情况下需要做什么？“。

  • 0
    TI__Guru**** 2925100 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Jason、

    请留出一些时间联系 I2C 专家。

    感谢您的耐心！

    此致、

    Borislav Lazarkov

  • 0
    TI__Guru**** 2925100 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    是否有任何更新？ 是否有任何保守的建议？

  • 0
    TI__Guru**** 2925100 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    它已经 2 周了。 您是否仍然有机会了解模式之间的转换？

  • 0
    TI__Guru**** 2925100 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Jason、

    对此处延迟的回复、赶不上您的 e2e 主题深表歉意。

    我们在 Linux 驱动程序中不支持在主模式和从模式之间转换 — I2C 驱动程序仅为主模式。

    带 Claude 的双重检查：

      The i2c-omap driver (drivers/i2c/busses/i2c-omap.c) supports master mode only.

  Evidence from the driver:

  1. i2c_algorithm struct (line 1203): registers only .master_xfer and .master_xfer_atomic — there is no .reg_slave or .unreg_slave
  callback, which are required for slave mode support in the Linux I2C framework.
  2. functionality return value (line 851): returns I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_PROTOCOL_MANGLING — notably absent is
   I2C_FUNC_SLAVE.
  3. Slave-related register bits exist (OMAP_I2C_STAT_AAS, OMAP_I2C_CON_MST, etc.) confirming the hardware IP has slave capability, but
   the driver does not implement it. There is one reference to a slave in a comment (line 593) describing bus contention detection, not
   slave operation.

    您可以理解以下主题中不支持 Linux I2C 从设备的“原因“：
    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1024619/am6412-i2c-multi-master-mode/3793533#3793533

    https://e2e.ti.com/support/processors/f/791/t/887456

    此致、

    Nick