Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966117AbbD2PPk (ORCPT ); Wed, 29 Apr 2015 11:15:40 -0400 Received: from foss.arm.com ([217.140.101.70]:33515 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933223AbbD2PPi (ORCPT ); Wed, 29 Apr 2015 11:15:38 -0400 Date: Wed, 29 Apr 2015 16:15:28 +0100 From: Mark Rutland To: Geert Uytterhoeven Cc: Geert Uytterhoeven , Rob Herring , Pawel Moll , Ian Campbell , Kumar Gala , Marc Zyngier , "devicetree@vger.kernel.org" , "linux-pm@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-sh@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Magnus Damm Subject: Re: [PATCH] ARM: gic: Document Power and Clock Domain optional properties Message-ID: <20150429151527.GA8781@leverpostej> References: <1430146811-29862-1-git-send-email-geert+renesas@glider.be> <20150427155427.GB16191@leverpostej> <20150427171502.GD16191@leverpostej> <20150429125703.GB11757@leverpostej> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3995 Lines: 113 Hi Geert, > >> >> > I'm also concerned that the carving up of clock inputs, power domains, > >> >> > and other physical details is implementation-specific. I imagine that > >> >> > pretty much every user that will care about this is using GIC-400, so > >> >> > could we make this specific to GIC-400? > >> >> > >> >> I have no idea which GIC version is being used. > >> > > >> > This is unfortunate. > >> > > >> >> This is for Renesas R-Mobile APE6 (r8a73a4) and various R-Car Gen2. > >> >> According to the DTS, they're compatible with "arm,cortex-a15-gic" and > >> >> "arm,cortex-a7-gic", and work with that value. > >> > > >> > Who put the DT together in the first place? > >> > >> Magnus (added to CC). > >> > >> > If it's a multi-cluster SoC then we know that we're not using any > >> > built-in distributor... > >> > >> R-Mobile APE6 has 2 clusters (4xCA15 and 4xCA7). > >> R-Car Gen2 has 1 or 2 clusters (2/4xCA15 and/or 2/4xCA7). > > > > It looks like we should be able to read the GICD_IIDR to figure out what > > imlpementation is used. Could you see what GICD_IIDR reports on those > > platforms? There's a patch at the end of the email to do so. > > Thanks! > > - R-Mobile APE6 (r8a73a4): GICD_IIDR reports 0x0200043b > - R-Car Gen M2-W (r8a7791): GICD_IIDR reports 0x0200043b > > ProductID = 0x02 (GIC-400) > Variant = 0x0 > Revision = 0x0 > Implementer = 0x43b (ARM) > > So both are GIC-400 (in the mean time I found a reference to GIC-400 in > the APE6 docs). Ok. We already support the "arm,gic-400" compatible string, so these could be moved over, and given a CLK clock input. > I also ran it on a few other SoCs: > > - SH-Mobile AG5 (sh73a0): GICD_IIDR reports 0x0102043b > > Implementation version = 0x01 (Cortex-A9 MPCore) > Revision number = 0x020 > Implementer = 0x43b (ARM) > > Which GIC is that? That seems to be a GIC internal to the A9 MPCore, so "arm,cortex-a9-gic" is fine for this. It seems to take separate PERIPHCLK and PERIPHCLKEN clock inputs, though it's not clear to be from the TRM whether PERIPHCLKEN is generated internally from PERIPHCLK, or if it needs to be generated by an external clock controller. > - R-Mobile A1 (r8a7740): GICD_IIDR reports 0x0000043b > > ProductID = 0x00 (GIC-500 or Cortex-A15 MPCore or PL390) > Variant = 0x0 > Revision = 0x0 > Implementer = 0x43b (ARM) > > Seems like 0x0000043b can mean multiple things. Docs say PL390 r0p0. We might want to add an "arm,pl390" compatible string for this. The PL390 seems to take a single "gclk" clock input. > > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c > > index 7b315e3..02c8bb4 100644 > > --- a/drivers/irqchip/irq-gic.c > > +++ b/drivers/irqchip/irq-gic.c > > @@ -959,6 +959,7 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start, > > irq_hw_number_t hwirq_base; > > struct gic_chip_data *gic; > > int gic_irqs, irq_base, i; > > + unsigned long iidr; > > > > BUG_ON(gic_nr >= MAX_GIC_NR); > > > > @@ -996,6 +997,9 @@ void __init gic_init_bases(unsigned int gic_nr, int irq_start, > > gic_set_base_accessor(gic, gic_get_common_base); > > } > > > > + iidr = readl_relaxed(gic_data_dist_base(gic) + GIC_DIST_IIDR); > > + pr_info("GICD_IIDR reports 0x%08lx\n", (unsigned long)iidr); > > No need for the cast. For arm64 there is ;) > Perhaps just > > pr_debug("GICD_IIDR reports 0x%08lx\n", > readl_relaxed(gic_data_dist_base(gic) + GIC_DIST_IIDR)); I could fold the read in, but with the cast it was either overly long or weirdly formatted. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/