Messages in this thread | | | Date | Wed, 13 Jul 2022 17:33:43 -0700 | Subject | Re: [PATCH 4/5] usb: dwc3: Allow end transfer commands to be sent during soft disconnect | From | Wesley Cheng <> |
| |
Hi Thinh,
On 7/13/2022 5:19 PM, Thinh Nguyen wrote: > On 7/13/2022, Wesley Cheng wrote: >> Hi Thinh, >> >> On 7/12/2022 6:42 PM, Thinh Nguyen wrote: >>> On 7/12/2022, Wesley Cheng wrote: >>>> Hi Thinh, >>>> >>>> On 7/8/2022 6:58 PM, Thinh Nguyen wrote: >>>>> On 7/8/2022, Wesley Cheng wrote: >>>>>> If soft disconnect is in progress, allow the endxfer command to be >>>>>> sent, >>>>>> without this, there is an issue where the stop active transfer call >>>>>> (during pullup disable) wouldn't actually issue the endxfer command, >>>>>> while clearing the DEP flag. >>>>>> >>>>>> In addition, if the DWC3_EP_DELAY_STOP flag was set before soft >>>>>> disconnect >>>>>> started (i.e. from the dequeue path), ensure that when the EP0 >>>>>> transaction >>>>>> completes during soft disconnect, to issue the endxfer with the force >>>>>> parameter set, as it does not expect a command complete event. >>>>>> >>>>>> Signed-off-by: Wesley Cheng <quic_wcheng@quicinc.com> >>>>>> --- >>>>>> drivers/usb/dwc3/ep0.c | 3 +-- >>>>>> drivers/usb/dwc3/gadget.c | 5 ++++- >>>>>> 2 files changed, 5 insertions(+), 3 deletions(-) >>>>>> >>>>>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c >>>>>> index 506ef717fdc0..5851b0e9db0a 100644 >>>>>> --- a/drivers/usb/dwc3/ep0.c >>>>>> +++ b/drivers/usb/dwc3/ep0.c >>>>>> @@ -290,8 +290,7 @@ void dwc3_ep0_out_start(struct dwc3 *dwc) >>>>>> if (!(dwc3_ep->flags & DWC3_EP_DELAY_STOP)) >>>>>> continue; >>>>>> - dwc3_ep->flags &= ~DWC3_EP_DELAY_STOP; >>>>>> - dwc3_stop_active_transfer(dwc3_ep, true, true); >>>>>> + dwc3_stop_active_transfer(dwc3_ep, true, dwc->connected); >>>>>> } >>>>>> } >>>>>> diff --git a/drivers/usb/dwc3/gadget.c >>>>>> b/drivers/usb/dwc3/gadget.c >>>>>> index bd40608b19df..fba2797ad9ae 100644 >>>>>> --- a/drivers/usb/dwc3/gadget.c >>>>>> +++ b/drivers/usb/dwc3/gadget.c >>>>>> @@ -3696,8 +3696,10 @@ void dwc3_stop_active_transfer(struct dwc3_ep >>>>>> *dep, bool force, >>>>>> if (dep->number <= 1 && dwc->ep0state != EP0_DATA_PHASE) >>>>>> return; >>>>>> + if (interrupt && (dep->flags & DWC3_EP_DELAY_STOP)) >>>>>> + return; >>>>>> + >>>>>> if (!(dep->flags & DWC3_EP_TRANSFER_STARTED) || >>>>>> - (dep->flags & DWC3_EP_DELAY_STOP) || >>>>>> (dep->flags & DWC3_EP_END_TRANSFER_PENDING)) >>>>>> return; >>>>>> @@ -3744,6 +3746,7 @@ void dwc3_stop_active_transfer(struct >>>>>> dwc3_ep *dep, bool force, >>>>>> __dwc3_stop_active_transfer(dep, force, interrupt); >>>>>> spin_lock(&dwc->lock); >>>>>> + dep->flags &= ~DWC3_EP_DELAY_STOP; >>>>> >>>>> Can we clear this flag in __dwc3_stop_active_transfer(). It should >>>>> apply >>>>> if End Transfer command was sent. >>>> >>>> I wanted to make sure that we weren't modifying the DEP flags outside >>>> of a spin lock. Patch#3 modifies it where we unlock before calling >>>> __dwc3_stop_active_transfer(), so we can allow the dwc3 threaded IRQ >>>> handle events while the cmd status polling happens. >>>> >>>> Maybe we can unlock/lock the dwc3->lock inside >>>> __dwc3_stop_active_transfer() and that way we can ensure DEP flags are >>>> modified properly? >>> >>> I didn't realize that you unlock/lock when calling >>> __dwc3_stop_active_transfer(). We'd need to be careful if we want to >>> unlock/lock it, and avoid it all together if possible. It can be easily >>> overlooked just like dwc3_gadget_giveback(). >>> >>> What issue did you see without doing this? >> >> I saw endxfer timeout issues if I didn't do it. If we keep the lock >> held, then the DWC3 event processing would be blocked across the >> entire time we are waiting for the command act to clear. With >> unlocking before polling, then at least we're still able to handle the >> EP0 events that are pending. >> >> It was definitely one of the harder scenarios to reproduce. The main >> patch series which resolved a lot of the issues early on was patch#1. >> After adding that the other issues are seen maybe after a day or so of >> testing. >> > > I see. The soft-disconnect still go through right? > Can you try this and see if this works for you? > > diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c > index 13e4f1a03417..4f67a484c490 100644 > --- a/drivers/usb/dwc3/gadget.c > +++ b/drivers/usb/dwc3/gadget.c > @@ -451,7 +451,9 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, > unsigned int cmd, > > dwc3_writel(dep->regs, DWC3_DEPCMD, cmd); > > - if (!(cmd & DWC3_DEPCMD_CMDACT)) { > + if (!(cmd & DWC3_DEPCMD_CMDACT) || > + (DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_ENDTRANSFER && > + !(cmd & DWC3_DEPCMD_CMDIOC))) { > ret = 0; > goto skip_status; > } > > > We can set it and forget it when we're about to de-initialize the > controller. Just like what we've already done by not waiting for the End > Transfer endpoint command completion interrupt. >
I can see this working for the soft disconnect case, but we'll need to address it differently for the EP dequeue scenario where IOC/interrupt is required to clean up the TRBs. This is one of the reasons why I went with the spinlock approach, since it would apply to both situations.
Thanks Wesley Cheng
| |