[PATCH 2/2] powerpc/85xx: handle the eLBC error interrupt if it exist in dts

Scott Wood scottwood at freescale.com
Wed Jan 8 07:45:00 EST 2014


On Tue, 2014-01-07 at 04:01 -0600, Wang Dongsheng-B40534 wrote:
> 
> > -----Original Message-----
> > From: Wood Scott-B07421
> > Sent: Tuesday, January 07, 2014 2:58 PM
> > To: Wang Dongsheng-B40534
> > Cc: linuxppc-dev at lists.ozlabs.org; Xie Shaohui-B21989; Kumar Gala
> > Subject: Re: [PATCH 2/2] powerpc/85xx: handle the eLBC error interrupt if it
> > exist in dts
> > 
> > On Tue, 2014-01-07 at 14:27 +0800, Dongsheng Wang wrote:
> > > From: Wang Dongsheng <dongsheng.wang at freescale.com>
> > 
> > AFAICT this patch was originally written by Shaohui Xie.
> > 
> > > On P3041, P1020, P1021, P1022, P1023 eLBC event interrupts are routed
> > > to Int9(P3041) & Int3(P102x) while ELBC error interrupts are routed to
> > > Int0, we need to call request_irq for each.
> > 
> > For p3041 I thought that was only on early silicon revs that we don't
> > support anymore.
> > 
> > As for p102x, have you tested that this is actually what happens?  How
> > would we distinguish eLBC errors from other error sources, given that
> > there's no EISR0?  Do we just hope that no other error interrupts
> > happen?
> Yes, I tested. The interrupt is shard eLBC interrupt handler could check the error.
> This patch is fix "nobody cared" the error interrupt. After sleep resume the lbc
> will get a chip select error.

s/no other error interrupts happen/no other error interrupts for which
we don't have a handler registered or which don't even have an
associated status register happen/

-Scott




More information about the Linuxppc-dev mailing list