Hi, John Youn <John.Youn@xxxxxxxxxxxx> writes: >>>>>> + dwc3_writel(dwc->regs, DWC3_GEVNTCOUNT(0), count); >>>>>> + >>>> After that evt->buf[lpos, lpos + count] seems goes back to HW, so >>>> thread should not rely on this? >>>> >>>> Or I miss something? >>> >>> Hi, >>> >>> Yes, you're right. That's a possibility and to be safe we can cache >>> those. >>> >>> We're relying on the same mechanism that keeps the event buffer from >>> becoming full. Since it is just as (un)likely a possibility. That's >>> why you must size the event buffer appropriately taking into account >>> your system's latency, etc. >>> >>> And if the event buffer becomes full, that indicates something really >>> wrong happened in the controller. You shouldn't be getting 100's of >>> events at a time. >>> >>> But yes, we can address the overwriting issue. >>> >>> Either: >>> >>> 1) Cache all incoming events. Requires double the event buffer space. >>> >>> 2) Cache just one event and write back only '4' during hard >>> interrupt. Then in threaded interrupt read the one event from >>> cache, and process the remaining events from buffer as before. >>> Doesn't require a large cache, but a bit messier. >>> >>> Any other thoughts or ideas? >> >> do you really need to clear at least one event for this? >> > > Unfortunately yes. That's how the workaround works. We need to write > this during IMOD to de-assert the interrupt since the mask bit doesn't > work. okay. Then we should cache and clear a single event. > We could do this only for 3.00a as well. if we do this only for 3.00a then the code will look odd :-) It shouldn't cause any problems for any other revisions -- balbi
Attachment:
signature.asc
Description: PGP signature
