[Xenomai-help] RTDM driver structure

[Xenomai-help] RTDM driver structure

[Bob Feretich]

  I want to verify that my understanding of the RTDM driver structure is 
correct.

My driver is created as a module that is loaded by Linux insmod. Given 
that...

My module_init routine (and module_exit)...
*  is executed in the Linux driver context.
*  should use Linux spin locks and events instead of rt_locks and events.
*  can call rtdm_irq_request (rtrm_irq_free) to register my interrupt 
handlers
       for rt interrupts.
*  can call rtdm_device_register (rt_dm_device_unregister) to register 
my rt device.
*  can call Linux omap dm_timer routines to reserve general purpose timers,
       so that Linux will not give my timers to others. (these routines 
call Linux locks)

My driver's open_nrt close_nrt entry points... (open_rt & close_rt are 
deprecated)
*  are executed in the caller's Linux user context, if the caller is a 
standard Linux
       user process.
*  are executed in the caller's Xenomai user context (secondary mode), 
if the caller
       is a rt user process.
*  can use Linux spin locks and events instead of rt_locks and events, 
if I know
       that protection is not needed from rt tasks and interrupt handlers.
*  should use rt locks and events, if protection is needed from rt tasks 
and
       interrupt handlers.

My driver's ioctl_rt, read_rt, and write_rt entry points...
*  are executed in the caller's Xenomai user context (primary mode), if 
the caller
       is a rt user process running in primary mode.
*  are executed in the caller's Xenomai user context (secondary mode), 
if the caller
       is a rt user process running in secondary mode.
*  must use rt locks and events.

My driver's ioctl_nrt, read_nrt, and write_nrt entry points...
*  are executed in the caller's Linux user context, if the caller is a 
standard
       Linux user process.
*  I should use rt locks and events, for protection from rt tasks and
       interrupt handlers.

My driver's rt interrupt handler entry points...
*  are executed in the Xenomai interrupt context.
*  must use rt locks and events.

Is the above correct?

The OMAP3 chip has a collection of hardware timers that must be shared 
between the Linux and Xenomai environments. I want to allocate/reserve 5 
timers for my use in the real time environment for the creation of pulse 
width modulation output signals, but the rest of the timers should be 
available for general Linux use. Being able to call omap dm_timer 
routines in the module_init and module_exit routines make this much easier.

Regards,
Bob Feretich

Re: [Xenomai-help] RTDM driver structure

[Gilles Chanteperdrix]

Bob Feretich wrote:
>   I want to verify that my understanding of the RTDM driver structure is 
> correct.
> 
> My driver is created as a module that is loaded by Linux insmod. Given 
> that...
> 
> My module_init routine (and module_exit)...
> *  is executed in the Linux driver context.
> *  should use Linux spin locks and events instead of rt_locks and events.
> *  can call rtdm_irq_request (rtrm_irq_free) to register my interrupt 
> handlers
>        for rt interrupts.
> *  can call rtdm_device_register (rt_dm_device_unregister) to register 
> my rt device.
> *  can call Linux omap dm_timer routines to reserve general purpose timers,
>        so that Linux will not give my timers to others. (these routines 
> call Linux locks)
> 
> My driver's open_nrt close_nrt entry points... (open_rt & close_rt are 
> deprecated)
> *  are executed in the caller's Linux user context, if the caller is a 
> standard Linux
>        user process.
> *  are executed in the caller's Xenomai user context (secondary mode), 
> if the caller
>        is a rt user process.
> *  can use Linux spin locks and events instead of rt_locks and events, 
> if I know
>        that protection is not needed from rt tasks and interrupt handlers.
> *  should use rt locks and events, if protection is needed from rt tasks 
> and
>        interrupt handlers.
> 
> My driver's ioctl_rt, read_rt, and write_rt entry points...
> *  are executed in the caller's Xenomai user context (primary mode), if 
> the caller
>        is a rt user process running in primary mode.
> *  are executed in the caller's Xenomai user context (secondary mode), 
> if the caller
>        is a rt user process running in secondary mode.
> *  must use rt locks and events.
> 
> My driver's ioctl_nrt, read_nrt, and write_nrt entry points...
> *  are executed in the caller's Linux user context, if the caller is a 
> standard
>        Linux user process.
> *  I should use rt locks and events, for protection from rt tasks and
>        interrupt handlers.
> 
> My driver's rt interrupt handler entry points...
> *  are executed in the Xenomai interrupt context.
> *  must use rt locks and events.
> 
> Is the above correct?

Hi,

Yes, this is correct. Note however, that if you need to lock something
in the init_module or an nrt callback, and you use a linux lock, you
will not be able to use this lock from rt context, so, the only way to
solve this will be to use an rtdm lock.

> 
> The OMAP3 chip has a collection of hardware timers that must be shared 
> between the Linux and Xenomai environments. I want to allocate/reserve 5 
> timers for my use in the real time environment for the creation of pulse 
> width modulation output signals, but the rest of the timers should be 
> available for general Linux use. Being able to call omap dm_timer 
> routines in the module_init and module_exit routines make this much easier.

Another remark: Xenomai uses, as, a system timer, a timer in one-shot
mode (same as Linux so-called "high resolution timers"), so, if you
program several periodic software timers, Xenomai timer subsystem will
arrange for your timer callbacks to be called at the right time, so it
looks like you will not gain much by using several hardware timers. If
you fear that Xenomai timing subsystem will not scale well with many
timers, you can enable the heap-based or wheel-based timer management.

Regards.

-- 
					    Gilles.

Re: [Xenomai-help] RTDM driver structure

[Bob Feretich]

  Comments inline...

