Thanks for your reply.
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
Thankyou veru much
Naveen
--- 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.
>
>
> > 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
