[RFC PATCH 13/14] ARM: vexpress: Definition of vexpress dts specification

[Grant Likely]

On Mon, Aug 23, 2010 at 9:47 AM, Lorenzo Pieralisi
<Lorenzo.Pieralisi at arm.com> wrote:
> Hi Grant,
>
>> -----Original Message-----
>> From: glikely at secretlab.ca [mailto:glikely at secretlab.ca] On Behalf Of Grant
>> Likely
>> Sent: 20 August 2010 21:32
>> To: Lorenzo Pieralisi
>> Cc: devicetree-discuss at lists.ozlabs.org; Philippe Robin; nico at fluxnic.net;
>> linux at arm.linux.org.uk; Catalin Marinas; jeremy.kerr at canonical.com
>> Subject: Re: [RFC PATCH 13/14] ARM: vexpress: Definition of vexpress dts
>> specification
>>
>> Hi Lorenzo,
>>
>> On Fri, Aug 20, 2010 at 11:51 AM, Lorenzo Pieralisi
>> <Lorenzo.Pieralisi at arm.com> wrote:
>> >> > +               };
>> >> > +
>> >> > +               smsc at 4e000000 {
>> >> > +                       compatible = "smc,smsc-911";
>> >> > +                        reg = <0x4e000000 0x1000>;
>> >> > +                       interrupts = <47>;
>> >>
>> >> I suspect this interrupts property is wrong.  An interrupts specifier
>> >> is specific to the interrupt controller node; so this should always
>> >> specify the interrupt input on a specific controller (either gic-cpu
>> >> or gic-dist in this system).  It looks like '47' is the global irq
>> >> number.  Am I correct?
>> >>
>> >
>> > Strictly related to the previous point.
>> >
>> > When you say input Grant you mean input HW pin or interrupt HW ID ?
>> >
>> > I think you mean the irq ID specific to a given interrupt controller,
>> > because that is what SW sees and controls.
>>
>> I mean HW pin, but see discussion below to make sure we're talking
>> about the same thing.
>>
>> > 47 is the eth interrupt ID on the gic-dist, that in this particular
>> > case becomes the global IRQ number as well if I am not mistaken.
>> > (it is retrieved through the platform device resource).
>> > I think it is correct as it is, but I will countercheck.
>>
>> Okay.  Just to make sure I understand... I see two interrupt
>> controllers in this device tree; gic-cpu and gic-dist.  I'm assuming
>> that each irq controller has N interrupt inputs numbered 0..N-1.  My
>> expectation would be that each device is wired to a single interrupt
>> pin on one of the two controllers.  I also would expect that (unless
>> there are two interrupt input pins on the CPU) one of the irq
>> controllers is cascaded to the other.  Am I correct so far?
>>
>
> Well, it is the fact that I coded them as two controllers which is the
> source of confusion, I apologise but it is good to start discussing
> a proper binding.
> The gic-cpu and gic-dist are two subcomponents of a single
> interrupt controller called GIC. Devices are wired to the gic-dist which
> is in charge of distributing interrupts to the gic-cpu (per cpu IRQ IF).

Ah, so this is really just one device.  It probably makes sense to
describe it with only one interrupt-controller node then.  (Or if it
is a couple of nodes, only one should be declared as an
interrupt-controller.

>> So, if 47 was the hardware input number, that would mean irq-dist had
>> least 48 discrete interrupt inputs (this is actually what had me
>> suspicious; I assumed that that are only 32 inputs on the gic
>> controller but I didn't go and check).
>
> The GIC deals with interrupts through ID numbers, and yes the gic-dist
> can have more than 48 discrete interrupts lines.
> The point is that HW input pin numbers or wires map to irq ID through a shift
> (e.g. HW ID 37 means interrupt pin 5, because the first 32 irq IDs are
> used for SW IRQs and private (to one core) peripheral IRQs).
> That's why I asked if  "interrupts" should represent the HW input pin/line.
> Ethernet interrupt GIC HW ID is 47 (vexpress), but that does not mean
> the eth device irq line is connected to the 47th irq input line in
> the gic-dist because interrupt ID for peripherals start at ID 16
> (and there are two kinds of peripherals, private to a core (ID 16..31)
> or common to all cores, ID 32 onwards).

In general, using the HW input pin number is a good idea because the
device tree data is supposed to describe the hardware.

> TO be honest I do not think we should think in HW interrupt pin terms, in
> this context it is the GIC HW ID that should go into "interrupts"

Hmmm.  You've lost me here.  I'm not catching how HW ID is lining up
with HW interrupt pin number, and so having trouble determining which
is the better value to specify.

> (which in
> turn means we may well end up having two identical "interrupts" values
> on different GICs (cascaded), and that's perfectly fine because
> they are relative to a given controller).

Correct.

>> From the Linux perspective, the hw irq numbers for each controller
>> needs to be mapped onto the flat Linux irq space.  So if gic-cpu has N
>> irqs and gic-dist has M irqs, then the mapping might look something
>> like this:
>>
>> linux irq
>> (0)   == gic-cpu:0
>> (1)   == gic-cpu:1
>> ...
>> (N-2) == gpi-cpu:N-2
>> (N-1) == gpi-cpu:N-1
>> (N)   == gic-dist:0
>> (N+1) == gic-dist:1
>> ...
>> (N+M-2) == gpi-dist:M-2
>> (N+M-1) == gpi-dist:M-1
>>
>> Am I still correct, or have I misunderstood the versatile interrupt
>> controller architecture?
>
> The two components have to be seen as one interrupt controller.
> It is possible we need two "reg" properties since the offset between
> gic-cpu registers and gic-dist ones may differ.
> If there is a board/SoC with two cascaded GICs your reasoning
> above applies, agreed, sorry for having split the single GIC in two
> interrupt controllers, that caused confusion (but it is a RFC
> to define a proper binding 8-) ).

:-)

>> Regardless though, the linux mapping doesn't actually have any bearing
>> on the device tree because the mapping from HW to linux irq number is
>> all internal to the kernel.  The kernel could choose to start the
>> mapping at 42 or somewhere else and it would all still work.  The
>> of_irq support code has all the information it needs to translate an
>> interrupt specifier to an interrupt controller, and then map the
>> number to the linux irq number.
>>
>
> Agreed, and took your point and Warner's. I did not want to code the
> Linux global number in the interrupts property. IMHO that should define
> the GIC HW irq ID and it is not Linux specific, see above.
> But due to the current mapping 47 ends up being the Linux IRQ number
> as well.

"accidental" congruity is perfectly fine; as long as the software
doesn't depend on the congruity continuing to exist in the future.

> It is time I started writing a GIC binding since it is likely to be
> reused for different boards (and gic init code should be factored out
> of board specific dirs).
>
> I hope it helps.

I think so; but I'm still a little confused.  HW documentation would help.

g.