From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlGxn-0000wA-VW for qemu-devel@nongnu.org; Thu, 12 Jan 2012 04:28:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RlGxh-0002Be-Kv for qemu-devel@nongnu.org; Thu, 12 Jan 2012 04:28:51 -0500 Received: from goliath.siemens.de ([192.35.17.28]:19601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RlGxh-0002Aw-A8 for qemu-devel@nongnu.org; Thu, 12 Jan 2012 04:28:45 -0500 Message-ID: <4F0EA7C9.9010506@siemens.com> Date: Thu, 12 Jan 2012 10:28:41 +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> <7FA9DB36-4A2F-4F15-AD67-AB77952F76F6@suse.de> In-Reply-To: <7FA9DB36-4A2F-4F15-AD67-AB77952F76F6@suse.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: Alexander Graf Cc: =?ISO-8859-1?Q?Andreas_F=E4rber?= , =?ISO-8859-1?Q?Herv=E9_Poussineau?= , qemu-devel Developers On 2012-01-12 09:18, Alexander Graf wrote: >=20 > On 12.01.2012, at 09:09, Jan Kiszka wrote: >=20 >> 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(-) >>>>>>> >>>>>>> diff --git a/hw/i8259.c b/hw/i8259.c >>>>>>> index 84d330d..59e8bd6 100644 >>>>>>> --- a/hw/i8259.c >>>>>>> +++ b/hw/i8259.c >>>>>>> @@ -26,6 +26,7 @@ >>>>>>> #include "isa.h" >>>>>>> #include "monitor.h" >>>>>>> #include "qemu-timer.h" >>>>>>> +#include "sysbus.h" >>>>>>> >>>>>>> /* debug PIC */ >>>>>>> //#define DEBUG_PIC >>>>>>> @@ -524,16 +525,60 @@ void irq_info(Monitor *mon) >>>>>>> >>>>>>> qemu_irq *i8259_init(qemu_irq parent_irq) >>>>>>> { >>>>>>> - PicState2 *s; >>>>>>> + DeviceState *dev; >>>>>>> + dev =3D qdev_create(NULL, "i8259"); >>>>>>> + qdev_init_nofail(dev); >>>>>>> + qdev_connect_gpio_out(dev, 0, parent_irq); >>>>>>> + >>>>>>> + return dev->gpio_in; >>>>>>> +} >>>>>>> + >>>>>>> +typedef struct SysBusPicState2 { >>>>>>> + SysBusDevice busdev; >>>>>>> + PicState2 state; >>>>>>> +} SysBusPicState2; >>>>>>> + >>>>>>> +static void i8259_set_irq_sysbus(void *opaque, int line, int lev= el) >>>>>>> +{ >>>>>>> + SysBusPicState2 *sysbus =3D opaque; >>>>>>> + PicState2 *s =3D &sysbus->state; >>>>>>> + i8259_set_irq(s, line, level); >>>>>>> +} >>>>>>> + >>>>>>> +static int i8259_sysbus_init(SysBusDevice *dev) >>>>>>> +{ >>>>>>> + SysBusPicState2 *sysbus =3D FROM_SYSBUS(SysBusPicState2, dev= ); >>>>>>> + PicState2 *s =3D &sysbus->state; >>>>>>> + >>>>>>> + if (isa_pic) { >>>>>>> + return 1; >>>>>>> + } >>>>>>> >>>>>>> - s =3D qemu_mallocz(sizeof(PicState2)); >>>>>>> pic_init1(0x20, 0x4d0, &s->pics[0]); >>>>>>> pic_init1(0xa0, 0x4d1, &s->pics[1]); >>>>>>> s->pics[0].elcr_mask =3D 0xf8; >>>>>>> s->pics[1].elcr_mask =3D 0xde; >>>>>>> - s->parent_irq =3D parent_irq; >>>>>>> s->pics[0].pics_state =3D s; >>>>>>> s->pics[1].pics_state =3D s; >>>>>>> isa_pic =3D s; >>>>>>> - return qemu_allocate_irqs(i8259_set_irq, s, 16); >>>>>>> + >>>>>>> + qdev_init_gpio_in(&dev->qdev, i8259_set_irq_sysbus, 16); >>>>>>> + qdev_init_gpio_out(&dev->qdev, &s->parent_irq, 1); >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static SysBusDeviceInfo i8259_sysbus_info =3D { >>>>>>> + .qdev.name =3D "i8259", >>>>>>> + .qdev.size =3D sizeof(SysBusPicState2), >>>>>>> + .init =3D i8259_sysbus_init, >>>>>>> + .qdev.props =3D (Property[]) { >>>>>>> + DEFINE_PROP_END_OF_LIST() >>>>>>> + }, >>>>>>> +}; >>>>>>> + >>>>>>> +static void i8259_register_devices(void) >>>>>>> +{ >>>>>>> + sysbus_register_withprop(&i8259_sysbus_info); >>>>>>> } >>>>>>> + >>>>>>> +device_init(i8259_register_devices) >>>>>> >>>>>> 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 you're saying we should do the same for PCI? > To create an ISA bus that sits behind a PCI device I first need to crea= te a PCI bus which is exposed by the host bridge which then again needs i= nterrupt lines. >=20 > I'm still puzzled how we would pass on irq lines then. I mean setting t= hem after init means that during init we can't instantiate other devices = that we can wire up to anything, right? The ordering is: 1. create PCI bridge 1.1. create ISA bus 2. create i8259 3. bind interrupts to i8259 4. create further ISA devices All this can be part of the chipset instantiation. It is not today as we reuse everything from 2. on for isapc. But that could likely be refactore= d. Jan --=20 Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux