* [Xenomai-help] PowerPC irq unmask
@ 2009-01-23 7:32 Federico Ridolfo
2009-01-23 8:52 ` Philippe Gerum
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Federico Ridolfo @ 2009-01-23 7:32 UTC (permalink / raw)
To: xenomai
Hi all,
my platform is a mpc5200b based one. I wrote
some rtdm driver for that platform on linux-2.6.18
kernel. Some info:
- ARCH=ppc
- no fdt (so no dts)
- u-boot
- xenomai 2.3.2,
- adeos-ipipe-2.6.18-ppc-1.5-01.patch
All works fine.
Now i want to use:
- ARCH = powerpc
- linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
- fdt (so i have a dts file)
- xenomai-2.4.6.1
- u-boot
Ok. My board boots, all peripheral s work. Xenomai works, but
my rtdm drivers don't work. The problem is that the rtdm_irq_request
returns -ENODEV coming from line 166 in wrappers.h:
...
#else /* > 2.6.19 */
#define rthal_irq_chip_enable(irq) \
({ \
int __err__ = 0; \
if (unlikely(rthal_irq_handlerp(irq)->unmask == NULL)) \
__err__ = -ENODEV; \
else \
rthal_irq_handlerp(irq)->unmask(irq); \
__err__; \
})
...
Seems that adeos doesn't not set the unmask function. In the linux kernel
the right functions for my pic in in
arch/powerpc/platforms/52xx/mpc52xx_pic.c
I thing i have to add some code in mpc52xx_pic.c in order to match
device tree table
and also something in my dts file. Any help is very usefull!!!
Thanks
--
chicco
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 7:32 [Xenomai-help] PowerPC irq unmask Federico Ridolfo
@ 2009-01-23 8:52 ` Philippe Gerum
2009-01-23 9:10 ` Federico Ridolfo
2009-01-23 10:25 ` Philippe Gerum
2009-01-23 19:29 ` Wolfgang Grandegger
2 siblings, 1 reply; 14+ messages in thread
From: Philippe Gerum @ 2009-01-23 8:52 UTC (permalink / raw)
To: federico.ridolfo; +Cc: xenomai
Federico Ridolfo wrote:
> Hi all,
> my platform is a mpc5200b based one. I wrote
> some rtdm driver for that platform on linux-2.6.18
> kernel. Some info:
> - ARCH=ppc
> - no fdt (so no dts)
> - u-boot
> - xenomai 2.3.2,
> - adeos-ipipe-2.6.18-ppc-1.5-01.patch
> All works fine.
>
> Now i want to use:
> - ARCH = powerpc
> - linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
> - fdt (so i have a dts file)
> - xenomai-2.4.6.1
> - u-boot
> Ok. My board boots, all peripheral s work. Xenomai works, but
> my rtdm drivers don't work. The problem is that the rtdm_irq_request
> returns -ENODEV coming from line 166 in wrappers.h:
> ...
> #else /* > 2.6.19 */
> #define rthal_irq_chip_enable(irq) \
> ({ \
> int __err__ = 0; \
> if (unlikely(rthal_irq_handlerp(irq)->unmask == NULL)) \
> __err__ = -ENODEV; \
> else \
> rthal_irq_handlerp(irq)->unmask(irq); \
> __err__; \
> })
> ...
> Seems that adeos doesn't not set the unmask function. In the linux kernel
> the right functions for my pic in in
Adeos reuses what Linux provides. In this case, an unmask routine is provided
for all the SDMA, external, peripheral and main interrupt sources.
Which IRQ are you trying to grab? What does you code look like?
> arch/powerpc/platforms/52xx/mpc52xx_pic.c
> I thing i have to add some code in mpc52xx_pic.c in order to match
> device tree table
> and also something in my dts file.
Don't do that. It would be wrong.
Any help is very usefull!!!
> Thanks
>
>
> --
> chicco
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 8:52 ` Philippe Gerum
@ 2009-01-23 9:10 ` Federico Ridolfo
2009-01-23 9:48 ` Philippe Gerum
0 siblings, 1 reply; 14+ messages in thread
From: Federico Ridolfo @ 2009-01-23 9:10 UTC (permalink / raw)
To: rpm; +Cc: xenomai
Philippe Gerum wrote:
> Federico Ridolfo wrote:
>
>> Hi all,
>> my platform is a mpc5200b based one. I wrote
>> some rtdm driver for that platform on linux-2.6.18
>> kernel. Some info:
>> - ARCH=ppc
>> - no fdt (so no dts)
>> - u-boot
>> - xenomai 2.3.2,
>> - adeos-ipipe-2.6.18-ppc-1.5-01.patch
>> All works fine.
>>
>> Now i want to use:
>> - ARCH = powerpc
>> - linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
>> - fdt (so i have a dts file)
>> - xenomai-2.4.6.1
>> - u-boot
>> Ok. My board boots, all peripheral s work. Xenomai works, but
>> my rtdm drivers don't work. The problem is that the rtdm_irq_request
>> returns -ENODEV coming from line 166 in wrappers.h:
>> ...
>> #else /* > 2.6.19 */
>> #define rthal_irq_chip_enable(irq) \
>> ({ \
>> int __err__ = 0; \
>> if (unlikely(rthal_irq_handlerp(irq)->unmask == NULL)) \
>> __err__ = -ENODEV; \
>> else \
>> rthal_irq_handlerp(irq)->unmask(irq); \
>> __err__; \
>> })
>> ...
>> Seems that adeos doesn't not set the unmask function. In the linux kernel
>> the right functions for my pic in in
>>
>
> Adeos reuses what Linux provides. In this case, an unmask routine is provided
> for all the SDMA, external, peripheral and main interrupt sources.
>
> Which IRQ are you trying to grab? What does you code look like?
I wrote 2 rtdm drivers. The first one tries to grab MPC52xx_GPIO_IRQ (= 12)
in order to use USB1_9 of MPC5200B has an interrupt pin.
The second driver is a RTDM SPI driver for PSC3 (full spi mode)
and PSC6, so i'm trying to grap MPC52xx_PSC3_IRQ (= 42) and
MPC52xx_PSC6_IRQ (= 43).
>
>> arch/powerpc/platforms/52xx/mpc52xx_pic.c
>> I thing i have to add some code in mpc52xx_pic.c in order to match
>> device tree table
>> and also something in my dts file.
>>
>
> Don't do that. It would be wrong.
>
mmm... some .config mistake? I don't known...
> Any help is very usefull!!!
>
>> Thanks
>>
>>
>> --
>> chicco
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>
>>
>
>
>
--
Dott. Ing. Federico Ridolfo
COL Giovanni Paolo S.P.A.
Stabilimento Catania
Via Luigi Pirandello,Contrada Cugno, 95040 Piano Tavola, BELPASSO (CT)
tel. +39 095 7133088
e-mail: federico.ridolfo@domain.hid
--
AVVERTENZE AI SENSI DEL D.LGS. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e negli eventuali files allegati, sono da considerarsi strettamente riservate. Il loro utilizzo e` consentito esclusivamente al destinatario del messaggio, per le finalita` indicate nel messaggio stesso. Qualora riceveste per errore questo messaggio, Vi preghiamo cortesemente di darcene notizia all'indirizzo e-mail di cui sopra e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema; costituisce comportamento contrario ai principi dettati dal D.lgs. 196/2003 il trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita` diverse.
Ogni dato previsto e trattato dal D.lgs. 196/2003, eventualmente presente nell'e-mail e` trattato nel rispetto della legge.
This e-mail is confidential and may also contain privileged information. If you are not the intended recipient you are not authorised to read, print, save, process or disclose this message.
If you have received this message by mistake, please inform the sender immediately and delete this e-mail, its attachments and any copies.
Any use, distribution, reproduction or disclosure by any person other than the intended recipient is strictly forbidden and the person responsible may incur penalties (D.lgs. 196/2003 Italian law).
Every information treated by D.lgs. 196/2003 Italian law, eventually present in this e-mail are treated in the respect of the law.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 9:10 ` Federico Ridolfo
@ 2009-01-23 9:48 ` Philippe Gerum
2009-01-23 10:16 ` Federico Ridolfo
0 siblings, 1 reply; 14+ messages in thread
From: Philippe Gerum @ 2009-01-23 9:48 UTC (permalink / raw)
To: federico.ridolfo; +Cc: xenomai
Federico Ridolfo wrote:
> Philippe Gerum wrote:
>> Federico Ridolfo wrote:
>>
>>> Hi all,
>>> my platform is a mpc5200b based one. I wrote
>>> some rtdm driver for that platform on linux-2.6.18
>>> kernel. Some info:
>>> - ARCH=ppc
>>> - no fdt (so no dts)
>>> - u-boot
>>> - xenomai 2.3.2,
>>> - adeos-ipipe-2.6.18-ppc-1.5-01.patch
>>> All works fine.
>>>
>>> Now i want to use:
>>> - ARCH = powerpc
>>> - linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
>>> - fdt (so i have a dts file)
>>> - xenomai-2.4.6.1
>>> - u-boot
>>> Ok. My board boots, all peripheral s work. Xenomai works, but
>>> my rtdm drivers don't work. The problem is that the rtdm_irq_request
>>> returns -ENODEV coming from line 166 in wrappers.h:
>>> ...
>>> #else /* > 2.6.19 */
>>> #define rthal_irq_chip_enable(irq) \
>>> ({ \
>>> int __err__ = 0; \
>>> if (unlikely(rthal_irq_handlerp(irq)->unmask == NULL)) \
>>> __err__ = -ENODEV; \
>>> else \
>>> rthal_irq_handlerp(irq)->unmask(irq); \
>>> __err__; \
>>> })
>>> ...
>>> Seems that adeos doesn't not set the unmask function. In the linux kernel
>>> the right functions for my pic in in
>>>
>> Adeos reuses what Linux provides. In this case, an unmask routine is provided
>> for all the SDMA, external, peripheral and main interrupt sources.
>>
>> Which IRQ are you trying to grab? What does you code look like?
> I wrote 2 rtdm drivers. The first one tries to grab MPC52xx_GPIO_IRQ (= 12)
> in order to use USB1_9 of MPC5200B has an interrupt pin.
> The second driver is a RTDM SPI driver for PSC3 (full spi mode)
> and PSC6, so i'm trying to grap MPC52xx_PSC3_IRQ (= 42) and
> MPC52xx_PSC6_IRQ (= 43).
>
Ok, what does /proc/interrupts say?
>>
>>> arch/powerpc/platforms/52xx/mpc52xx_pic.c
>>> I thing i have to add some code in mpc52xx_pic.c in order to match
>>> device tree table
>>> and also something in my dts file.
>>>
>> Don't do that. It would be wrong.
>>
> mmm... some .config mistake? I don't known...
>> Any help is very usefull!!!
>>
>>> Thanks
>>>
>>>
>>> --
>>> chicco
>>>
>>> _______________________________________________
>>> Xenomai-help mailing list
>>> Xenomai-help@domain.hid
>>> https://mail.gna.org/listinfo/xenomai-help
>>>
>>>
>>
>>
>
>
> --
> Dott. Ing. Federico Ridolfo
> COL Giovanni Paolo S.P.A.
> Stabilimento Catania
> Via Luigi Pirandello,Contrada Cugno, 95040 Piano Tavola, BELPASSO (CT)
> tel. +39 095 7133088
> e-mail: federico.ridolfo@domain.hid
>
--
Philippe.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 9:48 ` Philippe Gerum
@ 2009-01-23 10:16 ` Federico Ridolfo
0 siblings, 0 replies; 14+ messages in thread
From: Federico Ridolfo @ 2009-01-23 10:16 UTC (permalink / raw)
To: rpm; +Cc: xenomai
Philippe Gerum wrote:
> Federico Ridolfo wrote:
>
>> Philippe Gerum wrote:
>>
>>> Federico Ridolfo wrote:
>>>
>>>
>>>> Hi all,
>>>> my platform is a mpc5200b based one. I wrote
>>>> some rtdm driver for that platform on linux-2.6.18
>>>> kernel. Some info:
>>>> - ARCH=ppc
>>>> - no fdt (so no dts)
>>>> - u-boot
>>>> - xenomai 2.3.2,
>>>> - adeos-ipipe-2.6.18-ppc-1.5-01.patch
>>>> All works fine.
>>>>
>>>> Now i want to use:
>>>> - ARCH = powerpc
>>>> - linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
>>>> - fdt (so i have a dts file)
>>>> - xenomai-2.4.6.1
>>>> - u-boot
>>>> Ok. My board boots, all peripheral s work. Xenomai works, but
>>>> my rtdm drivers don't work. The problem is that the rtdm_irq_request
>>>> returns -ENODEV coming from line 166 in wrappers.h:
>>>> ...
>>>> #else /* > 2.6.19 */
>>>> #define rthal_irq_chip_enable(irq) \
>>>> ({ \
>>>> int __err__ = 0; \
>>>> if (unlikely(rthal_irq_handlerp(irq)->unmask == NULL)) \
>>>> __err__ = -ENODEV; \
>>>> else \
>>>> rthal_irq_handlerp(irq)->unmask(irq); \
>>>> __err__; \
>>>> })
>>>> ...
>>>> Seems that adeos doesn't not set the unmask function. In the linux kernel
>>>> the right functions for my pic in in
>>>>
>>>>
>>> Adeos reuses what Linux provides. In this case, an unmask routine is provided
>>> for all the SDMA, external, peripheral and main interrupt sources.
>>>
>>> Which IRQ are you trying to grab? What does you code look like?
>>>
>> I wrote 2 rtdm drivers. The first one tries to grab MPC52xx_GPIO_IRQ (= 12)
>> in order to use USB1_9 of MPC5200B has an interrupt pin.
>> The second driver is a RTDM SPI driver for PSC3 (full spi mode)
>> and PSC6, so i'm trying to grap MPC52xx_PSC3_IRQ (= 42) and
>> MPC52xx_PSC6_IRQ (= 43).
>>
>>
>
> Ok, what does /proc/interrupts say?
>
>
on 2.6.18 (works fine):
~ # cat /proc/interrupts
CPU0
22: 245 MPC52xx Level mpc52xx-fec_rx
23: 101 MPC52xx Level mpc52xx-fec_tx
40: 292 MPC52xx Level mpc52xx_psc_uart
44: 7 MPC52xx Level mpc52xx-fec_ctrl
46: 431 MPC52xx Level ide0
54: 0 MPC52xx Level i2c-mpc
55: 38 MPC52xx Level i2c-mpc
BAD: 0
Instead in 2.6.26:
~ # cat /proc/interrupts
CPU0
129: 1201427 MPC52xx Peripherals Edge mpc52xx_psc_uart
135: 15252 MPC52xx Peripherals Edge mpc52xx_ata
143: 0 MPC52xx Peripherals Edge i2c-mpc
144: 36 MPC52xx Peripherals Edge i2c-mpc
BAD: 0
>>>
>>>
>>>> arch/powerpc/platforms/52xx/mpc52xx_pic.c
>>>> I thing i have to add some code in mpc52xx_pic.c in order to match
>>>> device tree table
>>>> and also something in my dts file.
>>>>
>>>>
>>> Don't do that. It would be wrong.
>>>
>>>
>> mmm... some .config mistake? I don't known...
>>
>>> Any help is very usefull!!!
>>>
>>>
>>>> Thanks
>>>>
>>>>
>>>> --
>>>> chicco
>>>>
>>>> _______________________________________________
>>>> Xenomai-help mailing list
>>>> Xenomai-help@domain.hid
>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>
>>>>
>>>>
>>>
>>>
>> --
>> Dott. Ing. Federico Ridolfo
>> COL Giovanni Paolo S.P.A.
>> Stabilimento Catania
>> Via Luigi Pirandello,Contrada Cugno, 95040 Piano Tavola, BELPASSO (CT)
>> tel. +39 095 7133088
>> e-mail: federico.ridolfo@domain.hid
>>
>>
>
>
>
--
Dott. Ing. Federico Ridolfo
COL Giovanni Paolo S.P.A.
Stabilimento Catania
Via Luigi Pirandello,Contrada Cugno, 95040 Piano Tavola, BELPASSO (CT)
tel. +39 095 7133088
e-mail: federico.ridolfo@domain.hid
--
AVVERTENZE AI SENSI DEL D.LGS. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e negli eventuali files allegati, sono da considerarsi strettamente riservate. Il loro utilizzo e` consentito esclusivamente al destinatario del messaggio, per le finalita` indicate nel messaggio stesso. Qualora riceveste per errore questo messaggio, Vi preghiamo cortesemente di darcene notizia all'indirizzo e-mail di cui sopra e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema; costituisce comportamento contrario ai principi dettati dal D.lgs. 196/2003 il trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalita` diverse.
Ogni dato previsto e trattato dal D.lgs. 196/2003, eventualmente presente nell'e-mail e` trattato nel rispetto della legge.
This e-mail is confidential and may also contain privileged information. If you are not the intended recipient you are not authorised to read, print, save, process or disclose this message.
If you have received this message by mistake, please inform the sender immediately and delete this e-mail, its attachments and any copies.
Any use, distribution, reproduction or disclosure by any person other than the intended recipient is strictly forbidden and the person responsible may incur penalties (D.lgs. 196/2003 Italian law).
Every information treated by D.lgs. 196/2003 Italian law, eventually present in this e-mail are treated in the respect of the law.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 7:32 [Xenomai-help] PowerPC irq unmask Federico Ridolfo
2009-01-23 8:52 ` Philippe Gerum
@ 2009-01-23 10:25 ` Philippe Gerum
2009-01-23 17:06 ` Federico Ridolfo
2009-01-23 19:29 ` Wolfgang Grandegger
2 siblings, 1 reply; 14+ messages in thread
From: Philippe Gerum @ 2009-01-23 10:25 UTC (permalink / raw)
To: federico.ridolfo; +Cc: xenomai
Federico Ridolfo wrote:
> Hi all,
> my platform is a mpc5200b based one. I wrote
> some rtdm driver for that platform on linux-2.6.18
> kernel. Some info:
> - ARCH=ppc
> - no fdt (so no dts)
> - u-boot
> - xenomai 2.3.2,
> - adeos-ipipe-2.6.18-ppc-1.5-01.patch
> All works fine.
>
> Now i want to use:
> - ARCH = powerpc
> - linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
> - fdt (so i have a dts file)
> - xenomai-2.4.6.1
> - u-boot
> Ok. My board boots, all peripheral s work. Xenomai works, but
> my rtdm drivers don't work. The problem is that the rtdm_irq_request
> returns -ENODEV coming from line 166 in wrappers.h:
> ...
> #else /* > 2.6.19 */
> #define rthal_irq_chip_enable(irq) \
> ({ \
> int __err__ = 0; \
> if (unlikely(rthal_irq_handlerp(irq)->unmask == NULL)) \
> __err__ = -ENODEV; \
> else \
> rthal_irq_handlerp(irq)->unmask(irq); \
> __err__; \
> })
> ...
> Seems that adeos doesn't not set the unmask function. In the linux kernel
> the right functions for my pic in in
> arch/powerpc/platforms/52xx/mpc52xx_pic.c
> I thing i have to add some code in mpc52xx_pic.c in order to match
> device tree table
To complete my previous answer: unless you have a very particular hw design, it
is unlikely that the PIC code is missing anything to support your board.
> and also something in my dts file.
However, a too generic device tree description may not reflect all the
peripherals you have on your board, so yes, updating it may be needed so that
the platform code maps the hw interrupt sources you want.
I suspect you will have no regular drivers on these IRQs, so /proc/interrupts
should not list them.
The point is: are those interrupts sources known from the kernel? Enabling the
debug switch in arch/powerpc/kernel/irq.c should give you some hints about which
hw IRQ sources are actually enumerated then mapped on your board (remember to
increase the console_loglevel or set ignore_loglevel to get this ouput). If you
don't find those you need, then you will likely want to fix the dts file.
Any help is very usefull!!!
> Thanks
>
>
> --
> chicco
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 10:25 ` Philippe Gerum
@ 2009-01-23 17:06 ` Federico Ridolfo
2009-01-23 18:07 ` Philippe Gerum
0 siblings, 1 reply; 14+ messages in thread
From: Federico Ridolfo @ 2009-01-23 17:06 UTC (permalink / raw)
To: rpm; +Cc: xenomai
Ok, i'm debugging the problem, but i have not a solution.
I compiled the kernel with the debug switch for irq.c.
In addition i added the mpc52xx_psc_spi module in my
.config.
So, now i'm sure that the irq used in mpc52xx_psc_spi
for the PSC3 is 131 and for PSC6 is 132:
# dmesg
mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
(de)activate_cs function will be called
irq: irq_create_mapping(0xc041d2a0, 0x84)
irq: -> using host @c041d2a0
irq: -> obtained virq 132
I'm using the same irqs for my rtdm spi driver, but it doesnìt work.
If i reboot the board and try my rtdm driver, the result is -ENODEV
If i "modprobe mpc52xx_psc_spi" and retry my rtdm driver -> the board
hangs for ever.
I have the same result also if i "rrmod mpc52xx_psc_spi" before.
My dts is:
/dts-v1/;
/ {
model = "colgp,cirneco5200";
compatible = "colgp,cirneco5200";
#address-cells = <1>;
#size-cells = <1>;
cpus {
#address-cells = <1>;
#size-cells = <0>;
PowerPC,5200@domain.hid {
device_type = "cpu";
reg = <0>;
d-cache-line-size = <32>;
i-cache-line-size = <32>;
d-cache-size = <0x4000>; // L1, 16K
i-cache-size = <0x4000>; // L1, 16K
timebase-frequency = <0>; // from bootloader
bus-frequency = <0>; // from bootloader
clock-frequency = <0>; // from bootloader
};
};
memory {
device_type = "memory";
reg = <0x00000000 0x04000000>; // 64MB
//reg = <0x00000000 0x08000000>; // 64MB
//reg = <0x00000000 0x10000000>; // 256MB
};
soc5200@domain.hid {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,mpc5200b-immr";
ranges = <0 0xf0000000 0x0000c000>;
reg = <0xf0000000 0x00000100>;
bus-frequency = <0>; // from bootloader
system-frequency = <0>; // from bootloader
cdm@domain.hid {
compatible = "fsl,mpc5200b-cdm","fsl,mpc5200-cdm";
reg = <0x200 0x38>;
};
mpc5200_pic: interrupt-controller@domain.hid {
// 5200 interrupts are encoded into two levels;
interrupt-controller;
#interrupt-cells = <3>;
device_type = "interrupt-controller";
compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
reg = <0x500 0x80>;
};
// General Purpose Timer
timer@domain.hid {
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <0>;
reg = <0x600 0x10>;
interrupts = <1 9 0>;
interrupt-parent = <&mpc5200_pic>;
fsl,has-wdt;
};
timer@domain.hid {
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <1>;
reg = <0x610 0x10>;
interrupts = <1 10 0>;
interrupt-parent = <&mpc5200_pic>;
};
timer@domain.hid {
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <2>;
reg = <0x620 0x10>;
interrupts = <1 11 0>;
interrupt-parent = <&mpc5200_pic>;
};
timer@domain.hid {
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <3>;
reg = <0x630 0x10>;
interrupts = <1 12 0>;
interrupt-parent = <&mpc5200_pic>;
};
timer@domain.hid {
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <4>;
reg = <0x640 0x10>;
interrupts = <1 13 0>;
interrupt-parent = <&mpc5200_pic>;
};
timer@domain.hid {
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <5>;
reg = <0x650 0x10>;
interrupts = <1 14 0>;
interrupt-parent = <&mpc5200_pic>;
};
timer@domain.hid {
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <6>;
reg = <0x660 0x10>;
interrupts = <1 15 0>;
interrupt-parent = <&mpc5200_pic>;
};
timer@domain.hid {
compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
cell-index = <7>;
reg = <0x670 0x10>;
interrupts = <1 16 0>;
interrupt-parent = <&mpc5200_pic>;
};
rtc@domain.hid { // Real time clock
compatible = "fsl,mpc5200b-rtc","fsl,mpc5200-rtc";
device_type = "rtc";
reg = <0x800 0x100>;
interrupts = <1 5 0 1 6 0>;
interrupt-parent = <&mpc5200_pic>;
};
can@domain.hid {
compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
cell-index = <0>;
interrupts = <2 17 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <0x900 0x80>;
};
can@domain.hid {
compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
cell-index = <1>;
interrupts = <2 18 0>;
interrupt-parent = <&mpc5200_pic>;
reg = <0x980 0x80>;
};
gpio@domain.hid {
compatible = "fsl,mpc5200b-gpio","fsl,mpc5200-gpio";
reg = <0xb00 0x40>;
interrupts = <1 7 0>;
interrupt-parent = <&mpc5200_pic>;
};
gpio@domain.hid {
compatible = "fsl,mpc5200b-gpio-wkup","fsl,mpc5200-gpio-wkup";
reg = <0xc00 0x40>;
interrupts = <1 8 0 0 3 0>;
interrupt-parent = <&mpc5200_pic>;
};
spi@domain.hid {
compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
reg = <0xf00 0x20>;
interrupts = <2 13 0 2 14 0>;
interrupt-parent = <&mpc5200_pic>;
};
usb@domain.hid {
compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci","ohci-be";
reg = <0x1000 0xff>;
interrupts = <2 6 0>;
interrupt-parent = <&mpc5200_pic>;
};
dma-controller@domain.hid {
device_type = "dma-controller";
compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
reg = <0x1200 0x80>;
interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
3 4 0 3 5 0 3 6 0 3 7 0
3 8 0 3 9 0 3 10 0 3 11 0
3 12 0 3 13 0 3 14 0 3 15 0>;
interrupt-parent = <&mpc5200_pic>;
};
xlb@domain.hid {
compatible = "fsl,mpc5200b-xlb","fsl,mpc5200-xlb";
reg = <0x1f00 0x100>;
};
serial@domain.hid { // PSC1
device_type = "serial";
compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
port-number = <0>; // Logical port assignment
cell-index = <0>;
reg = <0x2000 0x100>;
interrupts = <2 1 0>;
interrupt-parent = <&mpc5200_pic>;
};
serial@domain.hid { // PSC2
device_type = "serial";
compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
cell-index = <1>;
port-number = <1>;
reg = <0x2200 0x100>;
interrupts = <2 2 0>;
interrupt-parent = <&mpc5200_pic>;
};
spi@domain.hid { // PSC3 in spi mode
compatible = "fsl,mpc5200b-psc-spi","fsl,mpc5200-psc-spi";
cell-index = <2>;
port-number = <2>;
reg = <0x2400 0x100>;
interrupts = <2 3 0>;
interrupt-parent = <&mpc5200_pic>;
};
// PSC3 in CODEC mode example
//i2s@domain.hid { // PSC3
// compatible = "fsl,mpc5200b-psc-i2s"; //not 5200 compatible
// cell-index = <2>;
// reg = <0x2400 0x100>;
// interrupts = <2 3 0>;
// interrupt-parent = <&mpc5200_pic>;
//};
//serial@domain.hid { // PSC3
// device_type = "serial";
// compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
// cell-index = <2>;
// reg = <0x2400 0x100>;
// interrupts = <2 3 0>;
// interrupt-parent = <&mpc5200_pic>;
//};
serial@domain.hid { // PSC4 uart
device_type = "serial";
compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
cell-index = <3>;
port-number = <3>;
reg = <0x2600 0x100>;
interrupts = <2 11 0>;
interrupt-parent = <&mpc5200_pic>;
};
serial@domain.hid { // PSC5 uart
device_type = "serial";
compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
cell-index = <4>;
port-number = <4>;
reg = <0x2800 0x100>;
interrupts = <2 12 0>;
interrupt-parent = <&mpc5200_pic>;
};
// PSC6 in spi mode example
spi@domain.hid { // PSC6
compatible = "fsl,mpc5200b-psc-spi","fsl,mpc5200-psc-spi";
cell-index = <5>;
port-number = <5>;
reg = <0x2c00 0x100>;
interrupts = <2 4 0>;
interrupt-parent = <&mpc5200_pic>;
};
//serial@domain.hid { // PSC6 in UART mode
// device_type = "serial";
// compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
// cell-index = <5>;
// port-number = <5>;
// reg = <0x2c00 0x100>;
// interrupts = <2 4 0>;
// interrupt-parent = <&mpc5200_pic>;
//};
ethernet@domain.hid {
device_type = "network";
compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
reg = <0x3000 0x400>;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = <2 5 0>;
interrupt-parent = <&mpc5200_pic>;
phy-handle = <&phy0>;
};
mdio@domain.hid {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-mdio", "fsl,mpc5200-mdio";
reg = <0x3000 0x400>; // fec range, since we need to
setup fec interrupts
interrupts = <2 5 0>; // these are for "mii command
finished", not link changes & co.
interrupt-parent = <&mpc5200_pic>;
phy0: ethernet-phy@domain.hid {
device_type = "ethernet-phy";
reg = <0>;
};
};
ata@domain.hid {
device_type = "ata";
compatible = "fsl,mpc5200b-ata","fsl,mpc5200-ata";
reg = <0x3a00 0x100>;
interrupts = <2 7 0>;
interrupt-parent = <&mpc5200_pic>;
};
i2c@domain.hid {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
cell-index = <0>;
reg = <0x3d00 0x40>;
interrupts = <2 15 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
};
i2c@domain.hid {
#address-cells = <1>;
#size-cells = <0>;
compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
cell-index = <1>;
reg = <0x3d40 0x40>;
interrupts = <2 16 0>;
interrupt-parent = <&mpc5200_pic>;
fsl5200-clocking;
rtc@domain.hid {
device_type = "rtc";
compatible = "epson,pcf8563";
reg = <0x51>;
};
};
sram@domain.hid {
compatible = "fsl,mpc5200b-sram","fsl,mpc5200-sram","sram";
reg = <0x8000 0x4000>;
};
};
pci@domain.hid {
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
device_type = "pci";
compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
reg = <0xf0000d00 0x100>;
interrupt-map-mask = <0xf800 0 0 7>;
interrupt-map = <0xc000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
0xc000 0 0 2 &mpc5200_pic 1 1 3
0xc000 0 0 3 &mpc5200_pic 1 2 3
0xc000 0 0 4 &mpc5200_pic 1 3 3
0xc800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
0xc800 0 0 2 &mpc5200_pic 1 2 3
0xc800 0 0 3 &mpc5200_pic 1 3 3
0xc800 0 0 4 &mpc5200_pic 0 0 3>;
clock-frequency = <0>; // From boot loader
interrupts = <2 8 0 2 9 0 2 10 0>;
interrupt-parent = <&mpc5200_pic>;
bus-range = <0 0>;
ranges = <0x42000000 0 0x80000000 0x80000000 0 0x20000000
0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
};
};
Ideas? Thanks for your help
Philippe Gerum wrote:
> Federico Ridolfo wrote:
>
>> Hi all,
>> my platform is a mpc5200b based one. I wrote
>> some rtdm driver for that platform on linux-2.6.18
>> kernel. Some info:
>> - ARCH=ppc
>> - no fdt (so no dts)
>> - u-boot
>> - xenomai 2.3.2,
>> - adeos-ipipe-2.6.18-ppc-1.5-01.patch
>> All works fine.
>>
>> Now i want to use:
>> - ARCH = powerpc
>> - linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
>> - fdt (so i have a dts file)
>> - xenomai-2.4.6.1
>> - u-boot
>> Ok. My board boots, all peripheral s work. Xenomai works, but
>> my rtdm drivers don't work. The problem is that the rtdm_irq_request
>> returns -ENODEV coming from line 166 in wrappers.h:
>> ...
>> #else /* > 2.6.19 */
>> #define rthal_irq_chip_enable(irq) \
>> ({ \
>> int __err__ = 0; \
>> if (unlikely(rthal_irq_handlerp(irq)->unmask == NULL)) \
>> __err__ = -ENODEV; \
>> else \
>> rthal_irq_handlerp(irq)->unmask(irq); \
>> __err__; \
>> })
>> ...
>> Seems that adeos doesn't not set the unmask function. In the linux kernel
>> the right functions for my pic in in
>> arch/powerpc/platforms/52xx/mpc52xx_pic.c
>> I thing i have to add some code in mpc52xx_pic.c in order to match
>> device tree table
>>
>
> To complete my previous answer: unless you have a very particular hw design, it
> is unlikely that the PIC code is missing anything to support your board.
>
>
>> and also something in my dts file.
>>
>
> However, a too generic device tree description may not reflect all the
> peripherals you have on your board, so yes, updating it may be needed so that
> the platform code maps the hw interrupt sources you want.
>
> I suspect you will have no regular drivers on these IRQs, so /proc/interrupts
> should not list them.
>
> The point is: are those interrupts sources known from the kernel? Enabling the
> debug switch in arch/powerpc/kernel/irq.c should give you some hints about which
> hw IRQ sources are actually enumerated then mapped on your board (remember to
> increase the console_loglevel or set ignore_loglevel to get this ouput). If you
> don't find those you need, then you will likely want to fix the dts file.
>
> Any help is very usefull!!!
>
>> Thanks
>>
>>
>> --
>> chicco
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 17:06 ` Federico Ridolfo
@ 2009-01-23 18:07 ` Philippe Gerum
2009-01-23 18:18 ` Federico Ridolfo
0 siblings, 1 reply; 14+ messages in thread
From: Philippe Gerum @ 2009-01-23 18:07 UTC (permalink / raw)
To: federico.ridolfo; +Cc: xenomai
Federico Ridolfo wrote:
> Ok, i'm debugging the problem, but i have not a solution.
> I compiled the kernel with the debug switch for irq.c.
> In addition i added the mpc52xx_psc_spi module in my
> .config.
> So, now i'm sure that the irq used in mpc52xx_psc_spi
> for the PSC3 is 131 and for PSC6 is 132:
>
> # dmesg
> mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
> (de)activate_cs function will be called
> irq: irq_create_mapping(0xc041d2a0, 0x84)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 132
>
Please send all the IRQ related information, you get in the boot log, because
the few lines above do not match what your dts file below says.
As far as I understand those lines, the generic IRQ code is asked to create a
virtual mapping for hwirq 132 out of the OF specs, and this hint is kept so that
you actually get virq 132. So far so good.
However, to get asked for 132, your dts file should have specified an intspec
which rather looks like { 2 4 <sense-type> } and not { 2 3 <sense-type> } as
mentioned in the spi@domain.hid block. { 2 3 <sense-type> } for PSC3 in SPI mode would
rather give us hwirq 131 (the hairy computation determining the hwirq number
from the inspec is available from mpc52xx_irqhost_xlate()).
So either you are not booting with the blob that matches the dts file below, or
the console output above is misleading. In short, I'm lost.
> I'm using the same irqs for my rtdm spi driver, but it doesnìt work.
> If i reboot the board and try my rtdm driver, the result is -ENODEV
>
> If i "modprobe mpc52xx_psc_spi" and retry my rtdm driver -> the board
> hangs for ever.
> I have the same result also if i "rrmod mpc52xx_psc_spi" before.
> My dts is:
> /dts-v1/;
>
> / {
> model = "colgp,cirneco5200";
> compatible = "colgp,cirneco5200";
> #address-cells = <1>;
> #size-cells = <1>;
>
> cpus {
> #address-cells = <1>;
> #size-cells = <0>;
>
> PowerPC,5200@domain.hid {
> device_type = "cpu";
> reg = <0>;
> d-cache-line-size = <32>;
> i-cache-line-size = <32>;
> d-cache-size = <0x4000>; // L1, 16K
> i-cache-size = <0x4000>; // L1, 16K
> timebase-frequency = <0>; // from bootloader
> bus-frequency = <0>; // from bootloader
> clock-frequency = <0>; // from bootloader
> };
> };
>
> memory {
> device_type = "memory";
> reg = <0x00000000 0x04000000>; // 64MB
> //reg = <0x00000000 0x08000000>; // 64MB
> //reg = <0x00000000 0x10000000>; // 256MB
> };
>
> soc5200@domain.hid {
> #address-cells = <1>;
> #size-cells = <1>;
> compatible = "fsl,mpc5200b-immr";
> ranges = <0 0xf0000000 0x0000c000>;
> reg = <0xf0000000 0x00000100>;
> bus-frequency = <0>; // from bootloader
> system-frequency = <0>; // from bootloader
>
> cdm@domain.hid {
> compatible = "fsl,mpc5200b-cdm","fsl,mpc5200-cdm";
> reg = <0x200 0x38>;
> };
>
> mpc5200_pic: interrupt-controller@domain.hid {
> // 5200 interrupts are encoded into two levels;
> interrupt-controller;
> #interrupt-cells = <3>;
> device_type = "interrupt-controller";
> compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
> reg = <0x500 0x80>;
> };
>
> // General Purpose Timer
> timer@domain.hid {
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <0>;
> reg = <0x600 0x10>;
> interrupts = <1 9 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl,has-wdt;
> };
>
> timer@domain.hid {
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <1>;
> reg = <0x610 0x10>;
> interrupts = <1 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> timer@domain.hid {
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <2>;
> reg = <0x620 0x10>;
> interrupts = <1 11 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> timer@domain.hid {
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <3>;
> reg = <0x630 0x10>;
> interrupts = <1 12 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> timer@domain.hid {
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <4>;
> reg = <0x640 0x10>;
> interrupts = <1 13 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> timer@domain.hid {
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <5>;
> reg = <0x650 0x10>;
> interrupts = <1 14 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> timer@domain.hid {
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <6>;
> reg = <0x660 0x10>;
> interrupts = <1 15 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> timer@domain.hid {
> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
> cell-index = <7>;
> reg = <0x670 0x10>;
> interrupts = <1 16 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> rtc@domain.hid { // Real time clock
> compatible = "fsl,mpc5200b-rtc","fsl,mpc5200-rtc";
> device_type = "rtc";
> reg = <0x800 0x100>;
> interrupts = <1 5 0 1 6 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> can@domain.hid {
> compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
> cell-index = <0>;
> interrupts = <2 17 0>;
> interrupt-parent = <&mpc5200_pic>;
> reg = <0x900 0x80>;
> };
>
> can@domain.hid {
> compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
> cell-index = <1>;
> interrupts = <2 18 0>;
> interrupt-parent = <&mpc5200_pic>;
> reg = <0x980 0x80>;
> };
>
> gpio@domain.hid {
> compatible = "fsl,mpc5200b-gpio","fsl,mpc5200-gpio";
> reg = <0xb00 0x40>;
> interrupts = <1 7 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> gpio@domain.hid {
> compatible = "fsl,mpc5200b-gpio-wkup","fsl,mpc5200-gpio-wkup";
> reg = <0xc00 0x40>;
> interrupts = <1 8 0 0 3 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> spi@domain.hid {
> compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
> reg = <0xf00 0x20>;
> interrupts = <2 13 0 2 14 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> usb@domain.hid {
> compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci","ohci-be";
> reg = <0x1000 0xff>;
> interrupts = <2 6 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> dma-controller@domain.hid {
> device_type = "dma-controller";
> compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
> reg = <0x1200 0x80>;
> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
> 3 4 0 3 5 0 3 6 0 3 7 0
> 3 8 0 3 9 0 3 10 0 3 11 0
> 3 12 0 3 13 0 3 14 0 3 15 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> xlb@domain.hid {
> compatible = "fsl,mpc5200b-xlb","fsl,mpc5200-xlb";
> reg = <0x1f00 0x100>;
> };
>
> serial@domain.hid { // PSC1
> device_type = "serial";
> compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
> port-number = <0>; // Logical port assignment
> cell-index = <0>;
> reg = <0x2000 0x100>;
> interrupts = <2 1 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> serial@domain.hid { // PSC2
> device_type = "serial";
> compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
> cell-index = <1>;
> port-number = <1>;
> reg = <0x2200 0x100>;
> interrupts = <2 2 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
>
> spi@domain.hid { // PSC3 in spi mode
> compatible = "fsl,mpc5200b-psc-spi","fsl,mpc5200-psc-spi";
> cell-index = <2>;
> port-number = <2>;
> reg = <0x2400 0x100>;
> interrupts = <2 3 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> // PSC3 in CODEC mode example
> //i2s@domain.hid { // PSC3
> // compatible = "fsl,mpc5200b-psc-i2s"; //not 5200 compatible
> // cell-index = <2>;
> // reg = <0x2400 0x100>;
> // interrupts = <2 3 0>;
> // interrupt-parent = <&mpc5200_pic>;
> //};
>
> //serial@domain.hid { // PSC3
> // device_type = "serial";
> // compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
> // cell-index = <2>;
> // reg = <0x2400 0x100>;
> // interrupts = <2 3 0>;
> // interrupt-parent = <&mpc5200_pic>;
> //};
>
> serial@domain.hid { // PSC4 uart
> device_type = "serial";
> compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
> cell-index = <3>;
> port-number = <3>;
> reg = <0x2600 0x100>;
> interrupts = <2 11 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> serial@domain.hid { // PSC5 uart
> device_type = "serial";
> compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
> cell-index = <4>;
> port-number = <4>;
> reg = <0x2800 0x100>;
> interrupts = <2 12 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> // PSC6 in spi mode example
> spi@domain.hid { // PSC6
> compatible = "fsl,mpc5200b-psc-spi","fsl,mpc5200-psc-spi";
> cell-index = <5>;
> port-number = <5>;
> reg = <0x2c00 0x100>;
> interrupts = <2 4 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
>
> //serial@domain.hid { // PSC6 in UART mode
> // device_type = "serial";
> // compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
> // cell-index = <5>;
> // port-number = <5>;
> // reg = <0x2c00 0x100>;
> // interrupts = <2 4 0>;
> // interrupt-parent = <&mpc5200_pic>;
> //};
>
>
> ethernet@domain.hid {
> device_type = "network";
> compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
> reg = <0x3000 0x400>;
> local-mac-address = [ 00 00 00 00 00 00 ];
> interrupts = <2 5 0>;
> interrupt-parent = <&mpc5200_pic>;
> phy-handle = <&phy0>;
> };
>
> mdio@domain.hid {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mpc5200b-mdio", "fsl,mpc5200-mdio";
> reg = <0x3000 0x400>; // fec range, since we need to
> setup fec interrupts
> interrupts = <2 5 0>; // these are for "mii command
> finished", not link changes & co.
> interrupt-parent = <&mpc5200_pic>;
>
> phy0: ethernet-phy@domain.hid {
> device_type = "ethernet-phy";
> reg = <0>;
> };
> };
>
> ata@domain.hid {
> device_type = "ata";
> compatible = "fsl,mpc5200b-ata","fsl,mpc5200-ata";
> reg = <0x3a00 0x100>;
> interrupts = <2 7 0>;
> interrupt-parent = <&mpc5200_pic>;
> };
>
> i2c@domain.hid {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
> cell-index = <0>;
> reg = <0x3d00 0x40>;
> interrupts = <2 15 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
> };
>
> i2c@domain.hid {
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
> cell-index = <1>;
> reg = <0x3d40 0x40>;
> interrupts = <2 16 0>;
> interrupt-parent = <&mpc5200_pic>;
> fsl5200-clocking;
> rtc@domain.hid {
> device_type = "rtc";
> compatible = "epson,pcf8563";
> reg = <0x51>;
> };
> };
> sram@domain.hid {
> compatible = "fsl,mpc5200b-sram","fsl,mpc5200-sram","sram";
> reg = <0x8000 0x4000>;
> };
> };
>
> pci@domain.hid {
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> device_type = "pci";
> compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
> reg = <0xf0000d00 0x100>;
> interrupt-map-mask = <0xf800 0 0 7>;
> interrupt-map = <0xc000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
> 0xc000 0 0 2 &mpc5200_pic 1 1 3
> 0xc000 0 0 3 &mpc5200_pic 1 2 3
> 0xc000 0 0 4 &mpc5200_pic 1 3 3
>
> 0xc800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
> 0xc800 0 0 2 &mpc5200_pic 1 2 3
> 0xc800 0 0 3 &mpc5200_pic 1 3 3
> 0xc800 0 0 4 &mpc5200_pic 0 0 3>;
> clock-frequency = <0>; // From boot loader
> interrupts = <2 8 0 2 9 0 2 10 0>;
> interrupt-parent = <&mpc5200_pic>;
> bus-range = <0 0>;
> ranges = <0x42000000 0 0x80000000 0x80000000 0 0x20000000
> 0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
> 0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
> };
> };
>
> Ideas? Thanks for your help
>
> Philippe Gerum wrote:
>> Federico Ridolfo wrote:
>>
>>> Hi all,
>>> my platform is a mpc5200b based one. I wrote
>>> some rtdm driver for that platform on linux-2.6.18
>>> kernel. Some info:
>>> - ARCH=ppc
>>> - no fdt (so no dts)
>>> - u-boot
>>> - xenomai 2.3.2,
>>> - adeos-ipipe-2.6.18-ppc-1.5-01.patch
>>> All works fine.
>>>
>>> Now i want to use:
>>> - ARCH = powerpc
>>> - linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
>>> - fdt (so i have a dts file)
>>> - xenomai-2.4.6.1
>>> - u-boot
>>> Ok. My board boots, all peripheral s work. Xenomai works, but
>>> my rtdm drivers don't work. The problem is that the rtdm_irq_request
>>> returns -ENODEV coming from line 166 in wrappers.h:
>>> ...
>>> #else /* > 2.6.19 */
>>> #define rthal_irq_chip_enable(irq) \
>>> ({ \
>>> int __err__ = 0; \
>>> if (unlikely(rthal_irq_handlerp(irq)->unmask == NULL)) \
>>> __err__ = -ENODEV; \
>>> else \
>>> rthal_irq_handlerp(irq)->unmask(irq); \
>>> __err__; \
>>> })
>>> ...
>>> Seems that adeos doesn't not set the unmask function. In the linux kernel
>>> the right functions for my pic in in
>>> arch/powerpc/platforms/52xx/mpc52xx_pic.c
>>> I thing i have to add some code in mpc52xx_pic.c in order to match
>>> device tree table
>>>
>> To complete my previous answer: unless you have a very particular hw design, it
>> is unlikely that the PIC code is missing anything to support your board.
>>
>>
>>> and also something in my dts file.
>>>
>> However, a too generic device tree description may not reflect all the
>> peripherals you have on your board, so yes, updating it may be needed so that
>> the platform code maps the hw interrupt sources you want.
>>
>> I suspect you will have no regular drivers on these IRQs, so /proc/interrupts
>> should not list them.
>>
>> The point is: are those interrupts sources known from the kernel? Enabling the
>> debug switch in arch/powerpc/kernel/irq.c should give you some hints about which
>> hw IRQ sources are actually enumerated then mapped on your board (remember to
>> increase the console_loglevel or set ignore_loglevel to get this ouput). If you
>> don't find those you need, then you will likely want to fix the dts file.
>>
>> Any help is very usefull!!!
>>
>>> Thanks
>>>
>>>
>>> --
>>> chicco
>>>
>>> _______________________________________________
>>> Xenomai-help mailing list
>>> Xenomai-help@domain.hid
>>> https://mail.gna.org/listinfo/xenomai-help
>>>
>>>
>>
>>
>
>
>
--
Philippe.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 18:07 ` Philippe Gerum
@ 2009-01-23 18:18 ` Federico Ridolfo
2009-01-24 9:58 ` Philippe Gerum
0 siblings, 1 reply; 14+ messages in thread
From: Federico Ridolfo @ 2009-01-23 18:18 UTC (permalink / raw)
To: rpm; +Cc: xenomai
Thanks in advance.
~ # modprobe mpc52xx_psc_spi
~ # dmesg
Using mpc5200-simple-platform machine description
Linux version 2.6.26.2-cirneco (root@domain.hid) (gcc version 4.1.0) #1
PREEMPT Fri Jan 23 16:46:14 CET 2009
console [udbg0] enabled
Entering add_active_range(0, 0, 16384) 0 entries of 256 used
PCI host bridge /pci@domain.hid (primary) ranges:
MEM 0x0000000080000000..0x000000009fffffff -> 0x0000000080000000 Prefetch
MEM 0x00000000a0000000..0x00000000afffffff -> 0x00000000a0000000
IO 0x00000000b0000000..0x00000000b0ffffff -> 0x0000000000000000
Top of RAM: 0x4000000, Total RAM: 0x4000000
Memory hole size: 0MB
Zone PFN ranges:
DMA 0 -> 16384
Normal 16384 -> 16384
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 16384
On node 0 totalpages: 16384
DMA zone: 128 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 16256 pages, LIFO batch:3
Normal zone: 0 pages used for memmap
Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256
Kernel command line: console=ttyPSC0 root=/dev/sda3 rw console=ttyPSC0
irq: Allocated host of type 2 @0xc041d2a0
MPC52xx PIC is up and running!
PID hash table entries: 256 (order: 8, 1024 bytes)
time_init: decrementer frequency = 33.000000 MHz
time_init: processor frequency = 396.000000 MHz
clocksource: timebase mult[79364d9] shift[22] registered
clockevent: decrementer mult[872] shift[16] cpu[0]
I-pipe 2.4-03: pipeline enabled.
Console: colour dummy device 80x25
irq: irq_create_mapping(0xc041d2a0, 0x81)
irq: -> using host @c041d2a0
irq: -> obtained virq 129
console handover: boot [udbg0] -> real [ttyPSC0]
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 61180k/65536k available (3304k kernel code, 4288k reserved, 140k
data, 207k bss, 144k init)
Calibrating delay loop... 65.79 BogoMIPS (lpj=131584)
Mount-cache hash table entries: 512
net_namespace: 192 bytes
NET: Registered protocol family 16
irq: irq_create_mapping(0xc041d2a0, 0x8f)
irq: -> using host @c041d2a0
irq: -> obtained virq 143
irq: irq_create_mapping(0xc041d2a0, 0x90)
irq: -> using host @c041d2a0
irq: -> obtained virq 144
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of PCI bridge 1, will remap
PCI: Cannot allocate resource region 1 of PCI bridge 1, will remap
PCI: Bridge: 0000:00:0f.0
IO window: 1000-1fff
MEM window: 0xa0000000-0xa00fffff
PREFETCH window: 0x0000000080000000-0x00000000800fffff
DMA: MPC52xx BestComm driver
DMA: MPC52xx BestComm engine @f0001200 ok !
SCSI subsystem initialized
libata version 3.00 loaded.
Switched to high resolution mode on CPU 0
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
TCP: Hash tables configured (established 2048 bind 2048)
TCP reno registered
NET: Registered protocol family 1
I-pipe: Domain Xenomai registered.
Xenomai: hal/powerpc started.
Xenomai: real-time nucleus v2.5-devel (Flying In A Blue Dream) loaded.
Xenomai: debug mode enabled.
Xenomai: starting native API services.
Xenomai: starting POSIX services.
Xenomai: starting RTDM services.
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 119
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
pci 0000:01:04.0: Firmware left e100 interrupts enabled; disabling
pci 0000:01:05.0: Firmware left e100 interrupts enabled; disabling
Serial: 8250/16550 driver $Revision: 1.90 $ 16 ports, IRQ sharing enabled
Serial: MPC52xx PSC UART driver
irq: irq_create_mapping(0xc041d2a0, 0x81)
irq: -> using host @c041d2a0
irq: -> existing mapping on virq 129
f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC
irq: irq_create_mapping(0xc041d2a0, 0x82)
irq: -> using host @c041d2a0
irq: -> obtained virq 130
f0002200.serial: ttyPSC1 at MMIO 0xf0002200 (irq = 130) is a MPC52xx PSC
irq: irq_create_mapping(0xc041d2a0, 0x8b)
irq: -> using host @c041d2a0
irq: -> obtained virq 139
f0002600.serial: ttyPSC3 at MMIO 0xf0002600 (irq = 139) is a MPC52xx PSC
irq: irq_create_mapping(0xc041d2a0, 0x8c)
irq: -> using host @c041d2a0
irq: -> obtained virq 140
f0002800.serial: ttyPSC4 at MMIO 0xf0002800 (irq = 140) is a MPC52xx PSC
eepro100.c:v1.09j-t 9/29/99 Donald Becker
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin
<saw@domain.hid> and others
eepro100 0000:01:04.0: enabling device (0006 -> 0007)
eth0: OEM i82557/i82558 10/100 Ethernet, 00:40:42:01:2a:e3, IRQ 0.
Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII
Primary interface chip unknown-15 PHY #31.
Secondary interface chip i82555.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x14c7a6d0).
eepro100 0000:01:05.0: enabling device (0006 -> 0007)
eth1: OEM i82557/i82558 10/100 Ethernet, 00:40:42:01:2a:e4, IRQ 0.
Board assembly ffffff-255, Physical connectors present: RJ45 BNC AUI MII
Primary interface chip unknown-15 PHY #31.
Secondary interface chip i82555.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x14c7a6d0).
e100: Intel(R) PRO/100 Network Driver, 3.5.23-k4-NAPI
e100: Copyright(c) 1999-2006 Intel Corporation
mpc52xx MII bus: probed
irq: irq_create_mapping(0xc041d2a0, 0xc0)
irq: -> using host @c041d2a0
irq: -> obtained virq 192
irq: irq_create_mapping(0xc041d2a0, 0xc1)
irq: -> using host @c041d2a0
irq: -> obtained virq 193
irq: irq_create_mapping(0xc041d2a0, 0x85)
irq: -> using host @c041d2a0
irq: -> obtained virq 133
net eth2: Using PHY at MDIO address 0
Uniform Multi-Platform E-IDE driver
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ide_generic: please use "probe_mask=0x3f" module parameter for probing
all legacy ISA IDE ports
Driver 'sd' needs updating - please use bus_type methods
ata: MPC52xx IDE/ATA libata driver
irq: irq_create_mapping(0xc041d2a0, 0x87)
irq: -> using host @c041d2a0
irq: -> obtained virq 135
scsi0 : mpc52xx_ata
ata1: PATA max PIO4 ata_regs 0xf0003a00 irq 135
ata1.00: ATA-4: TRANSCEND, 20070418, max UDMA/66
ata1.00: 994896 sectors, multi 0: LBA
ata1.00: configured for PIO4
scsi 0:0:0:0: Direct-Access ATA TRANSCEND 2007 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 994896 512-byte hardware sectors (509 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] 994896 512-byte hardware sectors (509 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
physmap flash device (mpc5200): 1000000 at fc000000
phys_mapped_flash: Found 1 x16 devices at 0x0 in 16-bit bank
Amd/Fujitsu Extended Query Table at 0x0040
phys_mapped_flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
i2c /dev entries driver
TCP cubic registered
NET: Registered protocol family 17
802.1Q VLAN Support v1.8 Ben Greear <greearb@domain.hid>
All bugs added by David S. Miller <davem@domain.hid>
kjournald starting. Commit interval 5 seconds
EXT3-fs warning: maximal mount count reached, running e2fsck is recommended
EXT3 FS on sda3, internal journal
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem).
Freeing unused kernel memory: 144k init
rtc-pcf8563 1-0051: chip found, driver version 0.4.3
rtc-pcf8563 1-0051: rtc core: registered rtc-pcf8563 as rtc0
net eth2: attached phy 0 to driver LXT971
rtc-pcf8563 1-0051: low voltage detected, date/time is not reliable.
PPP generic driver version 2.4.2
PHY: f0003000:00 - Link is Up - 100/Full
irq: irq_create_mapping(0xc041d2a0, 0x83)
irq: -> using host @c041d2a0
irq: -> obtained virq 131
mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
(de)activate_cs function will be called
irq: irq_create_mapping(0xc041d2a0, 0x84)
irq: -> using host @c041d2a0
irq: -> obtained virq 132
mpc52xx-psc-spi f0002c00.spi: probe called without platform data, no
(de)activate_cs function will be called
Philippe Gerum wrote:
> Federico Ridolfo wrote:
>
>> Ok, i'm debugging the problem, but i have not a solution.
>> I compiled the kernel with the debug switch for irq.c.
>> In addition i added the mpc52xx_psc_spi module in my
>> .config.
>> So, now i'm sure that the irq used in mpc52xx_psc_spi
>> for the PSC3 is 131 and for PSC6 is 132:
>>
>> # dmesg
>> mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
>> (de)activate_cs function will be called
>> irq: irq_create_mapping(0xc041d2a0, 0x84)
>> irq: -> using host @c041d2a0
>> irq: -> obtained virq 132
>>
>>
>
> Please send all the IRQ related information, you get in the boot log, because
> the few lines above do not match what your dts file below says.
>
> As far as I understand those lines, the generic IRQ code is asked to create a
> virtual mapping for hwirq 132 out of the OF specs, and this hint is kept so that
> you actually get virq 132. So far so good.
>
> However, to get asked for 132, your dts file should have specified an intspec
> which rather looks like { 2 4 <sense-type> } and not { 2 3 <sense-type> } as
> mentioned in the spi@domain.hid block. { 2 3 <sense-type> } for PSC3 in SPI mode would
> rather give us hwirq 131 (the hairy computation determining the hwirq number
> from the inspec is available from mpc52xx_irqhost_xlate()).
>
> So either you are not booting with the blob that matches the dts file below, or
> the console output above is misleading. In short, I'm lost.
>
>
>> I'm using the same irqs for my rtdm spi driver, but it doesnìt work.
>> If i reboot the board and try my rtdm driver, the result is -ENODEV
>>
>> If i "modprobe mpc52xx_psc_spi" and retry my rtdm driver -> the board
>> hangs for ever.
>> I have the same result also if i "rrmod mpc52xx_psc_spi" before.
>> My dts is:
>> /dts-v1/;
>>
>> / {
>> model = "colgp,cirneco5200";
>> compatible = "colgp,cirneco5200";
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> cpus {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> PowerPC,5200@domain.hid {
>> device_type = "cpu";
>> reg = <0>;
>> d-cache-line-size = <32>;
>> i-cache-line-size = <32>;
>> d-cache-size = <0x4000>; // L1, 16K
>> i-cache-size = <0x4000>; // L1, 16K
>> timebase-frequency = <0>; // from bootloader
>> bus-frequency = <0>; // from bootloader
>> clock-frequency = <0>; // from bootloader
>> };
>> };
>>
>> memory {
>> device_type = "memory";
>> reg = <0x00000000 0x04000000>; // 64MB
>> //reg = <0x00000000 0x08000000>; // 64MB
>> //reg = <0x00000000 0x10000000>; // 256MB
>> };
>>
>> soc5200@domain.hid {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "fsl,mpc5200b-immr";
>> ranges = <0 0xf0000000 0x0000c000>;
>> reg = <0xf0000000 0x00000100>;
>> bus-frequency = <0>; // from bootloader
>> system-frequency = <0>; // from bootloader
>>
>> cdm@domain.hid {
>> compatible = "fsl,mpc5200b-cdm","fsl,mpc5200-cdm";
>> reg = <0x200 0x38>;
>> };
>>
>> mpc5200_pic: interrupt-controller@domain.hid {
>> // 5200 interrupts are encoded into two levels;
>> interrupt-controller;
>> #interrupt-cells = <3>;
>> device_type = "interrupt-controller";
>> compatible = "fsl,mpc5200b-pic","fsl,mpc5200-pic";
>> reg = <0x500 0x80>;
>> };
>>
>> // General Purpose Timer
>> timer@domain.hid {
>> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>> cell-index = <0>;
>> reg = <0x600 0x10>;
>> interrupts = <1 9 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> fsl,has-wdt;
>> };
>>
>> timer@domain.hid {
>> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>> cell-index = <1>;
>> reg = <0x610 0x10>;
>> interrupts = <1 10 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> timer@domain.hid {
>> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>> cell-index = <2>;
>> reg = <0x620 0x10>;
>> interrupts = <1 11 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> timer@domain.hid {
>> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>> cell-index = <3>;
>> reg = <0x630 0x10>;
>> interrupts = <1 12 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> timer@domain.hid {
>> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>> cell-index = <4>;
>> reg = <0x640 0x10>;
>> interrupts = <1 13 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> timer@domain.hid {
>> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>> cell-index = <5>;
>> reg = <0x650 0x10>;
>> interrupts = <1 14 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> timer@domain.hid {
>> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>> cell-index = <6>;
>> reg = <0x660 0x10>;
>> interrupts = <1 15 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> timer@domain.hid {
>> compatible = "fsl,mpc5200b-gpt","fsl,mpc5200-gpt";
>> cell-index = <7>;
>> reg = <0x670 0x10>;
>> interrupts = <1 16 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> rtc@domain.hid { // Real time clock
>> compatible = "fsl,mpc5200b-rtc","fsl,mpc5200-rtc";
>> device_type = "rtc";
>> reg = <0x800 0x100>;
>> interrupts = <1 5 0 1 6 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> can@domain.hid {
>> compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
>> cell-index = <0>;
>> interrupts = <2 17 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> reg = <0x900 0x80>;
>> };
>>
>> can@domain.hid {
>> compatible = "fsl,mpc5200b-mscan","fsl,mpc5200-mscan";
>> cell-index = <1>;
>> interrupts = <2 18 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> reg = <0x980 0x80>;
>> };
>>
>> gpio@domain.hid {
>> compatible = "fsl,mpc5200b-gpio","fsl,mpc5200-gpio";
>> reg = <0xb00 0x40>;
>> interrupts = <1 7 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> gpio@domain.hid {
>> compatible = "fsl,mpc5200b-gpio-wkup","fsl,mpc5200-gpio-wkup";
>> reg = <0xc00 0x40>;
>> interrupts = <1 8 0 0 3 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> spi@domain.hid {
>> compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi";
>> reg = <0xf00 0x20>;
>> interrupts = <2 13 0 2 14 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> usb@domain.hid {
>> compatible = "fsl,mpc5200b-ohci","fsl,mpc5200-ohci","ohci-be";
>> reg = <0x1000 0xff>;
>> interrupts = <2 6 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> dma-controller@domain.hid {
>> device_type = "dma-controller";
>> compatible = "fsl,mpc5200b-bestcomm","fsl,mpc5200-bestcomm";
>> reg = <0x1200 0x80>;
>> interrupts = <3 0 0 3 1 0 3 2 0 3 3 0
>> 3 4 0 3 5 0 3 6 0 3 7 0
>> 3 8 0 3 9 0 3 10 0 3 11 0
>> 3 12 0 3 13 0 3 14 0 3 15 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> xlb@domain.hid {
>> compatible = "fsl,mpc5200b-xlb","fsl,mpc5200-xlb";
>> reg = <0x1f00 0x100>;
>> };
>>
>> serial@domain.hid { // PSC1
>> device_type = "serial";
>> compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
>> port-number = <0>; // Logical port assignment
>> cell-index = <0>;
>> reg = <0x2000 0x100>;
>> interrupts = <2 1 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> serial@domain.hid { // PSC2
>> device_type = "serial";
>> compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
>> cell-index = <1>;
>> port-number = <1>;
>> reg = <0x2200 0x100>;
>> interrupts = <2 2 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>>
>> spi@domain.hid { // PSC3 in spi mode
>> compatible = "fsl,mpc5200b-psc-spi","fsl,mpc5200-psc-spi";
>> cell-index = <2>;
>> port-number = <2>;
>> reg = <0x2400 0x100>;
>> interrupts = <2 3 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> // PSC3 in CODEC mode example
>> //i2s@domain.hid { // PSC3
>> // compatible = "fsl,mpc5200b-psc-i2s"; //not 5200 compatible
>> // cell-index = <2>;
>> // reg = <0x2400 0x100>;
>> // interrupts = <2 3 0>;
>> // interrupt-parent = <&mpc5200_pic>;
>> //};
>>
>> //serial@domain.hid { // PSC3
>> // device_type = "serial";
>> // compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
>> // cell-index = <2>;
>> // reg = <0x2400 0x100>;
>> // interrupts = <2 3 0>;
>> // interrupt-parent = <&mpc5200_pic>;
>> //};
>>
>> serial@domain.hid { // PSC4 uart
>> device_type = "serial";
>> compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
>> cell-index = <3>;
>> port-number = <3>;
>> reg = <0x2600 0x100>;
>> interrupts = <2 11 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> serial@domain.hid { // PSC5 uart
>> device_type = "serial";
>> compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
>> cell-index = <4>;
>> port-number = <4>;
>> reg = <0x2800 0x100>;
>> interrupts = <2 12 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> // PSC6 in spi mode example
>> spi@domain.hid { // PSC6
>> compatible = "fsl,mpc5200b-psc-spi","fsl,mpc5200-psc-spi";
>> cell-index = <5>;
>> port-number = <5>;
>> reg = <0x2c00 0x100>;
>> interrupts = <2 4 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>>
>> //serial@domain.hid { // PSC6 in UART mode
>> // device_type = "serial";
>> // compatible = "fsl,mpc5200b-psc-uart","fsl,mpc5200-psc-uart";
>> // cell-index = <5>;
>> // port-number = <5>;
>> // reg = <0x2c00 0x100>;
>> // interrupts = <2 4 0>;
>> // interrupt-parent = <&mpc5200_pic>;
>> //};
>>
>>
>> ethernet@domain.hid {
>> device_type = "network";
>> compatible = "fsl,mpc5200b-fec","fsl,mpc5200-fec";
>> reg = <0x3000 0x400>;
>> local-mac-address = [ 00 00 00 00 00 00 ];
>> interrupts = <2 5 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> phy-handle = <&phy0>;
>> };
>>
>> mdio@domain.hid {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> compatible = "fsl,mpc5200b-mdio", "fsl,mpc5200-mdio";
>> reg = <0x3000 0x400>; // fec range, since we need to
>> setup fec interrupts
>> interrupts = <2 5 0>; // these are for "mii command
>> finished", not link changes & co.
>> interrupt-parent = <&mpc5200_pic>;
>>
>> phy0: ethernet-phy@domain.hid {
>> device_type = "ethernet-phy";
>> reg = <0>;
>> };
>> };
>>
>> ata@domain.hid {
>> device_type = "ata";
>> compatible = "fsl,mpc5200b-ata","fsl,mpc5200-ata";
>> reg = <0x3a00 0x100>;
>> interrupts = <2 7 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> };
>>
>> i2c@domain.hid {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
>> cell-index = <0>;
>> reg = <0x3d00 0x40>;
>> interrupts = <2 15 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> fsl5200-clocking;
>> };
>>
>> i2c@domain.hid {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> compatible = "fsl,mpc5200b-i2c","fsl,mpc5200-i2c","fsl-i2c";
>> cell-index = <1>;
>> reg = <0x3d40 0x40>;
>> interrupts = <2 16 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> fsl5200-clocking;
>> rtc@domain.hid {
>> device_type = "rtc";
>> compatible = "epson,pcf8563";
>> reg = <0x51>;
>> };
>> };
>> sram@domain.hid {
>> compatible = "fsl,mpc5200b-sram","fsl,mpc5200-sram","sram";
>> reg = <0x8000 0x4000>;
>> };
>> };
>>
>> pci@domain.hid {
>> #interrupt-cells = <1>;
>> #size-cells = <2>;
>> #address-cells = <3>;
>> device_type = "pci";
>> compatible = "fsl,mpc5200b-pci","fsl,mpc5200-pci";
>> reg = <0xf0000d00 0x100>;
>> interrupt-map-mask = <0xf800 0 0 7>;
>> interrupt-map = <0xc000 0 0 1 &mpc5200_pic 0 0 3 // 1st slot
>> 0xc000 0 0 2 &mpc5200_pic 1 1 3
>> 0xc000 0 0 3 &mpc5200_pic 1 2 3
>> 0xc000 0 0 4 &mpc5200_pic 1 3 3
>>
>> 0xc800 0 0 1 &mpc5200_pic 1 1 3 // 2nd slot
>> 0xc800 0 0 2 &mpc5200_pic 1 2 3
>> 0xc800 0 0 3 &mpc5200_pic 1 3 3
>> 0xc800 0 0 4 &mpc5200_pic 0 0 3>;
>> clock-frequency = <0>; // From boot loader
>> interrupts = <2 8 0 2 9 0 2 10 0>;
>> interrupt-parent = <&mpc5200_pic>;
>> bus-range = <0 0>;
>> ranges = <0x42000000 0 0x80000000 0x80000000 0 0x20000000
>> 0x02000000 0 0xa0000000 0xa0000000 0 0x10000000
>> 0x01000000 0 0x00000000 0xb0000000 0 0x01000000>;
>> };
>> };
>>
>> Ideas? Thanks for your help
>>
>> Philippe Gerum wrote:
>>
>>> Federico Ridolfo wrote:
>>>
>>>
>>>> Hi all,
>>>> my platform is a mpc5200b based one. I wrote
>>>> some rtdm driver for that platform on linux-2.6.18
>>>> kernel. Some info:
>>>> - ARCH=ppc
>>>> - no fdt (so no dts)
>>>> - u-boot
>>>> - xenomai 2.3.2,
>>>> - adeos-ipipe-2.6.18-ppc-1.5-01.patch
>>>> All works fine.
>>>>
>>>> Now i want to use:
>>>> - ARCH = powerpc
>>>> - linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
>>>> - fdt (so i have a dts file)
>>>> - xenomai-2.4.6.1
>>>> - u-boot
>>>> Ok. My board boots, all peripheral s work. Xenomai works, but
>>>> my rtdm drivers don't work. The problem is that the rtdm_irq_request
>>>> returns -ENODEV coming from line 166 in wrappers.h:
>>>> ...
>>>> #else /* > 2.6.19 */
>>>> #define rthal_irq_chip_enable(irq) \
>>>> ({ \
>>>> int __err__ = 0; \
>>>> if (unlikely(rthal_irq_handlerp(irq)->unmask == NULL)) \
>>>> __err__ = -ENODEV; \
>>>> else \
>>>> rthal_irq_handlerp(irq)->unmask(irq); \
>>>> __err__; \
>>>> })
>>>> ...
>>>> Seems that adeos doesn't not set the unmask function. In the linux kernel
>>>> the right functions for my pic in in
>>>> arch/powerpc/platforms/52xx/mpc52xx_pic.c
>>>> I thing i have to add some code in mpc52xx_pic.c in order to match
>>>> device tree table
>>>>
>>>>
>>> To complete my previous answer: unless you have a very particular hw design, it
>>> is unlikely that the PIC code is missing anything to support your board.
>>>
>>>
>>>
>>>> and also something in my dts file.
>>>>
>>>>
>>> However, a too generic device tree description may not reflect all the
>>> peripherals you have on your board, so yes, updating it may be needed so that
>>> the platform code maps the hw interrupt sources you want.
>>>
>>> I suspect you will have no regular drivers on these IRQs, so /proc/interrupts
>>> should not list them.
>>>
>>> The point is: are those interrupts sources known from the kernel? Enabling the
>>> debug switch in arch/powerpc/kernel/irq.c should give you some hints about which
>>> hw IRQ sources are actually enumerated then mapped on your board (remember to
>>> increase the console_loglevel or set ignore_loglevel to get this ouput). If you
>>> don't find those you need, then you will likely want to fix the dts file.
>>>
>>> Any help is very usefull!!!
>>>
>>>
>>>> Thanks
>>>>
>>>>
>>>> --
>>>> chicco
>>>>
>>>> _______________________________________________
>>>> Xenomai-help mailing list
>>>> Xenomai-help@domain.hid
>>>> https://mail.gna.org/listinfo/xenomai-help
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 7:32 [Xenomai-help] PowerPC irq unmask Federico Ridolfo
2009-01-23 8:52 ` Philippe Gerum
2009-01-23 10:25 ` Philippe Gerum
@ 2009-01-23 19:29 ` Wolfgang Grandegger
2 siblings, 0 replies; 14+ messages in thread
From: Wolfgang Grandegger @ 2009-01-23 19:29 UTC (permalink / raw)
To: federico.ridolfo; +Cc: xenomai
Federico Ridolfo wrote:
> Hi all,
> my platform is a mpc5200b based one. I wrote
> some rtdm driver for that platform on linux-2.6.18
> kernel. Some info:
> - ARCH=ppc
> - no fdt (so no dts)
> - u-boot
> - xenomai 2.3.2,
> - adeos-ipipe-2.6.18-ppc-1.5-01.patch
> All works fine.
>
> Now i want to use:
> - ARCH = powerpc
> - linux kernel from denx: ipipe-2.6-26-powerpc-2.4-03
> - fdt (so i have a dts file)
> - xenomai-2.4.6.1
> - u-boot
> Ok. My board boots, all peripheral s work. Xenomai works, but
> my rtdm drivers don't work. The problem is that the rtdm_irq_request
> returns -ENODEV coming from line 166 in wrappers.h:
Just to be sure. Are you using OF functions to retrieve the IRQ number?
It's mandetory! Otherwise the interrupt is not known to the system. Just
using the IRQ number does not work any more. You can find various
examples in the kernel how to get and map OF resources, e.g.:
http://lxr.linux.no/linux+v2.6.28.1/drivers/net/fec_mpc52xx.c#L975
And of course, you need proper interrupt definitions in your DTS file.
Wolfgang.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-23 18:18 ` Federico Ridolfo
@ 2009-01-24 9:58 ` Philippe Gerum
2009-01-26 11:35 ` Federico Ridolfo
0 siblings, 1 reply; 14+ messages in thread
From: Philippe Gerum @ 2009-01-24 9:58 UTC (permalink / raw)
To: federico.ridolfo; +Cc: xenomai
Federico Ridolfo wrote:
Ok, things look clearer now. As an introductory remark, the actual OF data does
not match the comments found in your dts file, which does not help at all (e.g.
PSC0 is tagged as PSC1 etc). The device description blob seems to match
otherwise, at least for the PSCs.
> irq: irq_create_mapping(0xc041d2a0, 0x81)
> irq: -> using host @c041d2a0
> irq: -> existing mapping on virq 129
> f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC
> irq: irq_create_mapping(0xc041d2a0, 0x82)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 130
> f0002200.serial: ttyPSC1 at MMIO 0xf0002200 (irq = 130) is a MPC52xx PSC
> irq: irq_create_mapping(0xc041d2a0, 0x8b)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 139
> f0002600.serial: ttyPSC3 at MMIO 0xf0002600 (irq = 139) is a MPC52xx PSC
> irq: irq_create_mapping(0xc041d2a0, 0x8c)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 140
> f0002800.serial: ttyPSC4 at MMIO 0xf0002800 (irq = 140) is a MPC52xx PSC
<snip>
This is where you loaded the psc_psi module, which in turn caused two more IRQs
to be mapped and claimed by the driver. This explains part of the behavior you
observed: at init time, all IRQ descriptors point at a dummy interrupt chip
controller, which has no unmask handler (i.e. NULL); and the kernel provides no
default unmask handler whatsoever.
Therefore, until the psc_spi module is loaded, there is no unmask handler for
PSC3 and PSC6 IRQs, since those have not been mapped and claimed by the driver
yet. Hence, -ENODEV is received when rtdm_irq_request() attempts to enable the line.
Second issue: once the driver is loaded, and you attempt to load your RTDM
driver, the board locks up badly. At that point, you don't receive -ENODEV
anymore since PSC3 and PSC6 IRQs have been mapped, so they do have a valid
unmask handler (unloading your driver won't dispose of the mapping).
This means that your RTDM driver is missing a call to e.g.
irq_of_parse_and_map(), in order to map the PSC3 and PSC6 IRQs you want to use,
and get back their actual virtual numbers to pass to rtdm_irq_request(); as
Wolfgang pointed out, you should go through the OF parsing to get those values,
and never use pre-defined constants now that you depend on a device tree. You
may want to have a look at the CAN drivers in the Xenomai drivers/ area to find
out how to retrieve the OF node that corresponds to some device by name (i.e.
of_find_compatible_node()).
Regarding the lockup, I suspect this has something to do with your RTDM
interrupt handler; the PSC3/PSC6 IRQs are level ones, so your board likely locks
up out of an interrupt storm, due to a bad device acknowledge or something
alike. In any case, you want to fix the IRQ mapping issue first, so that you
don't need to fiddle with the standard psc_spi driver to get those mapped. This
should reduce the number of opportunities for breakage when looking at the
second issue.
> irq: irq_create_mapping(0xc041d2a0, 0x83)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 131
> mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
> (de)activate_cs function will be called
> irq: irq_create_mapping(0xc041d2a0, 0x84)
> irq: -> using host @c041d2a0
> irq: -> obtained virq 132
> mpc52xx-psc-spi f0002c00.spi: probe called without platform data, no
> (de)activate_cs function will be called
>
> Philippe Gerum wrote:
>> Federico Ridolfo wrote:
>>
>>> Ok, i'm debugging the problem, but i have not a solution.
>>> I compiled the kernel with the debug switch for irq.c.
>>> In addition i added the mpc52xx_psc_spi module in my
>>> .config.
>>> So, now i'm sure that the irq used in mpc52xx_psc_spi
>>> for the PSC3 is 131 and for PSC6 is 132:
>>>
>>> # dmesg
>>> mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
>>> (de)activate_cs function will be called
>>> irq: irq_create_mapping(0xc041d2a0, 0x84)
>>> irq: -> using host @c041d2a0
>>> irq: -> obtained virq 132
>>>
>>>
>> Please send all the IRQ related information, you get in the boot log, because
>> the few lines above do not match what your dts file below says.
>>
>> As far as I understand those lines, the generic IRQ code is asked to create a
>> virtual mapping for hwirq 132 out of the OF specs, and this hint is kept so that
>> you actually get virq 132. So far so good.
>>
>> However, to get asked for 132, your dts file should have specified an intspec
>> which rather looks like { 2 4 <sense-type> } and not { 2 3 <sense-type> } as
>> mentioned in the spi@domain.hid block. { 2 3 <sense-type> } for PSC3 in SPI mode would
>> rather give us hwirq 131 (the hairy computation determining the hwirq number
>> from the inspec is available from mpc52xx_irqhost_xlate()).
>>
>> So either you are not booting with the blob that matches the dts file below, or
>> the console output above is misleading. In short, I'm lost.
>>
>>
>>> I'm using the same irqs for my rtdm spi driver, but it doesnìt work.
>>> If i reboot the board and try my rtdm driver, the result is -ENODEV
>>>
>>> If i "modprobe mpc52xx_psc_spi" and retry my rtdm driver -> the board
>>> hangs for ever.
>>> I have the same result also if i "rrmod mpc52xx_psc_spi" before.
>>> My dts is:
>>> /dts-v1/;
>>>
--
Philippe.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-24 9:58 ` Philippe Gerum
@ 2009-01-26 11:35 ` Federico Ridolfo
2009-01-26 14:52 ` Bosko Radivojevic
0 siblings, 1 reply; 14+ messages in thread
From: Federico Ridolfo @ 2009-01-26 11:35 UTC (permalink / raw)
To: rpm; +Cc: xenomai
Thanks, now my rtdm drrivers work!!
You are great.
Philippe Gerum wrote:
> Federico Ridolfo wrote:
>
> Ok, things look clearer now. As an introductory remark, the actual OF data does
> not match the comments found in your dts file, which does not help at all (e.g.
> PSC0 is tagged as PSC1 etc). The device description blob seems to match
> otherwise, at least for the PSCs.
>
>
>> irq: irq_create_mapping(0xc041d2a0, 0x81)
>> irq: -> using host @c041d2a0
>> irq: -> existing mapping on virq 129
>> f0002000.serial: ttyPSC0 at MMIO 0xf0002000 (irq = 129) is a MPC52xx PSC
>> irq: irq_create_mapping(0xc041d2a0, 0x82)
>> irq: -> using host @c041d2a0
>> irq: -> obtained virq 130
>> f0002200.serial: ttyPSC1 at MMIO 0xf0002200 (irq = 130) is a MPC52xx PSC
>> irq: irq_create_mapping(0xc041d2a0, 0x8b)
>> irq: -> using host @c041d2a0
>> irq: -> obtained virq 139
>> f0002600.serial: ttyPSC3 at MMIO 0xf0002600 (irq = 139) is a MPC52xx PSC
>> irq: irq_create_mapping(0xc041d2a0, 0x8c)
>> irq: -> using host @c041d2a0
>> irq: -> obtained virq 140
>> f0002800.serial: ttyPSC4 at MMIO 0xf0002800 (irq = 140) is a MPC52xx PSC
>>
>
> <snip>
>
> This is where you loaded the psc_psi module, which in turn caused two more IRQs
> to be mapped and claimed by the driver. This explains part of the behavior you
> observed: at init time, all IRQ descriptors point at a dummy interrupt chip
> controller, which has no unmask handler (i.e. NULL); and the kernel provides no
> default unmask handler whatsoever.
>
> Therefore, until the psc_spi module is loaded, there is no unmask handler for
> PSC3 and PSC6 IRQs, since those have not been mapped and claimed by the driver
> yet. Hence, -ENODEV is received when rtdm_irq_request() attempts to enable the line.
>
> Second issue: once the driver is loaded, and you attempt to load your RTDM
> driver, the board locks up badly. At that point, you don't receive -ENODEV
> anymore since PSC3 and PSC6 IRQs have been mapped, so they do have a valid
> unmask handler (unloading your driver won't dispose of the mapping).
> This means that your RTDM driver is missing a call to e.g.
> irq_of_parse_and_map(), in order to map the PSC3 and PSC6 IRQs you want to use,
> and get back their actual virtual numbers to pass to rtdm_irq_request(); as
> Wolfgang pointed out, you should go through the OF parsing to get those values,
> and never use pre-defined constants now that you depend on a device tree. You
> may want to have a look at the CAN drivers in the Xenomai drivers/ area to find
> out how to retrieve the OF node that corresponds to some device by name (i.e.
> of_find_compatible_node()).
>
> Regarding the lockup, I suspect this has something to do with your RTDM
> interrupt handler; the PSC3/PSC6 IRQs are level ones, so your board likely locks
> up out of an interrupt storm, due to a bad device acknowledge or something
> alike. In any case, you want to fix the IRQ mapping issue first, so that you
> don't need to fiddle with the standard psc_spi driver to get those mapped. This
> should reduce the number of opportunities for breakage when looking at the
> second issue.
>
>
>> irq: irq_create_mapping(0xc041d2a0, 0x83)
>> irq: -> using host @c041d2a0
>> irq: -> obtained virq 131
>> mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
>> (de)activate_cs function will be called
>> irq: irq_create_mapping(0xc041d2a0, 0x84)
>> irq: -> using host @c041d2a0
>> irq: -> obtained virq 132
>> mpc52xx-psc-spi f0002c00.spi: probe called without platform data, no
>> (de)activate_cs function will be called
>>
>> Philippe Gerum wrote:
>>
>>> Federico Ridolfo wrote:
>>>
>>>
>>>> Ok, i'm debugging the problem, but i have not a solution.
>>>> I compiled the kernel with the debug switch for irq.c.
>>>> In addition i added the mpc52xx_psc_spi module in my
>>>> .config.
>>>> So, now i'm sure that the irq used in mpc52xx_psc_spi
>>>> for the PSC3 is 131 and for PSC6 is 132:
>>>>
>>>> # dmesg
>>>> mpc52xx-psc-spi f0002400.spi: probe called without platform data, no
>>>> (de)activate_cs function will be called
>>>> irq: irq_create_mapping(0xc041d2a0, 0x84)
>>>> irq: -> using host @c041d2a0
>>>> irq: -> obtained virq 132
>>>>
>>>>
>>>>
>>> Please send all the IRQ related information, you get in the boot log, because
>>> the few lines above do not match what your dts file below says.
>>>
>>> As far as I understand those lines, the generic IRQ code is asked to create a
>>> virtual mapping for hwirq 132 out of the OF specs, and this hint is kept so that
>>> you actually get virq 132. So far so good.
>>>
>>> However, to get asked for 132, your dts file should have specified an intspec
>>> which rather looks like { 2 4 <sense-type> } and not { 2 3 <sense-type> } as
>>> mentioned in the spi@domain.hid block. { 2 3 <sense-type> } for PSC3 in SPI mode would
>>> rather give us hwirq 131 (the hairy computation determining the hwirq number
>>> from the inspec is available from mpc52xx_irqhost_xlate()).
>>>
>>> So either you are not booting with the blob that matches the dts file below, or
>>> the console output above is misleading. In short, I'm lost.
>>>
>>>
>>>
>>>> I'm using the same irqs for my rtdm spi driver, but it doesnìt work.
>>>> If i reboot the board and try my rtdm driver, the result is -ENODEV
>>>>
>>>> If i "modprobe mpc52xx_psc_spi" and retry my rtdm driver -> the board
>>>> hangs for ever.
>>>> I have the same result also if i "rrmod mpc52xx_psc_spi" before.
>>>> My dts is:
>>>> /dts-v1/;
>>>>
>>>>
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-26 11:35 ` Federico Ridolfo
@ 2009-01-26 14:52 ` Bosko Radivojevic
2009-01-27 7:39 ` Federico Ridolfo
0 siblings, 1 reply; 14+ messages in thread
From: Bosko Radivojevic @ 2009-01-26 14:52 UTC (permalink / raw)
To: federico.ridolfo; +Cc: xenomai
Federico,
may you write a small comment regarding what you had to change
(especially regarding OF). Just for the rest of us ;)
Thanks.
On Mon, Jan 26, 2009 at 12:35 PM, Federico Ridolfo
<federico.ridolfo@domain.hid> wrote:
> Thanks, now my rtdm drrivers work!!
> You are great.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [Xenomai-help] PowerPC irq unmask
2009-01-26 14:52 ` Bosko Radivojevic
@ 2009-01-27 7:39 ` Federico Ridolfo
0 siblings, 0 replies; 14+ messages in thread
From: Federico Ridolfo @ 2009-01-27 7:39 UTC (permalink / raw)
To: Bosko Radivojevic; +Cc: xenomai
Sure. I'll describe what i did for SPI driver on PSC3
in order to use OF:
- add a right node in dts file:
spi@domain.hid { // PSC3 in spi mode
compatible = "rtdm-spi","rtdm-spi";
cell-index = <2>;
reg = <0x2400 0x100>;
interrupts = <2 3 0>;
interrupt-parent = <&mpc5200_pic>;
};
- add headers in my rtdm driver:
#if defined(CONFIG_PPC_MERGE)
#include <linux/of.h>
#include <linux/of_platform.h>
#endif
- use OF to get irq in the rtdm driver:
#ifdef CONFIG_PPC_MERGE
/* Use Open Firmware device tree */
struct device_node *np = NULL;
struct resource r[2] = {};
np = of_find_compatible_node(np, NULL, "rtdm-spi");
if (np == NULL)
{
rtdm_printk("np = NULL!??!");
return -ENODEV;
}
ret = of_address_to_resource(np, 0, &r[0]);
if (ret)
{
rtdm_printk("of_address_to_resource returns: %d",ret);
return ret;
}
of_irq_to_resource(np, 0, &r[1]);
intr = r[1].start;
rtdm_printk("irq from OF:%d\n",intr);
#else
intr = MPC52xx_PSC3_IRQ;
#endif
- compile kernel and make dtb
I'm using u-boot 1.3.0 and both uImage, dtb and rootfs
are in a UDMA Compact Flash on ATA.
Ciao
Bosko Radivojevic wrote:
> Federico,
>
> may you write a small comment regarding what you had to change
> (especially regarding OF). Just for the rest of us ;)
>
> Thanks.
>
> On Mon, Jan 26, 2009 at 12:35 PM, Federico Ridolfo
> <federico.ridolfo@domain.hid> wrote:
>
>> Thanks, now my rtdm drrivers work!!
>> You are great.
>>
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-01-27 7:39 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-23 7:32 [Xenomai-help] PowerPC irq unmask Federico Ridolfo
2009-01-23 8:52 ` Philippe Gerum
2009-01-23 9:10 ` Federico Ridolfo
2009-01-23 9:48 ` Philippe Gerum
2009-01-23 10:16 ` Federico Ridolfo
2009-01-23 10:25 ` Philippe Gerum
2009-01-23 17:06 ` Federico Ridolfo
2009-01-23 18:07 ` Philippe Gerum
2009-01-23 18:18 ` Federico Ridolfo
2009-01-24 9:58 ` Philippe Gerum
2009-01-26 11:35 ` Federico Ridolfo
2009-01-26 14:52 ` Bosko Radivojevic
2009-01-27 7:39 ` Federico Ridolfo
2009-01-23 19:29 ` Wolfgang Grandegger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.