On 02.05.22 20:08, C Smith wrote:
> On Sun, May 1, 2022 at 11:25 PM Jan Kiszka <[email protected]> wrote:
>>
>> On 29.04.22 21:01, Richard Weinberger via Xenomai wrote:
>>> On Fri, Apr 29, 2022 at 9:04 AM C Smith via Xenomai <[email protected]> 
>>> wrote:
>>>> int Lp_port_handler(rtdm_irq_t *irq_handle_p)
>>>> {
>>>>    static int err;
>>>>    unsigned long next;
>>>>    rtdm_irq_t *handle_p;
>>>>
>>>>    handle_p = rtdm_irq_get_arg(irq_handle_p, rtdm_irq_t);
>>>>
>>>>    next = rtdm_clock_read();
>>>>    // do some timing calculations with 'next' var here ...
>>>>    err = rtdm_irq_enable(handle_p);   //re-enable this for subsequent 
>>>> interrupts
>>>
>>> You don't need this.
>>> Unconditionally enabling the interrupt line will confuse the IRQ subsystem.
>>>
>>
>> ...and it was never supported in primary mode. If it worked, then by
>> chance and by disabling related checks. Enable/disable are no masking APIs.
>>
>> Jan
>>
>>>>   return 0;
>>>
>>> Please use RTDM_IRQ_HANDLED here instead of raw values.
>>>
>>>> }
>>>
>>> Thanks,
>>> //richard
> 
> I was thinking the rtdm_irq_enable() was like an STI, but that was a
> mistake.  I looked at the 16550A and CAN drivers for examples of
> interrupt handlers, and indeed I found I must return RTDM_IRQ_HANDLED
> too like Richard says, or Xenomai de-registers the interrupt since no
> one appears to handle it. There doesn't seem to be an interrupt
> example in Xenomai 3.1 or Xeno3.2 sources. Perhaps I should submit a
> demo interrupt handler module as a patch?

Well, we have quite a few real drivers in the codebase. Maybe rather
enable one to serve a reference, e.g. by adding a document that
describes the relevant bits a bit more verbose? The UART drivers my
serve as input here as they do not come with an own core.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Reply via email to