qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] IRQ number, interrupt number, interrupt line & GPIO[in/


From: Zhi Yong Wu
Subject: Re: [Qemu-devel] IRQ number, interrupt number, interrupt line & GPIO[in/out]
Date: Sun, 4 Mar 2012 11:30:02 +0800

On Sun, Mar 4, 2012 at 1:12 AM, Peter Maydell <address@hidden> wrote:
> 2012/3/3 Zhi Yong Wu <address@hidden>:
>> thanks a lot for your help, they are very in theory.:). actually these
>> concepts all exist in QEMU. I would like to know how they work
>> together.
>
> It's a mess. qemu_irq is the most fundamental data type we
> use to model a general 'pin' or 'signal' line; despite the name
> it can be used for other things besides interrupt lines, like
> general purpose I/O. This is used by basically all devices.
>
> The base class Device for all devices implemented using the
> QEMU Object Model provides a number of qdev_* functions for
> registering and manipulating input and output I/O lines,
> eg qdev_get_gpio_in and qdev_connect_gpio_out. These are
> written in terms of the basic qemu_irq type. Despite the
> 'gpio' name, you can use these for interrupt lines if you want.
>
> The SysBus class (used for a lot of devices which are really
> just trying to provide memory-mapped I/O and some interrupt
> or signal lines) also provides an abstraction of qemu_irq
> (functions sysbus_connect_irq(), sysbus_init_irq(), etc).
> Again, there's no reason you can't use these for other
> purposes than interrupts, although since every SysBus device
> is also a Device, mostly by convention the sysbus abstraction
> is used for the real outbound interrupt lines and the Device
> gpio abstraction for everything else.
>
> My opinion is that we should clean this up as part of properly
> converting to the new object model. In particular SysBus should
> just disappear and all Devices should be able to export named
> input and output signals, which can be used for interrupts
> or general I/O or whatever. Unfortunately we're probably
> stuck with the incredibly badly named 'qemu_irq' type for the
> rest of eternity...
thanks
>
> -- PMM



-- 
Regards,

Zhi Yong Wu



reply via email to

[Prev in Thread] Current Thread [Next in Thread]