[SNIP] > > > > > Would you be able to ftrace the interrupt handler function and see if you > > > can see a difference in number or timing of interrupts? I'm at a bit of > > > a loss. > > > > I tried ftrace but I really wasn't sure what I was looking for. > > Capturing a "bad" case was pretty tricky. But I think I've identified a > > fix (I'll send it as a proper patch shortly). The gist is > > > > diff --git a/drivers/spi/spi-fsl-espi.c b/drivers/spi/spi-fsl-espi.c > > index 7e7c92cafdbb..cb120b68c0e2 100644 > > --- a/drivers/spi/spi-fsl-espi.c > > +++ b/drivers/spi/spi-fsl-espi.c > > @@ -574,13 +574,14 @@ static void fsl_espi_cpu_irq(struct fsl_espi > > *espi, u32 events) > > static irqreturn_t fsl_espi_irq(s32 irq, void *context_data) > > { > > struct fsl_espi *espi = context_data; > > - u32 events; > > + u32 events, mask; > > > > spin_lock(&espi->lock); > > > > /* Get interrupt events(tx/rx) */ > > events = fsl_espi_read_reg(espi, ESPI_SPIE); > > - if (!events) { > > + mask = fsl_espi_read_reg(espi, ESPI_SPIM); > > + if (!(events & mask)) { > > spin_unlock(&espi->lock); > > return IRQ_NONE; > > } > > > > The SPIE register contains the TXCNT so events is pretty much always > > going to have something set. By checking events against what we've > > actually requested interrupts for we don't see any spurious events. > > > > I've tested this on the T2080RDB and on our custom hardware and it seems > > to resolve the problem. > > > > I looked at the fsl_espi_irq() too and noticed that clearing of the IRQ events > are after processing TX/RX. That looks a bit odd to me. I should have been more specific. I think you can loose IRQs as fsl_espi_irq() works now. Consider this: 1) You get TX IRQ and enter fsl_espi_irq() 2) Enter fsl_espi_fill_tx_fifo() to process any chars until done. 3) Now you get one more TX IRQ 4) fsl_espi_irq() clear events -> IRQ from 3) is lost. Jocke