MPC85xx External/Internal Interrupts

MPC85xx External/Internal Interrupts

[Alemao]

Hi all,

In all MPC85xx DTS files I have seen this interrupt configuration for
TSEC1:

interrupts = <29 2 30 2 34 2>;

29 - TSEC1 interrupt transmit
30 - TSEC1 interrupt receive
34 - TSEC1 interrupt error


But in MPC8555RM, chapter 10.1.5.2 the numbers are these:

13 - TSEC1 interrupt transmit
14 - TSEC1 interrupt receive
18 - TSEC1 interrupt error


Im a little bit confused about this internal interrupts, how can I get
this numbers? TSEC1 is working normally.


My real problem is that my driver is trying to request the external
interrupt IRQ0, and I dont know what number use in INTR_NUM:

request_irq(INTR_NUM, , , , )


Im using linux-2.6.26

Cheers,

--
Alemao

Fwd: MPC85xx External/Internal Interrupts

[Alemao]

Hi all,

In all MPC85xx DTS files I have seen this interrupt configuration for
TSEC1:

interrupts = <29 2 30 2 34 2>;

29 - TSEC1 interrupt transmit
30 - TSEC1 interrupt receive
34 - TSEC1 interrupt error


But in MPC8555RM, chapter 10.1.5.2 the numbers are these:

13 - TSEC1 interrupt transmit
14 - TSEC1 interrupt receive
18 - TSEC1 interrupt error


Im a little bit confused about this internal interrupts, how can I get
this numbers? TSEC1 is working normally.


My real problem is that my driver is trying to request the external
interrupt IRQ0, and I dont know what number use in INTR_NUM:

request_irq(INTR_NUM, , , , )


Im using linux-2.6.26

Cheers,

--
Alemao

MPC85xx External/Internal Interrupts

[Alemao]

Hi all,

In all MPC85xx DTS files I have seen this interrupt configuration for
TSEC1:

interrupts = <29 2 30 2 34 2>;

29 - TSEC1 interrupt transmit
30 - TSEC1 interrupt receive
34 - TSEC1 interrupt error


But in MPC8555RM, chapter 10.1.5.2 the numbers are these:

13 - TSEC1 interrupt transmit
14 - TSEC1 interrupt receive
18 - TSEC1 interrupt error


Im a little bit confused about this internal interrupts, how can I get
this numbers? TSEC1 is working normally.


My real problem is that my driver is trying to request the external
interrupt IRQ0, and I dont know what number use in INTR_NUM:

request_irq(INTR_NUM, , , , )


Im using linux-2.6.26

Cheers,

--
Alemao

Re: MPC85xx External/Internal Interrupts

[Alemao]

I've read some posts in the list, and about:

irq_of_parse_and_map()
irq_create_map()

But Im still trying to understand MPC85xx TSEC1 dts.

Gianfar driver is using request_irq(), and request_irq() uses virtual
irq, right?

Thats why in dts all irqs for TSEC1 are "offseted" of 16?

Manual  |  DTS
---------------
13         29
14         30
18         34

And about external IRQs, MPC8555RM doesnt have IDs for them, what
should I use to request IRQ0 using irq_create_map()??

In MPC83xx all interrupts have IDs, including IRQ0, IRQ1...
That make things much more clear.

Thanks in advance,

--
Alemao

Re: MPC85xx External/Internal Interrupts

[Alemao]

On Fri, Sep 4, 2009 at 4:14 PM, Alemao<xcarandiru@gmail.com> wrote:
> I've read some posts in the list, and about:
>
> irq_of_parse_and_map()
> irq_create_map()
>
> But Im still trying to understand MPC85xx TSEC1 dts.
>
> Gianfar driver is using request_irq(), and request_irq() uses virtual
> irq, right?
>
> Thats why in dts all irqs for TSEC1 are "offseted" of 16?
>
> Manual =A0| =A0DTS
> ---------------
> 13 =A0 =A0 =A0 =A0 29
> 14 =A0 =A0 =A0 =A0 30
> 18 =A0 =A0 =A0 =A0 34
>

This makes no sense.

CPM2-PIC, in MPC8555ERM, its on 30. In DTS is on 46. Offset of 16.
But my platform code use irq_of_parse_and_map()!

So why this offset?!?!

--
Alemao