On 8/5/2010 12:07 AM, Gilles Chanteperdrix wrote:
>
> Another remark: Xenomai uses, as, a system timer, a timer in one-shot
> mode (same as Linux so-called "high resolution timers"), so, if you
> program several periodic software timers, Xenomai timer subsystem will
> arrange for your timer callbacks to be called at the right time, so it
> looks like you will not gain much by using several hardware timers. If
> you fear that Xenomai timing subsystem will not scale well with many
> timers, you can enable the heap-based or wheel-based timer management.
The GPTimers that I am using have special hardware that drives pins on 
the chip. They can be programmed to create waveforms of specific pulse 
width and period and auto-restart so that the pulse train is continuous. 
Software only gets involved when the pulse width or period needs to be 
changed.  If I used the Xenomai timer, software (to change the state of 
a GPIO pin) would be invoked every time any of these signals needed to 
transition.

Using the hardware timers for the generation pulse trains of fixed pulse 
width and period takes zero CPU cycles.

Regards,
Bob

Re: [Xenomai-help] RTDM driver structure

[Gilles Chanteperdrix]

Bob Feretich wrote:
>   Comments inline...
> 
> On 8/5/2010 12:07 AM, Gilles Chanteperdrix wrote:
>> Another remark: Xenomai uses, as, a system timer, a timer in one-shot
>> mode (same as Linux so-called "high resolution timers"), so, if you
>> program several periodic software timers, Xenomai timer subsystem will
>> arrange for your timer callbacks to be called at the right time, so it
>> looks like you will not gain much by using several hardware timers. If
>> you fear that Xenomai timing subsystem will not scale well with many
>> timers, you can enable the heap-based or wheel-based timer management.
> The GPTimers that I am using have special hardware that drives pins on 
> the chip. They can be programmed to create waveforms of specific pulse 
> width and period and auto-restart so that the pulse train is continuous. 
> Software only gets involved when the pulse width or period needs to be 
> changed.  If I used the Xenomai timer, software (to change the state of 
> a GPIO pin) would be invoked every time any of these signals needed to 
> transition.
> 
> Using the hardware timers for the generation pulse trains of fixed pulse 
> width and period takes zero CPU cycles.

Ok. Understood, the software could not even reloead the registers fast
enough.

-- 
					    Gilles.

Re: [Xenomai-help] RTDM driver structure - an update

[Bob Feretich]

  I completed porting my PWM timer driver to Xenomai.
I limited the heavy use of the dm_timer routines to the module_init and 
module_exit routines. Other parts of the driver only used the dm_timer 
routines that read and wrote timer registers.

You guys did a great job defining and implementing Xenomai and RTDM. 
Porting the Linux driver to RTDM was easy (2 days). It worked the first 
time I got a clean compile!

I have 4 pulse width modulated signals being output by the OMAP3 chip, 3 
are completely generated by hardware, the other is done by software 
being activated by RT interrupts. When I examined the signals with a 
scope, I couldn't tell which one was software generated. In the pure 
Linux environment I was seeing 100-200 microseconds of jitter on the 
software generated signal on a lightly loaded system. Under the same 
conditions in Xenomai, there was no noticeable jitter.

Thanks for your help.
Regards,
Bob Feretich

On 8/5/2010 12:07 AM, Gilles Chanteperdrix wrote:
> Bob Feretich wrote:
>>    I want to verify that my understanding of the RTDM driver structure is
>> correct.
>>
>> My driver is created as a module that is loaded by Linux insmod. Given
>> that...
>>
>> My module_init routine (and module_exit)...
>> *  is executed in the Linux driver context.
>> *  should use Linux spin locks and events instead of rt_locks and events.
>> *  can call rtdm_irq_request (rtrm_irq_free) to register my interrupt
>> handlers
>>         for rt interrupts.
>> *  can call rtdm_device_register (rt_dm_device_unregister) to register
>> my rt device.
>> *  can call Linux omap dm_timer routines to reserve general purpose timers,
>>         so that Linux will not give my timers to others. (these routines
>> call Linux locks)
>>
>> My driver's open_nrt close_nrt entry points... (open_rt&  close_rt are
>> deprecated)
>> *  are executed in the caller's Linux user context, if the caller is a
>> standard Linux
>>         user process.
>> *  are executed in the caller's Xenomai user context (secondary mode),
>> if the caller
>>         is a rt user process.
>> *  can use Linux spin locks and events instead of rt_locks and events,
>> if I know
>>         that protection is not needed from rt tasks and interrupt handlers.
>> *  should use rt locks and events, if protection is needed from rt tasks
>> and
>>         interrupt handlers.
>>
>> My driver's ioctl_rt, read_rt, and write_rt entry points...
>> *  are executed in the caller's Xenomai user context (primary mode), if
>> the caller
>>         is a rt user process running in primary mode.
>> *  are executed in the caller's Xenomai user context (secondary mode),
>> if the caller
>>         is a rt user process running in secondary mode.
>> *  must use rt locks and events.
>>
>> My driver's ioctl_nrt, read_nrt, and write_nrt entry points...
>> *  are executed in the caller's Linux user context, if the caller is a
>> standard
>>         Linux user process.
>> *  I should use rt locks and events, for protection from rt tasks and
>>         interrupt handlers.
>>
>> My driver's rt interrupt handler entry points...
>> *  are executed in the Xenomai interrupt context.
>> *  must use rt locks and events.
>>
>> Is the above correct?
> Hi,
>
> Yes, this is correct. Note however, that if you need to lock something
> in the init_module or an nrt callback, and you use a linux lock, you
> will not be able to use this lock from rt context, so, the only way to
> solve this will be to use an rtdm lock.
>
>> The OMAP3 chip has a collection of hardware timers that must be shared
>> between the Linux and Xenomai environments. I want to allocate/reserve 5
>> timers for my use in the real time environment for the creation of pulse
>> width modulation output signals, but the rest of the timers should be
>> available for general Linux use. Being able to call omap dm_timer
>> routines in the module_init and module_exit routines make this much easier.
> Another remark: Xenomai uses, as, a system timer, a timer in one-shot
> mode (same as Linux so-called "high resolution timers"), so, if you
> program several periodic software timers, Xenomai timer subsystem will
> arrange for your timer callbacks to be called at the right time, so it
> looks like you will not gain much by using several hardware timers. If
> you fear that Xenomai timing subsystem will not scale well with many
> timers, you can enable the heap-based or wheel-based timer management.
>
> Regards.
>

