All of lore.kernel.org
 help / color / mirror / Atom feed
* [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 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 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: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

* 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

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.