* ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
@ 2016-02-15 8:16 Geert Uytterhoeven
2016-02-15 8:45 ` Marc Zyngier
0 siblings, 1 reply; 6+ messages in thread
From: Geert Uytterhoeven @ 2016-02-15 8:16 UTC (permalink / raw)
To: linux-arm-kernel
Cc Marz Zyngier
Cc Dirk Behme
Cc devicetree
Cc linux-renesas-soc
Drop linux-sh
On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>> >> > + gic: interrupt-controller at 0xf1010000 {
>>> >> + compatible = "arm,gic-400";
>>> >> + #interrupt-cells = <3>;
>>> >> + #address-cells = <0>;
>>> >> + interrupt-controller;
>>> >> + reg = <0x0 0xf1010000 0 0x1000>,
>>> >> + <0x0 0xf1020000 0 0x2000>;
>>> >> + interrupts = <GIC_PPI 9
>>> >> + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>> >> + };
>>> >
>>> > No GICH and GICV?
>>>
>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>
>> See the "GIC virtualization extensions (VGIC)" section in
>> Documentation/devicetree/bindings/arm/gic.txt
>
> DDI0471B_gic400_r0p1_trm.pdf says:
>
> Address range GIC-400 functional block
> A. 0x0000 - 0x0FFF Reserved
> B. 0x1000 - 0x1FFF Distributor
> C. 0x2000 - 0x3FFF CPU interfaces
> D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
> is performing the access
> E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
> selected by address bits [11:9]
> F. 0x6000 - 0x7FFF Virtual CPU interfaces
>
> The DT binding document says:
> 1. The first region is the GIC distributor register base and size.
> 2. The 2nd region is the GIC cpu interface register base and size.
> 3. The first additional region is the GIC virtual interface control register
> base and size.
> 4. The 2nd additional region is the GIC virtual cpu interface register base
> and size.
>
> Matching with the example:
>
> interrupt-controller at 2c001000 {
> compatible = "arm,cortex-a15-gic";
> #interrupt-cells = <3>;
> interrupt-controller;
> reg = <0x2c001000 0x1000>,
> <0x2c002000 0x1000>,
> <0x2c004000 0x2000>,
> <0x2c006000 0x2000>;
> interrupts = <1 9 0xf04>;
> };
>
> This means:
> - reg entry 1. covers address range B,
> - reg entry 2. covers address range C,
> - reg entry 3. covers address ranges D _and_ E,
> - reg entry 4. covers address range F.
>
> On R-Car Gen3, the base addresses are:
>
> Distributor : 0xF101_0000
> CPU interfaces : 0xF102_0000
> Virtual interfaces : 0xF104_0000
> Virtual interfaces : 0xF105_0000
> Virtual CPU interfaces : 0xF106_0000
>
> Note the additional multiplication factor of 16 in the offsets relative to
> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>
> As address ranges D and E are merged in a single reg entry, how is the GIC
> driver supposed to know about this multiplication factor?
>
> Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 6+ messages in thread
* ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
2016-02-15 8:16 ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support) Geert Uytterhoeven
@ 2016-02-15 8:45 ` Marc Zyngier
2016-02-15 10:35 ` Geert Uytterhoeven
0 siblings, 1 reply; 6+ messages in thread
From: Marc Zyngier @ 2016-02-15 8:45 UTC (permalink / raw)
To: linux-arm-kernel
On 15/02/16 08:16, Geert Uytterhoeven wrote:
> Cc Marz Zyngier
> Cc Dirk Behme
> Cc devicetree
> Cc linux-renesas-soc
> Drop linux-sh
>
> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>>>>> + gic: interrupt-controller at 0xf1010000 {
>>>>>> + compatible = "arm,gic-400";
>>>>>> + #interrupt-cells = <3>;
>>>>>> + #address-cells = <0>;
>>>>>> + interrupt-controller;
>>>>>> + reg = <0x0 0xf1010000 0 0x1000>,
>>>>>> + <0x0 0xf1020000 0 0x2000>;
>>>>>> + interrupts = <GIC_PPI 9
>>>>>> + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>> + };
>>>>>
>>>>> No GICH and GICV?
>>>>
>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>
>>> See the "GIC virtualization extensions (VGIC)" section in
>>> Documentation/devicetree/bindings/arm/gic.txt
>>
>> DDI0471B_gic400_r0p1_trm.pdf says:
>>
>> Address range GIC-400 functional block
>> A. 0x0000 - 0x0FFF Reserved
>> B. 0x1000 - 0x1FFF Distributor
>> C. 0x2000 - 0x3FFF CPU interfaces
>> D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>> is performing the access
>> E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>> selected by address bits [11:9]
>> F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>
>> The DT binding document says:
>> 1. The first region is the GIC distributor register base and size.
>> 2. The 2nd region is the GIC cpu interface register base and size.
>> 3. The first additional region is the GIC virtual interface control register
>> base and size.
>> 4. The 2nd additional region is the GIC virtual cpu interface register base
>> and size.
>>
>> Matching with the example:
>>
>> interrupt-controller at 2c001000 {
>> compatible = "arm,cortex-a15-gic";
>> #interrupt-cells = <3>;
>> interrupt-controller;
>> reg = <0x2c001000 0x1000>,
>> <0x2c002000 0x1000>,
>> <0x2c004000 0x2000>,
>> <0x2c006000 0x2000>;
>> interrupts = <1 9 0xf04>;
>> };
>>
>> This means:
>> - reg entry 1. covers address range B,
>> - reg entry 2. covers address range C,
>> - reg entry 3. covers address ranges D _and_ E,
>> - reg entry 4. covers address range F.
>>
>> On R-Car Gen3, the base addresses are:
>>
>> Distributor : 0xF101_0000
>> CPU interfaces : 0xF102_0000
>> Virtual interfaces : 0xF104_0000
>> Virtual interfaces : 0xF105_0000
>> Virtual CPU interfaces : 0xF106_0000
>>
>> Note the additional multiplication factor of 16 in the offsets relative to
>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>
>> As address ranges D and E are merged in a single reg entry, how is the GIC
>> driver supposed to know about this multiplication factor?
The answer is very simple, the GIC driver doesn't give a damn about the
second part of the GICH region, because it is absolutely unusable for
any realistic use-case. Only the banked version of GICH is of any
relevance (the first 512 bytes, in essence).
Aligning the GIC regions on 64kB boundaries is documented in the SBSA
specification, independently of the GIC400 documentation.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 6+ messages in thread
* ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
2016-02-15 8:45 ` Marc Zyngier
@ 2016-02-15 10:35 ` Geert Uytterhoeven
2016-02-15 10:55 ` Marc Zyngier
0 siblings, 1 reply; 6+ messages in thread
From: Geert Uytterhoeven @ 2016-02-15 10:35 UTC (permalink / raw)
To: linux-arm-kernel
Hi Marc,
On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>>>>>> + gic: interrupt-controller at 0xf1010000 {
>>>>>>> + compatible = "arm,gic-400";
>>>>>>> + #interrupt-cells = <3>;
>>>>>>> + #address-cells = <0>;
>>>>>>> + interrupt-controller;
>>>>>>> + reg = <0x0 0xf1010000 0 0x1000>,
>>>>>>> + <0x0 0xf1020000 0 0x2000>;
>>>>>>> + interrupts = <GIC_PPI 9
>>>>>>> + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>>> + };
>>>>>>
>>>>>> No GICH and GICV?
>>>>>
>>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>>
>>>> See the "GIC virtualization extensions (VGIC)" section in
>>>> Documentation/devicetree/bindings/arm/gic.txt
>>>
>>> DDI0471B_gic400_r0p1_trm.pdf says:
>>>
>>> Address range GIC-400 functional block
>>> A. 0x0000 - 0x0FFF Reserved
>>> B. 0x1000 - 0x1FFF Distributor
>>> C. 0x2000 - 0x3FFF CPU interfaces
>>> D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>>> is performing the access
>>> E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>> selected by address bits [11:9]
>>> F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>>
>>> The DT binding document says:
>>> 1. The first region is the GIC distributor register base and size.
>>> 2. The 2nd region is the GIC cpu interface register base and size.
>>> 3. The first additional region is the GIC virtual interface control register
>>> base and size.
>>> 4. The 2nd additional region is the GIC virtual cpu interface register base
>>> and size.
>>>
>>> Matching with the example:
>>>
>>> interrupt-controller at 2c001000 {
>>> compatible = "arm,cortex-a15-gic";
>>> #interrupt-cells = <3>;
>>> interrupt-controller;
>>> reg = <0x2c001000 0x1000>,
>>> <0x2c002000 0x1000>,
>>> <0x2c004000 0x2000>,
>>> <0x2c006000 0x2000>;
>>> interrupts = <1 9 0xf04>;
>>> };
>>>
>>> This means:
>>> - reg entry 1. covers address range B,
>>> - reg entry 2. covers address range C,
>>> - reg entry 3. covers address ranges D _and_ E,
>>> - reg entry 4. covers address range F.
>>>
>>> On R-Car Gen3, the base addresses are:
>>>
>>> Distributor : 0xF101_0000
>>> CPU interfaces : 0xF102_0000
>>> Virtual interfaces : 0xF104_0000
>>> Virtual interfaces : 0xF105_0000
>>> Virtual CPU interfaces : 0xF106_0000
>>>
>>> Note the additional multiplication factor of 16 in the offsets relative to
>>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>>
>>> As address ranges D and E are merged in a single reg entry, how is the GIC
>>> driver supposed to know about this multiplication factor?
>
> The answer is very simple, the GIC driver doesn't give a damn about the
> second part of the GICH region, because it is absolutely unusable for
> any realistic use-case. Only the banked version of GICH is of any
> relevance (the first 512 bytes, in essence).
>
> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
> specification, independently of the GIC400 documentation.
If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
"GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
"<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
and the first 4 KiB of address range E. I.e.
reg = <0x0 0xf1010000 0 0x1000>,
<0x0 0xf1020000 0 0x2000>,
<0x0 0xf104f000 0 0x2000>,
<0x0 0xf1060000 0 0x2000>;
Is that correct?
Thanks again!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 6+ messages in thread
* ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
2016-02-15 10:35 ` Geert Uytterhoeven
@ 2016-02-15 10:55 ` Marc Zyngier
2016-02-15 18:53 ` Dirk Behme
0 siblings, 1 reply; 6+ messages in thread
From: Marc Zyngier @ 2016-02-15 10:55 UTC (permalink / raw)
To: linux-arm-kernel
On 15/02/16 10:35, Geert Uytterhoeven wrote:
> Hi Marc,
>
> On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>>>>>>> + gic: interrupt-controller at 0xf1010000 {
>>>>>>>> + compatible = "arm,gic-400";
>>>>>>>> + #interrupt-cells = <3>;
>>>>>>>> + #address-cells = <0>;
>>>>>>>> + interrupt-controller;
>>>>>>>> + reg = <0x0 0xf1010000 0 0x1000>,
>>>>>>>> + <0x0 0xf1020000 0 0x2000>;
>>>>>>>> + interrupts = <GIC_PPI 9
>>>>>>>> + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>>>> + };
>>>>>>>
>>>>>>> No GICH and GICV?
>>>>>>
>>>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>>>
>>>>> See the "GIC virtualization extensions (VGIC)" section in
>>>>> Documentation/devicetree/bindings/arm/gic.txt
>>>>
>>>> DDI0471B_gic400_r0p1_trm.pdf says:
>>>>
>>>> Address range GIC-400 functional block
>>>> A. 0x0000 - 0x0FFF Reserved
>>>> B. 0x1000 - 0x1FFF Distributor
>>>> C. 0x2000 - 0x3FFF CPU interfaces
>>>> D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>>>> is performing the access
>>>> E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>>> selected by address bits [11:9]
>>>> F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>>>
>>>> The DT binding document says:
>>>> 1. The first region is the GIC distributor register base and size.
>>>> 2. The 2nd region is the GIC cpu interface register base and size.
>>>> 3. The first additional region is the GIC virtual interface control register
>>>> base and size.
>>>> 4. The 2nd additional region is the GIC virtual cpu interface register base
>>>> and size.
>>>>
>>>> Matching with the example:
>>>>
>>>> interrupt-controller at 2c001000 {
>>>> compatible = "arm,cortex-a15-gic";
>>>> #interrupt-cells = <3>;
>>>> interrupt-controller;
>>>> reg = <0x2c001000 0x1000>,
>>>> <0x2c002000 0x1000>,
>>>> <0x2c004000 0x2000>,
>>>> <0x2c006000 0x2000>;
>>>> interrupts = <1 9 0xf04>;
>>>> };
>>>>
>>>> This means:
>>>> - reg entry 1. covers address range B,
>>>> - reg entry 2. covers address range C,
>>>> - reg entry 3. covers address ranges D _and_ E,
>>>> - reg entry 4. covers address range F.
>>>>
>>>> On R-Car Gen3, the base addresses are:
>>>>
>>>> Distributor : 0xF101_0000
>>>> CPU interfaces : 0xF102_0000
>>>> Virtual interfaces : 0xF104_0000
>>>> Virtual interfaces : 0xF105_0000
>>>> Virtual CPU interfaces : 0xF106_0000
>>>>
>>>> Note the additional multiplication factor of 16 in the offsets relative to
>>>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>>>
>>>> As address ranges D and E are merged in a single reg entry, how is the GIC
>>>> driver supposed to know about this multiplication factor?
>>
>> The answer is very simple, the GIC driver doesn't give a damn about the
>> second part of the GICH region, because it is absolutely unusable for
>> any realistic use-case. Only the banked version of GICH is of any
>> relevance (the first 512 bytes, in essence).
>>
>> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
>> specification, independently of the GIC400 documentation.
>
> If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
> "GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
> "<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
> and the first 4 KiB of address range E. I.e.
>
> reg = <0x0 0xf1010000 0 0x1000>,
> <0x0 0xf1020000 0 0x2000>,
> <0x0 0xf104f000 0 0x2000>,
> <0x0 0xf1060000 0 0x2000>;
>
> Is that correct?
My preference would be to expose the full 128kB of the region - assuming
your HW actually supports the SBSA aliasing.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 6+ messages in thread
* ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
2016-02-15 10:55 ` Marc Zyngier
@ 2016-02-15 18:53 ` Dirk Behme
2016-02-15 18:57 ` Marc Zyngier
0 siblings, 1 reply; 6+ messages in thread
From: Dirk Behme @ 2016-02-15 18:53 UTC (permalink / raw)
To: linux-arm-kernel
On 15.02.2016 11:55, Marc Zyngier wrote:
> On 15/02/16 10:35, Geert Uytterhoeven wrote:
>> Hi Marc,
>>
>> On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>>>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>>>>>>>> + gic: interrupt-controller at 0xf1010000 {
>>>>>>>>> + compatible = "arm,gic-400";
>>>>>>>>> + #interrupt-cells = <3>;
>>>>>>>>> + #address-cells = <0>;
>>>>>>>>> + interrupt-controller;
>>>>>>>>> + reg = <0x0 0xf1010000 0 0x1000>,
>>>>>>>>> + <0x0 0xf1020000 0 0x2000>;
>>>>>>>>> + interrupts = <GIC_PPI 9
>>>>>>>>> + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>>>>> + };
>>>>>>>>
>>>>>>>> No GICH and GICV?
>>>>>>>
>>>>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>>>>
>>>>>> See the "GIC virtualization extensions (VGIC)" section in
>>>>>> Documentation/devicetree/bindings/arm/gic.txt
>>>>>
>>>>> DDI0471B_gic400_r0p1_trm.pdf says:
>>>>>
>>>>> Address range GIC-400 functional block
>>>>> A. 0x0000 - 0x0FFF Reserved
>>>>> B. 0x1000 - 0x1FFF Distributor
>>>>> C. 0x2000 - 0x3FFF CPU interfaces
>>>>> D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>>>>> is performing the access
>>>>> E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>>>> selected by address bits [11:9]
>>>>> F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>>>>
>>>>> The DT binding document says:
>>>>> 1. The first region is the GIC distributor register base and size.
>>>>> 2. The 2nd region is the GIC cpu interface register base and size.
>>>>> 3. The first additional region is the GIC virtual interface control register
>>>>> base and size.
>>>>> 4. The 2nd additional region is the GIC virtual cpu interface register base
>>>>> and size.
>>>>>
>>>>> Matching with the example:
>>>>>
>>>>> interrupt-controller at 2c001000 {
>>>>> compatible = "arm,cortex-a15-gic";
>>>>> #interrupt-cells = <3>;
>>>>> interrupt-controller;
>>>>> reg = <0x2c001000 0x1000>,
>>>>> <0x2c002000 0x1000>,
>>>>> <0x2c004000 0x2000>,
>>>>> <0x2c006000 0x2000>;
>>>>> interrupts = <1 9 0xf04>;
>>>>> };
>>>>>
>>>>> This means:
>>>>> - reg entry 1. covers address range B,
>>>>> - reg entry 2. covers address range C,
>>>>> - reg entry 3. covers address ranges D _and_ E,
>>>>> - reg entry 4. covers address range F.
>>>>>
>>>>> On R-Car Gen3, the base addresses are:
>>>>>
>>>>> Distributor : 0xF101_0000
>>>>> CPU interfaces : 0xF102_0000
>>>>> Virtual interfaces : 0xF104_0000
>>>>> Virtual interfaces : 0xF105_0000
>>>>> Virtual CPU interfaces : 0xF106_0000
>>>>>
>>>>> Note the additional multiplication factor of 16 in the offsets relative to
>>>>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>>>>
>>>>> As address ranges D and E are merged in a single reg entry, how is the GIC
>>>>> driver supposed to know about this multiplication factor?
>>>
>>> The answer is very simple, the GIC driver doesn't give a damn about the
>>> second part of the GICH region, because it is absolutely unusable for
>>> any realistic use-case. Only the banked version of GICH is of any
>>> relevance (the first 512 bytes, in essence).
>>>
>>> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
>>> specification, independently of the GIC400 documentation.
>>
>> If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
>> "GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
>> "<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
>> and the first 4 KiB of address range E. I.e.
>>
>> reg = <0x0 0xf1010000 0 0x1000>,
>> <0x0 0xf1020000 0 0x2000>,
>> <0x0 0xf104f000 0 0x2000>,
>> <0x0 0xf1060000 0 0x2000>;
>>
>> Is that correct?
>
> My preference would be to expose the full 128kB of the region
That would be
<0x0 0xf1040000 0 0x20000>
then? Ok?
Best regards
Dirk
^ permalink raw reply [flat|nested] 6+ messages in thread
* ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support)
2016-02-15 18:53 ` Dirk Behme
@ 2016-02-15 18:57 ` Marc Zyngier
0 siblings, 0 replies; 6+ messages in thread
From: Marc Zyngier @ 2016-02-15 18:57 UTC (permalink / raw)
To: linux-arm-kernel
On 15/02/16 18:53, Dirk Behme wrote:
> On 15.02.2016 11:55, Marc Zyngier wrote:
>> On 15/02/16 10:35, Geert Uytterhoeven wrote:
>>> Hi Marc,
>>>
>>> On Mon, Feb 15, 2016 at 9:45 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>>>> On 15/02/16 08:16, Geert Uytterhoeven wrote:
>>>>> On Wed, Dec 9, 2015 at 9:23 AM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>>>>> On Tue, Nov 3, 2015 at 3:28 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>>>>> On Wed, Oct 21, 2015 at 03:34:39PM +0200, Geert Uytterhoeven wrote:
>>>>>>>> On Thu, Oct 15, 2015 at 12:58 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>>>>>>>>>>> + gic: interrupt-controller at 0xf1010000 {
>>>>>>>>>> + compatible = "arm,gic-400";
>>>>>>>>>> + #interrupt-cells = <3>;
>>>>>>>>>> + #address-cells = <0>;
>>>>>>>>>> + interrupt-controller;
>>>>>>>>>> + reg = <0x0 0xf1010000 0 0x1000>,
>>>>>>>>>> + <0x0 0xf1020000 0 0x2000>;
>>>>>>>>>> + interrupts = <GIC_PPI 9
>>>>>>>>>> + (GIC_CPU_MASK_SIMPLE(1) | IRQ_TYPE_LEVEL_HIGH)>;
>>>>>>>>>> + };
>>>>>>>>>
>>>>>>>>> No GICH and GICV?
>>>>>>>>
>>>>>>>> These seem to be defined in the "arm,gic-v3" DT bindings only, while this is
>>>>>>>> an "arm,gic-400" (GICD_IIDR 0x0200043b)?
>>>>>>>
>>>>>>> See the "GIC virtualization extensions (VGIC)" section in
>>>>>>> Documentation/devicetree/bindings/arm/gic.txt
>>>>>>
>>>>>> DDI0471B_gic400_r0p1_trm.pdf says:
>>>>>>
>>>>>> Address range GIC-400 functional block
>>>>>> A. 0x0000 - 0x0FFF Reserved
>>>>>> B. 0x1000 - 0x1FFF Distributor
>>>>>> C. 0x2000 - 0x3FFF CPU interfaces
>>>>>> D. 0x4000 - 0x4FFF Virtual interface control block, for the processor that
>>>>>> is performing the access
>>>>>> E. 0x5000 - 0x5FFF Virtual interface control block, for the processor
>>>>>> selected by address bits [11:9]
>>>>>> F. 0x6000 - 0x7FFF Virtual CPU interfaces
>>>>>>
>>>>>> The DT binding document says:
>>>>>> 1. The first region is the GIC distributor register base and size.
>>>>>> 2. The 2nd region is the GIC cpu interface register base and size.
>>>>>> 3. The first additional region is the GIC virtual interface control register
>>>>>> base and size.
>>>>>> 4. The 2nd additional region is the GIC virtual cpu interface register base
>>>>>> and size.
>>>>>>
>>>>>> Matching with the example:
>>>>>>
>>>>>> interrupt-controller at 2c001000 {
>>>>>> compatible = "arm,cortex-a15-gic";
>>>>>> #interrupt-cells = <3>;
>>>>>> interrupt-controller;
>>>>>> reg = <0x2c001000 0x1000>,
>>>>>> <0x2c002000 0x1000>,
>>>>>> <0x2c004000 0x2000>,
>>>>>> <0x2c006000 0x2000>;
>>>>>> interrupts = <1 9 0xf04>;
>>>>>> };
>>>>>>
>>>>>> This means:
>>>>>> - reg entry 1. covers address range B,
>>>>>> - reg entry 2. covers address range C,
>>>>>> - reg entry 3. covers address ranges D _and_ E,
>>>>>> - reg entry 4. covers address range F.
>>>>>>
>>>>>> On R-Car Gen3, the base addresses are:
>>>>>>
>>>>>> Distributor : 0xF101_0000
>>>>>> CPU interfaces : 0xF102_0000
>>>>>> Virtual interfaces : 0xF104_0000
>>>>>> Virtual interfaces : 0xF105_0000
>>>>>> Virtual CPU interfaces : 0xF106_0000
>>>>>>
>>>>>> Note the additional multiplication factor of 16 in the offsets relative to
>>>>>> the base address 0xf1000000 (e.g. 0x50000 instead of 0x5000).
>>>>>>
>>>>>> As address ranges D and E are merged in a single reg entry, how is the GIC
>>>>>> driver supposed to know about this multiplication factor?
>>>>
>>>> The answer is very simple, the GIC driver doesn't give a damn about the
>>>> second part of the GICH region, because it is absolutely unusable for
>>>> any realistic use-case. Only the banked version of GICH is of any
>>>> relevance (the first 512 bytes, in essence).
>>>>
>>>> Aligning the GIC regions on 64kB boundaries is documented in the SBSA
>>>> specification, independently of the GIC400 documentation.
>>>
>>> If I understand the SBSA spec correctly (BTW, arm,gic.txt doesn't use the
>>> "GICC" terminology, unlike arm,gic-v3.txt), that means reg entry 3 should be
>>> "<0xf104f000 0x2000>", so it covers the aliased last 4 KiB of address range D,
>>> and the first 4 KiB of address range E. I.e.
>>>
>>> reg = <0x0 0xf1010000 0 0x1000>,
>>> <0x0 0xf1020000 0 0x2000>,
>>> <0x0 0xf104f000 0 0x2000>,
>>> <0x0 0xf1060000 0 0x2000>;
>>>
>>> Is that correct?
>>
>> My preference would be to expose the full 128kB of the region
>
>
> That would be
>
> <0x0 0xf1040000 0 0x20000>
>
> then? Ok?
Exactly.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-02-15 18:57 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-15 8:16 ARM GIC DT binding reg block mismatch? (Re: [PATCH v11 1/8] arm64: renesas: r8a7795: Add Renesas R8A7795 SoC support) Geert Uytterhoeven
2016-02-15 8:45 ` Marc Zyngier
2016-02-15 10:35 ` Geert Uytterhoeven
2016-02-15 10:55 ` Marc Zyngier
2016-02-15 18:53 ` Dirk Behme
2016-02-15 18:57 ` Marc Zyngier
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).