Re: [Xenomai-help] RTDM driver structure - an update

[Everett Wang]

Hi Bob,

Great job. :-D Do you have plan to port SPI to RTDM? Last time when I
checked the rs232 driver
in RTDM for omap3 still also had problem. I don't mind to work on
that. But I am driver-challenged person.

Have a nice weekend.

Everett

On Sat, Aug 7, 2010 at 10:22 AM, Bob Feretich
<bob.feretich@domain.hid> wrote:
>  I completed porting my PWM timer driver to Xenomai.
> I limited the heavy use of the dm_timer routines to the module_init and
> module_exit routines. Other parts of the driver only used the dm_timer
> routines that read and wrote timer registers.
>
> You guys did a great job defining and implementing Xenomai and RTDM.
> Porting the Linux driver to RTDM was easy (2 days). It worked the first
> time I got a clean compile!
>
> I have 4 pulse width modulated signals being output by the OMAP3 chip, 3
> are completely generated by hardware, the other is done by software
> being activated by RT interrupts. When I examined the signals with a
> scope, I couldn't tell which one was software generated. In the pure
> Linux environment I was seeing 100-200 microseconds of jitter on the
> software generated signal on a lightly loaded system. Under the same
> conditions in Xenomai, there was no noticeable jitter.
>
> Thanks for your help.
> Regards,
> Bob Feretich
>
> On 8/5/2010 12:07 AM, Gilles Chanteperdrix wrote:
>> Bob Feretich wrote:
>>>    I want to verify that my understanding of the RTDM driver structure is
>>> correct.
>>>
>>> My driver is created as a module that is loaded by Linux insmod. Given
>>> that...
>>>
>>> My module_init routine (and module_exit)...
>>> *  is executed in the Linux driver context.
>>> *  should use Linux spin locks and events instead of rt_locks and events.
>>> *  can call rtdm_irq_request (rtrm_irq_free) to register my interrupt
>>> handlers
>>>         for rt interrupts.
>>> *  can call rtdm_device_register (rt_dm_device_unregister) to register
>>> my rt device.
>>> *  can call Linux omap dm_timer routines to reserve general purpose timers,
>>>         so that Linux will not give my timers to others. (these routines
>>> call Linux locks)
>>>
>>> My driver's open_nrt close_nrt entry points... (open_rt&  close_rt are
>>> deprecated)
>>> *  are executed in the caller's Linux user context, if the caller is a
>>> standard Linux
>>>         user process.
>>> *  are executed in the caller's Xenomai user context (secondary mode),
>>> if the caller
>>>         is a rt user process.
>>> *  can use Linux spin locks and events instead of rt_locks and events,
>>> if I know
>>>         that protection is not needed from rt tasks and interrupt handlers.
>>> *  should use rt locks and events, if protection is needed from rt tasks
>>> and
>>>         interrupt handlers.
>>>
>>> My driver's ioctl_rt, read_rt, and write_rt entry points...
>>> *  are executed in the caller's Xenomai user context (primary mode), if
>>> the caller
>>>         is a rt user process running in primary mode.
>>> *  are executed in the caller's Xenomai user context (secondary mode),
>>> if the caller
>>>         is a rt user process running in secondary mode.
>>> *  must use rt locks and events.
>>>
>>> My driver's ioctl_nrt, read_nrt, and write_nrt entry points...
>>> *  are executed in the caller's Linux user context, if the caller is a
>>> standard
>>>         Linux user process.
>>> *  I should use rt locks and events, for protection from rt tasks and
>>>         interrupt handlers.
>>>
>>> My driver's rt interrupt handler entry points...
>>> *  are executed in the Xenomai interrupt context.
>>> *  must use rt locks and events.
>>>
>>> Is the above correct?
>> Hi,
>>
>> Yes, this is correct. Note however, that if you need to lock something
>> in the init_module or an nrt callback, and you use a linux lock, you
>> will not be able to use this lock from rt context, so, the only way to
>> solve this will be to use an rtdm lock.
>>
>>> The OMAP3 chip has a collection of hardware timers that must be shared
>>> between the Linux and Xenomai environments. I want to allocate/reserve 5
>>> timers for my use in the real time environment for the creation of pulse
>>> width modulation output signals, but the rest of the timers should be
>>> available for general Linux use. Being able to call omap dm_timer
>>> routines in the module_init and module_exit routines make this much easier.
>> Another remark: Xenomai uses, as, a system timer, a timer in one-shot
>> mode (same as Linux so-called "high resolution timers"), so, if you
>> program several periodic software timers, Xenomai timer subsystem will
>> arrange for your timer callbacks to be called at the right time, so it
>> looks like you will not gain much by using several hardware timers. If
>> you fear that Xenomai timing subsystem will not scale well with many
>> timers, you can enable the heap-based or wheel-based timer management.
>>
>> Regards.
>>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>

Re: [Xenomai-help] RTDM driver structure - an update

[Gilles Chanteperdrix]

Everett Wang wrote:
> Hi Bob,
> 
> Great job. :-D Do you have plan to port SPI to RTDM? Last time when I
> checked the rs232 driver
> in RTDM for omap3 still also had problem. I don't mind to work on
> that. But I am driver-challenged person.

