* [Adeos-main] wake_up_interruptible ? @ 2006-01-21 22:44 Hannes Mayer 2006-01-23 0:44 ` Alexis Berlemont 0 siblings, 1 reply; 12+ messages in thread From: Hannes Mayer @ 2006-01-21 22:44 UTC (permalink / raw) To: adeos-main Hi all! I've got a kernel module which creates a chrdev. In the read file operation I have a interruptible_sleep_on. Now I want to wake it up from an IPIPE interrupt handler (i.e. unblock the read operation from user-space on the chrdev), but I bet wake_up_interruptible is forbidden in HRT context, isn't it ? Thanks and best regards, Hannes. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-21 22:44 [Adeos-main] wake_up_interruptible ? Hannes Mayer @ 2006-01-23 0:44 ` Alexis Berlemont 2006-01-23 10:56 ` Gilles Chanteperdrix 0 siblings, 1 reply; 12+ messages in thread From: Alexis Berlemont @ 2006-01-23 0:44 UTC (permalink / raw) To: adeos-main Hi, > I've got a kernel module which creates a chrdev. > In the read file operation I have a interruptible_sleep_on. > Now I want to wake it up from an IPIPE interrupt handler > (i.e. unblock the read operation from user-space on the > chrdev), but I bet wake_up_interruptible is forbidden > in HRT context, isn't it ? Why not using a semaphore : in your read fops function : down_interruptible(pointer_read_sem); in your IPIPE interrupt handler: up(pointer_read_sem); In an interrupt handler, I think you can use a Linux semaphore. I am quite sure semaphores are used in the Xenomai pipe implementation. Best regards. Alexis. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-23 0:44 ` Alexis Berlemont @ 2006-01-23 10:56 ` Gilles Chanteperdrix 2006-01-24 17:08 ` Hannes Mayer 0 siblings, 1 reply; 12+ messages in thread From: Gilles Chanteperdrix @ 2006-01-23 10:56 UTC (permalink / raw) To: adeos-main Alexis Berlemont wrote: > Hi, > > > > I've got a kernel module which creates a chrdev. > > In the read file operation I have a interruptible_sleep_on. > > Now I want to wake it up from an IPIPE interrupt handler > > (i.e. unblock the read operation from user-space on the > > chrdev), but I bet wake_up_interruptible is forbidden > > in HRT context, isn't it ? > > Why not using a semaphore : > > in your read fops function : > > down_interruptible(pointer_read_sem); > > in your IPIPE interrupt handler: > > up(pointer_read_sem); > > In an interrupt handler, I think you can use a Linux semaphore. I am quite > sure semaphores are used in the Xenomai pipe implementation. For the "up" function to work properly, Linux scheduler data have to be in a consistent state. But with the IPIPE patch, Linux may be preempted by a higher priority domain at any point where hardware interrupts are not disabled, and where scheduler data are not necessarily in a consistent state. One way to wake up a regular Linux thread from a higher priority domain interrupt handler is to propagate this interrupt after HRT processing in higher priority domains and run wake_up_interruptible from Linux domain interrupt handler. -- Gilles Chanteperdrix. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-23 10:56 ` Gilles Chanteperdrix @ 2006-01-24 17:08 ` Hannes Mayer 2006-01-24 19:23 ` Hannes Mayer 0 siblings, 1 reply; 12+ messages in thread From: Hannes Mayer @ 2006-01-24 17:08 UTC (permalink / raw) To: adeos-main Thank you both Alexis and Gilles! I think I'll pass on the blocking chrdev for now until I exactly understand what is allowed and what is not within IPIPE. For now, I'll poll from userspace and see if data is available. I wanted to use the blocking read for notification only anyway. Thanks again, Hannes. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-24 17:08 ` Hannes Mayer @ 2006-01-24 19:23 ` Hannes Mayer 2006-01-24 20:46 ` Alexis Berlemont 2006-01-24 21:08 ` Gilles Chanteperdrix 0 siblings, 2 replies; 12+ messages in thread From: Hannes Mayer @ 2006-01-24 19:23 UTC (permalink / raw) To: adeos-main Gilles, now I think I've got what you mean. Something like this ? inter_domain_irq = ipipe_alloc_virq(); ret = request_irq(inter_domain_irq, linux_handler, SA_INTERRUPT, "virtualIRQ", NULL); enable_irq(inter_domain_irq); void ipipe_handler(unsigned irq) { [...] ipipe_trigger_irq(inter_domain_irq); [...] } void linux_handler(void) { wake_up_interruptible(&skeleton_wait); } I've tried this, but the linux_handler is never called. I bet I'm missing something very trivial here, but it doesn't come to mind... On the other hand, if I request_irq() for the parallelport INT and pass that INT from IPIPE to linux, the linux_handler is called. But it doesn't work with a virq. Thanks and best regards, Hannes. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-24 19:23 ` Hannes Mayer @ 2006-01-24 20:46 ` Alexis Berlemont 2006-01-24 21:16 ` Hannes Mayer 2006-01-24 21:08 ` Gilles Chanteperdrix 1 sibling, 1 reply; 12+ messages in thread From: Alexis Berlemont @ 2006-01-24 20:46 UTC (permalink / raw) To: adeos-main Hi, Sorry for the silly things I said earlier, forgot the most important step : the soft irq... > > Something like this ? > > inter_domain_irq = ipipe_alloc_virq(); > ret = request_irq(inter_domain_irq, linux_handler, SA_INTERRUPT, > "virtualIRQ", NULL); enable_irq(inter_domain_irq); > > void ipipe_handler(unsigned irq) { > [...] > ipipe_trigger_irq(inter_domain_irq); > [...] > } > > void linux_handler(void) { > wake_up_interruptible(&skeleton_wait); > } I think you should not use request_irq() but ipipe_virtualize_irq() : inter_domain_irq = ipipe_alloc_virq(); -ret=request_irq(inter_domain_irq,linux_handler,SA_INTERRUPT,"virtualIRQ",NULL); + ret = ipipe_virtualize_irq(ipipe_root_domain, inter_domain_irq, &ipipe_handler, NULL, NULL, IPIPE_HANDLE_MASK); -enable_irq(inter_domain_irq); Your function linux_handler will be called in the root domain (Linux) any time you use the function ipipe_trigger_irq(...inter_domain_irq...) in a non Linux domain. If you want a good example, you can have a look at the function rthal_init() (in xenomai/ksrc/arch/generic/hal.c) I think you should also double-check what I am saying ;) I am bit tired and .. silly. Thanks Gilles. Alexis. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-24 20:46 ` Alexis Berlemont @ 2006-01-24 21:16 ` Hannes Mayer 2006-01-27 16:44 ` Hannes Mayer 0 siblings, 1 reply; 12+ messages in thread From: Hannes Mayer @ 2006-01-24 21:16 UTC (permalink / raw) To: Alexis Berlemont; +Cc: adeos-main Alexis Berlemont wrote: > Hi, > > Sorry for the silly things I said earlier, forgot the most important step : > the soft irq... > >> Something like this ? >> >> inter_domain_irq = ipipe_alloc_virq(); >> ret = request_irq(inter_domain_irq, linux_handler, SA_INTERRUPT, >> "virtualIRQ", NULL); enable_irq(inter_domain_irq); >> >> void ipipe_handler(unsigned irq) { >> [...] >> ipipe_trigger_irq(inter_domain_irq); >> [...] >> } >> >> void linux_handler(void) { >> wake_up_interruptible(&skeleton_wait); >> } > > I think you should not use request_irq() but ipipe_virtualize_irq() : > > inter_domain_irq = ipipe_alloc_virq(); > -ret=request_irq(inter_domain_irq,linux_handler,SA_INTERRUPT,"virtualIRQ",NULL); > + ret = ipipe_virtualize_irq(ipipe_root_domain, > inter_domain_irq, > &ipipe_handler, > NULL, NULL, > IPIPE_HANDLE_MASK); > -enable_irq(inter_domain_irq); > > Your function linux_handler will be called in the root domain (Linux) any time > you use the function ipipe_trigger_irq(...inter_domain_irq...) in a non Linux > domain. Yes, I thought of this too. I just tried this and it works nicely. I'm just curious if the wake_up_interruptible in the new ipipe-interrupt handler (linux_handler in the above snippet) will affect HRT in any other ipipe-int-handler in the same domain ? Thank you very much and best regards, Hannes. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-24 21:16 ` Hannes Mayer @ 2006-01-27 16:44 ` Hannes Mayer 2006-01-29 10:50 ` Philippe Gerum 0 siblings, 1 reply; 12+ messages in thread From: Hannes Mayer @ 2006-01-27 16:44 UTC (permalink / raw) To: adeos-main; +Cc: Alexis Berlemont, gilles.chanteperdrix Ciao Gilles! Ciao Alexis! Just a quick followup: If I assign an ISR like this inter_domain_irq = ipipe_alloc_virq(); ipipe_virtualize_irq(ipipe_current_domain, inter_domain_irq, (ipipe_irq_handler_t)&wake_up_handler,NULL,NULL,IPIPE_DYNAMIC_MASK); and I have a SYSCALL in the ISR void wake_up_handler(unsigned irq) { wake_up_interruptible(&skeleton_wait); } will that affect other HRT interrupt handlers that *must* remain in HRT ? Thanks a lot, Hannes. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-27 16:44 ` Hannes Mayer @ 2006-01-29 10:50 ` Philippe Gerum 2006-01-30 13:48 ` Hannes Mayer 0 siblings, 1 reply; 12+ messages in thread From: Philippe Gerum @ 2006-01-29 10:50 UTC (permalink / raw) To: Hannes Mayer; +Cc: Alexis Berlemont, adeos-main, gilles.chanteperdrix Hannes Mayer wrote: > Ciao Gilles! Ciao Alexis! > > Just a quick followup: > > If I assign an ISR like this > > inter_domain_irq = ipipe_alloc_virq(); > ipipe_virtualize_irq(ipipe_current_domain, inter_domain_irq, > (ipipe_irq_handler_t)&wake_up_handler,NULL,NULL,IPIPE_DYNAMIC_MASK); > > and I have a SYSCALL in the ISR > > void wake_up_handler(unsigned irq) { > wake_up_interruptible(&skeleton_wait); > } > > will that affect other HRT interrupt handlers that *must* remain > in HRT ? > Nope. > Thanks a lot, > Hannes. > > _______________________________________________ > Adeos-main mailing list > Adeos-main@domain.hid > https://mail.gna.org/listinfo/adeos-main > -- Philippe. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-29 10:50 ` Philippe Gerum @ 2006-01-30 13:48 ` Hannes Mayer 0 siblings, 0 replies; 12+ messages in thread From: Hannes Mayer @ 2006-01-30 13:48 UTC (permalink / raw) To: Philippe Gerum; +Cc: adeos-main Philippe Gerum wrote: [...] >> will that affect other HRT interrupt handlers that *must* remain >> in HRT ? >> > > Nope. Thanks a lot Philippe! Best regards, Hannes. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-24 19:23 ` Hannes Mayer 2006-01-24 20:46 ` Alexis Berlemont @ 2006-01-24 21:08 ` Gilles Chanteperdrix 2006-01-24 21:20 ` Hannes Mayer 1 sibling, 1 reply; 12+ messages in thread From: Gilles Chanteperdrix @ 2006-01-24 21:08 UTC (permalink / raw) To: Hannes Mayer; +Cc: adeos-main Hannes Mayer wrote: > > Gilles, now I think I've got what you mean. > > Something like this ? > > inter_domain_irq = ipipe_alloc_virq(); > ret = request_irq(inter_domain_irq, linux_handler, SA_INTERRUPT, "virtualIRQ", NULL); > enable_irq(inter_domain_irq); > > void ipipe_handler(unsigned irq) { > [...] > ipipe_trigger_irq(inter_domain_irq); > [...] > } > > void linux_handler(void) { > wake_up_interruptible(&skeleton_wait); > } > > > I've tried this, but the linux_handler is never called. > I bet I'm missing something very trivial here, but it > doesn't come to mind... > > On the other hand, if I request_irq() for the parallelport > INT and pass that INT from IPIPE to linux, the linux_handler > is called. But it doesn't work with a virq. If you have a real irq, you do not need to allocate a virtual irq. intall an handler in the HRT domain with ipipe_virtualize_irq(), a handler in the Linux domain with request_irq(), and call ipipe_propagate_irq() from within the HRT domain interrupt handler. -- Gilles Chanteperdrix. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Adeos-main] wake_up_interruptible ? 2006-01-24 21:08 ` Gilles Chanteperdrix @ 2006-01-24 21:20 ` Hannes Mayer 0 siblings, 0 replies; 12+ messages in thread From: Hannes Mayer @ 2006-01-24 21:20 UTC (permalink / raw) To: Gilles Chanteperdrix; +Cc: adeos-main Gilles Chanteperdrix wrote: [...] > If you have a real irq, you do not need to allocate a virtual irq. > > intall an handler in the HRT domain with ipipe_virtualize_irq(), a > handler in the Linux domain with request_irq(), and call > ipipe_propagate_irq() from within the HRT domain interrupt handler. That is solution #2 I already tried and it works :-) But I don't want to block almost all real IRQ's from linux and only propagate when I have data. Instead I prefer to have a more general driver template. But for the private project I'm working on, this solution would be sufficient. Thank you very much and best regards, Hannes. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-01-30 13:48 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-01-21 22:44 [Adeos-main] wake_up_interruptible ? Hannes Mayer 2006-01-23 0:44 ` Alexis Berlemont 2006-01-23 10:56 ` Gilles Chanteperdrix 2006-01-24 17:08 ` Hannes Mayer 2006-01-24 19:23 ` Hannes Mayer 2006-01-24 20:46 ` Alexis Berlemont 2006-01-24 21:16 ` Hannes Mayer 2006-01-27 16:44 ` Hannes Mayer 2006-01-29 10:50 ` Philippe Gerum 2006-01-30 13:48 ` Hannes Mayer 2006-01-24 21:08 ` Gilles Chanteperdrix 2006-01-24 21:20 ` Hannes Mayer
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.