otg模式,是不是默认初始化为gadget device模式

仅从你贴的 dwc2_driver_probe() 来看:

不能简单地说 OTG 模式默认初始化为 Gadget(Device) 模式。

需要看 dr_mode 和 OTG 检测结果。


先看这段代码

retval = dwc2_get_dr_mode(hsotg);

这里会读取设备树:

dr_mode = "host";
dr_mode = "peripheral";
dr_mode = "otg";

然后设置:

hsotg->dr_mode

如果 dr_mode=peripheral

会执行:

dwc2_gadget_init(hsotg);

不会执行:

dwc2_hcd_init(hsotg);

因为:

if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL)
        dwc2_hcd_init(hsotg);

条件不成立。

最终就是:

纯Device模式

如果 dr_mode=host

会执行:

dwc2_hcd_init(hsotg);

不会执行:

dwc2_gadget_init(hsotg);

因为:

if (hsotg->dr_mode != USB_DR_MODE_HOST)
        dwc2_gadget_init(hsotg);

条件不成立。

最终:

纯Host模式

如果 dr_mode=otg

你的情况应该是这个。

此时:

if (hsotg->dr_mode != USB_DR_MODE_HOST)
        dwc2_gadget_init(hsotg);

if (hsotg->dr_mode != USB_DR_MODE_PERIPHERAL)
        dwc2_hcd_init(hsotg);

两个条件都成立。

因此:

probe阶段:
    Gadget初始化
    HCD初始化

都会执行。


为什么两个都初始化?

因为 OTG 需要支持动态切换:

Host <----> Device

Linux 必须提前准备:

Gadget Framework
Host Controller Driver
OTG状态机

所以:

probe
 ├─ dwc2_gadget_init()
 ├─ dwc2_hcd_init()
 └─ dwc2_drd_init()

都会执行。


那最终是 Host 还是 Device?

这取决于 OTG 检测。

例如 Micro-USB OTG:

ID脚

ID = 0
    Host

ID = 1
    Device

或者 Type-C:

CC逻辑
    ↓
Role Switch

从代码看

最关键的是:

retval = dwc2_drd_init(hsotg);

DRD = Dual Role Device。

这里会建立:

OTG FSM
Role Switch
Extcon
USB Role Switch

等机制。

后面根据:

ID
VBUS
Type-C事件

决定当前角色。


再看你之前贴的代码

if (dwc2_is_device_mode(hsotg)) {
        spin_unlock_irqrestore(&hsotg->lock, flags);
        return 0;
}

这是 _dwc2_hcd_start()

说明:

虽然HCD已经初始化了
但当前角色是Device

于是:

不启动Host
不打开VBUS
直接返回

因此 OTG 模式下实际流程通常是

probe
 ├─ dwc2_gadget_init()
 ├─ dwc2_hcd_init()
 └─ dwc2_drd_init()

当前无连接
      ↓
默认Device状态(很多平台如此)

插入OTG Host线(ID=0)
      ↓
切换Host
      ↓
_dwc2_hcd_start()
      ↓
dwc2_vbus_supply_init()
      ↓
regulator_enable()

拔线
      ↓
切回Device
      ↓
dwc2_hcd_stop()
      ↓
regulator_disable()

所以针对你的代码:

OTG 模式下并不是“只初始化 Gadget”。

而是:

  • dwc2_gadget_init() 会执行;

  • dwc2_hcd_init() 也会执行;

  • 真正运行成 Host 还是 Device,要等 dwc2_drd_init() 建立的 OTG/Role-Switch 机制根据 ID、VBUS 或 Type-C 事件来决定。

不过在很多 SoC(包括不少 STM32、Rockchip、TI 平台)的 OTG 场景下,上电后的初始角色往往是 Device(B-device),所以你会看到 _dwc2_hcd_start() 里经常首先判断:

dwc2_is_device_mode(hsotg)

成立后直接返回。这样 Host 部分虽然初始化过,但并未真正启动,也不会打开 VBUS。

内容概要:本研究聚焦于“绿电直连型电氢氨园区”的优化运行,提出一种直接利用绿色电力驱动制氢与合成氨的综合能源系统架构。通过构建包含风/光发电、电解水制氢、氢气储存、合成氨反应及电能直供等关键环节的系统模型,研究旨在实现能源的高效转化与梯级利用,降低对外部电网依赖,提升园区能源自洽率与经济性。研究综合运用Matlab与Python工具进行建模与仿真,结合实际气象与负荷数据,对系统在不同工况下的运行策略、能量流动、设备容量配置及经济技术指标进行深入分析与优化,并形成完整的Word论文文档,为新型零碳产业园区的规划与建设提供了理论依据和技术支撑。; 适合人群:具备新能源、电力系统、化工或综合能源系统背景的科研人员,以及从事园区规划、能源管理、低碳技术开发的工程技术人员。; 使用场景及目标:①研究绿电如何高效耦合至化工生产流程,实现“电-氢-氨”多能互补;②掌握综合能源系统(IES)的建模、仿真与优化方法,特别是多时间尺度下的运行调度策略;③为撰写高水平学术论文或完成相关课题研究积累数据、代码与写作模板。; 阅读建议:此资源包含代码、数据和完整论文,建议使用者先通读Word论文以理解整体框架与理论基础,再结合Matlab/Python代码进行复现与调试,最后可基于提供的数据和模型进行二次开发,以深化对绿电综合利用技术的理解。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值