Thankyou very much for your reply. --- David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 24 July 2006 2:04 am, Naveen Mamindlapalli > wrote: > > Thanks for your reply. > > > > I am doing FPGA testing of EHCI host controller > which > > is under development. > > > > Even In standard Intel PC ( Intel 82801DB/DBM USB > 2.0 > > Enhanced Host Controller ) which is running > > Linux-2.6.14 , this code path is traversed some > times > > but every thing seems ok ( no irq nobody cared > > messages ). > > The issue is clearly the code you're loading into > the FPGA; > you should fix that hardware race before it turns > into real > silicon (assuming that's the intent). > > > > But In my case as soon as I entered this function > with > > splinlock_irq_save , I am getting an EHCI > interrupt > > with STS_IAA bit set and I am clearing the same > bit in > > this function and now there are no status bits for > > indicating the occurence of that interrupt.So when > I > > go back to ehci_irq after spinunlock_irq_save in > > ehci_watchdog , the following piece of code is > > executed. > > > > if (!status) { __/* irq sharing? */ > > spin_unlock(&ehci->lock); > > return IRQ_NONE; > > } > > So to restate: the problem is that your FPGA code > is > issuing an IRQ when it shouldn't be. As if the IRQ > line is still held high even when none of the > enabled > IRQ sources is still reporting the IRQ. > > The issue is actually twofold. Not just the fact > that > the IRQ is still triggered ... but also that the IAA > IRQ was delayed for so long that the watchdog fired. > In our case host controller generates the IAA IRQ after the entire asynchronous schedule list traversed and the observe the head of the queue twice before setting the STS_IAA bit as per section 4.8.2 ( Alternative method for removing queue heads ) in EHCI spec.And then IRQ is generated on the next interrupt threshold. So some times the watchdog is fired before the interrupt was generated and hence in watchdog routine if STS_IAA bit is set , it is clearing that bit.But before clearing if interrupt threshold is reached, our interrupt controller gennerating the interrupt. Clearly I observed that this is not the problem of lost IAA IRQ's.So in my case why the code in ehci_watchdog should be traversed. ----------------------------------------------------- if (ehci->reclaim) { u32 status = readl (&ehci->regs->status); if (status & STS_IAA) { ehci_vdbg (ehci, "lost IAA\n"); COUNT (ehci->stats.lost_iaa); writel (STS_IAA, &ehci->regs->status); ehci->reclaim_ready = 1; } } ----------------------------------------------------- If I comment the above piece of code in ehci_watchdog function, eveything is working fine for me.Is there any problem by commenting the above code. Please correct me if I am wrong.I doubt why the above code is not in #ifdef CONFIG_VT8235 #endif > > > But copy is fine even with this problem.Does any > > memory leakage will happen > > with this problem in long run. > > I can't see why there would be leakage. > > - Dave > > > > Is there any harm if > > this problem is not fixed in the hardware. > > > > I have observed that in my PC , this interrupt is > not > > coming when I am in ehci_watchdog function. > > > > Due to some problems while booting up the > Linux-2.6.17 > > , I am not able to do FPGA testing on the latest > > kernel.But codewise everything seems same with > respect > > to asynchronous transfers.So I am expecting the > same > > behaviour with this kernel also. > > > > Please give me some suggestion with respect to > this > > problem. > > > > Thanks you very much, > > Naveen > > > > --- David Brownell <[EMAIL PROTECTED]> wrote: > > > > > From: David Brownell <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > > > Subject: Re: irq nobody cared in EHCI - > Linux-2.6.14 > > > Date: Tue, 18 Jul 2006 14:46:02 -0700 > > > CC: Naveen Mamindlapalli > > > <[EMAIL PROTECTED]> > > > > > > On Tuesday 18 July 2006 5:30 am, Naveen > > > Mamindlapalli wrote: > > > > > > > > Why ehci_watchdog is encountering the > condition > > > > if(ehci->reclaim) & if (status * STS_IAA) > only > > > some times. > > > > > > Because the silicon bug being worked around by > the > > > watchdog doesn't > > > appear all the time. Whose EHCI silicon are you > > > using? (Note > > > that I'm assuming you mean "&" not "*" ... very > > > different.) > > > > > > > > > > CODE in ehci-hcd.c : ehci_watchdog function: > > > > > > > > > > ------------------------------------------------------------------ > > > > if (ehci->reclaim) { > > > > u32 status = readl (&ehci->regs->status); > > > > if (status & STS_IAA) { > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > I doubt why we should clear any interrupt > status > > > bits in a function which is > > > > not an interrupt service routine. > > > > > > It's _status_ not specifically "interrupt" > status > > > ... so it would be set > > > even if the IRQ were not enabled. And the > silicon > > > bug is that STS_IAA > > > sometimes gets set without the IRQ triggering, > even > > > if the IRQ is enabled, > > > leading to hangs -- unless the watchdog is there > to > > > cause the IAA handling > > > to happen in those cases. (Seen reasonably > often on > > > VIA hardware.) > > > > > > > > > > Can anybody give some suggestions on this. > > > > > > If you're getting the "nobody cared" that > implies > > > your EHCI controller > > > has such a silicon problem, yes? It also > implies > > > your code doesn't > > > match any recent version ... IRQ_NONE is never > > > returned. > > > > > > > > > USB issues like this are best brought up on the > USB > > > list, since they're > > > not going to be ARM-specific. And as has been > > > noted, 2.6.14 is kind of > > > old ... try a current kernel. There seem to be > some > > > glitches still in > > > the unlink paths, but none that show up on > hardware > > > I have access to. > > > > > > - Dave > > > > > > > > > > > > > > > > > __________________________________________________________ > > Yahoo! India Answers: Share what you know. Learn > something new > > http://in.answers.yahoo.com/ > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of > IT > > Join SourceForge.net's Techsay panel and you'll > get the chance to share your > > opinions on IT & business topics through brief > surveys -- and earn cash > > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > linux-usb-devel@lists.sourceforge.net > > To unsubscribe, use the last form field at: > > > https://lists.sourceforge.net/lists/listinfo/linux-usb-devel > === message truncated === Thanks & Regards Naveen.M __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel