qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH 45/50] lasips2: use qdev gpio for output IRQ


From: Mark Cave-Ayland
Subject: Re: [PATCH 45/50] lasips2: use qdev gpio for output IRQ
Date: Mon, 20 Jun 2022 14:22:32 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

On 20/06/2022 11:17, Peter Maydell wrote:

On Sat, 11 Jun 2022 at 16:44, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:

On 10/06/2022 08:17, Mark Cave-Ayland wrote:

On 09/06/2022 12:18, Peter Maydell wrote:
If you find yourself #defining names for IRQ lines then this is
probably a sign you should be using named GPIO lines :-)

Yeah that's something I've done a few times here, mainly to have just one "set 
IRQ"
function rather a separate one for both keyboard and mouse. It takes a bit more 
work,
but I can certainly separate them out.

Looking at this again, the gpio being defined here actually is the (only) 
lasips2
output IRQ, and so should be left unnamed.

The reason for adding LASIPS2_IRQ was so that the gpio connection process 
looked like:

      qdev_connect_gpio_out(dev, LASIPS2_IRQ, irq);

instead of:

      qdev_connect_gpio_out(dev, 0, irq);

Would you still prefer for me to simply hardcode 0 here and drop the LASIPS2_IRQ
define in this case since there is only one output IRQ?

Well, I think that "unnamed GPIO out" lines should be for
actual GPIO lines, ie on a GPIO controller or similar.
If you want an outbound IRQ line and don't want to name it,
that's what sysbus IRQ lines do. Otherwise, name the GPIO line.

That's interesting - I've always been under the impression that this was the other way around, i.e. for a TYPE_DEVICE then unnamed gpios are equivalent to IRQs, and that gpio lines for any other non-IRQ purpose should be named :/

So... I'm not really sure what to do in the context of this patchset. Would using qdev gpios with suitable "QEMU interface" comments be good enough, or do you really feel strongly that these should be converted to SysBus IRQs?

Following on from this we should also consider starting a new thread re: the future of SysBusDevice and how we would like to model SysBus IRQs and mmio regions going forward.


ATB,

Mark.



reply via email to

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