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.

[参考译文] TPS6.5982万:AutomaticIDRequest (0x29位24)的行为

Guru**** 2483885 points


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

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/664115/tps65982-behavior-of-automaticidrequest-0x29-bit24

部件号:TPS6.5982万

大家好,

我的客户想知道 AutomaticIDRequest 位的行为方式,我需要向他们解释该功能。
请帮助我了解此位的行为。

从Host interface guide中的解释中,我了解了AutomaticIDRequest的行为,如下所示。

[我对AutomaticIDRequest 位行为的理解]
如果此位设置为“0”,则TPS6.5982万在作为DFP工作时从不会发出“发现标识”命令作为Initiator。
因此,EC需要在电缆插头DP alt流程中发出通过4cc命令发现身份

我还有4个问题。
1.我以上的理解是否正确?

2. AutomaticIDRequest和 AMIntrusiveMode之间有何区别?

3. 将AutomaticIDRequest设置为“0”时,TPS6.5982万如何处理以下命令?
-发现SVID
-发现模式
-进入模式
-退出模式
注意

4.当TPS6.5982万处于UFP且AutomaticIDRequest设置为“0”时,它是否会自动响应收到的所有VDM命令?

此致,

Takashi Onawa

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

    1.您的理解正确。

    2.启用AutomaticIDRequest后,PD控制器将在适当时自动发送Discover Identities (发现标识)消息。 启用AMIntrusiveMode后,PD不会通过CC线路自动发送任何“备用模式”通信,EC将通过4CC命令发送“备用模式”消息。 我不建议启用AMIntrusiveMode,因为它在进入备用模式时严重依赖于EC发送正确的消息。

    3.当AutomaticIDRequest设置为0时,TPS6.5982万不会自动发送Discover SVID或Discover Modes消息。 在主机告诉它发送“发现SVID”或“发现模式”消息之前,它不会尝试协商任何备用模式。 输入模式,退出模式和注意消息不受AutomaticIDRequest位的影响。

    4. TPS6.5982万仍将自动响应所有接收到的VDMS,并将AutomaticIDRequest设置为0。将AutomaticIDRequest设置为0时,它不会自动发送VDMS,但仍会响应接收到的VDMS。 仅当禁用AMIntrusiveMode时才会出现这种情况。

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

    谢谢,我几乎可以理解函数的行为方式。 让我在结束前提出一个问题。

    此功能的概念是什么?
    即,应在哪些类型的应用程序和情况下禁用AutomaticIDRequest?

    此致,
    Takashi Onawa
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好,Onawa-san,

    如果不想自动开始协商备用模式,可以禁用AutomaticIDRequest。 也许您只想在EC确定的特定条件下协商备用模式。 禁用AutomaticIDRequest将允许用户在开始协商备用模式时进行控制。 否则,TPS6.5982万将始终自动尝试协商备用模式。

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

    AutomaticIDRequest位是否仅影响Alt模式协商进程的命令?
    Discover Identity (发现标识)命令不仅用于Alt模式协商进程,还用于E-marker通信。

    如果客户希望在AutomaticIDRequest关闭的情况下进行E-marker IC通信,EC是否还必须通过4cc命令发送Discover Identity VDM进行电缆通信?
    如果是,应在何时发出命令?

    此致,
    Takashi Onawa
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好,Onawa-san,

    禁用AutomaticIDRequest不会影响到在连接后直接发生的与E标记的通信。 即使禁用了AutomaticIDRequest,PD控制器仍将与E标记进行通信。
    AutomaticIDRequest应仅与备用模式的"发现标识"命令相关。

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

    谢谢。 我明白了。

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

    您好,Eric,

    如何禁用自动IDRequest by FW设置?

    谢谢


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

    要禁用自动ID请求,只需取消选中屏幕截图中"自动ID请求"旁边的框。

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

    您好,Eric,

    非常感谢,我没有注意到这个方框。

    我们还面临另一个有关自动ID请求和MacBookPro兼容性的问题,请给我们一些建议。 谢谢。

    FW工具:TPS6598x应用定制工具版本3.10

    应用程序:Monitor

    问题: 启用“自动ID请求”时,发生了MacBookPro问题。

    1.打开显示器电源,关闭MacBookPro电源。

    2.通过USB-C电缆连接显示器和MacBookPro。

    3.开启MacBookPro。

    4. DisplayPort没问题。 但USB集线器无法正常工作。

    根本原因:当问题重复出现时,显示器的角色是DFP_U/UFP_D/Source。

    *显示器必须成为UFP_U才能使用USB集线器。

    PD协商的详细信息---(a)

    1.连接时,显示器为DFP_U/Source。

    2. PS_RDY之后,监视器发送DR_SWP。

    3. MacBookPro拒绝DR_SWP。

    4.监控发送发现标识。(启动备用模式)

    5.最后,MONITOR变为DFP_U/UFP_D/Source。

    *PA271Q应重新发送DR_SWP消息。

     

    在"自动ID请求"设置为禁用后

    PD协商的详细信息---(b)

    1.连接时,显示器为DFP_U/Source。

    2. PS_RDY之后,监视器发送DR_SWP。

    3. MacBookPro拒绝DR_SWP。

    4.大约400毫秒后,显示器重新发送DR_SWP和MacBookPro接受。

       此时,MONITOR变为UFP_U/Source。

    5. MacBookPro发送发现标识。(开始备用模式)

    6.最后,MONITOR变为UFP_U/UFP_D/SourceUSB集线器可以正常工作。

    如果应启用"自动ID请求"以通过合规性测试,是否有其他方式重新发送DR_SWP?

    非常感谢

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

    这是一条非常古老的线。 请打开新问题的新线程吗? 它可以更好地帮助我们更快地响应您的请求。

    谢谢!
    Eric