Re: [Qemu-devel] [PATCH v4 3/4] target-arm: Extend the gic node properties

[Christoffer Dall]

[whoops, re-adding qemu-devel]

On Thu, Jul 9, 2015 at 5:07 PM, Alexander Graf <address@hidden> wrote:
> On 07/09/15 16:44, Christoffer Dall wrote:
>>
>> On Thu, Jul 09, 2015 at 04:02:14PM +0200, Claudio Fontana wrote:
>>>
>>> Hello Christoffer,
>>>
>>> just one question:
>>>
>>>> In preparation for adding the GICv2m which requires address specifiers
>>>> and is a subnode of the gic, we extend the gic DT definition to specify
>>>> the #address-cells and #size-cells properties and add an empty ranges
>>>> property properties of the DT node, since this is required to add the
>>>> v2m node as a child of the gic node.
>>>>
>>>> Note that we must also expand the irq-map to reference the gic with the
>>>> right address-cells as a consequence of this change.
>>>>
>>>> Reviewed-by: Eric Auger <address@hidden>
>>>> Suggested-by: Shanker Donthineni <address@hidden>
>>>> Signed-off-by: Christoffer Dall <address@hidden>
>>>> ---
>>>> Changes since v3:
>>>>   - Rewrote patch and changed authorship and tags accordingly
>>>>   - Fixed spelling in commit message
>>>> Changes since v2:
>>>>   - New separate patch factoring out changes to existing code for eased
>>>>     bisectability in case we broke something
>>>>   - The above fixes the issue with non-MSI compatible guests.
>>>>
>>>>   hw/arm/virt.c | 11 +++++++----
>>>>   1 file changed, 7 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>>>> index e5235ef..387dac8 100644
>>>> --- a/hw/arm/virt.c
>>>> +++ b/hw/arm/virt.c
>>>> @@ -317,6 +317,9 @@ static void fdt_add_gic_node(VirtBoardInfo *vbi)
>>>>                                        2,
>>>> vbi->memmap[VIRT_GIC_DIST].size,
>>>>                                        2,
>>>> vbi->memmap[VIRT_GIC_CPU].base,
>>>>                                        2,
>>>> vbi->memmap[VIRT_GIC_CPU].size);
>>>> +    qemu_fdt_setprop_cell(vbi->fdt, "/intc", "#address-cells", 0x2);
>>>> +    qemu_fdt_setprop_cell(vbi->fdt, "/intc", "#size-cells", 0x2);
>>>> +    qemu_fdt_setprop(vbi->fdt, "/intc", "ranges", NULL, 0);
>>>>       qemu_fdt_setprop_cell(vbi->fdt, "/intc", "phandle",
>>>> vbi->gic_phandle);
>>>>   }
>>>>   @@ -585,7 +588,7 @@ static void create_pcie_irq_map(const
>>>> VirtBoardInfo *vbi,
>>>> uint32_t gic_phandle,
>>>>                                   int first_irq, const char *nodename)
>>>>   {
>>>>       int devfn, pin;
>>>> -    uint32_t full_irq_map[4 * 4 * 8] = { 0 };
>>>> +    uint32_t full_irq_map[4 * 4 * 10] = { 0 };
>>>>       uint32_t *irq_map = full_irq_map;
>>>>         for (devfn = 0; devfn <= 0x18; devfn += 0x8) {
>>>> @@ -598,13 +601,13 @@ static void create_pcie_irq_map(const
>>>> VirtBoardInfo *vbi,
>>>> uint32_t gic_phandle,
>>>>               uint32_t map[] = {
>>>>                   devfn << 8, 0, 0,                           /* devfn
>>>> */
>>>>                   pin + 1,                                    /* PCI pin
>>>> */
>>>> -                gic_phandle, irq_type, irq_nr, irq_level }; /* GIC irq
>>>> */
>>>> +                gic_phandle, 0, 0, irq_type, irq_nr, irq_level }; /*
>>>> GIC irq */
>>>
>>> can you help me understand how to decode this?
>>> We are adding two 32bit "0" values in the map.
>>> So now gic_phandle field occupies a total of 3 x 32bit values.
>>> Is this really what was intended?
>>>
>>> If the #address-cell and #size-cells of the intc are 2 and 2
>>> respectively,
>>> shouldn't this be
>>>
>>> gic_phandle, 0, irq_type, irq_nr, irq_level ?
>>>
>>> Too much time since I read this code I guess..
>>>
>> I'll be honest and say that I don't fully understand the details of the
>> interrupt-map specification, and I cannot seem to find it online either
>> (the working link I had before gives me a 404 these days).
>>
>> So I followed the suggestion from Shanker and it worked with adding two
>> zeroes, not with only adding one, so I figured it was the correct thing
>> to do.
>>
>> Perhaps Alex Graf who wrote the original code to generate the interrupt
>> map can help?
>
>
> The page works quite well for me:
>
>   http://devicetree.org/Device_Tree_Usage#Advanced_Interrupt_Mapping

It explains it conceptually, yes, but it's hardly a spec.  At least I
can't understand from that page why the entries in the map have to be
changed based on size-cells and address-cells in the interrupt
controller...

I didn't think the bits we needed to add were related to the phandle;
I always thought a phandle was just an internal to the DT 32-bit
number to refer to a different node.

>
> When it comes to dt bits where I'm uncertain, I usually end up asking Rob
> though :).
>

Rob, can you help us out here?  Beers are on me at SFO15 ;)

-Christoffer