From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Mon, 23 Jan 2006 18:41:52 +0200 From: Dmitry Adamushko In-Reply-To: <43D41364.6000300@domain.hid> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_38025_20017524.1138034512415" References: <43D41364.6000300@domain.hid> Subject: [Xenomai-core] Re: [PATCH] Shared irqs v.5 List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai@xenomai.org ------=_Part_38025_20017524.1138034512415 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline On 23/01/06, Jan Kiszka wrote: > > Dmitry Adamushko wrote: > > Hello Jan, > > > > as I promised earlier today, here is the patch. > > I finally had a look at your patch (not yet a try), and it looks really > nice and light-weight. I have another version here at hand. The only difference is that xnintr_irq_handler() handles all interrupts and destinguished the timer interrupt via "irq == XNARCH_TIMER_IRQ" to handle it appropriately. This way, the i-cache is, hopefully, used a bit more effectively. But it doesn't make a big difference in other parts of code so you may start testing with the one I posted earlier. Now I only have two topics on my wish list: > o Handling of edge-triggered IRQs (ISA-cards...). As I tried to explain, > in this case we have to run the IRQ handler list as long as the full > list completed without any handler reporting XN_ISR_ENABLE back. Then > and only then we are safe to not stall the IRQ line. See e.g. > serial8250_interrupt() in linux/drivers/serial/8250.c for a per-driver > solution and [1] for some discussion on sharing IRQs (be warned, it's > from the evil side ;) ). Ok. e.g. we may introduce another flag to handle such a special case. Something along XN_ISR_EDGETIRQ and maybe a separate xnintr_etshirq_handler() (xnintr_attach() will set it up properly) so to avoid interfering with another code. No big overhead I guess. serial8250_interrupt() defines a maximum number of iterations so we should do the same (?) to avoid brain-damaged cases. On our systems we already have two of those use-cases: the xeno_16550A > handling up to 4 devices on the same IRQ on an ISA card (I don't want > to know what worst-case latency can be caused here...) and our > SJA-1000 CAN driver for PC/104 ISA card with 2 controllers on the same > interrupt line. So a common solution would reduce the code size and > potential bug sources. > > o Store and display (/proc) the driver name(s) registered on an IRQ line > somewhere (ipipe?). This is just a nice-to-have. I introduced the RTDM > API with the required argument in place, would be great if we can use > this some day. Yes, the proper /proc extension should be avalable. Actually, the "native" skin can't be extended to support the shared interrupts only by adding a new flag. The "problem" is the way the /proc/xenomai/registry/interrupts is implemented there (and I assume any other skin follows the same way). The rt_registry object is created per each RT_INTR structure and, hence, per each xnintr_t. I'd see the following scheme : either /proc/xenomai/interrupts lists all interrupts objects registered on the nucleus layer (xnintr_t should have a "name" field). IRQN drivers 3 driver1 ... 5 driver2, driver3 and the skin presents per-object information as ll /proc/xenomai/registry/interrupts driver1 driver2 driver3 each of those files contains the same information as now. To achieve this, 1) xnintr_t should be extended with a "name" field; 2) rt_intr_create() should contain a "name" argument and not use auto-generation (as "irqN") any more. or ll /proc/xenomai/registry/interrupts 3 5 Those are directories and e.g. ll /proc/xenomai/registry/interrupts/5 driver2 driver3 Those are "files" and contain the same information as now. This is harder to implement since the registry interface should be extended (for each skin). > ... > Jan > > > PS: Still at home? Yes. This week I'm going to Belgium to attend a few meeting with some customers of my potential employer. So my next step for the nearest future will be finally determined there :) How many degrees Centigrade? I guess our current -9°C > here in Hannover must appear ridiculous, almost subtropical warm to you. > ;) Hey, I'm not from Syberia :o) This is a kind of common delusion I guess as the whole former USSR is assotiated with cold winters, bears, eak.. KGB etc. :o) from wikipedia.com (about Belarus) : "The climate ranges from harsh winters (average January temperatures are in the range −8 °C to −2 °C) to cool and moist summers(average temperature 15 °C to 20 °C)." Actually, last days it was very cooooold - even about -30C. This happens from time to time but very rare (once in a few years or so) and it's not considered as something normal here. e.g. schools were closed a few last days when the temperature was below -25. Actually, the weather is getting crazy last years and not only here :) [1] http://www.microsoft.com/whdc/system/sysperf/apic.mspx > > > -- Best regards, Dmitry Adamushko ------=_Part_38025_20017524.1138034512415 Content-Type: text/html; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 23/01/06, Jan Kiszka <jan.kiszka@domain.hid> wrote:
Dmitry Adamushko wrote:
> Hello Jan,
>
> as I promised earlier today, here is the patch.

