[Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request
On 05/09/06, Jan Kiszka <[EMAIL PROTECTED]> wrote:
@Dmitry: What happens under CONFIG_XENO_OPT_SHIRQ_LEVEL &&!CONFIG_XENO_OPT_SHIRQ_EDGE when someone comes along withXN_ISR_SHARED|XN_ISR_EDGE? Looks like the level-triggered shared handlergets installed. Should we catch this? At Kconfig or at nucleus level?
Currently XN_ISR_SHARED and XN_ISR_EDGE are unconditionally available
for any configuration. So nothing stops a user from calling
rtdm_irq_request( ... , RTDM_IRQTYPE_SHARED | RTDM_IRQTYPE_EDGE) even
when IRQ shared infrastructure is off.
(the second call gives -EBUSY and a "bug" report is sent. I mean, if
the user has overlooked "shared irq" section on the configure step and
consider it a default behavior).
Probably the clean solution would be to export XN_ISR_SHARED and
XN_ISR_EDGE only when their corresponding CONFIG_* parameters are
defined.
Then e.g. rtdm skin should do :
#ifdef XN_ISR_SHARED
#define RTDM_IRQTYPE_SHARED XN_ISR_SHARED
#endif
and let a compiler complain on undefined symbol when a user tries to
use SHARED/EDGE without proper CONFIG options. Although, I'm not sure
it would be clear for all users.
Another approach,
in xnintr.h
#ifdef CONFIG_XENO_OPT_SHIRQ_LAYER
#define XN_ISR_SHARED 1
#else
#define XN_ISR_SHARED XN_ISR_WARNING
#endif
and then catch all wrong use cases in one place :
int xnintr_attach(xnintr_t *intr, void *cookie)
{
intr->hits = 0;
intr->cookie = cookie;
+ if (intr->flags & XN_ISR_WARNING) {
+
xnlogerr("blablabla...\n");
+ return -EINVAL;
+ }
#if defined(CONFIG_XENO_OPT_SHIRQ_LEVEL) || defined(CONFIG_XENO_OPT_SHIRQ_EDGE)
return xnintr_shirq_attach(intr, cookie);
#else /* !CONFIG_XENO_OPT_SHIRQ_LEVEL && !CONFIG_XENO_OPT_SHIRQ_EDGE */
return xnarch_hook_irq(intr->irq, &xnintr_irq_handler, intr->iack,
intr);
#endif /* CONFIG_XENO_OPT_SHIRQ_LEVEL || CONFIG_XENO_OPT_SHIRQ_EDGE */
}
?
-- Best regards,Dmitry Adamushko
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request
Wolfgang Grandegger wrote: > Jan Kiszka wrote: >> Hi Wolfgang, >> >> in the process of preparing to merge rtdm_irq_enable into >> rtdm_irq_request I would like to check if the attached patch is ok, thus >> we could finally drop rtdm_irq_enable once the API is refactored. Please >> check carefully when the first IRQs may happen and what the handler >> expects to be initialised! SJA1000 /should/ be ok as it works with > >> shared IRQs, but MSCAN does not (why, BTW?) and /may/ stumble. > > OK. Why should I use shared interrupts if there is no need? Most > embedded PowerPC systems have a dedicated interrupt source. Of course, /me forgot once again that not all the world is designed like crappy x86. :) At this chance I looked over the irq_flag mechanism of the CAN stack and found a minor cleanup: this #ifdef [1] is not required. If there is no sharing support, the subscriber will simply be redirected to the non-shared handler. @Dmitry: What happens under CONFIG_XENO_OPT_SHIRQ_LEVEL && !CONFIG_XENO_OPT_SHIRQ_EDGE when someone comes along with XN_ISR_SHARED|XN_ISR_EDGE? Looks like the level-triggered shared handler gets installed. Should we catch this? At Kconfig or at nucleus level? Jan [1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/sja1000/rtcan_peak_pci.c?v=SVN-trunk#L233 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request
Jan Kiszka wrote:
Hi Wolfgang,
in the process of preparing to merge rtdm_irq_enable into
rtdm_irq_request I would like to check if the attached patch is ok, thus
we could finally drop rtdm_irq_enable once the API is refactored. Please
check carefully when the first IRQs may happen and what the handler
expects to be initialised! SJA1000 /should/ be ok as it works with
shared IRQs, but MSCAN does not (why, BTW?) and /may/ stumble.
OK. Why should I use shared interrupts if there is no need? Most
embedded PowerPC systems have a dedicated interrupt source.
Wolfgang.
Jan
Index: ksrc/drivers/can/mscan/rtcan_mscan.c
===
--- ksrc/drivers/can/mscan/rtcan_mscan.c(revision 1559)
+++ ksrc/drivers/can/mscan/rtcan_mscan.c(working copy)
@@ -801,7 +801,8 @@ int __init rtcan_mscan_init_one(int idx)
printk("ERROR! rtdm_irq_request for IRQ %d failed\n", irq);
goto out_dev_free;
}
-
+rtdm_irq_enable(&dev->irq_handle);
+
mscan_chip_config(regs);
@@ -814,8 +815,6 @@ int __init rtcan_mscan_init_one(int idx)
rtcan_mscan_create_proc(dev);
-rtdm_irq_enable(&dev->irq_handle);
-
/* Remember initialized devices */
rtcan_mscan_devs[idx] = dev;
Index: ksrc/drivers/can/sja1000/rtcan_sja1000.c
===
--- ksrc/drivers/can/sja1000/rtcan_sja1000.c(revision 1559)
+++ ksrc/drivers/can/sja1000/rtcan_sja1000.c(working copy)
@@ -747,6 +747,7 @@ int rtcan_sja1000_register(struct rtcan_
printk("ERROR! IRQ %d busy or invalid (code=%d)!\n", chip->irq_num,
ret);
return ret;
}
+rtdm_irq_enable(&dev->irq_handle);
sja1000_chip_config(dev);
@@ -759,8 +760,6 @@ int rtcan_sja1000_register(struct rtcan_
rtcan_sja_create_proc(dev);
-rtdm_irq_enable(&dev->irq_handle);
-
return 0;
out_irq_free:
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] RTAI Vs Xenomai performance
HI Jan, I am runnng the testsuite given by RTAI and Xenomai, I need to this figures to compare on performance for the doc to port XENOMAI on MIPS. I see RTAI gives results in nanoseconds and XENOMAI in microsecond, so i should say latency with Xenomai is 3000 micrsecond where as RTAI its 3000 Nanosecond , correct me if I am wrong. I have attached both testsuite reults Thanks In Advance Neelu --- Jan Kiszka <[EMAIL PROTECTED]> wrote: > Miguel Angel Alvarez wrote: > > I am also very intrerested in this kind of porting > guidance, because I > > have to evaluate the difficulties in porting > Xenomai (and Adeos) into > > Coldfire v4 (m68k) architecture. > > See this posting for the Adeos part: > > https://mail.gna.org/public/adeos-main/2006-09/msg1.html > > Regarding the porting effort of Xenomai: I would > recommend to browse > through existing architectures, e.g. Blackfin, in > order to asses the > amount and complexity of services you have to deal > with. > > Jan > > __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/== Sampling period: 100 us == Test mode: periodic user-mode task == All results in microseconds warming up... RTT| 00:00:01 (periodic user-mode task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD| 0.363| 1.307| 6.443| 0| 0.363| 6.443 RTD| 0.259| 68.339| 594.219| 5| 0.259| 594.219 RTD| 500.179| 18.290| 506.059| 5| 0.259| 594.219 RTD| 500.254| 18.285| 505.818| 5| 0.259| 594.219 RTD| 500.265| 18.323| 506.288| 5| 0.259| 594.219 RTD| 500.212| 18.288| 508.575| 5| 0.259| 594.219 RTD| 500.354| -2.511|1129.323| 11| 0.259|1129.323 RTD|1100.297| -25.688|1108.217| 11| 0.259|1129.323 RTD|1100.244| -25.686|1108.423| 11| 0.259|1129.323 RTD|1100.177| -25.686|1108.608| 11| 0.259|1129.323 RTD|1100.172| 16.570|1675.939| 16| 0.259|1675.939 RTD|1600.103| -8.670|1608.491| 16| 0.259|1675.939 RTD|1600.266| -8.666|1608.856| 16| 0.259|1675.939 RTD|1600.227| -8.665|1608.532| 16| 0.259|1675.939 RTD|1600.025| -8.662|1608.813| 16| 0.259|1675.939 RTD|1600.415| 29.702|2202.194| 21| 0.259|2202.194 RTD|2100.416| 8.355|2108.844| 21| 0.259|2202.194 RTD|2100.301| 8.355|2108.579| 21| 0.259|2202.194 RTD|2100.323| 8.350|2108.491| 21| 0.259|2202.194 RTD|2100.137| 8.352|2108.733| 21| 0.259|2202.194 RTD|2100.402| 42.772|2661.862| 26| 0.259|2661.862 RTT| 00:00:22 (periodic user-mode task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD|2600.325| 25.370|2608.703| 26| 0.259|2661.862 RTD|2600.041| 25.371|2608.807| 26| 0.259|2661.862 RTD|2600.179| 25.368|2608.871| 26| 0.259|2661.862 RTD|2600.228| 38.876|3201.108| 31| 0.259|3201.108 RTD|3100.178| 42.382|3109.105| 31| 0.259|3201.108 RTD|3098.880| 42.348|3108.497| 31| 0.259|3201.108 RTD|3098.891| 42.361|3109.042| 31| 0.259|3201.108 RTD|3100.342| 42.399|3108.477| 31| 0.259|3201.108 RTD|3100.263| 52.008|3648.872| 36| 0.259|3648.872 RTD|3600.352| 59.412|3608.707| 36| 0.259|3648.872 RTD|3600.307| 59.408|3608.992| 36| 0.259|3648.872 RTD|3600.490| 59.400|3608.473| 36| 0.259|3648.872 RTD|3600.300| 59.404|3609.087| 36| 0.259|3648.872 RTD|3600.145| 65.078|4192.166| 41| 0.259|4192.166 RTD|3748.422| 76.426|4108.637| 41| 0.259|4192.166 RTD|3748.422| 76.424|4108.577| 41| 0.259|4192.166 RTD|3748.422| 76.427|4108.534| 41| 0.259|4192.166 RTD|3748.422| 76.423|4108.954| 41| 0.259|4192.166 RTD|3748.422| 14.152|4725.161| 47| 0.259|4725.161 RTD|3748.422| 32.450|4708.704| 47| 0.259|4725.161 RTD|3748.422| 32.474|4708.777| 47| 0.259|4725.161 RTT| 00:00:43 (periodic user-mode task, 100 us period) RTH|-lat min|-lat avg|-lat max|-overrun|lat best|---lat worst RTD|3748.422| 32.828|4709.
[Xenomai-core] Re: RTAI Vs Xenomai performance
Hi Neelu,
please start a new thread when switching the topic, don't reply to
existing ones (CC'ing people who may not want this).
somshekar kadam wrote:
> HI Jan,
>
> I am runnng the testsuite given by RTAI and Xenomai,
>
> I need to this figures to compare on performance for
> the doc to port XENOMAI on MIPS.
>
> I see RTAI gives results in nanoseconds and XENOMAI in
> microsecond, so i should say latency with Xenomai is
> 3000 micrsecond where as RTAI its 3000 Nanosecond ,
> correct me if I am wrong.
RTAI is in nanoseconds as Xenomai used to be in early days, but its
results are as broken as Xenomai's (watch out for the maximum!).
> I have attached both testsuite reults
You likely have a SMI problem, see TROUBLESHOOTING for details.
This makes me wonder if some simple test ("dmesg | grep
CONFIG_XENO_HW_SMI_WORKAROUND") in latency or at least in xeno_test to
detect this may make this FAQ less frequent... :)
Jan
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] RTAI Vs Xenomai performance
somshekar kadam wrote: > HI Jan, > > I am runnng the testsuite given by RTAI and Xenomai, > > I need to this figures to compare on performance for > the doc to port XENOMAI on MIPS. > > I see RTAI gives results in nanoseconds and XENOMAI in > microsecond, so i should say latency with Xenomai is > 3000 micrsecond where as RTAI its 3000 Nanosecond , > correct me if I am wrong. > I have attached both testsuite reults As indicated by the overruns count, you have a hardware problem, most likely an issue with SMIs, or power management. Please read the TROUBLESHOOTING file. -- Gilles Chanteperdrix. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Move rtdm_irq_enable close to rtdm_irq_request
Hi Wolfgang,
in the process of preparing to merge rtdm_irq_enable into
rtdm_irq_request I would like to check if the attached patch is ok, thus
we could finally drop rtdm_irq_enable once the API is refactored. Please
check carefully when the first IRQs may happen and what the handler
expects to be initialised! SJA1000 /should/ be ok as it works with
shared IRQs, but MSCAN does not (why, BTW?) and /may/ stumble.
Jan
Index: ksrc/drivers/can/mscan/rtcan_mscan.c
===
--- ksrc/drivers/can/mscan/rtcan_mscan.c(revision 1559)
+++ ksrc/drivers/can/mscan/rtcan_mscan.c(working copy)
@@ -801,7 +801,8 @@ int __init rtcan_mscan_init_one(int idx)
printk("ERROR! rtdm_irq_request for IRQ %d failed\n", irq);
goto out_dev_free;
}
-
+rtdm_irq_enable(&dev->irq_handle);
+
mscan_chip_config(regs);
@@ -814,8 +815,6 @@ int __init rtcan_mscan_init_one(int idx)
rtcan_mscan_create_proc(dev);
-rtdm_irq_enable(&dev->irq_handle);
-
/* Remember initialized devices */
rtcan_mscan_devs[idx] = dev;
Index: ksrc/drivers/can/sja1000/rtcan_sja1000.c
===
--- ksrc/drivers/can/sja1000/rtcan_sja1000.c(revision 1559)
+++ ksrc/drivers/can/sja1000/rtcan_sja1000.c(working copy)
@@ -747,6 +747,7 @@ int rtcan_sja1000_register(struct rtcan_
printk("ERROR! IRQ %d busy or invalid (code=%d)!\n", chip->irq_num,
ret);
return ret;
}
+rtdm_irq_enable(&dev->irq_handle);
sja1000_chip_config(dev);
@@ -759,8 +760,6 @@ int rtcan_sja1000_register(struct rtcan_
rtcan_sja_create_proc(dev);
-rtdm_irq_enable(&dev->irq_handle);
-
return 0;
out_irq_free:
signature.asc
Description: OpenPGP digital signature
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
somshekar kadam wrote: > Hi Jan, > > To begin with porting I need some help you people, > I dont see an announcement of Xenomai start, who are > the Authors and maintainers of this I know were very > well its you and Philipe Gerum and others also whom i > dont know. As I need to put all this in a document , > can help me on this. Mmh, I'm not yet sure I understood completely what you are looking for, but if its the start of Xenomai 2 + its history, this may help: https://mail.gna.org/public/rtai-dev/2005-10/msg2.html More contributors can be found in the CREDITS file, including those who work on important parts that don't show up in the ChangeLog. A comprehensive roadmap document is in the making, but we cannot provide a concrete release date yet. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
Miguel Angel Alvarez wrote: > I am also very intrerested in this kind of porting guidance, because I > have to evaluate the difficulties in porting Xenomai (and Adeos) into > Coldfire v4 (m68k) architecture. See this posting for the Adeos part: https://mail.gna.org/public/adeos-main/2006-09/msg1.html Regarding the porting effort of Xenomai: I would recommend to browse through existing architectures, e.g. Blackfin, in order to asses the amount and complexity of services you have to deal with. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
Hi Jan, To begin with porting I need some help you people, I dont see an announcement of Xenomai start, who are the Authors and maintainers of this I know were very well its you and Philipe Gerum and others also whom i dont know. As I need to put all this in a document , can help me on this. Thanks In Advance Neelu my nick name --- Jan Kiszka <[EMAIL PROTECTED]> wrote: > somshekar kadam wrote: > > Hi All, > > > > After a good study with help of mailing list, we > fix > > on porting Xenomai to our ustom board running with > > Mips4k . > > Nice to hear. :) > > > what I understand is we have Adeos with Xenomai, > and > > realtime capability of Xenomai. > > Yep. > > > > > our ultimate goal is realtime. To Begin with port > of > > Xenomai I would like to know , in case is there a > > porting doc or some pointer which help to > understand > > Xenomai better and quick, to go ahead. > > Please comment on this. > > Your first step still remains the fairly independent > port of Adeos/Ipipe > over MIPS. Philippe already pointed out the > available resources. Start > over a recent vanilla kernel (or do you need special > patches for your > targets?), make Linux boot with Ipipe enabled, then > stress the event > pipeline with a simple Ipipe test module. > > Once this works you can proceed to Xenomai, porting > over what's under > ksrc/arch/ and include/asm-. Not all > internal functions may > be documented. Try to grab their meaning from other > archs and/or their > usage - or ask on this list. > > Another hint: post your patches early even if they > do not work yet. We > may have a look and comment on style and > functionality. This will make > it easier to finally merge them (which should be > your goal to ease > long-term maintenance). And it may attract early > adopters that can > provide further feedback and test results. > > Jan > > __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
somshekar kadam wrote: > Hi All, > > After a good study with help of mailing list, we fix > on porting Xenomai to our ustom board running with > Mips4k . Nice to hear. :) > what I understand is we have Adeos with Xenomai, and > realtime capability of Xenomai. Yep. > > our ultimate goal is realtime. To Begin with port of > Xenomai I would like to know , in case is there a > porting doc or some pointer which help to understand > Xenomai better and quick, to go ahead. > Please comment on this. Your first step still remains the fairly independent port of Adeos/Ipipe over MIPS. Philippe already pointed out the available resources. Start over a recent vanilla kernel (or do you need special patches for your targets?), make Linux boot with Ipipe enabled, then stress the event pipeline with a simple Ipipe test module. Once this works you can proceed to Xenomai, porting over what's under ksrc/arch/ and include/asm-. Not all internal functions may be documented. Try to grab their meaning from other archs and/or their usage - or ask on this list. Another hint: post your patches early even if they do not work yet. We may have a look and comment on style and functionality. This will make it easier to finally merge them (which should be your goal to ease long-term maintenance). And it may attract early adopters that can provide further feedback and test results. Jan signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai port to MIPS
somshekar kadam wrote: Hi All, After a good study with help of mailing list, we fix on porting Xenomai to our ustom board running with Mips4k . what I understand is we have Adeos with Xenomai, and realtime capability of Xenomai. our ultimate goal is realtime. To Begin with port of Xenomai I would like to know , in case is there a porting doc or some pointer which help to understand Xenomai better and quick, to go ahead. Please comment on this. Thanks In Advance Neelu __ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.com/ ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core I am also very intrerested in this kind of porting guidance, because I have to evaluate the difficulties in porting Xenomai (and Adeos) into Coldfire v4 (m68k) architecture. Thanks Miguel Ángel - PLEASE NOTE --- This message, along with any attachments, may be confidential or legally privileged. It is intended only for the named person(s), who is/are the only authorized recipients. If this message has reached you in error, kindly destroy it without review and notify the sender immediately. Thank you for your help. µSysCom uses virus scanning software but excludes any liability for viruses contained in any attachment. ROGAMOS LEA ESTE TEXTO --- Este mensaje y sus anexos pueden contener información confidencial y/o con derecho legal. Está dirigido únicamente a la/s persona/s o entidad/es reseñadas como único destinatario autorizado. Si este mensaje le hubiera llegado por error, por favor elimínelo sin revisarlo ni reenviarlo y notifíquelo inmediatamente al remitente. Gracias por su colaboración. µSysCom utiliza software antivirus, pero no se hace responsable de los virus contenidos en los ficheros anexos. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
