Re: [PATCH] usb: dwc3: Clear DWC3_EVENT_PENDING when count is 0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 2/3/2023 4:06 AM, Thinh Nguyen wrote:
On Thu, Feb 02, 2023, Linyu Yuan wrote:
On 2/2/2023 2:57 AM, Thinh Nguyen wrote:
On Tue, Jan 31, 2023, Linyu Yuan wrote:
hi Thinh,


regarding your suggestion, assume it is not PCIe type,  still have one
question,


-       if (evt->flags & DWC3_EVENT_PENDING)
+       if (evt->flags & DWC3_EVENT_PENDING) {
+               if (!evt->count) {
+                       u32 reg = dwc3_readl(dwc->regs, DWC3_GEVNTSIZ(0));
+
+                       if (!(reg & DWC3_GEVNTSIZ_INTMASK))
+                               evt->flags &= ~DWC3_EVENT_PENDING;

do we need to return IRQ_WAKE_THREAD  ?
No, if evt->count is 0, but GEVNTCOUNT is > 0, the controller will
generate interrupt. The evt->count will be updated and the events will
be handled on the next interrupt.

when will next interrupt happen ?
Immediately after. You can test this by just return IRQ_HANDLED and not
clear the GEVNTCOUNT to see its behavior.


if it immediately, it will be good.


정재훈  could you update a new patch which Thinh suggest.

maybe we didn't find the root cause of irq strom, but the change have no side effect.



as when enter here, i guess GEVENTCOUNT is already > 0, but we didn't read
it.
GEVNTCOUNT is always updating as new events are generated. We only clear
however many events we process, but that doesn't stop it from
incrementing.


just consider if there is a case that next GEVNETCOUNT increase which happen long time later,

maybe think too much.



BR,
Thinh


+               }
                  return IRQ_HANDLED;

as here return IRQ HANDLED, how can we make sure a new IRQ will be handled
after previous IRQ thread clean PENDING flag ?
If evt->count > 0, that means the bottom half is still running. So,
leave it be. If evt->count == 0, then the cached events are processed,
we're safe to clear the PENDING flag. New interrupt will be generated if
GEVNTCOUNT is > 0.

+       }


also for non-PCIe controller, consider IRQ mask register working correctly,

consider a case IRQ happen before IRQ thread exit,  here just return
IRQ_HANDLED.

once IRQ thread exit, it will clean PENDING flag, so next IRQ event will run
normally.

if 정재훈 saw PENDING flag is not cleared, does it mean IRQ thread have no
chance to exit ?
The PENDING flag should be cleared eventually when the bottom half
completes. I don't expect the interrupt storm to block the IRQ thread
forever, but I can't guarantee the device behavor. 정재훈 can confirm.
This change should resolve the interrupt storm.

BR,
Thinh



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux