On 10/04/14 15:49, Russell King - ARM Linux wrote:
That said, I don't understand why it breaks now but not earlier, nothing has changed around that. Hmm, except now we use proper DT bindings, so the IRQ comes from DT. But I don't see why that would affect this.
It looks like the updates stopped DSI from initialising.
Hm, so are we talking about Linus' master, or linux-next? I'm testing on Linus' tree for today, with multi_v7_defconfig + DSS enabled, the display on 4430 SDP comes up fine for me (but something causes the boot to halt right after mounting my rootfs, but that's probably different thing). And the display seems to work with CMA and without CMA.
Can you share the .config?
If the interrupt is registered as a shared interrupt, it means that the interrupt may be shared with another device, which may trigger that interrupt at any moment, whether or not your hardware is accessible.
That means you must:
- have some way to make it accessible in the interrupt handler
- have some way to know that the interrupt could never have come from the hardware (and this return IRQ_NONE)
- not register it as a shared interrupt, thus ensuring that no other device driver could register and raise an interrupt when you're not ready to deal with it
I'll try to come up with a proper fix. For the time being, the attached hack patch makes the problem go away with CONFIG_DEBUG_SHIRQ, which should allow booting even if the omapfb fails to start.
PS, as you can see from the above, there's another bug in OMAPDSS with dss_set_fck_rate().
I have a fix for that, but it depends for drivers/clk changes so I could not send it with the main pull request. The warning should be relatively harmless. I've attached the patch in any case.
Tomi