[Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 1354 bytes --]

Wolfgang Grandegger wrote:
> Jan Kiszka wrote:
>> Hi Wolfgang,
>>
>> in the process of preparing to merge rtdm_irq_enable into
>> rtdm_irq_request I would like to check if the attached patch is ok, thus
>> we could finally drop rtdm_irq_enable once the API is refactored. Please
>> check carefully when the first IRQs may happen and what the handler
>> expects to be initialised! SJA1000 /should/ be ok as it works with
> 
>> shared IRQs, but MSCAN does not (why, BTW?) and /may/ stumble.
> 
> OK. Why should I use shared interrupts if there is no need? Most
> embedded PowerPC systems have a dedicated interrupt source.

Of course, /me forgot once again that not all the world is designed like
crappy x86. :)

At this chance I looked over the irq_flag mechanism of the CAN stack and
found a minor cleanup: this #ifdef [1] is not required. If there is no
sharing support, the subscriber will simply be redirected to the
non-shared handler.

@Dmitry: What happens under CONFIG_XENO_OPT_SHIRQ_LEVEL &&
!CONFIG_XENO_OPT_SHIRQ_EDGE when someone comes along with
XN_ISR_SHARED|XN_ISR_EDGE? Looks like the level-triggered shared handler
gets installed. Should we catch this? At Kconfig or at nucleus level?

Jan


[1]http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/sja1000/rtcan_peak_pci.c?v=SVN-trunk#L233


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]