Baolin Wang <baolin.w...@linaro.org> writes:
>>>> I'm thinking this is a bug in configfs interface of Gadget API, not
>>>> dwc3. The only reason for this to happen would be if we get to
>>>> ->udc_stop() with endpoints still enabled.
>>>> Can you check if that's the case? i.e. can you check if any endpoints
>>>> are still enabled when we get here?
>>> No, it is not any endpoints are still enabled. Like I said in commit
>>> message, we will start end transfer command when disable the endpoint,
>>> if the end transfer command complete event comes after we have freed
>>> the gadget irq, it will trigger the interrupt line all the time to
>>> crash the system.
>> I see what the problem is. Databook tells us we *must* set CMDIOC when
>> issuing EndTransfer command and we should always wait for Command
>> Complete IRQ. However, we took a shortcut and just delayed for 100us
>> after issuing End Transfer.
> Yes, but 100us delay is not enough in some scenarios, like changing
> function with configfs frequently, we will met problems.

heh, 100us *is* enough. However we still get an IRQ because we requested
for it. If you want to fix this, then you need to find a way to get rid
of that 100us udelay() and add a proper wait_for_completion() to delay
execution until command complete IRQ fires up.


Attachment: signature.asc
Description: PGP signature

Reply via email to