[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56EC4A92.2090908@ti.com>
Date: Fri, 18 Mar 2016 20:36:02 +0200
From: Grygorii Strashko <grygorii.strashko@...com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
CC: Jon Hunter <jonathanh@...dia.com>,
Thomas Gleixner <tglx@...utronix.de>,
Jason Cooper <jason@...edaemon.net>,
Marc Zyngier <marc.zyngier@....com>,
BenoƮt Cousson <bcousson@...libre.com>,
Tony Lindgren <tony@...mide.com>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Stephen Warren <swarren@...dotorg.org>,
Thierry Reding <thierry.reding@...il.com>,
Kevin Hilman <khilman@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>,
Linus Walleij <linus.walleij@...aro.org>,
<linux-tegra@...r.kernel.org>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 14/15] dt-bindings: arm-gic: Drop 'clock-names' from
binding document
On 03/18/2016 03:02 PM, Geert Uytterhoeven wrote:
> Hi Grygorii,
>
> On Fri, Mar 18, 2016 at 1:47 PM, Grygorii Strashko
> <grygorii.strashko@...com> wrote:
>> On 03/18/2016 02:05 PM, Geert Uytterhoeven wrote:
>>> On Fri, Mar 18, 2016 at 11:56 AM, Jon Hunter <jonathanh@...dia.com> wrote:
>>>> On 18/03/16 10:52, Geert Uytterhoeven wrote:
>>>>> On Fri, Mar 18, 2016 at 11:13 AM, Jon Hunter <jonathanh@...dia.com> wrote:
>>>>>> On 18/03/16 09:13, Geert Uytterhoeven wrote:
>>>>>>> On Thu, Mar 17, 2016 at 3:19 PM, Jon Hunter <jonathanh@...dia.com> wrote:
>>>>>>>> Commit afbbd2338176 ("irqchip/gic: Document optional Clock and Power
>>>>>>>> Domain properties") documented optional clock and power-dmoain properties
>>>>>>>> for the ARM GIC. Currently, there are no users of these and for the
>>>>>>>> Tegra210 Audio GIC (based upon the GIC-400) there are two clocks, a
>>>>>>>> functional clock and interface clock, that need to be enabled.
>>>>>>>
>>>>>>> The reason that there are no users for this is twofold:
>>>>>>> 1. The GIC driver doesn't have Runtime PM support yet,
>>>>>>> 2. There was no clean way to prevent the GIC's clock from being disabled.
>>>>>>> Due to this, adding the clocks to the DTSes would mean that they will be
>>>>>>> disabled during boot up as unused clocks, leading to a system lock-up.
>>>>>>>
>>>>>>> I had hoped your series would fix part 1. I gave it a try on r8a7791/koelsch,
>>>>>>> but unfortunately it seems the platform driver only supports non-root
>>>>>>> controllers, while the r8a7791 GIC is the primary one...
>>>>>>
>>>>>> Can you try making the following change ...
>>>>>
>>>>> Thanks! I gave it a try, but no difference.
>>>>
>>>> I assume you added the appropriate compatible flag? Any more details you
>>>
>>> Doh... bad assumption... Silly me.
>>>
>>>> can share about why it is not working? Is it not registered early enough?
>>>
>>> With
>>>
>>> + { .compatible = "arm,gic-400", },
>>>
>>> the kernel no longer crashes due to accessing the GIC registers while the
>>> GIC module clock is disabled.
>>>
>>> However, the system doesn't boot completely, and time outs on SPI transfers
>>> make me believe interrupts are not working.
>>> Both with and without "the following change".
>>>
>>
>> Is my assumption correct that you are trying to enable RPM for primary GIC controller?
>
> That's correct.
>
>> If yes it may help to take a look on clocksource drivers which use early_platform_device/driver
>> sh_cmt.c sh_mtu2.c sh_tmu.c
>>
>> The primary interrupt controller is initialized very early init_IRQ->irqchip_init->of_irq_init()
>> (IRQCHIP_DECLARE) and, at least as i can see from st_xxx code, the same case is valid for
>> clocksource devices and it was solved using early_platform_device/drive staff.
>
> The GIC now depends on the clock driver, which may be a real platform driver,
> not initialized from CLK_OF_DECLARE().
Clock need to be accessible, but, seems, there is another issue -
if you will try to use gic_driver by just adding compatible string then,
most probably, gic_init_bases() will be called twice:
1: init_IRQ->irqchip_init->of_irq_init()->__gic_init_bases()->gic_init_bases()
2: gic_probe->gic_init_bases()
And GIC data will be replaced on the fly ;P
>
> Or do you mean to make the clock driver an early platform driver?
I can't say definitely - I've just studied it some time ago, but did not try it by myself.
--
regards,
-grygorii
Powered by blists - more mailing lists