Re: [PATCH 07/27] irqchip: Declare cortex-a7's irqchip to initialize gic from dt

[armdev]

On 10-Apr-2014, at 4:11 pm, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:

> On Thu, Apr 10 2014 at 11:30:41 am BST, armdev <armdev.ftm@xxxxxxxxx> wrote:
>> On 10-Apr-2014, at 3:51 pm, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
>> 
>>> On Thu, Apr 10 2014 at 11:09:02 am BST, armdev <armdev.ftm@xxxxxxxxx> wrote:
>>>> On 10-Apr-2014, at 3:34 pm, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
>>>> 
>>>>> On Thu, Apr 10 2014 at 10:28:24 am BST, Chanwoo Choi <cw00.choi@xxxxxxxxxxx> wrote:
>>>>>> This patch declare coretex-a7's irqchip to initialze gic from dt
>>>>>> with "arm,cortex-a7-gic" data.
>>>>>> 
>>>>>> Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
>>>>>> Signed-off-by: Chanwoo Choi <cw00.choi@xxxxxxxxxxx>
>>>>>> Signed-off-by: Kyungmin Park <kyungmin.park@xxxxxxxxxxx>
>>>>>> ---
>>>>>> drivers/irqchip/irq-gic.c | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>> 
>>>>>> diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
>>>>>> index 4300b66..8e906e4 100644
>>>>>> --- a/drivers/irqchip/irq-gic.c
>>>>>> +++ b/drivers/irqchip/irq-gic.c
>>>>>> @@ -1069,6 +1069,7 @@ gic_of_init(struct device_node *node, struct device_node *parent)
>>>>>> }
>>>>>> IRQCHIP_DECLARE(cortex_a15_gic, "arm,cortex-a15-gic", gic_of_init);
>>>>>> IRQCHIP_DECLARE(cortex_a9_gic, "arm,cortex-a9-gic", gic_of_init);
>>>>>> +IRQCHIP_DECLARE(cortex_a7_gic, "arm,cortex-a7-gic", gic_of_init);
>>>>>> IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic", gic_of_init);
>>>>>> IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
>>>>> 
>>>>> Frankly, this patch adds no value. Are we going to add
>>>>> "arm,cortex-a12-gic", "arm,cortex-a17-gic", "arm,cortex-a53-gic",
>>>>> "arm,cortex-a57-gic"? And that's just to mention the ARM Ltd cores...
>>>>> 
>>>>> Instead, how about defining a generic "arm,gic" property, and mandate
>>>>> that new DT files are using that? We can always use a more precise
>>>>> compatible for quirks.
>>>>> 
>>>> 
>>>> How about keeping it simple and tied to arm gic versions
>>>> arm,gicv1, arm,gicv2, arm,gicv2ve
>>> 
>>> That's a variation on the same theme. As for GICv2, we don't need to
>>> distinguish between having the Virtualization Extentions, the binding
>>> already allows you to tell one from the other.
>>> 
>> So if there be just 2 types of gic, it would be simple.
> 
> Not exactly. We just happen to support two revisions of the GIC
> architecture with the same binding. GICv3 has an entierely separate
> binding.
> 
>> gicv1 - 2 address sets (gicc and gicd)
> 
> Yes.
> 
>> gicv2 - 4 sets (gicc gicd gicv gich) and 1 maintenance interrupt. Right?
> 
> No.
> 
> The presence of the GICV, GICH and maintenance interrupt are indicative
> of the support for the Virtualization Extentions. GICv2 itself can
> perfectly be built without it.

then does gicv2-ve makes sense ?
> 
> 	M.
> -- 
> Jazz is not dead. It just smells funny.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/