From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:43995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKRkY-0005dX-Nz for qemu-devel@nongnu.org; Tue, 26 Mar 2013 07:09:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKRkS-00051b-En for qemu-devel@nongnu.org; Tue, 26 Mar 2013 07:09:06 -0400 Received: from moutng.kundenserver.de ([212.227.17.8]:50166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKRkS-00051L-5J for qemu-devel@nongnu.org; Tue, 26 Mar 2013 07:09:00 -0400 From: Arnd Bergmann Date: Tue, 26 Mar 2013 11:08:50 +0000 References: <1364293331-8722-1-git-send-email-peter.maydell@linaro.org> <201303261054.59928.arnd@arndb.de> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201303261108.50434.arnd@arndb.de> Subject: Re: [Qemu-devel] [PATCH v2 07/11] versatile_pci: Implement the correct PCI IRQ mapping List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: "Michael S. Tsirkin" , patches@linaro.org, Will Deacon , qemu-devel@nongnu.org, Paul Brook , Andreas =?utf-8?q?F=C3=A4rber?= , Aurelien Jarno On Tuesday 26 March 2013, Peter Maydell wrote: > > On 26 March 2013 10:54, Arnd Bergmann 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. > > 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. Arnd