If you are referring to the problem described here:
https://mail.gna.org/public/xenomai-help/2010-05/msg00166.html
Wolfgang answered here:
https://mail.gna.org/public/xenomai-help/2010-05/msg00167.html

If you are referring to another problem, it would be nice to receive a
real bug report, not just "omap3 has problems".

-- 
					    Gilles.

Re: [Xenomai-help] RTDM driver structure - an update

[Everett Wang]

On Sun, Aug 8, 2010 at 8:08 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> Everett Wang wrote:
>> Hi Bob,
>>
>> Great job. :-D Do you have plan to port SPI to RTDM? Last time when I
>> checked the rs232 driver
>> in RTDM for omap3 still also had problem. I don't mind to work on
>> that. But I am driver-challenged person.
>
> If you are referring to the problem described here:
> https://mail.gna.org/public/xenomai-help/2010-05/msg00166.html
> Wolfgang answered here:
> https://mail.gna.org/public/xenomai-help/2010-05/msg00167.html
>
> If you are referring to another problem, it would be nice to receive a
> real bug report, not just "omap3 has problems".
>
> --
>                                            Gilles.
>

Hi Gilles,

Sorry that I was not clear on the rs232 for omap3. I encountered a
problem when I tried to
run cross-link example for beagle-board on xenomai 2.5.3. Wolfgang
helped me for compiling
and loading the xeno_16550A.ko driver for rts0 and rts1. That was
resolved successfully. But I
still couldn't make cross-link example to run.

Wolfgang mentioned a potential problem in regshift for omap3. This
what he said:

quote

Wolfgang Grandegger to me, xenomai-help
show details May 26
.....
Next I would try to load the xeno_16550a.ko as described earlier. Then
you need to fix the register access by introducing a proper regshift, at
least. I can't tell if other fixups are necessary but if you are lucky
it will already work. And yes, implementing a RTDM SPI driver is even
harder, unfortunately.

Wolfgang.

end of quote.

