qemu-arm
[Top][All Lists]
Advanced

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

Re: [PATCH] hw/arm/virt: Fix PL061 node name and properties


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH] hw/arm/virt: Fix PL061 node name and properties
Date: Fri, 22 May 2020 11:46:52 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0

On 5/22/20 11:30 AM, Peter Maydell wrote:
On Fri, 22 May 2020 at 09:29, Geert Uytterhoeven <address@hidden> wrote:
On Thu, May 21, 2020 at 6:59 PM Peter Maydell <address@hidden> wrote:
On Tue, 19 May 2020 at 09:49, Geert Uytterhoeven
<address@hidden> wrote:
Make the created node comply with the PL061 Device Tree bindings:
   - Use generic node name "gpio" instead of "pl061",
   - Add missing "#interrupt-cells" and "interrupt-controller"
     properties.

[...]
Since the devicetree spec says that the interrupt-controller
property "defines a node as an interrupt controller node"
and a GPIO chip isn't an interrupt controller, this seems
like some kind of error in the dtb binding. Maybe I'm
missing something...

PL061 is an interrupt controller, as it can assert its interrupt output
based on activity on GPIO input lines.

By that logic the PL011 UART is an interrupt controller, because
it can assert its interrupt output based on activity on the serial
port input lines.

Yes :)

A GPIO controller is not an interrupt controller inherently.
Maybe you can use it in a system design as an interrupt
controller if you want to, and in that system's dtb perhaps
it would make sense to label it as one, but the virt board's
PL061 is in no way an interrupt controller -- it's just a GPIO
controller.

What actually goes wrong if QEMU doesn't specify these
properties?

It means that other devices that have their interrupt output connected
to a PL061 GPIO input won't work, as their driver in the guest OS cannot
find the interrupt.  Note that arm/virt.c currently doesn't instantiate
such devices.

OK. But why would we want to run an interrupt line through the GPIO
controller when we have a perfectly good interrupt controller in
the system already?

This is sometimes done on embedded devices when all the INTC lines are already wired. You'd use extra lines on free peripherals. Usually the peripheral offer a limited GPIO mode as passthru interrupt, else you use nasty hacks...


It might be reasonable to add the properties now to avoid setting
a bear trap for ourselves in future; on the other hand if running
interrupt lines through the GPIO controller doesn't work then it
acts as a nudge to stop people adding devices that are wired
up in a weird way.
[...]



reply via email to

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