On 9 November 2016 at 09:05, Felipe Balbi <balbi@xxxxxxxxxx> wrote: > > 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. > 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 this correctly and can add simple implementation for that in bottom half. In case of single event cache, VTE handling will be much harder/ugly ... - while we have to check if cache 4 or 12 bytes. Anyway is the VTE case at all? We don't support this currently and don't have an issues ... BR Janusz >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
