From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44334) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlKOD-0005O0-CE for qemu-devel@nongnu.org; Thu, 12 Jan 2012 08:08:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RlKO5-0005Hm-Ms for qemu-devel@nongnu.org; Thu, 12 Jan 2012 08:08:21 -0500 Received: from goliath.siemens.de ([192.35.17.28]:19446) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlKO5-0005Hb-D9 for qemu-devel@nongnu.org; Thu, 12 Jan 2012 08:08:13 -0500 Message-ID: <4F0EDB3A.30509@siemens.com> Date: Thu, 12 Jan 2012 14:08:10 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <1309092433-4385-2-git-send-email-hpoussin@reactos.org> <4F0E2371.2010105@web.de> <4F0E8D2E.8050502@siemens.com> <4F0E9317.2010704@siemens.com> <4F0E9550.2090702@siemens.com> <4F0ED7EC.6060907@web.de> In-Reply-To: <4F0ED7EC.6060907@web.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 1/5] i8259: qdev-ify creation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: =?ISO-8859-1?Q?Herv=E9_Poussineau?= , Alexander Graf , qemu-devel Developers On 2012-01-12 13:54, Andreas F=E4rber wrote: > Am 12.01.2012 09:09, schrieb Jan Kiszka: >> On 2012-01-12 09:05, Alexander Graf wrote: >>> >>> On 12.01.2012, at 09:00, Jan Kiszka wrote: >>> >>>> On 2012-01-12 08:58, Alexander Graf wrote: >>>>> >>>>> On 12.01.2012, at 08:35, Jan Kiszka wrote: >>>>> >>>>>> On 2012-01-12 01:04, Andreas F=E4rber wrote: >>>>>>> Alex, >>>>>>> >>>>>>> I have this in my mailbox, but I'm still waiting for an SoB. Herv= =E9? >>>>>>> >>>>>>> Regards, >>>>>>> Andreas >>>>>>> >>>>>>> -------- Original-Nachricht -------- >>>>>>> Betreff: [PATCH 1/5] i8259: qdev-ify creation >>>>>>> Datum: Sun, 26 Jun 2011 14:47:09 +0200 >>>>>>> Von: Herv=E9 Poussineau >>>>>>> An: andreas.faerber@web.de >>>>>>> Kopie (CC): Herv=E9 Poussineau >>>>>>> >>>>>>> --- >>>>>>> hw/i8259.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++= ++---- >>>>>>> 1 files changed, 49 insertions(+), 4 deletions(-) > [snip] >>>>>> This is obsolete. The i8259 has been significantly refactored (int= o two >>>>>> ISA devices) and qdev'ified some moons ago. >>>>> >>>>> The reason we were discussing this was a circular dependency on PRE= P. >>>>> >>>>> The PIC is sitting on the ISA bus. >>>>> The ISA bus is behind a PCI-ISA bridge >>>>> the PCI-ISA bridge is behind a PCI host controller >>>>> the PCI host controller needs interrupt lines in its initialization= which are attached to the PIC >>>>> >>>>> Any good ideas on how to resolve this? :) >>>> >>>> As we do this always: Split up initialization and IRQ line wiring. >>> >>> Well, yes, the theory is obvious. How would this look like in practic= e? To create a PIC device I need a bus: >>> >>> dev =3D isa_create(bus, "isa-i8259"); >>> >>> But to create the bus, I need an interrupt line, which I only get aft= er I created the PIC device. >> >> ISA bus creation and IRQ assignment are split up IIRC. >=20 > So far I haven't found a really qdev'ified example though. mips_malta > uses qemu_irq_proxy() to pre-initialize 16 IRQ lines IIUC, but it does > everything in a flat, sequential way, creating the i8259 on the board > rather than on a chipset. As I said, the reason for this on the PC side is that fact that we model several variants with the same code, and one of them does this at board level. >=20 > I'll send v2 of my series later, with the part that works today for > Anthony and the bridge that breaks. I'll cc you. >=20 > Maybe we can use a QOM property to access the i8259 on the i82378? I think the bridge doesn't need access to the PIC, it has to have it's output wired to the inputs of the latter. That can be done at the level that created both, ie. in the chipset (provided we refactor the init code accordingly). >=20 > I'm aware we don't have PicState2 in upstream, so this patch doesn't > apply; the interesting part from my view was that it adds a SysBus > device as opposed to ISADevice, so doesn't need the ISABus. > Going down that route would require to split PicState into an > ISAPicState and SysBusPicState with shared core. Modeling the i8259 as a sysbus device is a workaround, not a solution. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux