Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753534AbcD0PfF (ORCPT ); Wed, 27 Apr 2016 11:35:05 -0400 Received: from hqemgate16.nvidia.com ([216.228.121.65]:3567 "EHLO hqemgate16.nvidia.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752297AbcD0PfA (ORCPT ); Wed, 27 Apr 2016 11:35:00 -0400 X-PGP-Universal: processed; by hqnvupgp07.nvidia.com on Wed, 27 Apr 2016 08:34:26 -0700 Subject: Re: [PATCH V2 13/14] dt-bindings: arm-gic: Add documentation for Tegra210 AGIC To: Mark Rutland References: <1461150237-15580-1-git-send-email-jonathanh@nvidia.com> <1461150237-15580-14-git-send-email-jonathanh@nvidia.com> <20160422100052.GA10606@leverpostej> <571A0739.3090502@nvidia.com> <20160422112239.GF10606@leverpostej> CC: Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , "Pawel Moll" , Ian Campbell , Kumar Gala , Stephen Warren , Thierry Reding , Kevin Hilman , Geert Uytterhoeven , Grygorii Strashko , Lars-Peter Clausen , "Linus Walleij" , , , , From: Jon Hunter Message-ID: <5720DC1D.1080802@nvidia.com> Date: Wed, 27 Apr 2016 16:34:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160422112239.GF10606@leverpostej> X-Originating-IP: [10.21.132.106] X-ClientProxiedBy: UKMAIL101.nvidia.com (10.26.138.13) To UKMAIL101.nvidia.com (10.26.138.13) Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2795 Lines: 69 On 22/04/16 12:22, Mark Rutland wrote: [snip] >>>> I am not sure if it will be popular to add Tegra specific clock names >>>> to the GIC DT docs. However, in that case, then possibly the only >>>> alternative is to move the Tegra AGIC driver into its own file and >>>> expose the GIC APIs for it to use. Then we could add our own DT doc >>>> for the Tegra AGIC as well (based upon the ARM GIC). >>> >>> The clock-names don't seem right to me, as they sound like provide names >>> or global clock line names rather than consumer-side names ("clk" and >>> "apb_pclk"). >> >> Yes that would be fine with me. > > Ok; if we model the apb_pclk as owned by the AXI switch (which it is), > then there's no change for the GIC binding, short of the additional > compatible string as an extension of "arm,gic-400", as we already model > that clock in the GIC-400 binding. I have been re-working this based upon the feedback received. In the GIC driver we have the following definitions ... IRQCHIP_DECLARE(gic_400, "arm,gic-400", gic_of_init); IRQCHIP_DECLARE(arm11mp_gic, "arm,arm11mp-gic", gic_of_init); IRQCHIP_DECLARE(arm1176jzf_dc_gic, "arm,arm1176jzf-devchip-gic", gic_of_init); 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); IRQCHIP_DECLARE(pl390, "arm,pl390", gic_of_init); If I have something like the following in my dts ... agic: interrupt-controller@702f9000 { compatible = "nvidia,tegra210-agic", "arm,gic-400"; ... }; The problem with this is that it tries to register the interrupt controller early during of_irq_init() before the platform driver has chance to initialise it. To avoid this I got rid of the "nvidia,tegra210-agic" string and added the following for the platform driver ... static const struct of_device_id gic_match[] = { { .compatible = "arm,arm11mp-gic-pm", .data = &arm11mp_gic_data }, { .compatible = "arm,cortex-a15-gic-pm", .data = &cortexa15_gic_data }, { .compatible = "arm,cortex-a9-gic-pm", .data = &cortexa9_gic_data }, { .compatible = "arm,gic400-pm", .data = &gic400_data }, { .compatible = "arm,pl390-pm", .data = &pl390_data }, {}, }; It is not ideal as now we have a *-pm variant of each compatible string :-( Another option would be to add some code in gic_of_init() to check for the presence of a "clocks" node in the DT binding and bail out of the early initialisation if found but may be that is a bit of a hack. Mark, what are your thoughts on this? Cheers Jon