Re: Question regarding Interrupt "delivery" to user mode process

Re: Question regarding Interrupt "delivery" to user mode process

[David Bruce]

The below link contain code snippets that process SONET events via an 
interrupt. Basically an user space application waits on an ioctl call 
for events that are queued. These events are queued via a kernel thread 
that waits on a wait_event_interruptible call. When an interupt happens 
the thread processes the events, timestamps them and puts a message on a 
queue.

There is other code that is left out the starts the thread. If you are 
interested...ask.

http://www.geocities.com/dbruce_01721/event.c

RE: Question regarding Interrupt "delivery" to user mode process

[Stephen Warren]

This is certainly do-able.

Take a look at the Gelato project - they actually are able to do whole
user-mode device drivers for PCI. You can probably snag some of their
kernel->user-mode IRQ notification code for what you want.

http://www.gelato.unsw.edu.au/IA64wiki/UserLevelDrivers=20

--=20
Stephen Warren, Software Engineer, NVIDIA, Fort Collins, CO
swarren@nvidia.com        http://www.nvidia.com/
swarren@wwwdotorg.org     http://www.wwwdotorg.org/pgp.html

Question regarding Interrupt "delivery" to user mode process

[Caruso, Nick]

Note that "delivery" is in quotes - I don't mean to actually deliver an
interrupt, but rather to wake the process when the interrupt occurs.

This is a broad question, but I'm hoping someone out there with real
experience in this area can comment on a design idea we're kicking
around.
If there's a better mailing list for asking this type of question,
please tell me!

We are building a device with an MPC5200 processor which needs to detect
incoming pulses at a 13 mSec rate.  We've got this incoming pulse wired
to an IRQ on the MPC5200 and we now need a method for detecting these
interrupts in a user mode process.

The design we're contemplating is a small character device driver in the
kernel that will allow a user mode process to perform a blocking read on
a file descriptor, and return from the read call whenever an interrupt
occurs. =20

We're not concerned (for the moment) with missing interrupts - we think
we can service them fast enough (we just need to record a
chronometer-type timestamp for some other incoming (serial) data).

Does this sound like a workable approach?  Does anyone know of a better
way?  My implementation plan is to derive something from the 3rd edition
Linux Device Drivers book "scull-pipe" device driver.

Any comments or suggestions would be greatly appreciated.

    thanks and best regards,
       Nick Caruso

Re: Question regarding Interrupt "delivery" to user mode process

[Tolunay Orkun]

Dear Nick,

Caruso, Nick wrote:
> Note that "delivery" is in quotes - I don't mean to actually deliver an
> interrupt, but rather to wake the process when the interrupt occurs.
> 
> This is a broad question, but I'm hoping someone out there with real
> experience in this area can comment on a design idea we're kicking
> around.
> If there's a better mailing list for asking this type of question,
> please tell me!
> 
> We are building a device with an MPC5200 processor which needs to detect
> incoming pulses at a 13 mSec rate.  We've got this incoming pulse wired
> to an IRQ on the MPC5200 and we now need a method for detecting these
> interrupts in a user mode process.
> 
> The design we're contemplating is a small character device driver in the
> kernel that will allow a user mode process to perform a blocking read on
> a file descriptor, and return from the read call whenever an interrupt
> occurs.  

I have done a similar char device driver in 2.4 kernel on a PPC405GP 
board. The driver receives the interrupt but does not enable the 
interrupt. However, it releases the user mode application waiting on 
"select" call (could be "poll" as well) from the /dev/device. Once the 
user application processes the interrupt, it performs an ioctl to the 
device driver to re-enable the interrupt.

We do not have hard timing issues like you have. I think 13mSec rate is 
pretty problematic for handling the interrupts consistently from a user 
mode application like I did. But, you can try. It is pretty easy to do.

There is a quirk for PPC405 however: Linux (2.4) calls ack_irq() before 
branching to the IRQ handler. However, if irq is level triggered and 
external interrupt source has not yet deasserted, the interrupt status 
bit in interrupt status register will remain set! To avoid spurious 
interrupt it is necessary to call ack_irq() again before enabling the 
interrupts again. I had discussed this in the old linuxppc-embedded list 
while I was doing this driver.

> We're not concerned (for the moment) with missing interrupts - we think
> we can service them fast enough (we just need to record a
> chronometer-type timestamp for some other incoming (serial) data).
> 
> Does this sound like a workable approach?  Does anyone know of a better
> way?  My implementation plan is to derive something from the 3rd edition
> Linux Device Drivers book "scull-pipe" device driver.
> 
> Any comments or suggestions would be greatly appreciated.
> 
>     thanks and best regards,
>        Nick Caruso
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Question regarding Interrupt "delivery" to user mode process

[Eugene Surovegin]

