[Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request

2006-09-05 Thread Dmitry Adamushko
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

2006-09-05 Thread Jan Kiszka
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

2006-09-05 Thread Wolfgang Grandegger

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

2006-09-05 Thread somshekar kadam
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

2006-09-05 Thread Jan Kiszka
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

2006-09-05 Thread Gilles Chanteperdrix
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

2006-09-05 Thread Jan Kiszka
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

2006-09-05 Thread Jan Kiszka
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

2006-09-05 Thread Jan Kiszka
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

2006-09-05 Thread somshekar kadam

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

2006-09-05 Thread Jan Kiszka
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

2006-09-05 Thread Miguel Angel Alvarez

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