主题中讨论的其他器件：TPS65217
工具/软件：Linux
大家好、
我们的产品使用带有"按需"调节器的 CPU 频率调节。 在大多数情况下、在更改 CPU 频率的同时流式传输音乐效果很好、但我们不时会遇到 HCI UART 链路问题。 在 CPU 频率发生变化后、主机似乎无法再与 BT 控制器通信。
可以通过 A2DP 播放音频并并行运行 cpu_scaling.sh 脚本(请参阅下面的链接)来重现此问题。 此脚本将 CPU 调节器设置为"userspace"并随机更改 CPU 频率、而不会产生任何额外的 CPU 负载。 将频率从 800MHz 切换到1GHz 也会触发该问题、这意味着它与 CPU 短缺无关、而与内核更改 CPU 频率时发生的冻结/锁定更相关。
HFILL：
禁用 BT 深度睡眠和 HCIL 后、当问题发生时、HCI 链路停止工作几百毫秒、但会在之后恢复。 我猜、对于 HFILL、BT 控制器将在主机更改其 CPU 频率时进入深度睡眠状态、因此主机缺少信息、无法再与 BT 控制器通信。 如果没有 HILL、数据包会延迟、从而导致中断、但通信仍然有效。
我无法使用电路板上的逻辑分析仪捕获 HCI 线路、这些线路位于无法访问的 PCB 层上。UART 回送：
我进行了一些低级测试、试图在没有 BT 控制 器的情况下更轻松地隔离和重现问题(请参阅下面的 serial_loopback.py)。 要运行测试、您必须连接 UART TX/RX、使用正确的串行端口运行"../serial_loopback.py /dev/ttyO1 "并并行运行 cpu_scaling.sh。
test01_delay 显示没有问题，即使在更改频率时也会尊重基本延迟(至少为 time.sleep())。
test11_serial_loopback 显示、有时更改 CPU 频率时、UART 环回需要~750ms 完成(正常情况下为~10ms)。 使用 CONFIG_PRETER_ANULOY=y 重新编译内核将正常回送时间减少到几 ms、但~750ms 回送的问题仍然存在。
您能不能帮助理解为什么会发生这种750ms 的延迟？ 您的电路板上是否有相同的行为？ CPU 时钟和 UART 模块之间是否存在链接？
环境：
感谢你的帮助。
-Julien
