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

[Grant Likely]

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?

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).

>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?

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.

[...]
>> > +       clocks {
>> > +               ref24_clk: clock at 0 {
>> > +                       device_type = "clock";
>> > +                       compatible = "fixed-clock";
>> > +                       clock-frequency = <24000000>;
>> > +                       clock-output-names = "ref";
>>
>> This will of course need to be updated to the clock binding that
>> Jeremy and I have settled on, but you already knew that.  :-)
>>
>
> Yes, again, you are right I knew that but I wanted to post a version
> I completely tested before applying the new clock bindings when rebasing.
> I will update the code for the next respin.


Cool, I look forward to seeing it.  Thanks!

g.