Re: MPC85xx External/Internal Interrupts

[Alemao]

I've read some posts in the list, and about:

irq_of_parse_and_map()
irq_create_map()

But Im still trying to understand MPC85xx TSEC1 dts.

Gianfar driver is using request_irq(), and request_irq() uses virtual
irq, right?

Thats why in dts all irqs for TSEC1 are "offseted" of 16?

Manual  |  DTS
----------------------
13         29
14         30
18         34

And about external IRQs, MPC8555RM doesnt have IDs for them, what
should I use to request IRQ0 using irq_create_map()??

In MPC83xx all interrupts have IDs, including IRQ0, IRQ1...
That make things much more clear.

Thanks in advance,

--
Alemao

Re: MPC85xx External/Internal Interrupts

[Alemao]

On Fri, Sep 4, 2009 at 4:28 PM, Alemao<xcarandiru@gmail.com> wrote:
> I've read some posts in the list, and about:
>
> irq_of_parse_and_map()
> irq_create_map()
>
> But Im still trying to understand MPC85xx TSEC1 dts.
>
> Gianfar driver is using request_irq(), and request_irq() uses virtual
> irq, right?
>
> Thats why in dts all irqs for TSEC1 are "offseted" of 16?
>
> Manual  |  DTS
> ----------------------
> 13         29
> 14         30
> 18         34
>

This makes no sense.

CPM2-PIC, in MPC8555ERM, its on 30. In DTS is on 46. Offset of 16.
But my platform code use irq_of_parse_and_map()!

So why this offset?!?!

Cheers,

--
Alemao

Re: MPC85xx External/Internal Interrupts

[Sebastian Andrzej Siewior]

* Alemao | 2009-09-04 16:29:15 [-0300]:

>On Fri, Sep 4, 2009 at 4:28 PM, Alemao<xcarandiru@gmail.com> wrote:
>> I've read some posts in the list, and about:
>>
>> irq_of_parse_and_map()
>> irq_create_map()
>>
>> But Im still trying to understand MPC85xx TSEC1 dts.
>>
>> Gianfar driver is using request_irq(), and request_irq() uses virtual
>> irq, right?
Yes. request_irq() expects a linux-irq-number. irq_of_parse_and_map()
provides such a number.

>>
>> Thats why in dts all irqs for TSEC1 are "offseted" of 16?
>>
>> Manual ?| ?DTS
>> ----------------------
>> 13 ? ? ? ? 29
>> 14 ? ? ? ? 30
>> 18 ? ? ? ? 34
>>
>
>This makes no sense.
>
>CPM2-PIC, in MPC8555ERM, its on 30. In DTS is on 46. Offset of 16.
>But my platform code use irq_of_parse_and_map()!
>
>So why this offset?!?!
irq_of_parse_and_map() creates a mapping between the hardware irq number
as specified in the device tree and the linux number (virq) which is
used within the linux api in request_irq() for instance.
irq_of_parse_and_map() is essential to create a mapping between those
two. The interrupt controller on the MPC8555 (mpic) specifies the first
few interrupt numbers as external sources followed by internal sources. 
Now, during the init sequenze of the mpic every interrupt source
(internal and external) becomes its uniqe vector number which identifies
the source by a number. This number is the hardware interrupt number
i.e. that thing in the device tree. The init sequence is a for loop
which starts at 0 for the first interrupt source which happens to be
external interrupt 0, 1 for external interrupt 1 and so on. At the time
it reaches the first internal interrupt source the vector number is 16.
That's why you always have an offset of 16 between every internal
interupt source number in the MPC855ERM document and those weired
numbers in the device tree :)

>Alemao
Sebastian

Re: MPC85xx External/Internal Interrupts

[Sebastian Andrzej Siewior]

* Alemao | 2009-09-04 16:29:15 [-0300]:

>On Fri, Sep 4, 2009 at 4:28 PM, Alemao<xcarandiru@gmail.com> wrote:
>> I've read some posts in the list, and about:
>>
>> irq_of_parse_and_map()
>> irq_create_map()
>>
>> But Im still trying to understand MPC85xx TSEC1 dts.
>>
>> Gianfar driver is using request_irq(), and request_irq() uses virtual
>> irq, right?
Yes. request_irq() expects a linux-irq-number. irq_of_parse_and_map()
provides such a number.

>>
>> Thats why in dts all irqs for TSEC1 are "offseted" of 16?
>>
>> Manual ?| ?DTS
>> ----------------------
>> 13 ? ? ? ? 29
>> 14 ? ? ? ? 30
>> 18 ? ? ? ? 34
>>
>
>This makes no sense.
>
>CPM2-PIC, in MPC8555ERM, its on 30. In DTS is on 46. Offset of 16.
>But my platform code use irq_of_parse_and_map()!
>
>So why this offset?!?!
irq_of_parse_and_map() creates a mapping between the hardware irq number
as specified in the device tree and the linux number (virq) which is
used within the linux api in request_irq() for instance.
irq_of_parse_and_map() is essential to create a mapping between those
two. The interrupt controller on the MPC8555 (mpic) specifies the first
few interrupt numbers as external sources followed by internal sources. 
Now, during the init sequenze of the mpic every interrupt source
(internal and external) becomes its uniqe vector number which identifies
the source by a number. This number is the hardware interrupt number
i.e. that thing in the device tree. The init sequence is a for loop
which starts at 0 for the first interrupt source which happens to be
external interrupt 0, 1 for external interrupt 1 and so on. At the time
it reaches the first internal interrupt source the vector number is 16.
That's why you always have an offset of 16 between every internal
interupt source number in the MPC855ERM document and those weired
numbers in the device tree :)

>Alemao
Sebastian

Re: MPC85xx External/Internal Interrupts

[Scott Wood]

On Sun, Sep 06, 2009 at 01:06:41PM +0200, Sebastian Andrzej Siewior wrote:
> irq_of_parse_and_map() creates a mapping between the hardware irq number
> as specified in the device tree and the linux number (virq) which is
> used within the linux api in request_irq() for instance.
> irq_of_parse_and_map() is essential to create a mapping between those
> two. The interrupt controller on the MPC8555 (mpic) specifies the first
> few interrupt numbers as external sources followed by internal sources. 
> Now, during the init sequenze of the mpic every interrupt source
> (internal and external) becomes its uniqe vector number which identifies
> the source by a number. This number is the hardware interrupt number
> i.e. that thing in the device tree. The init sequence is a for loop
> which starts at 0 for the first interrupt source which happens to be
> external interrupt 0, 1 for external interrupt 1 and so on. At the time
> it reaches the first internal interrupt source the vector number is 16.
> That's why you always have an offset of 16 between every internal
> interupt source number in the MPC855ERM document and those weired
> numbers in the device tree :)

This seems to be a common point of confusion -- we should probably put
something in the dts bindings that explains it.  Am I correct in assuming
that this particular internal/external split is Freescale-specific and
not a general OpenPIC thing?

-Scott

Re: MPC85xx External/Internal Interrupts

[Scott Wood]

On Sun, Sep 06, 2009 at 01:06:41PM +0200, Sebastian Andrzej Siewior wrote:
> irq_of_parse_and_map() creates a mapping between the hardware irq number
> as specified in the device tree and the linux number (virq) which is
> used within the linux api in request_irq() for instance.
> irq_of_parse_and_map() is essential to create a mapping between those
> two. The interrupt controller on the MPC8555 (mpic) specifies the first
> few interrupt numbers as external sources followed by internal sources. 
> Now, during the init sequenze of the mpic every interrupt source
> (internal and external) becomes its uniqe vector number which identifies
> the source by a number. This number is the hardware interrupt number
> i.e. that thing in the device tree. The init sequence is a for loop
> which starts at 0 for the first interrupt source which happens to be
> external interrupt 0, 1 for external interrupt 1 and so on. At the time
> it reaches the first internal interrupt source the vector number is 16.
> That's why you always have an offset of 16 between every internal
> interupt source number in the MPC855ERM document and those weired
> numbers in the device tree :)

This seems to be a common point of confusion -- we should probably put
something in the dts bindings that explains it.  Am I correct in assuming
that this particular internal/external split is Freescale-specific and
not a general OpenPIC thing?

-Scott

Re: MPC85xx External/Internal Interrupts

[Sebastian Andrzej Siewior]

* Scott Wood | 2009-09-09 13:28:57 [-0500]:

