On 2016-09-22 16:41, Sebastian Andrzej Siewior wrote: > On 2016-09-22 16:16:19 [+0200], Claudius Heine wrote: >> Thanks for your help, but I am sorry to disappoint: > > I am surprised. You have UART and SPI sharing the interrupt and from > output it is SPI that does not cooperate. > Disable SPI and the warning/error should go. > Maybe RT hits a condition the SPI driver return IRQ_NONE instead of > doing something. It does, but I'm not yet understanding why (the driver's status register actually does not list any reasons, but when disabling the device, the problem is gone). I'll try to dig deeper, just to exclude a generic -rt problem. However, I found a workaround for our target, with positive side effect (one slow legacy INT less, one shared INT less - we could do more): diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c index 520ed1d..4ec458f 100644 --- a/drivers/spi/spi-pxa2xx-pci.c +++ b/drivers/spi/spi-pxa2xx-pci.c @@ -168,6 +168,7 @@ static int pxa2xx_spi_pci_probe(struct pci_dev *dev, dev_err(&dev->dev, "failed to ioremap() registers\n"); return -EIO; } + pci_enable_msi(dev); ssp->irq = dev->irq; ssp->port_id = (c->port_id >= 0) ? c->port_id : dev->devfn; ssp->type = c->type; As you've written that code: Any reason why we should refrain from doing that upstream? Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
