Dmitry Adamushko wrote: > On 06/09/06, Jan Kiszka <[EMAIL PROTECTED]> 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
