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

[Bob Feretich <bob.feretich@domain.hid>]

  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 ...
>>