RE: [PATCH 2/2] powerpc/85xx: handle the eLBC error interrupt if it exist in dts
-Original Message- From: Wood Scott-B07421 Sent: Tuesday, January 07, 2014 2:58 PM To: Wang Dongsheng-B40534 Cc: linuxppc-dev@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.w...@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. -Dongsheng -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 2/2] powerpc/85xx: handle the eLBC error interrupt if it exist in dts
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@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.w...@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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 2/2] powerpc/85xx: handle the eLBC error interrupt if it exist in dts
-Original Message- From: Wood Scott-B07421 Sent: Wednesday, January 08, 2014 4:45 AM To: Wang Dongsheng-B40534 Cc: linuxppc-dev@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 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@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.w...@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/ If the ip-block does not handle their error interrupt is a ip-block issue that. Since the use of this shared interrupt must maintain their status, once there is no deal shared interrupt, it will affect the other ip-block. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
