Hi, Janusz Dziedzic <janusz.dziedzic@xxxxxxxxx> writes: >> 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. >> > Cache all incoming events looks better for me, while we don't need > care of Vendor Test Event (12Bytes) here - and we will always handle That doesn't matter. If we write 4 to GEVNTCOUNT(0), then only 4 bytes will be cleared. We can still read the following 8 bytes of data from the event buffer itself. > this correctly and can add simple implementation for that in bottom > half. we can still handle this all correctly :-) -- balbi
Attachment:
signature.asc
Description: PGP signature
