Re: [PATCH 14/15] dt-bindings: arm-gic: Drop 'clock-names' from binding document

[Jon Hunter]

On 18/03/16 12:05, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Fri, Mar 18, 2016 at 11:56 AM, Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
>> On 18/03/16 10:52, Geert Uytterhoeven wrote:
>>> On Fri, Mar 18, 2016 at 11:13 AM, Jon Hunter <jonathanh@xxxxxxxxxx> wrote:
>>>> On 18/03/16 09:13, Geert Uytterhoeven wrote:
>>>>> On Thu, Mar 17, 2016 at 3:19 PM, Jon Hunter <jonathanh@xxxxxxxxxx> 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".

Yes, I recall now why I did not support primary controllers and it is
because you need to call set_smp_cross_call() (for SMP) and
set_handle_irq(). Both of which are located in the __init section and
need to be called early during boot. So to make this work for primary
controllers, more work would need to be done.

Jon