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

Reply via email to