[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1498754384.2378.10.camel@synopsys.com>
Date: Thu, 29 Jun 2017 16:39:45 +0000
From: Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
To: "robh@...nel.org" <robh@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Vineet.Gupta1@...opsys.com" <Vineet.Gupta1@...opsys.com>,
"Eugeniy.Paltsev@...opsys.com" <Eugeniy.Paltsev@...opsys.com>,
"Alexey.Brodkin@...opsys.com" <Alexey.Brodkin@...opsys.com>,
"linux-snps-arc@...ts.infradead.org"
<linux-snps-arc@...ts.infradead.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 3/3 v6] ARC: hsdk: initial port for HSDK board
On Wed, 2017-06-28 at 17:50 -0500, Rob Herring wrote:
> > > > + #clock-cells = <0>;
> > > > + compatible = "fixed-clock";
> > > > + clock-frequency = <1000000000>;
> > > > + };
> > > > +
> > > > + core_intc: archs-intc@cpu {
> > >
> > > cpu is not a valid unit-address. How are these interrupt
> > > controllers addressed?
> >
> > We have per-core INTC so each core communicates to its own INTC and
> > there's no way
> > for any core to talk with INTC of another core.
> >
> > But then we have the next level INTC which is IDU (Interrupt
> > Distribution Unit)
> > which dispatches "common" IRQs to different upstream per-core INTC,
> > see below its node.
>
> Okay, I'd just do "cpu-interrupt-controller" for the node name then.
> There doesn't seem to be an easy way to use just "interrupt-
> controller"
> since you have 2 nodes at the same level and no unit-address (i.e. a
> reg property).
>
To be more clarify, what is better way do describe such hardware in
device tree?
------------- -------------
| cpu core 0| | cpu core 1|
------------- -------------
| interrupt | | interrupt |
| controller| | controller|
| 0 | | 1 |
------------- -------------
^ ^
| |
-----------
| |
----------------
| interrupt |
| distribution |
| unit |
----------------
^
|
|<--other devices interrupt lines
We can't just create a node for each core interrupt controller because
we wouldn't able to specify which one is parent for interrupt
distribution unit:
------------>>>-------------
cpus {
cpu@0 { intc@0 };
cpu@1 { intc@1 };
};
interrupt-distribution-unit {
interrupt-parent = ????
};
------------>>>-------------
Should we simply create one core interrupt controller node for all cpus
(instead of one per each cpu core), or where is a better option?
--
Eugeniy Paltsev
Powered by blists - more mailing lists