>> That's why you always have an offset of 16 between every internal
>> interupt source number in the MPC855ERM document and those weired
>> numbers in the device tree :)
>
>This seems to be a common point of confusion -- we should probably put
>something in the dts bindings that explains it.  Am I correct in assuming
>that this particular internal/external split is Freescale-specific and
>not a general OpenPIC thing?
Yes it looks like this. I can see this split in all mpc85xx boards and
mpc8610 boards from Freescale. There just two boards where I don't see
this kind of split: holly & kurobox and I don't the have the reference
manual for both of them to check. I also don't have an OpenPIC spec to
check there.
So from this it looks like e500/e600 thing and FSL only so far.

>
>-Scott

Sebastian

Re: MPC85xx External/Internal Interrupts

[Sebastian Andrzej Siewior]

* Scott Wood | 2009-09-09 13:28:57 [-0500]:

>> That's why you always have an offset of 16 between every internal
>> interupt source number in the MPC855ERM document and those weired
>> numbers in the device tree :)
>
>This seems to be a common point of confusion -- we should probably put
>something in the dts bindings that explains it.  Am I correct in assuming
>that this particular internal/external split is Freescale-specific and
>not a general OpenPIC thing?
Yes it looks like this. I can see this split in all mpc85xx boards and
mpc8610 boards from Freescale. There just two boards where I don't see
this kind of split: holly & kurobox and I don't the have the reference
manual for both of them to check. I also don't have an OpenPIC spec to
check there.
So from this it looks like e500/e600 thing and FSL only so far.

>
>-Scott

Sebastian

Re: MPC85xx External/Internal Interrupts

[Sebastian Andrzej Siewior]

* Sebastian Andrzej Siewior | 2009-09-10 15:15:44 [+0200]:

>* Scott Wood | 2009-09-09 13:28:57 [-0500]:
>
>>> That's why you always have an offset of 16 between every internal
>>> interupt source number in the MPC855ERM document and those weired
>>> numbers in the device tree :)
>>
>>something in the dts bindings that explains it.  Am I correct in assuming
>>that this particular internal/external split is Freescale-specific and
>>not a general OpenPIC thing?
>Yes it looks like this. 
>manual for both of them to check. I also don't have an OpenPIC spec to
>check there.
I had to say this. Now I got one. According to the OpenPIC there is no
such thing as an internal and external interrupt sources. Base + 0x10000
is the first interrupt source register and the number of interrupt
sources is specified in the feature register. 

So the split is a FSL thing.
What do you thing about making this clear? Adding into every .dts a
comment right on top or maybe in
Documentation/powerpc/dts-bindings/fsl/?

>>
>>-Scott

Sebastian

Re: MPC85xx External/Internal Interrupts

[Scott Wood]

Sebastian Andrzej Siewior wrote:
> So the split is a FSL thing.
> What do you thing about making this clear? Adding into every .dts a
> comment right on top or maybe in
> Documentation/powerpc/dts-bindings/fsl/?

Add an fsl/mpic.txt binding that describes this and any other 
pecularities above and beyond the base openpic binding.

-Scott

[RFC] doc/powerpc: try to explain why the interrupt numbers are off by 16

[Sebastian Andrzej Siewior]

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
---
 Documentation/powerpc/dts-bindings/fsl/mpic.txt |   42 +++++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt

