On 10-Apr-2014, at 4:11 pm, Marc Zyngier <marc.zyng...@arm.com> wrote:
> On Thu, Apr 10 2014 at 11:30:41 am BST, armdev <armdev....@gmail.com> wrote: >> On 10-Apr-2014, at 3:51 pm, Marc Zyngier <marc.zyng...@arm.com> wrote: >> >>> On Thu, Apr 10 2014 at 11:09:02 am BST, armdev <armdev....@gmail.com> wrote: >>>> On 10-Apr-2014, at 3:34 pm, Marc Zyngier <marc.zyng...@arm.com> wrote: >>>> >>>>> On Thu, Apr 10 2014 at 10:28:24 am BST, Chanwoo Choi >>>>> <cw00.c...@samsung.com> wrote: >>>>>> This patch declare coretex-a7's irqchip to initialze gic from dt >>>>>> with "arm,cortex-a7-gic" data. >>>>>> >>>>>> Cc: Thomas Gleixner <t...@linutronix.de> >>>>>> Signed-off-by: Chanwoo Choi <cw00.c...@samsung.com> >>>>>> Signed-off-by: Kyungmin Park <kyungmin.p...@samsung.com> >>>>>> --- >>>>>> 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
