On 17/10/2023 14:18, Krishna Kurapati wrote:
Currently on QC targets, the conndone/disconnect events in device mode are
generated by controller when software writes to QSCRATCH registers in qcom
glue layer rather than the vbus line being routed to dwc3 core IP for it
to recognize and generate these events.
We need to write '1' to UTMI_OTG_VBUS_VALID bit of QSCRATCH_HS_PHY_CTRL
register to generate a connection done event and "0" if we need to
generate a disconnect event during cable removal or mode switch. Exactly
what is done by "dwc3_qcom_vbus_override_enable" call in dwc3-qcom.
When the disconnect is not generated upon cable removal, the connected
flag of dwc3 is left marked as "true" and it blocks runtime suspend.
The goal of these vendor hooks is to let the mode change and cable removal
notifications from core reach the glue layers so that glue can take
necessary action.
Before flattening the device tree, glue driver is not sure when the core
probe was completed as core probe can be deferred. In this case, glue is
not sure when to register vendor hooks. So mandate enabling runtime only
for flattened device node platforms so that glue can know when to register
vendor hooks.
The following are the requirements aimed in this implementation:
1. When enum in device mode, Glue/core must stay active.
2. When cable is connected but UDC is not written yet, then glue/core
must be suspended.
3. Upon removing cable in device mode, the disconnect event must be
generated and unblock runtime suspend for dwc3 core.
Signed-off-by: Krishna Kurapati <quic_kriskura@xxxxxxxxxxx>
What happens to this code if you
static int count;
1. sleep in dwc3_probe for 10 milliseconds
2. return -EPROBE_DEFER
3. if count++ < 5 goto 1
i.e. if we simulate say waiting on a PHY driver to probe in dwc3_probe()
and what happens if we introduce a 100 millsecond sleep into
dwc3_qcom_probe() - and run a fake disconnect event from
dwc3_qcom_probe_core() directly ?
In other words if make it that dwc3_probe() completes and struct
dwc3_glue_ops->notify_cable_disconnect() fires prior to
dwc3_qcom_probe_core() completing ?
i.e. I don't immediately see how you've solved the probe() completion
race condition here.
---
bod
