Re: [Xenomai-help] Interrupt numbers
On 12/23/2011 01:38 AM, Terry Fryar wrote: > Using Xenomai 2.60 with 2.6.38 omap kernel on beagleboard xm. > > Trying to use a GPIO pin as an interrupt and catch this in a xenomai > userspace program. Got the GPIO132 pin set as an input and is working fine. > I guess I'll need to set the irq enable register on the omap cpu to enable > it to generate irqs. Now...what irq number do I use in the xenomai > rt_intr_create() function call?? I'm not sure how the omap gpio interrupts > are mapped to the linux kernel/xenomai stuff?? Can I use what's in the > arch/arm/plat-omap/include/plat/irqs.h header file? It appears that each > bank of GPIO pins has it's own interrupt number?? Xenomai uses the same interrupt numbers as linux. But rt_intr_create is deprecated in user-space, you should instead write a driver using the rtdm skin. The enable bit is handled by xenomai when you request the irq at xenomai level. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt numbers
Thanks Gilles!! -Original Message- From: Gilles Chanteperdrix [mailto:gilles.chanteperd...@xenomai.org] Sent: Friday, December 23, 2011 3:45 AM To: Terry Fryar Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Interrupt numbers On 12/23/2011 01:38 AM, Terry Fryar wrote: > Using Xenomai 2.60 with 2.6.38 omap kernel on beagleboard xm. > > Trying to use a GPIO pin as an interrupt and catch this in a xenomai > userspace program. Got the GPIO132 pin set as an input and is working fine. > I guess I'll need to set the irq enable register on the omap cpu to > enable it to generate irqs. Now...what irq number do I use in the > xenomai > rt_intr_create() function call?? I'm not sure how the omap gpio > interrupts are mapped to the linux kernel/xenomai stuff?? Can I use > what's in the arch/arm/plat-omap/include/plat/irqs.h header file? It > appears that each bank of GPIO pins has it's own interrupt number?? Xenomai uses the same interrupt numbers as linux. But rt_intr_create is deprecated in user-space, you should instead write a driver using the rtdm skin. The enable bit is handled by xenomai when you request the irq at xenomai level. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt numbers
On 23/12/11 04:45 AM, Gilles Chanteperdrix wrote: Xenomai uses the same interrupt numbers as linux. But rt_intr_create is deprecated in user-space, you should instead write a driver using the rtdm skin. The enable bit is handled by xenomai when you request the irq at xenomai level. Hi Gilles, We use rt_intr_create in our code. So I am trying to understand the reasons for it being deprecated. So far, I have not been able to see any comments in the code regarding the deprecation or anything in the git log. Can you pl comment on the reasons for deprecating rt_intr_create? Will it be removed in the next release? Rgds, Makarand. -- ___ NOTICE OF CONFIDENTIALITY: This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this e-mail and any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. _ ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt numbers
On 12/23/2011 04:26 PM, Makarand Pradhan wrote: > On 23/12/11 04:45 AM, Gilles Chanteperdrix wrote: >> >> Xenomai uses the same interrupt numbers as linux. But rt_intr_create is >> deprecated in user-space, you should instead write a driver using the >> rtdm skin. The enable bit is handled by xenomai when you request the irq >> at xenomai level. >> > Hi Gilles, > > We use rt_intr_create in our code. So I am trying to understand the > reasons for it being deprecated. So far, I have not been able to see any > comments in the code regarding the deprecation or anything in the git log. Splitting your code between driver and application enforces a clean separation between the two, which helps maintenance, so is good on the long run. > > Can you pl comment on the reasons for deprecating rt_intr_create? Will > it be removed in the next release? We never change ABI in a branch, so, all releases in the 2.6 branch are guaranteed to support the same services as xenomai 2.6.0. But in xenomai 3.0, rt_intr_create will certainly no longer be available. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt numbers
Thanks. On 23/12/11 10:53 AM, Gilles Chanteperdrix wrote: On 12/23/2011 04:26 PM, Makarand Pradhan wrote: On 23/12/11 04:45 AM, Gilles Chanteperdrix wrote: Xenomai uses the same interrupt numbers as linux. But rt_intr_create is deprecated in user-space, you should instead write a driver using the rtdm skin. The enable bit is handled by xenomai when you request the irq at xenomai level. Hi Gilles, We use rt_intr_create in our code. So I am trying to understand the reasons for it being deprecated. So far, I have not been able to see any comments in the code regarding the deprecation or anything in the git log. Splitting your code between driver and application enforces a clean separation between the two, which helps maintenance, so is good on the long run. Can you pl comment on the reasons for deprecating rt_intr_create? Will it be removed in the next release? We never change ABI in a branch, so, all releases in the 2.6 branch are guaranteed to support the same services as xenomai 2.6.0. But in xenomai 3.0, rt_intr_create will certainly no longer be available. -- ___ NOTICE OF CONFIDENTIALITY: This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail and delete this e-mail and any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. _ ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt numbers
I would imagine it was nice, however, to have a userspace interrupt ISR so that flaky code could be debugged in userspace before making it into a driver? -Original Message- From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] On Behalf Of Gilles Chanteperdrix Sent: Friday, December 23, 2011 9:53 AM To: Makarand Pradhan Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Interrupt numbers On 12/23/2011 04:26 PM, Makarand Pradhan wrote: > On 23/12/11 04:45 AM, Gilles Chanteperdrix wrote: >> >> Xenomai uses the same interrupt numbers as linux. But rt_intr_create >> is deprecated in user-space, you should instead write a driver using >> the rtdm skin. The enable bit is handled by xenomai when you request >> the irq at xenomai level. >> > Hi Gilles, > > We use rt_intr_create in our code. So I am trying to understand the > reasons for it being deprecated. So far, I have not been able to see > any comments in the code regarding the deprecation or anything in the git log. Splitting your code between driver and application enforces a clean separation between the two, which helps maintenance, so is good on the long run. > > Can you pl comment on the reasons for deprecating rt_intr_create? Will > it be removed in the next release? We never change ABI in a branch, so, all releases in the 2.6 branch are guaranteed to support the same services as xenomai 2.6.0. But in xenomai 3.0, rt_intr_create will certainly no longer be available. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt numbers
On 12/23/2011 05:16 PM, Terry Fryar wrote: I would imagine it was nice, however, to have a userspace interrupt ISR so that flaky code could be debugged in userspace before making it into a driver? Most interrupts are level sensitive these days, which means that you cannot safely step into the code which is supposed to ack the source device using a debugger, your kernel would be stormed by IRQs before you reach the point where the device request is acked. Remember that userland always runs with hw interrupts enabled, regardless of the domain. Even edge triggered IRQs would not give you any guarantee with respect to device timing requirements. GDB aside, also think about a transition to secondary mode for whatever reason while running in userland prior to acking the device: this would be another source of unexpected delays in the acknowledge path. Debugging work is likely to introduce these issues, unless one refrains from using anything else than rt_printf() for logging/observing the runtime state, but that would not help with level sensitive IRQs anyway. You may want to handle the main application logic that responds to an interrupt in userland through, in which case you need some RTDM driver handling the bottom half of real-time interrupts, which would in turn unblock a task sleeping on some read() or ioctl(), to process the event in userland (i.e. UIO-like for real-time IRQs). The bottom line is that you want the IRQ to be acknowledged at device level from kernel space. Keeping it masked in the PIC while transitioning to user-space would be another option, assuming it is not shared with the regular kernel (sharing between rt and non-rt would be just wrong anyway), if the device permits (infinitely) delayed acknowledges, but I would not recommend this. Typically, a user-space code can be wiped off at any time, leaving the device in a weird state. These are the reasons why I have killed the rt_intr_* API in 3.x, it was way too easy to shoot oneself in the foot (and believe me, I saw quite a few damaged feet in the past years due to this issue). What was missing in this API is a clear hint that some user-provided code should live in kernel space to ack each particular device controlled from userland. Using RTDM to implement such code and synchronize with the application logic in userland is a safe, sane and simple solution. -Original Message- From: xenomai-help-boun...@gna.org [mailto:xenomai-help-boun...@gna.org] On Behalf Of Gilles Chanteperdrix Sent: Friday, December 23, 2011 9:53 AM To: Makarand Pradhan Cc: xenomai-help@gna.org Subject: Re: [Xenomai-help] Interrupt numbers On 12/23/2011 04:26 PM, Makarand Pradhan wrote: On 23/12/11 04:45 AM, Gilles Chanteperdrix wrote: Xenomai uses the same interrupt numbers as linux. But rt_intr_create is deprecated in user-space, you should instead write a driver using the rtdm skin. The enable bit is handled by xenomai when you request the irq at xenomai level. Hi Gilles, We use rt_intr_create in our code. So I am trying to understand the reasons for it being deprecated. So far, I have not been able to see any comments in the code regarding the deprecation or anything in the git log. Splitting your code between driver and application enforces a clean separation between the two, which helps maintenance, so is good on the long run. Can you pl comment on the reasons for deprecating rt_intr_create? Will it be removed in the next release? We never change ABI in a branch, so, all releases in the 2.6 branch are guaranteed to support the same services as xenomai 2.6.0. But in xenomai 3.0, rt_intr_create will certainly no longer be available. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Interrupt numbers
Yeh, this is the direction we were going anyways, as I really only need the irq to trigger an unblock in userland. I've already got a kernel driver written using xenomai, so moving the irq code into a driver won't be a stretch!! -Original Message- From: Philippe Gerum [mailto:r...@xenomai.org] Sent: Friday, December 23, 2011 12:13 PM To: xenomai-help@gna.org Cc: terry.fr...@stcelectronics.com Subject: Re: [Xenomai-help] Interrupt numbers On 12/23/2011 05:16 PM, Terry Fryar wrote: > I would imagine it was nice, however, to have a userspace interrupt > ISR so that flaky code could be debugged in userspace before making it > into a driver? > Most interrupts are level sensitive these days, which means that you cannot safely step into the code which is supposed to ack the source device using a debugger, your kernel would be stormed by IRQs before you reach the point where the device request is acked. Remember that userland always runs with hw interrupts enabled, regardless of the domain. Even edge triggered IRQs would not give you any guarantee with respect to device timing requirements. GDB aside, also think about a transition to secondary mode for whatever reason while running in userland prior to acking the device: this would be another source of unexpected delays in the acknowledge path. Debugging work is likely to introduce these issues, unless one refrains from using anything else than rt_printf() for logging/observing the runtime state, but that would not help with level sensitive IRQs anyway. You may want to handle the main application logic that responds to an interrupt in userland through, in which case you need some RTDM driver handling the bottom half of real-time interrupts, which would in turn unblock a task sleeping on some read() or ioctl(), to process the event in userland (i.e. UIO-like for real-time IRQs). The bottom line is that you want the IRQ to be acknowledged at device level from kernel space. Keeping it masked in the PIC while transitioning to user-space would be another option, assuming it is not shared with the regular kernel (sharing between rt and non-rt would be just wrong anyway), if the device permits (infinitely) delayed acknowledges, but I would not recommend this. Typically, a user-space code can be wiped off at any time, leaving the device in a weird state. These are the reasons why I have killed the rt_intr_* API in 3.x, it was way too easy to shoot oneself in the foot (and believe me, I saw quite a few damaged feet in the past years due to this issue). What was missing in this API is a clear hint that some user-provided code should live in kernel space to ack each particular device controlled from userland. Using RTDM to implement such code and synchronize with the application logic in userland is a safe, sane and simple solution. > -Original Message- > From: xenomai-help-boun...@gna.org > [mailto:xenomai-help-boun...@gna.org] On Behalf Of Gilles > Chanteperdrix > Sent: Friday, December 23, 2011 9:53 AM > To: Makarand Pradhan > Cc: xenomai-help@gna.org > Subject: Re: [Xenomai-help] Interrupt numbers > > On 12/23/2011 04:26 PM, Makarand Pradhan wrote: >> On 23/12/11 04:45 AM, Gilles Chanteperdrix wrote: >>> >>> Xenomai uses the same interrupt numbers as linux. But rt_intr_create >>> is deprecated in user-space, you should instead write a driver using >>> the rtdm skin. The enable bit is handled by xenomai when you request >>> the irq at xenomai level. >>> >> Hi Gilles, >> >> We use rt_intr_create in our code. So I am trying to understand the >> reasons for it being deprecated. So far, I have not been able to see >> any comments in the code regarding the deprecation or anything in the >> git > log. > > Splitting your code between driver and application enforces a clean > separation between the two, which helps maintenance, so is good on the > long run. > >> >> Can you pl comment on the reasons for deprecating rt_intr_create? >> Will it be removed in the next release? > > We never change ABI in a branch, so, all releases in the 2.6 branch > are guaranteed to support the same services as xenomai 2.6.0. > > But in xenomai 3.0, rt_intr_create will certainly no longer be available. -- Philippe. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] How to Adapt ARM I-pipe patch to S3C6410
sorry for the mistake,my ipipe-patch is adeos-ipipe-2.6.37.6-arm-1.18-03 ,and where can I get the new "HowTo" as it maybe out of date. As I said,I add the printascii function in the begin of start_kernel(),but it didn't print out ,so I believe it didn't go to the start_kernel. I also add the printascii function to the arch/arm/kernel/head.S,I found when it run to "enable the mmu" it stopped. I believe the .config file works well before I patch the xenomai .I also believe the xenomai has nothing to do with the setup of hardware before the kernel startup. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