On Fri, Mar 25, 2005 at 11:40:16AM -0600, Tolunay Orkun wrote:

[snip]

> There is a quirk for PPC405 however: Linux (2.4) calls ack_irq() before 
> branching to the IRQ handler. However, if irq is level triggered and 
> external interrupt source has not yet deasserted, the interrupt status 
> bit in interrupt status register will remain set! To avoid spurious 
> interrupt it is necessary to call ack_irq() again before enabling the 
> interrupts again. I had discussed this in the old linuxppc-embedded list 
> while I was doing this driver.

This isn't 405 specific. This problem will exist on any system with 
level-sensitive IRQ source which wasn't ACK'ed. ACK'ed here means 
acknowledgment in device itself, not in PIC.

This is why this user-space IRQ handling is a bad idea, IMHO. You have 
to ACK IRQ (in device itself) in kernel-IRQ handler.

--
Eugene

Re: Question regarding Interrupt "delivery" to user mode process

[Tolunay Orkun]

Eugene Surovegin wrote:

>On Fri, Mar 25, 2005 at 11:40:16AM -0600, Tolunay Orkun wrote:
>
>[snip]
>
>  
>
>>There is a quirk for PPC405 however: Linux (2.4) calls ack_irq() before 
>>branching to the IRQ handler. However, if irq is level triggered and 
>>external interrupt source has not yet deasserted, the interrupt status 
>>bit in interrupt status register will remain set! To avoid spurious 
>>interrupt it is necessary to call ack_irq() again before enabling the 
>>interrupts again. I had discussed this in the old linuxppc-embedded list 
>>while I was doing this driver.
>>    
>>
>
>This isn't 405 specific. This problem will exist on any system with 
>level-sensitive IRQ source which wasn't ACK'ed. ACK'ed here means 
>acknowledgment in device itself, not in PIC.
>
>This is why this user-space IRQ handling is a bad idea, IMHO. You have 
>to ACK IRQ (in device itself) in kernel-IRQ handler.
>
>--
>Eugene
>  
>
Well, ACK'ing the IRQ in the kernel IRQ handler was impractical for us 
because you have to communicate using I2C (sloooow) and multiple devices 
of the same types is hooked to the same IRQ so we need to poll them to 
see which one has actually generated the the IRQ. That means many Nx I2C 
reads and 1x I2C write. Furthermore, N is a variable as I2C devices are 
hot plugged or removed from the bus so when nobody claims ownership we 
need to probe for new instance of device. Ugly but much better than 
purely polled operation...

Best regards,
Tolunay

Re: Question regarding Interrupt "delivery" to user mode process

[Tolunay Orkun]

Eugene,

>> There is a quirk for PPC405 however: Linux (2.4) calls ack_irq() 
>> before branching to the IRQ handler. However, if irq is level 
>> triggered and external interrupt source has not yet deasserted, the 
>> interrupt status bit in interrupt status register will remain set! To 
>> avoid spurious interrupt it is necessary to call ack_irq() again 
>> before enabling the interrupts again. I had discussed this in the old 
>> linuxppc-embedded list while I was doing this driver.
>>   
>
>
> This isn't 405 specific. This problem will exist on any system with 
> level-sensitive IRQ source which wasn't ACK'ed. ACK'ed here means 
> acknowledgment in device itself, not in PIC.

This would not be a problem for level triggered interrupts if 
enable_irq() cleared the pending IRQ bit before re-enabling the 
interrupt system if that particular interrupt was level triggered.

If there is a valid request still pending (i.e. external IRQ line is 
still asserted at the appropriate level) this would not cause loss of 
interrupt but in case there is no requester (i.e. all interrupts are 
properly acknowledged), the spurious interrupt due to delayed processing 
would be avoided.

Tolunay

Re: Question regarding Interrupt "delivery" to user mode process

[Eugene Surovegin]

On Fri, Mar 25, 2005 at 02:05:20PM -0600, Tolunay Orkun wrote:
> This would not be a problem for level triggered interrupts if 
> enable_irq() cleared the pending IRQ bit before re-enabling the 
> interrupt system if that particular interrupt was level triggered.
> 
> If there is a valid request still pending (i.e. external IRQ line is 
> still asserted at the appropriate level) this would not cause loss of 
> interrupt but in case there is no requester (i.e. all interrupts are 
> properly acknowledged), the spurious interrupt due to delayed processing 
> would be avoided.

Hmm, I think I agree with you. Let me think a little more and I'll 
probably add this additional ACK to 4xx PIC code.

Only thing which bothers me is that such hack will be 4xx specific, as 
none of PIC handlers I looked at (in arch/ppc) do this. So, I'm not 
quite sure it worth adding at all. After all, the way you use 
enable_irq/disable_irq isn't quite standard anyway :).

--
Eugene