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

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

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

Dmitry Adamushko wrote:
> On 06/09/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>
>> Dmitry Adamushko wrote:
> 
> 
> 
> 
>> -menu "Shared interrupts"
>> >> +menuconfig XENO_OPT_SHIRQ
>> >> +       bool "Shared interrupts"
>> >>
>> >> config XENO_OPT_SHIRQ_LEVEL
>> >>         bool "Level-triggered interrupts"
>> >> -       default n
>> >> +       depends on XENO_OPT_SHIRQ
>> >> +       default y
>> >>         help
>> >> -
>> >> +
>> >>         Enables support for shared level-triggered interrupts, so that
>> >>         multiple real-time interrupt handlers are allowed to control
>> >>         dedicated hardware devices which are configured to share
>> >> @@ -369,7 +371,8 @@ config XENO_OPT_SHIRQ_LEVEL
>> >>
>> >> config XENO_OPT_SHIRQ_EDGE
>> >>         bool "Edge-triggered interrupts"
>> >> -       default n
>> >> +       depends on XENO_OPT_SHIRQ
>> >> +       default y
>> >>         help
>> >
>> >
>> > So a user may end up with XENO_OPT_SHIRQ being enabled while both LEVEL
>> and
>> > EDGE are disabled? Maybe it's worth to make LEVEL "y" by default as
>> it's
>> > likely to be a required option?
>> >
>>
>> Do you see the "default y" above, no? :)
> 
> 
> Arghhh, again... nop, I bet it was not there before! How did you manage to
> hack my gmail account? :)

"Don't comment", my lawyer always says.

> 
> I thought about making only XENO_OPT_SHIRQ_LEVEL default y, but at least
>> for poor x86 users on legacy hardware (ISA) sharing takes at least as
>> often place with edge-triggered sources.
> 
> 
> I thought it's level-triggered indeed. At least, judging by the fact that
> linux provides a generic support only for level-triggered case.
> 
> e.g. cross-domain IRQ sharing (with you approach) would require only LEVEL
> option (I actually wanted to port/rework, taking into account the
> improvements we have discussed recently, your patch over some recent e.g.
> e1000 driver + Xeno so to have an up-to-date example illustrating the
> approach).
> 

Sounds good. Do you plan to use RTDM for the RT-stub? Then we would only
have to add the propagation flag to the return codes, right?

Anyway. So you have e1000 hardware to test it? [Mmh, then you could also
test our rt_e1000 in RTnet...] Another option would be the UHCI driver,
might be an even more common IRQ hog. But pick whatever is easier to
implement and test.

Jan


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