On 26 March 2013 11:08, Arnd Bergmann <a...@arndb.de> wrote: > On Tuesday 26 March 2013, Peter Maydell wrote: >> On 26 March 2013 10:54, Arnd Bergmann <a...@arndb.de> wrote: >> > Yes, very good. We will probably introduce sparse irq support on >> > versatile in the near future, and then the value we write into the >> > PCI_INTERRUPT_LINE field will become arbitrary from qemu's point >> > of view, but I will make sure that we fix the interrupt mapping >> > in the kernel at the same time so we always fall into the >> > "s->broken_irq_mapping = false;" case. >> >> Yeah, as long as you avoid the number 27 you're ok :-) > > Good point. I guess we'll have to keep using a legacy domain for > versatile then.
I'm happy to provide some other way for QEMU to detect a new working kernel if you want to implement one in the kernel, if that's cleaner. >> > We also need to find a way to make the new kernel work with >> > an old qemu, and I think we can do that by using the versatile-dt >> > board type with a PCI device node that sets all four lines to >> > 27, while using the actual interrupt lines for the default >> > versatile device tree. >> >> Personally I'd be happy for you to just say "needs a new QEMU". >> The broken QEMU is missing so much (including working memory >> windows) that I think it would be a pain to get the kernel to >> cope with it. > > But it was working earlier, so I'd definitely try not to break > if at all possible. A lot of people use the verstatile qemu > model to run kernels and I would not want to deal with the > complaints I'd get if we break those. Using a separate dts > file seems easy enough. Yeah, but it only worked earlier because the kernel PCI controller support was so broken and limited, I think. If you run a new kernel with the old QEMU it won't work even if you avoid the irq-mapping issues. Also I really don't want to get people into the habit of using a QEMU-specific dts file. The result will be that nobody will ever move on from that dts file to the one that gets used with real hardware. Plus, you guys make kernel changes that break running on QEMU all the time, so I don't see that as a big deal really. (Most recently, vexpress needed a pile of support for the config registers that define the voltage regulators and clocks.) -- PMM