I can't get the mail link from our mailing list since google groups
were blocked inside of China. :-(

Everett

Re: [Xenomai-help] RTDM driver structure - an update

[Bob Feretich]

  I am porting the the ADIS SPI driver now. The GPIO interrupt problem 
that I reported is from the Data Ready interrupt from the sensor.

The OMAP3 chip has 6 GPIO interrupt modules. Each module merges 32 GPIO 
interrupt channels (1 channel per GPIO pin). Interrupts on these 
channels can be routed to either the ARM MPU or to the graphics 
subsystem (IVA). Only the channels that are mapped to the MPU are of 
interest to Adeos.
MPU_IRQ  GPIO_module  GPIO_pins_in_module
  IRQ29   GPIO1        31-0
  IRQ30   GPIO2        63-34,33,32
  IRQ31   GPIO3        95-83,82,81,80,79-64
  IRQ32   GPIO4        127,126-96
  IRQ33   GPIO5        159-128
  IRQ34   GPIO6        191-160
The breaks in the above ranges indicate slightly different capabilities. 
A signal change on any GPIO pin can cause an interrupt to occur for the 
group. There are several 32-bit control registers (discussed below) 
associated with each group. The bits in the control registers are mapped 
one to one with the interrupt channels of the group.

The Linux interrupt handler receives the IRQ 29-34 GPIO_module 
interrupts, determines which channel caused it and calls the interrupt 
handler associated with that channel by mapping the interrupt to an IRQ 
in the IRQ 160 to 351 range. (These IRQs don't go through the twl family 
chips.)

The below registers should be used by Adeos to detect and process 
interrupts:
GPIOn_IRQSTATUS1
GPIOn_IRQENABLE1 aliases (GPIO_SETIRQENABLE1, GPIOn_CLEARIRQENABLE1)

The below registers need to be configured by the driver, to tell the 
hardware when to initiate an interrupt:
GPIOn_LEVELDETECT0   (0x1: enable the IRQ assertion on low level detect)
GPIOn_LEVELDETECT1   (0x1: enable the IRQ assertion on high level detect)
GPIOn_RISINGDETECT    (0x1: enable IRQ/Wakeup on rising edge detect)
GPIOn_FALLINGDETECT (0x1: enable IRQ/Wakeup on falling edge detect)
All the bits in the above xxxDETECT  registers are set to zeroes at 
processor initialization. If they remain zero, all GPIO Channel 
interrupts are effectively disabled. I'm sure this is what is occurring 
in my situation.

For standard Linux drivers, I configure the xxxDETECT registers by 
setting flags in the request_irq() call. These flags are not present in 
the rtdm_irq_request() parameters.
There is a RTDM_IRQTYPE_EDGE flag, but there is no description of what 
it does or when to use it. It is not sufficient to determine the 
settings of the xxxDETECT registers.
Also, the documentation is not clear whether an IRQ requested via 
rtdm_irq_request() is initially enabled or disabled (disabled would be 
better).

Setting values in the xxxDETECT registers has a scope that effects any 
driver listening to that IRQ (both Xenomai and Linux). In this case, it 
is appropriate that I request/reserve the IRQ in both environments and 
hold my reservation in both environments until my driver is unloaded. I 
can then configure these registers via my call to request_irq().
First, I will request the GPIO Channel IRQ in Linux, but keep it disabled.
Then, I will request it in Xenomai via rtdm_irq_request().
Then enable the IRQ only in Xenomai.

Will that screw up the IRQs handling in the Adeos pipe?
I assume that Adeos can handle interrupts occurring on either or both edges.

How should I set the flags on the rtdm_irq_request()?
Do the flags in an active request_irq() have an effect on a subsequent 
rtdm_irq_request()?
Do I need to mark the IRQ SHARED in the request_irq()?
Does executing a rtdm_irq_request(), without the SHARED flag, fail if 
the IRQ was reserved via request_irq()? (The purpose of the flag is not 
documented in the API manual.)
Do I need to specify the SHARED flag in both request_irq() and 
rtdm_irq_request()? I'd rather not allow any other driver access to my IRQ.

Per Gilles comment, Linux should not allow me to execute a 
"set_irq_type" without holding a reservation to the IRQ. And, if I am 
holding the reservation, then I could have configured the irq type via 
the request_irq().

Regards,
Bob


On 8/8/2010 2:36 AM, Everett Wang wrote:
> Hi Bob,
>
> Great job. :-D Do you have plan to port SPI to RTDM? Last time when I
> checked the rs232 driver
> in RTDM for omap3 still also had problem. I don't mind to work on
> that. But I am driver-challenged person.
>
> Have a nice weekend.
>
> Everett
>
> On Sat, Aug 7, 2010 at 10:22 AM, Bob Feretich
> <bob.feretich@domain.hid>  wrote:
>> ...snipped ...
>>

Re: [Xenomai-help] RTDM driver structure - an update

[Guenter Ebermann]

Hi Bob,

Am 10.08.2010 um 02:56 schrieb Bob Feretich:
> Do I need to mark the IRQ SHARED in the request_irq()?
> Does executing a rtdm_irq_request(), without the SHARED flag, fail if 
> the IRQ was reserved via request_irq()? (The purpose of the flag is not 
> documented in the API manual.)
> Do I need to specify the SHARED flag in both request_irq() and 
> rtdm_irq_request()? I'd rather not allow any other driver access to my IRQ.

I am relatively new to xenomai, but perhaps I can shed some light on shared
IRQs: Shared IRQs are used if more than one device share one interrupt line.
E.g.: Two PCI cards use the same interrupt line.

The cards output has high-resistance if the interrupt is disabled.  A external
pull-up is used. So if no interrupt is pending the voltage is high on the line.
The interrupt must also be level sensitive.

Whenever a interrupt occurs one card pulls down the IRQ line to ground. This
also works if both cards pull the IRQ down the same time (IRQ happens at the
same time).

Also the return value of the IRQ is important if the IRQ is shared.  The first
thing you have to do is check if it was your device that issued the irq (by
accessing some registers in your device).  If it was your device do what has to
be done (ack the interrupt in the device so that it doesnt pull down the level
to ground any more) and return IRQ_HANDLED.  If its not your return
IRQ_NO_HANDLED or such. 

So if you write a driver for one of this two cards you must use the IRQ_SHARED
flag (this is the same with standard linux interrupt API - just call
request_irq with irqflags=IRQF_SHARED) so that linux knows that after it calls
your handler it must also call all other handlers of this IRQ.

However shared IRQs can be used for all kind of devices. But PCI is the only
example I am aware of where it really is used. It is also the root of alot of
problems because one must be really careful to handle such shared IRQs
correctly.

So its more likely your device does not use shared IRQs.

But perhaps in xenomai API this flag means a different thing I am not yet aware
of.

Kind regards,
Guenter

Re: [Xenomai-help] RTDM driver structure - an update

[Bob Feretich]

  Gunther,
Thank you for the information.
No, the my hardware interrupt line is not being shared by other devices. 
So I really don't want it to be considered "shared". However, my concern 
was on how driver IRQ request calls are handled.

If a driver invokes request_irq() without the SHARED flag, I would 
expect Linux to reject subsequent request_irq() calls for the same IRQ 
made by other drivers. Similarly, if the first driver invokes 
request_irq() with the SHARED flag, I would expect Linux to accept 
subsequent request_irq() calls for the same IRQ made by other drivers 
if-and-only-if the other requests are made with the SHARED flag.

My temporary fix for the problem I encountered required me to request 
the same IRQ from Linux via request_irq() and then from Xenomai via 
rtdm_irq_request(). I had expected the Xenomai request to fail. However, 
that expectation assumed that there are interlocks between the 
environments. I perceived problems in either case. If there are no 
interlocks, then both a real-time driver and a non-real-time driver may 
be loaded to service the same IRQ and be ignorant of each other. This 
would probably be bad.

If there are interlocks...
Then for a non-shared IRQ, the first driver to request the IRQ would 
receive it. All other requestors, regardless of whether they are Xenomai 
or Linux would be refused.
For a shared IRQ, the rules get much more complex. I believe that the 
first driver to request the IRQ would receive it, but if the driver 
specified the SHARED flag sharing would restricted the environment of 
that first driver. Requests made from the other environment should be 
rejected whether or not they specify SHARED.
Since my temporary fix (requesting and receiving a non-shared IRQ in 
both the Linux and Xenomai environments) worked, if proved that there 
were no interlocks. Phillippe stated that this is a flaw in the current 
version of Xenomai.

Regards,
Bob

On 8/10/2010 12:43 AM, Guenter Ebermann wrote:
> Hi Bob,
>
> Am 10.08.2010 um 02:56 schrieb Bob Feretich:
>> Do I need to mark the IRQ SHARED in the request_irq()?
>> Does executing a rtdm_irq_request(), without the SHARED flag, fail if
>> the IRQ was reserved via request_irq()? (The purpose of the flag is not
>> documented in the API manual.)
>> Do I need to specify the SHARED flag in both request_irq() and
>> rtdm_irq_request()? I'd rather not allow any other driver access to my IRQ.
> I am relatively new to xenomai, but perhaps I can shed some light on shared
> IRQs: Shared IRQs are used if more than one device share one interrupt line.
> E.g.: Two PCI cards use the same interrupt line.
>
> The cards output has high-resistance if the interrupt is disabled.  A external
> pull-up is used. So if no interrupt is pending the voltage is high on the line.
> The interrupt must also be level sensitive.
>
> Whenever a interrupt occurs one card pulls down the IRQ line to ground. This
> also works if both cards pull the IRQ down the same time (IRQ happens at the
> same time).
>
> Also the return value of the IRQ is important if the IRQ is shared.  The first
> thing you have to do is check if it was your device that issued the irq (by
> accessing some registers in your device).  If it was your device do what has to
> be done (ack the interrupt in the device so that it doesnt pull down the level
> to ground any more) and return IRQ_HANDLED.  If its not your return
> IRQ_NO_HANDLED or such.
>
> So if you write a driver for one of this two cards you must use the IRQ_SHARED
> flag (this is the same with standard linux interrupt API - just call
> request_irq with irqflags=IRQF_SHARED) so that linux knows that after it calls
> your handler it must also call all other handlers of this IRQ.
>
> However shared IRQs can be used for all kind of devices. But PCI is the only
> example I am aware of where it really is used. It is also the root of alot of
> problems because one must be really careful to handle such shared IRQs
> correctly.
>
> So its more likely your device does not use shared IRQs.
>
> But perhaps in xenomai API this flag means a different thing I am not yet aware
> of.
>
> Kind regards,
> Guenter

Re: [Xenomai-help] RTDM driver structure - an update

[Gilles Chanteperdrix]

Bob Feretich wrote:
>   Gunther,
> Thank you for the information.
> No, the my hardware interrupt line is not being shared by other devices. 
> So I really don't want it to be considered "shared". However, my concern 
> was on how driver IRQ request calls are handled.
> 
> If a driver invokes request_irq() without the SHARED flag, I would 
> expect Linux to reject subsequent request_irq() calls for the same IRQ 
> made by other drivers. Similarly, if the first driver invokes 
> request_irq() with the SHARED flag, I would expect Linux to accept 
> subsequent request_irq() calls for the same IRQ made by other drivers 
> if-and-only-if the other requests are made with the SHARED flag.
> 
> My temporary fix for the problem I encountered required me to request 
> the same IRQ from Linux via request_irq() and then from Xenomai via 
> rtdm_irq_request(). I had expected the Xenomai request to fail. However, 
> that expectation assumed that there are interlocks between the 
> environments. I perceived problems in either case. If there are no 
> interlocks, then both a real-time driver and a non-real-time driver may 
> be loaded to service the same IRQ and be ignorant of each other. This 
> would probably be bad.
> 
> If there are interlocks...
> Then for a non-shared IRQ, the first driver to request the IRQ would 
> receive it. All other requestors, regardless of whether they are Xenomai 
> or Linux would be refused.

Ok. Adeos 101.

Xenomai and Linux are living in different Adeos domains, each with its
own interrupt handlers. The domains are organized in a pipeline. When an
interrupt is received, it goes down the pipeline until a domain accepts
it. The domain which accepts it may choose to propagate it or not to the
next domain. So, there is nothing wrong with registering an interrupt
handler for each domain. However, if the Xenomai domain interrupt
handler decides not to propagate the interrupt to the Linux domain,
Linux will simply never receive any interrupt.

The SHARED flag applies to interrupts in the same domain, and are
handled outside of the Adeos realm.

The timer interrupt, on the other hand, propagates the interrupt when it
sees fit, so that Linux timer handling is called. Both solutions are
allowed.

The reason why it is impossible to share an interrupt between two
different drivers, unaware of each other, living in Xenomai and Linux
domain is that it destroys the determinism. But even that can be made to
work if we make a Xenomai domain driver for the Linux domain interrupt,
aware of that Linux domain driver:
https://mail.gna.org/public/xenomai-core/2008-07/msg00025.html

> For a shared IRQ, the rules get much more complex. I believe that the 
> first driver to request the IRQ would receive it, but if the driver 
> specified the SHARED flag sharing would restricted the environment of 
> that first driver. Requests made from the other environment should be 
> rejected whether or not they specify SHARED.
> Since my temporary fix (requesting and receiving a non-shared IRQ in 
> both the Linux and Xenomai environments) worked, if proved that there 
> were no interlocks. Phillippe stated that this is a flaw in the current 
> version of Xenomai.

No, you misunderstood Philippe. What is a flaw in the current version of
Xenomai is the fact that rtdm_request_irq does not configure the GPIO
registers to set the GPIO interrupt to edge/level triggered, rising,
falling, etc... The fact that the same interrupt can be requested in
Xenomai domain and in Linux domain is perfectly normal, fits in the
Adeos architecture, and is even needed for handling the timer interrupt
on several architectures including arm.


-- 
					    Gilles.

Re: [Xenomai-help] RTDM driver structure - an update

[Philippe Gerum]

On Tue, 2010-08-10 at 15:33 +0200, Gilles Chanteperdrix wrote:
> Bob Feretich wrote:
> >   Gunther,
> > Thank you for the information.
> > No, the my hardware interrupt line is not being shared by other devices. 
> > So I really don't want it to be considered "shared". However, my concern 
> > was on how driver IRQ request calls are handled.
> > 
> > If a driver invokes request_irq() without the SHARED flag, I would 
> > expect Linux to reject subsequent request_irq() calls for the same IRQ 
> > made by other drivers. Similarly, if the first driver invokes 
> > request_irq() with the SHARED flag, I would expect Linux to accept 
> > subsequent request_irq() calls for the same IRQ made by other drivers 
> > if-and-only-if the other requests are made with the SHARED flag.
> > 
> > My temporary fix for the problem I encountered required me to request 
> > the same IRQ from Linux via request_irq() and then from Xenomai via 
> > rtdm_irq_request(). I had expected the Xenomai request to fail. However, 
> > that expectation assumed that there are interlocks between the 
> > environments. I perceived problems in either case. If there are no 
> > interlocks, then both a real-time driver and a non-real-time driver may 
> > be loaded to service the same IRQ and be ignorant of each other. This 
> > would probably be bad.
> > 
> > If there are interlocks...
> > Then for a non-shared IRQ, the first driver to request the IRQ would 
> > receive it. All other requestors, regardless of whether they are Xenomai 
> > or Linux would be refused.
> 
> Ok. Adeos 101.
> 
> Xenomai and Linux are living in different Adeos domains, each with its
> own interrupt handlers. The domains are organized in a pipeline. When an
> interrupt is received, it goes down the pipeline until a domain accepts
> it. The domain which accepts it may choose to propagate it or not to the
> next domain. So, there is nothing wrong with registering an interrupt
> handler for each domain. However, if the Xenomai domain interrupt
> handler decides not to propagate the interrupt to the Linux domain,
> Linux will simply never receive any interrupt.
> 
> The SHARED flag applies to interrupts in the same domain, and are
> handled outside of the Adeos realm.
> 
> The timer interrupt, on the other hand, propagates the interrupt when it
> sees fit, so that Linux timer handling is called. Both solutions are
> allowed.
> 
> The reason why it is impossible to share an interrupt between two
> different drivers, unaware of each other, living in Xenomai and Linux
> domain is that it destroys the determinism. But even that can be made to
> work if we make a Xenomai domain driver for the Linux domain interrupt,
> aware of that Linux domain driver:
> https://mail.gna.org/public/xenomai-core/2008-07/msg00025.html
> 
> > For a shared IRQ, the rules get much more complex. I believe that the 
> > first driver to request the IRQ would receive it, but if the driver 
> > specified the SHARED flag sharing would restricted the environment of 
> > that first driver. Requests made from the other environment should be 
> > rejected whether or not they specify SHARED.
> > Since my temporary fix (requesting and receiving a non-shared IRQ in 
> > both the Linux and Xenomai environments) worked, if proved that there 
> > were no interlocks. Phillippe stated that this is a flaw in the current 
> > version of Xenomai.
> 
> No, you misunderstood Philippe. What is a flaw in the current version of
> Xenomai is the fact that rtdm_request_irq does not configure the GPIO
> registers to set the GPIO interrupt to edge/level triggered, rising,
> falling, etc... The fact that the same interrupt can be requested in
> Xenomai domain and in Linux domain is perfectly normal, fits in the
> Adeos architecture, and is even needed for handling the timer interrupt
> on several architectures including arm.

Ack.

> 
> 

-- 
Philippe.

Re: [Xenomai-help] RTDM driver structure - an update

[Gilles Chanteperdrix]

Bob Feretich wrote:
>   I am porting the the ADIS SPI driver now. The GPIO interrupt problem 
> that I reported is from the Data Ready interrupt from the sensor.
> 
> The OMAP3 chip has 6 GPIO interrupt modules. Each module merges 32 GPIO 
> interrupt channels (1 channel per GPIO pin). Interrupts on these 
> channels can be routed to either the ARM MPU or to the graphics 
> subsystem (IVA). Only the channels that are mapped to the MPU are of 
> interest to Adeos.
> MPU_IRQ  GPIO_module  GPIO_pins_in_module
>   IRQ29   GPIO1        31-0
>   IRQ30   GPIO2        63-34,33,32
>   IRQ31   GPIO3        95-83,82,81,80,79-64
>   IRQ32   GPIO4        127,126-96
>   IRQ33   GPIO5        159-128
>   IRQ34   GPIO6        191-160
> The breaks in the above ranges indicate slightly different capabilities. 
> A signal change on any GPIO pin can cause an interrupt to occur for the 
> group. There are several 32-bit control registers (discussed below) 
> associated with each group. The bits in the control registers are mapped 
> one to one with the interrupt channels of the group.
> 
> The Linux interrupt handler receives the IRQ 29-34 GPIO_module 
> interrupts, determines which channel caused it and calls the interrupt 
> handler associated with that channel by mapping the interrupt to an IRQ 
> in the IRQ 160 to 351 range. (These IRQs don't go through the twl family 
> chips.)
> 
> The below registers should be used by Adeos to detect and process 
> interrupts:
> GPIOn_IRQSTATUS1
> GPIOn_IRQENABLE1 aliases (GPIO_SETIRQENABLE1, GPIOn_CLEARIRQENABLE1)
> 
> The below registers need to be configured by the driver, to tell the 
> hardware when to initiate an interrupt:
> GPIOn_LEVELDETECT0   (0x1: enable the IRQ assertion on low level detect)
> GPIOn_LEVELDETECT1   (0x1: enable the IRQ assertion on high level detect)
> GPIOn_RISINGDETECT    (0x1: enable IRQ/Wakeup on rising edge detect)
> GPIOn_FALLINGDETECT (0x1: enable IRQ/Wakeup on falling edge detect)
> All the bits in the above xxxDETECT  registers are set to zeroes at 
> processor initialization. If they remain zero, all GPIO Channel 
> interrupts are effectively disabled. I'm sure this is what is occurring 
> in my situation.
> 
> For standard Linux drivers, I configure the xxxDETECT registers by 
> setting flags in the request_irq() call. These flags are not present in 
> the rtdm_irq_request() parameters.
> There is a RTDM_IRQTYPE_EDGE flag, but there is no description of what 
> it does or when to use it. It is not sufficient to determine the 
> settings of the xxxDETECT registers.

The RTDM_IRQTYPE_EDGE is documented in RTDM API documentation: "Mark IRQ
as edge-triggered, relevant for correct handling of shared
edge-triggered IRQs. " Here:
http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__rtdmirq.html

It does not cause the hardware to be configured, it just has an effect
on what "flow handler" xenomai uses for this interrupt, in much the same
way as set_irq_handler(irq, handle_edge_irq) for Linux interrupts.

> Also, the documentation is not clear whether an IRQ requested via 
> rtdm_irq_request() is initially enabled or disabled (disabled would be 
> better).

I would guess it is enabled, like when requesting one with request_irq.

> 
> Setting values in the xxxDETECT registers has a scope that effects any 
> driver listening to that IRQ (both Xenomai and Linux). In this case, it 
> is appropriate that I request/reserve the IRQ in both environments and 
> hold my reservation in both environments until my driver is unloaded. I 
> can then configure these registers via my call to request_irq().
> First, I will request the GPIO Channel IRQ in Linux, but keep it disabled.
> Then, I will request it in Xenomai via rtdm_irq_request().
> Then enable the IRQ only in Xenomai.
> 
> Will that screw up the IRQs handling in the Adeos pipe?
> I assume that Adeos can handle interrupts occurring on either or both edges.
> 
> How should I set the flags on the rtdm_irq_request()?
> Do the flags in an active request_irq() have an effect on a subsequent 
> rtdm_irq_request()?

As explained by Philippe, rtdm_request_irq fails to do what request_irq
does when xxxDETECT bits are set, or when you call set_irq_type. But you
may be able to call set_irq_type for an IRQ registered with
rtdm_request_irq (from reading the code, nothing seems to prevent it).

Anyway, you can also call free_irq after request_irq and before
rtdm_request_irq, the hardware registers will probably stay configured.

> Do I need to mark the IRQ SHARED in the request_irq()?
> Does executing a rtdm_irq_request(), without the SHARED flag, fail if 
> the IRQ was reserved via request_irq()? (The purpose of the flag is not 
> documented in the API manual.)
> Do I need to specify the SHARED flag in both request_irq() and 
> rtdm_irq_request()? I'd rather not allow any other driver access to my IRQ.

the rtdm_request_irq "SHARED" flag, works the same way as IRQF_SHARED
for Linux interrupts. It means that Xenomai will be able to register
several handlers for the same interrupt, much like Linux will be able to
register several handlers with the SHARED flag. Its documentation is:
"Enable IRQ-sharing with other real-time drivers."

> 
> Per Gilles comment, Linux should not allow me to execute a 
> "set_irq_type" without holding a reservation to the IRQ. And, if I am 
> holding the reservation, then I could have configured the irq type via 
> the request_irq().

I am not so sure about that, from reading the code, it seems that
set_irq_type should work even for an irq which you have not requested
with request_irq.

But the long term solution is to do something at RTDM level to handle
this case.


-- 
					    Gilles.

Re: [Xenomai-help] RTDM driver structure - an update

[Bob Feretich]

  Comments inline..

On 8/10/2010 6:18 AM, Gilles Chanteperdrix wrote:
> ...snipped...
> The RTDM_IRQTYPE_EDGE is documented in RTDM API documentation: "Mark IRQ
> as edge-triggered, relevant for correct handling of shared
> edge-triggered IRQs. " Here:
> http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__rtdmirq.html
The above quotation is the full extent of the documentation. The driver 
authors (we) ask the question, "Should I include this flag when I call 
rtdm_irq_request()?" The documentation leaves the answer ambiguous in 
the case where the RTDM_IRQTYPE_SHARED flag is not coded.

It also creates confusion. We assume that RTDM_IRQTYPE_EDGE will cause 
hardware to be configured similar to request_irq().We knows that the 
specification of RTDM_IRQTYPE_EDGE is insufficient.  Normally we need to 
specify which edge is to cause the interrupt. We question whether 
specifying RTDM_IRQTYPE_EDGE will cause our ISR to be entered on both 
rising and falling edges.

The essence of this e-mail discussion eventually needs to be added to 
the rtdm_irq_request() documentation.

Regards,
Bob Feretich

Re: [Xenomai-help] RTDM driver structure - an update

[Gilles Chanteperdrix]

Bob Feretich wrote:
>   Comments inline..
> 
> On 8/10/2010 6:18 AM, Gilles Chanteperdrix wrote:
>> ...snipped...
>> The RTDM_IRQTYPE_EDGE is documented in RTDM API documentation: "Mark IRQ
>> as edge-triggered, relevant for correct handling of shared
>> edge-triggered IRQs. " Here:
>> http://www.xenomai.org/documentation/xenomai-2.5/html/api/group__rtdmirq.html
> The above quotation is the full extent of the documentation. The driver 
> authors (we) ask the question, "Should I include this flag when I call 
> rtdm_irq_request()?" The documentation leaves the answer ambiguous in 
> the case where the RTDM_IRQTYPE_SHARED flag is not coded.
> 
> It also creates confusion. We assume that RTDM_IRQTYPE_EDGE will cause 
> hardware to be configured similar to request_irq().We knows that the 
> specification of RTDM_IRQTYPE_EDGE is insufficient.  Normally we need to 
> specify which edge is to cause the interrupt. We question whether 
> specifying RTDM_IRQTYPE_EDGE will cause our ISR to be entered on both 
> rising and falling edges.

Yes, the doc is not perfect, but in this case, I find the sentence
unambiguous, this flag is only relevant for shared irqs. And Xenomai is
free software, it means that:
- in case of doubt you may have a look at the code;
- we accept documentation patches.

> 
> The essence of this e-mail discussion eventually needs to be added to 
> the rtdm_irq_request() documentation.

I agree that we should try and improve the documentation. But in the
rtdm_irq_request case, it is even the interface which we should improve
by adding bits for setting the hardware, and when we are done, the
documentation work will be much simpler.

-- 
					    Gilles.