On 22/04/16 11:00, Mark Rutland wrote:
> On Wed, Apr 20, 2016 at 12:03:56PM +0100, Jon Hunter wrote:
>> The Tegra AGIC interrupt controller is compatible with the ARM GIC-400
>> interrupt controller.
>
> The cover letter says it _is_ a GIC-400, just used in a slightly unusual
> manner (i.e. not directly connected to CPUs).
Correct.
>> The Tegra AGIC requires two clocks, namely the
>> "ape" (functional) and "apb2ape" (interface) clocks, to operate. Add
>> the compatible string and clock information for the AGIC to the GIC
>> device-tree binding documentation.
>
> The GIC-400 spec only describes "CLK" (which is what I imagine "ape" is.
> There isn't an APB clock described, and the manual seems to show GIC-400
> directly connected to AXI rather than APB, so that doesn't seem to even
> be the usual "apb_pclk".
>
> Is there some wrapper logic around a GIC-400 to giove it an APB
> interface? Or am I misudnerstanding the spec?
Looking at the Tegra documentation what we have is ...
APB --> AXI switch --> AGIC (GIC400)
I am not sure how such a switch would typically be modeled in DT but we
need the apb clock to interface to the GIC registers. I am not sure if
something like simple-pm-bus is appropriate here.
>> Signed-off-by: Jon Hunter <jonathanh@xxxxxxxxxx>
>> ---
>>
>> 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.
> I'm also not certain about the compatible string; if this really is a
> GIC-400 then I would at least expect "arm,gic-400" as a fallback.
OK.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
