From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:50818) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ud1WE-0006fk-PH for qemu-devel@nongnu.org; Thu, 16 May 2013 12:59:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ud1WB-00015w-8S for qemu-devel@nongnu.org; Thu, 16 May 2013 12:59:06 -0400 Received: from moutng.kundenserver.de ([212.227.17.10]:55873) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ud1WA-000155-UX for qemu-devel@nongnu.org; Thu, 16 May 2013 12:59:03 -0400 From: Arnd Bergmann Date: Thu, 16 May 2013 18:58:57 +0200 References: <1368545616-22344-1-git-send-email-peter.maydell@linaro.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201305161858.57214.arnd@arndb.de> Subject: Re: [Qemu-devel] [PATCH for-1.5 0/3] hw/pci-host/versatile: Fix issues with newer kernels List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Linus Walleij Cc: Peter Maydell , Anthony Liguori , "Michael S. Tsirkin" , Patch Tracking , Will Deacon , qemu-devel@nongnu.org, Joss Reeves , Andreas =?iso-8859-1?q?F=E4rber?= , Aurelien Jarno On Wednesday 15 May 2013, Linus Walleij wrote: > On Tue, May 14, 2013 at 5:33 PM, Peter Maydell wrote: > > > The reworking of the versatile PCI controller model so that it actually > > behaved like hardware included an attempt to autodetect whether the > > guest Linux kernel was assuming the old broken behaviour. Unfortunately > > it turns out that there are several different variant broken kernels > > which behave slightly differently (though none of them will work on > > real hardware). The first two patches in this series improve the > > autodetection so that we will work out of the box on more kernels. > > The third patch adds a property for forcing the behaviour, so that > > if there are further cases we didn't know about, at least users have > > a command line workaround they can enable. > > This looks like a viable approach to me. So FWIW: > Acked-by: Linus Walleij FWIW, I plan to really get this done in the kernel for 3.11 properly and rework the entire versatile and realview code base to work without any platform specific code in arch/arm. The plan is to use the new infrastructure for PCI and put that code into drivers/pci/host, and have it scan the hardware using DT only. We can have a backwards compatibility setup for versatile-pb without DT, but in the long run, I would prefer to kill off that boot option. If this works out, any Linux kernel built for any platform should be able to boot the versatilepb, versatileab, integratorcp, realview-eb, realview-eb-mpcore, realview-pb-a8, realview-pbx-a9, vexpress-a9 and vexpress-a15 models, as long as you pass a -cpu option matching a CPU enabled in the kernel, and all the drivers are enabled. I remember there was a way to autogenerate the dtb blob in qemu at some point, based on the devices enabled in the model. Did that ever make it in? Arnd