Hi Felipe, On Mon, Jul 15, 2013 at 11:48:01PM +0800, Felipe Balbi wrote: > On Fri, Jun 14, 2013 at 09:37:54AM +0800, Huang Rui wrote: > > On Thu, Jun 13, 2013 at 10:20:53PM +0800, Felipe Balbi wrote: > > > Hi, > > > > > > On Thu, Jun 13, 2013 at 08:26:12PM +0800, Huang Rui wrote: > > > > > > I was reading dwc3 codes and found that during the process of > > > > > > configuring event buffer (dwc3_event_buffers_setup), it only write the > > > > > > size of the buffer and doesn't write interrupt mask bit into GEVNTSIZ > > > > > > register like below, > > > > > > > > > > > > dwc3_writel(dwc->regs, DWC3_GEVNTSIZ(n), > > > > > > evt->length & 0xffff); > > > > > > > > > > > > But in spec, it suggests that write this bit to prevent the interrupt > > > > > > from being generated in an event buffer configuration. So need we set > > > > > > > > > > where does it say that ? I just re-read details about that bit and all > > > > > it says is that it can be used to mask the interrupt, but events will > > > > > still be queued. Maybe I'm missing some part. Which revision of the > > > > > databook are you reading ? > > > > > > > > Thanks a lot to look back into this issue. I read version 2.50a, in > > > > section 8.2.2, the step 3 to configure an Event Buffer describes: > > > > > > > > "Writes the size of the buffer and interrupt mask into GEVNTSIZn. > > > > Depending on your system interrupt latency, enough Event Buffer space > > > > must be allocated to avoid lost interrupts or reduced performance." > > > > > > > > If I misunderstood, please correct me. > > > > > > but we are writing Interrupt mask bit, just always writing 0 :-) > > > > > > > You're right. :) > > > > > > > Anyway, we don't really need that bit right now because linux will only > > > > > enable the IRQ line after request_*irq() has been called and we're > > > > > setting up our event buffers before calling that. > > > > > > > > > > > > > Yeah, when the event buffers are set up, it must not encounter any > > > > interrupts. > > > > > > right. > > > > > > > > OTOH, we could use that bit as means to get rid of IRQF_ONESHOT from > > > > > DWC3 driver. > > > > > > > > > > > > > Thanks to teach me. The IRQF_ONESHOT interrupt should also prevent the > > > > other interrupts until the current thread has been run, just like the > > > > function of interrupt mask bit, am I right? > > > > > > that's correct. IRQ subsystem makes sure to keep IRQs masked until > > > thread has finished running. > > > > > > > > Can you test a patch for me ? I don't have access to HW right now. I > > > > > assume the patch below works fine, does it ? > > > > > > > > > > > > > Sorry, I haven't got the board yet. Your patch looks good, and I will > > > > test it as soon as I get HW. > > > > > > alright, so it's likely that I'll get access to my stuff back before. > > > Anyway, if you happen to have time, I'd be glad to see a Tested-by, > > > always good to test on more than a single platform. > > > > With my pleasure if I get board at that time. > > sorry for the delay, but I just tested my 'testing' branch on OMAP5 > uEVM board and it's working fine, then I merged my dwc3-no-oneshot > branch on top and I still have dwc3 working. So this patch which I sent > you is alright. I'll queue it for v3.12. > Thank you, I saw that patch. But I just knew my HW board would be received in early September. Apology for that. When I get the board, I will test it at once. BTW, I have another small fix which sent last month: http://marc.info/?l=linux-usb&m=137105158909488&w=2 Could you kindly also queue it in your test branch? :) Thanks, Rui -- 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