I finally had a look at your patch (not yet a try), and it looks really
nice and light-weight.

I have another version here at hand. The only difference is that  xnintr_irq_handler() handles all interrupts and destinguished the timer interrupt via "irq == XNARCH_TIMER_IRQ" to handle it appropriately. This way, the i-cache is, hopefully, used a bit more effectively. But it doesn't make a big difference in other parts of code so you may start testing with the one I posted earlier.


Now I only have two topics on my wish list:
o Handling of edge-triggered IRQs (ISA-cards...). As I tried to explain,
  in this case we have to run the IRQ handler list as long as the full
  list completed without any handler reporting XN_ISR_ENABLE back. Then
  and only then we are safe to not stall the IRQ line. See e.g.
  serial8250_interrupt() in linux/drivers/serial/8250.c for a per-driver
  solution and [1] for some discussion on sharing IRQs (be warned, it's
  from the evil side ;) ).

Ok. e.g. we may introduce another flag to handle such a special case. Something along XN_ISR_EDGETIRQ and maybe a separate xnintr_etshirq_handler() (xnintr_attach() will set it up properly) so to avoid interfering with another code. No big overhead I guess.
serial8250_interrupt() defines a maximum number of iterations so we should do the same (?) to avoid brain-damaged cases.

  On our systems we already have two of those use-cases: the xeno_16550A
  handling up to 4 devices on the same IRQ on an ISA card (I don't want
  to know what worst-case latency can be caused here...) and our
  SJA-1000 CAN driver for PC/104 ISA card with 2 controllers on the same
  interrupt line. So a common solution would reduce the code size and
  potential bug sources.

o Store and display (/proc) the driver name(s) registered on an IRQ line
  somewhere (ipipe?). This is just a nice-to-have. I introduced the RTDM
  API with the required argument in place, would be great if we can use
  this some day.

Yes, the proper /proc extension should be avalable. Actually, the "native" skin can't be extended to support the shared interrupts only by adding a new flag. The "problem" is the way the /proc/xenomai/registry/interrupts is implemented there (and I assume any other skin follows the same way). The rt_registry object is created per each RT_INTR structure and, hence, per each xnintr_t.

I'd see the following scheme :

either

/proc/xenomai/interrupts lists all interrupts objects registered on the nucleus layer (xnintr_t should have a "name" field).

IRQN      drivers

3              driver1
...
5              driver2, driver3

and the skin presents per-object information as

ll /proc/xenomai/registry/interrupts

driver1
driver2
driver3

each of those files contains the same information as now.

To achieve this,

1) xnintr_t should be extended with a "name" field;

2) rt_intr_create() should contain a "name" argument and not use auto-generation (as "irqN") any more.

or

ll /proc/xenomai/registry/interrupts

3
5
 
Those are directories and e.g.

ll /proc/xenomai/registry/interrupts/5

driver2
driver3

Those are "files" and contain the same information as now.

This is harder to implement since the registry interface should be extended (for each skin).


> ...
 
Jan


PS: Still at home?

Yes. This week I'm going to Belgium to attend a few meeting with some customers of my potential employer. So my next step for the nearest future will be finally determined there :)
 

How many degrees Centigrade? I guess our current -9°C
here in Hannover must appear ridiculous, almost subtropical warm to you. ;)

Hey, I'm not from Syberia :o) This is a kind of common delusion I guess as the whole former USSR is assotiated with cold winters, bears, eak.. KGB etc. :o)

from wikipedia.com (about Belarus) :

"The climate ranges from harsh winters (average January temperatures are in the range −8 °C to −2 °C) to cool and moist summers (average temperature 15 °C to 20 °C)."

Actually, last days it was very cooooold - even about -30C. This happens from time to time but very rare (once in a few years or so) and it's not considered as something normal here. e.g. schools were closed a few last days when the temperature was below -25. Actually, the weather is getting crazy last years and not only here :)

[1] http://www.microsoft.com/whdc/system/sysperf/apic.mspx




--
Best regards,
Dmitry Adamushko ------=_Part_38025_20017524.1138034512415--