diff --git a/Documentation/powerpc/dts-bindings/fsl/mpic.txt b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
new file mode 100644
index 0000000..71e39cf
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
@@ -0,0 +1,42 @@
+* OpenPIC and its interrupt numbers on Freescale's e500/e600 cores
+
+The OpenPIC specification does not specify which interrupt source has to
+become which interrupt number. This is up to the software implementation
+of the interrupt controller. The only requirement is that every
+interrupt source has to have an unique interrupt number / vector number.
+To accomplish this the current implementation assigns the number zero to
+the first source, the number one to the second source and so on until
+all interrupt sources have their unique number.
+Usually the assigned vector number equals the interrupt number mentioned
+in the documentation for a given core / CPU. This is however not true
+for the e500 cores (MPC85XX CPUs) where the documentation distinguishes
+between internal and external interrupt sources and starts counting at
+zero for both of them.
+
+So what to write for external interrupt source X or internal interrupt
+source Y into the device tree? Here is an example:
+
+The memory map for the interrupt controller in the MPC8544[0] shows,
+that the first interrupt source starts at 0x5_0000 (PIC Register Address
+Map-Interrupt Source Configuration Registers). This source becomes the
+number zero therefore:
+ External interrupt 0 = interrupt number 0
+ External interrupt 1 = interrupt number 1
+ External interrupt 2 = interrupt number 2
+ ...
+Every interrupt number allocates 0x20 bytes register space. So to get
+its number it is sufficient to shift the lower 16bits to right by five.
+So for the external interrupt 10 we have:
+  0x0140 >> 5 = 10
+
+After the external sources, the internal sources follow. The in core I2C
+controller on the MPC8544 for instance has the internal source number
+27. Oo obtain its interrupt number we take the lower 16bits of its memory
+address (0x5_0560) and shift it right:
+ 0x0560 >> 5 = 43
+
+Therefore the I2C device node for the MPC8544 CPU has to have the
+interrupt number 43 specified in the device tree.
+
+[0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual
+    MPC8544ERM Rev. 1 10/2007
-- 
1.6.5.3

[RFC] doc/powerpc: try to explain why the interrupt numbers are off by 16

[Sebastian Andrzej Siewior]

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
---
 Documentation/powerpc/dts-bindings/fsl/mpic.txt |   42 +++++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt

diff --git a/Documentation/powerpc/dts-bindings/fsl/mpic.txt b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
new file mode 100644
index 0000000..71e39cf
--- /dev/null
+++ b/Documentation/powerpc/dts-bindings/fsl/mpic.txt
@@ -0,0 +1,42 @@
+* OpenPIC and its interrupt numbers on Freescale's e500/e600 cores
+
+The OpenPIC specification does not specify which interrupt source has to
+become which interrupt number. This is up to the software implementation
+of the interrupt controller. The only requirement is that every
+interrupt source has to have an unique interrupt number / vector number.
+To accomplish this the current implementation assigns the number zero to
+the first source, the number one to the second source and so on until
+all interrupt sources have their unique number.
+Usually the assigned vector number equals the interrupt number mentioned
+in the documentation for a given core / CPU. This is however not true
+for the e500 cores (MPC85XX CPUs) where the documentation distinguishes
+between internal and external interrupt sources and starts counting at
+zero for both of them.
+
+So what to write for external interrupt source X or internal interrupt
+source Y into the device tree? Here is an example:
+
+The memory map for the interrupt controller in the MPC8544[0] shows,
+that the first interrupt source starts at 0x5_0000 (PIC Register Address
+Map-Interrupt Source Configuration Registers). This source becomes the
+number zero therefore:
+ External interrupt 0 = interrupt number 0
+ External interrupt 1 = interrupt number 1
+ External interrupt 2 = interrupt number 2
+ ...
+Every interrupt number allocates 0x20 bytes register space. So to get
+its number it is sufficient to shift the lower 16bits to right by five.
+So for the external interrupt 10 we have:
+  0x0140 >> 5 = 10
+
+After the external sources, the internal sources follow. The in core I2C
+controller on the MPC8544 for instance has the internal source number
+27. Oo obtain its interrupt number we take the lower 16bits of its memory
+address (0x5_0560) and shift it right:
+ 0x0560 >> 5 = 43
+
+Therefore the I2C device node for the MPC8544 CPU has to have the
+interrupt number 43 specified in the device tree.
+
+[0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual
+    MPC8544ERM Rev. 1 10/2007
-- 
1.6.5.3

Re: [RFC] doc/powerpc: try to explain why the interrupt numbers are off by 16

[Kumar Gala]

On Dec 6, 2009, at 5:32 AM, Sebastian Andrzej Siewior wrote:

> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> ---
> Documentation/powerpc/dts-bindings/fsl/mpic.txt |   42 +++++++++++++++++++++++
> 1 files changed, 42 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt

applied to next

- k

Re: [RFC] doc/powerpc: try to explain why the interrupt numbers are off by 16

[Kumar Gala]

On Dec 6, 2009, at 5:32 AM, Sebastian Andrzej Siewior wrote:

> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
> ---
> Documentation/powerpc/dts-bindings/fsl/mpic.txt |   42 =
+++++++++++++++++++++++
> 1 files changed, 42 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/powerpc/dts-bindings/fsl/mpic.txt

applied to next

- k=