[PATCH 5/5] ARM: gic: add OF based initialization

Grant Likely grant.likely at secretlab.ca
Mon Sep 19 20:22:15 EDT 2011

On Mon, Sep 19, 2011 at 3:53 PM, Rob Herring <robherring2 at gmail.com> wrote:
> On 09/19/2011 04:14 PM, Grant Likely wrote:
>> * ARM Generic Interrupt Controller
>> ARM SMP cores are often associated with a GIC, providing per processor
>> interrupts (PPI), shared processor interrupts (SPI) and software
>> generated interrupts (SGI).
>> Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>> Secondary GICs are cascaded into the upward interrupt controller and do not
>> have PPIs or SGIs.
>> Main node required properties:
>> - compatible : should be one of:
>>        "arm,cortex-a9-gic"
>>        "arm,arm11mp-gic"
>> - interrupt-controller : Identifies the node as an interrupt controller
>> - #interrupt-cells : Specifies the number of cells needed to encode an
>>   interrupt source.  The type shall be a <u32> and the value shall be 3.
>>   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
>> interrupts.
>>   The 2nd cell contains the interrupt number for the interrupt type.
>> SPI interrupts are in the range [0-987].  PPI interrupts are in the
>> range [0-15].
>>   The 3rd cell is the flags, encoded as follows:
>>         bits[3:0] trigger type and level flags.
>>                     1 = low-to-high edge triggered
>>                     2 = high-to-low edge triggered
>>                     4 = active high level-sensitive
>>                     8 = active low level-sensitive
>>         bits[15:8] PPI interrupt cpu mask.  Each bit corresponds to
>> each of the 8 possible cpus attached to the GIC.  A bit set to '1'
>> indicated the interrupt is wired to that CPU.  Only valid for PPI
>> interrupts.
> How about a cpu mask of 0 means SPI and non-zero means PPI? Then we can
> drop the first cell.

Cells are cheap, and it is better to be explicit.  It is certainly
easier to extend in the future too if the type cell is used.


More information about the linux-arm-kernel mailing list