On Fri, Jan 16, 2015 at 08:41:06AM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> [150116 08:33]: > > I would still like to understand /why/ enabling preempt causes the error. > > Changing the preempt configuration really should not change what happens > > on the bus. (Think about it.) It's an indication that there is some > > other error present. > > We have a wrong irq number caused by $subject. And the wrong irq > gets triggered before the dma hardware is configured during dma > init. And then we get the invalid access error from omap_l3_noc. ... which should happen whether or not preempt is enabled, which is really my point. We know tha the wrong IRQ gets requested by the driver - and that wrong IRQ is requested whether or not we have preempt enabled. Yet we get the warning whether or not preempt is enabled. The DMA handler is not registered as a threaded handler, so it's not depending on a context switch to execute omap2_dma_irq_handler(). Another reason why I don't agree with your explanation is that by the time setup_irq() is called, we have already poked at the DMA hardware several times - omap_clear_dma() and omap2_disable_irq_lch() will have been called for each DMA channel - and both will write to the hardware. What's more is that the only things left after setup_irq() has been called is to possibly reserve the first two DMA channels and print the DMA message (via show_dma_caps). So I see nothing after setup_irq() which would "finish" any unfinished hardware initialisation. The final reason I don't agree is that I've put a printk() in omap2_dma_irq_handler(), and this does not trigger. So, I think this has nothing to do with the DMA hardware /at all/, but more to do with the GPIO code, and it suggests that the GPIO code publishes IRQs before it is safe for those IRQs to be used. Maybe it has to do with omap_gpio_irq_handler() being called... added printk(), nope, that's not called either. So it's not an IRQ which gets triggered at all. What is called are (in order): omap_gpio_unmask_irq() omap_set_gpio_irqenable() omap_enable_gpio_irqbank() and this reveals where the problem is, especially when you then add instrumentation into the runtime PM functions - and this reveals that when a GPIO IRQ is requested, these functions are called while the GPIO is runtime suspended. _That_ is where the *real* problem lies - requesting a GPIO interrupt results in the kernel touching possibly runtime-suspended hardware. The reason it happens with preempt is that preempt introduces scheduling points during the kernel boot which would not otherwise be there (with preempt disabled, you have to hit an explicit context switch due to contention on some lock or a wait in order for some other thread to run.) So, the GPIO driver really needs fixing - and I'd suggest fixing it first, before fixing the DMA problem, because the DMA problem allows us to see the GPIO problem. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
