All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@domain.hid>
To: Dmitry Adamushko <dmitry.adamushko@domain.hid>
Cc: xenomai@xenomai.org
Subject: [Xenomai-core] Re: Move rtdm_irq_enable close to rtdm_irq_request
Date: Wed, 06 Sep 2006 16:54:07 +0200	[thread overview]
Message-ID: <44FEE10F.5030208@domain.hid> (raw)
In-Reply-To: <b647ffbd0609060527o13a077f4ue1fd1b445b1379c7@domain.hid>


[-- Attachment #1.1: Type: text/plain, Size: 2445 bytes --]

Dmitry Adamushko wrote:
> On 06/09/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>
>> > If such a driver (that requires EDGE_SHARED) is a part of the mainline,
>> > then
>> > we may use Kconfig features either (1) to make it "selectable" only
>> when
>> > XENO_OPT_SHIRQ_EDGE is on or (2) select XENO_OPT_SHIRQ_EDGE
>> automatically
>> > when the driver has been choosen.
>> >
>>
>> Let's do both, the runtime check + some Kconfig magic for mainline
>> drivers.
>>
>> For the latter we should reorganise the config options slightly.
>> XENO_OPT_SHIRQ_* may better depend on a new switch XENO_OPT_SHIRQ. Thus,
>> when the user enables IRQ sharing and some in-tree driver requires
>> edge-triggering support, XENO_OPT_SHIRQ_EDGE will be selected by the
>> driver's Kconfig: select XENO_OPT_SHIRQ_EDGE if XENO_OPT_SHIRQ. With the
>> current layout it would look like this: select XENO_OPT_SHIRQ_EDGE if
>> XENO_OPT_SHIRQ_LEVEL.
> 
> 
> XENO_OPT_SHIRQ_LEVEL doesn't need to be on in order to use
> XENO_OPT_SHIRQ_EDGE.
> 
> Or you probably mean the following behavior :
> 
> (1)
> some driver with XN_ISR_EDGE is selected :
> 
> if XENO_OPT_IRQ
>     select XENO_OPT_SHIRQ_EDGE
> 
> else
>     "run-time" check in xnintr_attach() will report -EBUSY in case the line
> is already busy
> 
> What I meant is
> 
> (2)
> some driver with XN_ISR_EDGE is selected :
> 
> o   select XENO_OPT_SHIRQ_EDGE
> 
> So that shared irq support (only for edge-triggered interrupts) gets
> unconditionally enabled.
> 
> in case of (1), XENO_OPT_SHIRQ can't be enabled on its own, i.e. without
> any
> of XENO_OPT_SHIRQ_*.

See attached patch: XENO_OPT_SHIRQ would just be a menu-enabler without
any affect outside kconfig. You could enabled it and leave the rest off
(makes no sense of course) - as long as there are no edge-triggered
users around.

Doesn't apply on 2.4, though, but we would still have the runtime test
in place. As long as catching luser mistakes is that simple, I'm
personally in favour of appropriate tests.

> 
> Well, your proposal is probably better. With XN_ISR_EDGE a driver only
> declares that it's ready to work in shared mode but it doesn't mean it
> can't
> work in non-shared one.
> 
> If a user has a separate line for it, then the shared-IRQ infrastracture
> adds just non-used overhead. Yep, you are right (heh... you are asking who
> had doubts? :)
> 

Jan

[-- Attachment #1.2: shirq-kconfig.patch --]
[-- Type: text/plain, Size: 2709 bytes --]

Index: ksrc/drivers/serial/Kconfig
===================================================================
--- ksrc/drivers/serial/Kconfig	(revision 1561)
+++ ksrc/drivers/serial/Kconfig	(working copy)
@@ -3,6 +3,7 @@ menu "Serial drivers"
 config XENO_DRIVERS_16550A
 	depends on XENO_SKIN_RTDM
 	tristate "16550A UART driver"
+	select XENO_OPT_SHIRQ_EDGE if XENO_OPT_SHIRQ
 	help
 	Real-time UART driver for 16550A compatible controllers. See
 	doc/txt/16550A-driver.txt for more details.
Index: ksrc/drivers/can/sja1000/Kconfig
===================================================================
--- ksrc/drivers/can/sja1000/Kconfig	(revision 1561)
+++ ksrc/drivers/can/sja1000/Kconfig	(working copy)
@@ -1,24 +1,21 @@
 config XENO_DRIVERS_RTCAN_SJA1000
        depends on XENO_DRIVERS_RTCAN
        tristate "Philips SJA1000 CAN controller"
-       default n
 
 config XENO_DRIVERS_RTCAN_SJA1000_ISA
        depends on XENO_DRIVERS_RTCAN_SJA1000
        tristate "Standard ISA devices"
-       default n
+       select XENO_OPT_SHIRQ_EDGE if XENO_OPT_SHIRQ
 
 config XENO_DRIVERS_RTCAN_SJA1000_ISA_MAX_DEV
        depends on XENO_DRIVERS_RTCAN_SJA1000_ISA
        int "Maximum number of ISA devices"
-       default 4       
+       default 4
 
 config XENO_DRIVERS_RTCAN_SJA1000_PEAK_PCI
        depends on XENO_DRIVERS_RTCAN_SJA1000
        tristate "PEAK PCI Card"
-       default n
 
 config XENO_DRIVERS_RTCAN_SJA1000_PEAK_DNG
        depends on XENO_DRIVERS_RTCAN_SJA1000
        tristate "PEAK Parallel Port Dongle"
-       default n
Index: ksrc/nucleus/Kconfig
===================================================================
--- ksrc/nucleus/Kconfig	(revision 1561)
+++ ksrc/nucleus/Kconfig	(working copy)
@@ -355,13 +355,15 @@ config XENO_OPT_TIMER_WHEEL_STEP
 endmenu
 
 
-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
 
 	Enables support for shared edge-triggered interrupts, so that
@@ -377,8 +380,6 @@ config XENO_OPT_SHIRQ_EDGE
 	dedicated hardware devices which are configured to share
 	the same interrupt channel.
 
-endmenu
-
 menu "LTT tracepoints filtering"
 
 	depends on LTT

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

  reply	other threads:[~2006-09-06 14:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-05 12:58 [Xenomai-core] Move rtdm_irq_enable close to rtdm_irq_request Jan Kiszka
2006-09-05 15:38 ` [Xenomai-core] " Wolfgang Grandegger
2006-09-05 16:02   ` Jan Kiszka
2006-09-05 19:10     ` Dmitry Adamushko
2006-09-06  6:36       ` Jan Kiszka
2006-09-06  8:59         ` Dmitry Adamushko
2006-09-06  9:26           ` Jan Kiszka
2006-09-06 12:27             ` Dmitry Adamushko
2006-09-06 14:54               ` Jan Kiszka [this message]
2006-09-06 15:08                 ` Dmitry Adamushko
2006-09-06 15:54                   ` Jan Kiszka
2006-09-06 17:23                     ` Dmitry Adamushko
2006-09-06 18:13                       ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44FEE10F.5030208@domain.hid \
    --to=jan.kiszka@domain.hid \
    --cc=dmitry.adamushko@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.