[Xenomai-core] [RFC] support for sharing IRQs

[Xenomai-core] [RFC] support for sharing IRQs

[Jan Kiszka]

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

Hi,

at the moment the 16550A UART driver that comes with Xenomai does not
support IRQ sharing between serial ports or with other real-time
devices. I first considered adding such support to the driver
internally, but I think it's better work on a generic approach for Xenomai.

I have some code hanging around here which implements IRQ sharing at
skin level for an experimental in-house development over Xenomai. The
code is smart enough to register an IRQ sharing trampoline handler only
in case sharing is actually practiced for a specific line. The IRQ API
is just extended by a single flag (imagine RTDM_IRQ_SHARED) which is set
upon registering an ISR that is capable of IRQ sharing. The semantic is
the same as the kernel's SA_SHIRQ.

I think it would be possible to break this out and generate a mainline
patch. Anyway, the question for me is where to put this best, at skin
(RTDM?) or at nucleus level? Both is technically feasible, but which way
is desired? (I would vote for the nucleus...)

Jan


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

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Dmitry Adamushko]

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


Hi Jan,

>
> I have some code hanging around here which implements IRQ sharing at
> skin level for an experimental in-house development over Xenomai. The
> code is smart enough to register an IRQ sharing trampoline handler only
> in case sharing is actually practiced for a specific line.

Could you be a bit more specific on what is meant by "...sharing is
actually practiced for a specific line"?

To my knowledge, the matter is only about whether a certain device (driver)
permits the earlier obtained irq line to be shared with other devices.
i.e. a driver [1] may succeed with an irq registration request in case
another driver [2] already holds this line but both [1] and [2] have
specified a SA_SHIRQ flag.


> I think it would be possible to break this out and generate a mainline
> patch. Anyway, the question for me is where to put this best, at skin
> (RTDM?) or at nucleus level? Both is technically feasible, but which way
> is desired? (I would vote for the nucleus...)

If we have a policy that all the drivers should be implemented on top of
RTDM, then, it can be done there. If no (and I guess so), this feature
should be common and I'd vote for the nucleus.
It seems to me now, that some parts of the hal will be involved
(rthal_irq_request/release()) since the nucleus itself doesn't keep track
of registered irqs.


>
> Jan
>

---
Best regards,
Dmitry

[-- Attachment #2: Type: text/html, Size: 1684 bytes --]

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Jan Kiszka]

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

Dmitry Adamushko wrote:
> Hi Jan,
> 
>> I have some code hanging around here which implements IRQ sharing at
>> skin level for an experimental in-house development over Xenomai. The
>> code is smart enough to register an IRQ sharing trampoline handler only
>> in case sharing is actually practiced for a specific line.
> 
> Could you be a bit more specific on what is meant by "...sharing is
> actually practiced for a specific line"?

Ok, one have to remind that my existing code is built on top of the
non-sharing xnintr_xxx API. This means that I had to define a trampoline
ISR which does the loop over all registered end-user ISRs. And this
intermediate handler is only involved when A) the IRQ is sharable and B)
there is actually more than one ISR registered for it.

This "smartness" becomes obsolete when we embed a doubly-linked list
into xnintr_t and already iterate over it in xnintr_irq_handler().

> 
> To my knowledge, the matter is only about whether a certain device (driver)
> permits the earlier obtained irq line to be shared with other devices.
> i.e. a driver [1] may succeed with an irq registration request in case
> another driver [2] already holds this line but both [1] and [2] have
> specified a SA_SHIRQ flag.

Yep.

> 
> 
>> I think it would be possible to break this out and generate a mainline
>> patch. Anyway, the question for me is where to put this best, at skin
>> (RTDM?) or at nucleus level? Both is technically feasible, but which way
>> is desired? (I would vote for the nucleus...)
> 
> If we have a policy that all the drivers should be implemented on top of
> RTDM, then, it can be done there. If no (and I guess so), this feature
> should be common and I'd vote for the nucleus.

Drivers should be built over RTDM, that's true. But there may still be
driver-like applications, also in user space that attach directly to the
IRQs via the various skin APIs. I think it would be good to let them
live side-by-side with RTDM drivers or other IRQ-using applications.

> It seems to me now, that some parts of the hal will be involved
> (rthal_irq_request/release()) since the nucleus itself doesn't keep track
> of registered irqs.

That's true. And it also raises another question to me: why do we have
those two different IRQ models?

The HAL only one handler per IRQ which get called with the triggering
IRQ number. That handler will call the nucleus with an attached cookie.
And on the other side is the nucleus which works with a xnintr_t per
IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs,
rescheduling, etc.

I'm asking as this abstraction adds one trampoline call (at HAL level),
thus may lead to more I-cache misses. Isn't it worth considering some
HAL mechanisms based on more #defines and static inlines in this regard?

Jan


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

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Dmitry Adamushko]

On Monday 31 October 2005 16:04, you wrote:
> Dmitry Adamushko wrote:
> > It seems to me now, that some parts of the hal will be involved
> > (rthal_irq_request/release()) since the nucleus itself doesn't keep track
> > of registered irqs.
>
> That's true. And it also raises another question to me: why do we have
> those two different IRQ models?
>
> The HAL only one handler per IRQ which get called with the triggering
> IRQ number. That handler will call the nucleus with an attached cookie.
> And on the other side is the nucleus which works with a xnintr_t per
> IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs,
> rescheduling, etc.
>
> I'm asking as this abstraction adds one trampoline call (at HAL level),
> thus may lead to more I-cache misses. Isn't it worth considering some
> HAL mechanisms based on more #defines and static inlines in this regard?

Let's take a look at what we have got currently:

[1] 	ipipe_domain::irqs[IPIPE_NR_IRQS]	[ADEOS-IPIPE]

the handler is defined as void (*handler)(unsigned irq);

in our case, this is rthal_irq_trampoline() [2] , but can be different for 
some other cases;

[2] 	rthal_irq_trampoline()				[HAL]

struct rthal_realtime_irq[IPIPE_NR_IRQS]

the handler is defined as void (*handler)(unsigned irq, void *cookie);

this one normally does a simple thing, just calls xnintr_irq_handler() [3] as 
you have mentioned before.

[3] 	xnintr_irq_handler()				[nucleus]
 
this routine calls a certain user's ISR as well as handles some 
nucleus-specific chores (re-scheduling, etc.)

[4]	user's ISR						[user driver]

does user-specific things

Well, [3] is necessary anyway since some nucleus-related chores must be done 
and this is a correct layer for that (e.g. [2] knows nothing about 
scheduling).

What can be theoretically merged is [1] + [2] (errr... I said theoretically, 
it's still not the case to kill me for just having said that :o). To this 
end, ipipe_domain should be extended in order to contain all the fields of 
[2]::struct rthal_realtime_irq (at least, handler(irq, cookie) + cookie).
btw, ipipe_domain::irqs may even contain a pointer to the slightly modified 
xnintr_t structure (which is really e.g. a circular list) that may be passed 
as "cockie" to the xnintr_irq_handler().

The analogy is irq_desc_t vs. irqaction structures in Linux.

This way, xnintr_irq_handler() can be called from adeos-ipipe layer directly 
without the [2] layer.

But that change looks quite invasive to me so far since 
ipipe_domain::irqs::handler(irq - with a single parameter) is used all over 
the map.

In our case, the relation between xnintr_irq_handler() and 
rthal_irq_trampoline() is 1:1. The first one does much more things that the 
second one which is really almost a pure redirection layer.
Hopefully, xnintr_irq_handler() is i-cache-hot as long as possible under high 
irq load. In this case, I guess, rthal_irq_trampoline() will be in cache as 
well (since it's really small) and the overhead is only about having one 
array indexing op. and issuing a call via a pointer to the function 
(xnintr_irq_handler() in our case).
Do you think that really gives a significant overhead? Well, maybe so. I'm not 
a profie here anyway...

>
> Jan

---
Best regards,
Dmitry

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Jan Kiszka]

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

Dmitry Adamushko wrote:
> On Monday 31 October 2005 16:04, you wrote:
> 
>>Dmitry Adamushko wrote:
>>
>>>It seems to me now, that some parts of the hal will be involved
>>>(rthal_irq_request/release()) since the nucleus itself doesn't keep track
>>>of registered irqs.
>>
>>That's true. And it also raises another question to me: why do we have
>>those two different IRQ models?
>>
>>The HAL only one handler per IRQ which get called with the triggering
>>IRQ number. That handler will call the nucleus with an attached cookie.
>>And on the other side is the nucleus which works with a xnintr_t per
>>IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs,
>>rescheduling, etc.
>>
>>I'm asking as this abstraction adds one trampoline call (at HAL level),
>>thus may lead to more I-cache misses. Isn't it worth considering some
>>HAL mechanisms based on more #defines and static inlines in this regard?
> 
> 
> Let's take a look at what we have got currently:
> 
> [1] 	ipipe_domain::irqs[IPIPE_NR_IRQS]	[ADEOS-IPIPE]
> 
> the handler is defined as void (*handler)(unsigned irq);
> 
> in our case, this is rthal_irq_trampoline() [2] , but can be different for 
> some other cases;
> 
> [2] 	rthal_irq_trampoline()				[HAL]
> 
> struct rthal_realtime_irq[IPIPE_NR_IRQS]
> 
> the handler is defined as void (*handler)(unsigned irq, void *cookie);
> 
> this one normally does a simple thing, just calls xnintr_irq_handler() [3] as 
> you have mentioned before.
> 
> [3] 	xnintr_irq_handler()				[nucleus]
>  
> this routine calls a certain user's ISR as well as handles some 
> nucleus-specific chores (re-scheduling, etc.)
> 
> [4]	user's ISR						[user driver]
> 
> does user-specific things
> 
> Well, [3] is necessary anyway since some nucleus-related chores must be done 
> and this is a correct layer for that (e.g. [2] knows nothing about 
> scheduling).
> 
> What can be theoretically merged is [1] + [2] (errr... I said theoretically, 
> it's still not the case to kill me for just having said that :o). To this 
> end, ipipe_domain should be extended in order to contain all the fields of 
> [2]::struct rthal_realtime_irq (at least, handler(irq, cookie) + cookie).
> btw, ipipe_domain::irqs may even contain a pointer to the slightly modified 
> xnintr_t structure (which is really e.g. a circular list) that may be passed 
> as "cockie" to the xnintr_irq_handler().
> 
> The analogy is irq_desc_t vs. irqaction structures in Linux.
> 
> This way, xnintr_irq_handler() can be called from adeos-ipipe layer directly 
> without the [2] layer.
> 
> But that change looks quite invasive to me so far since 
> ipipe_domain::irqs::handler(irq - with a single parameter) is used all over 
> the map.
> 
> In our case, the relation between xnintr_irq_handler() and 
> rthal_irq_trampoline() is 1:1. The first one does much more things that the 
> second one which is really almost a pure redirection layer.
> Hopefully, xnintr_irq_handler() is i-cache-hot as long as possible under high 
> irq load. In this case, I guess, rthal_irq_trampoline() will be in cache as 
> well (since it's really small) and the overhead is only about having one 
> array indexing op. and issuing a call via a pointer to the function 
> (xnintr_irq_handler() in our case).
> Do you think that really gives a significant overhead? Well, maybe so. I'm not 
> a profie here anyway...
> 

...compared to the usefulness I still have to understand - yes.

Other option: what about merging [2] into [3], i.e. let
xnintr_irq_handler deal with the translation IRQ number -> cookie?

Philippe, I guess your wisdom is required here. Are we missing some
important point in your design right now?

Jan

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

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Dmitry Adamushko]

On Monday 31 October 2005 21:38, you wrote:
> > [...]
> > In our case, the relation between xnintr_irq_handler() and
> > rthal_irq_trampoline() is 1:1. The first one does much more things that
> > the second one which is really almost a pure redirection layer.
> > Hopefully, xnintr_irq_handler() is i-cache-hot as long as possible under
> > high irq load. In this case, I guess, rthal_irq_trampoline() will be in
> > cache as well (since it's really small) and the overhead is only about
> > having one array indexing op. and issuing a call via a pointer to the
> > function (xnintr_irq_handler() in our case).
> > Do you think that really gives a significant overhead? Well, maybe so.
> > I'm not a profie here anyway...
>
> ...compared to the usefulness I still have to understand - yes.
>
> Other option: what about merging [2] into [3], i.e. let
> xnintr_irq_handler deal with the translation IRQ number -> cookie?

In that case, the nucleus must keep track of all the irqs, i.e. some_struct 
irqs[IPIPE_NR_IRQS]. Ok, the rthal_realtime_irq[] may be removed here from 
hal.
But there is already the per-irq array in ipipe_domain struct. Having got [1] 
and [2] merged, we would have this array as the only one and avoid the use of 
rthal_realtime_irq[] at all. Although, the ipipe_domain would become a bit 
more heavy :) Well, but [2] into [3] is leeeess intrusive on the other hand.

>
> Philippe, I guess your wisdom is required here. Are we missing some
> important point in your design right now?
>

He would be glad you/we/someone else would come up with a worthy decision 
(even if it's "keep it as is") without relying on the explanation of the 
current design from his side.
Ok, the morning brings better solutions :o)

> Jan

---
Best regards,
Dmitry

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Jan Kiszka]

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

Dmitry Adamushko wrote:
> On Monday 31 October 2005 21:38, you wrote:
>>> [...]
>>> In our case, the relation between xnintr_irq_handler() and
>>> rthal_irq_trampoline() is 1:1. The first one does much more things that
>>> the second one which is really almost a pure redirection layer.
>>> Hopefully, xnintr_irq_handler() is i-cache-hot as long as possible under
>>> high irq load. In this case, I guess, rthal_irq_trampoline() will be in
>>> cache as well (since it's really small) and the overhead is only about
>>> having one array indexing op. and issuing a call via a pointer to the
>>> function (xnintr_irq_handler() in our case).
>>> Do you think that really gives a significant overhead? Well, maybe so.
>>> I'm not a profie here anyway...
>> ...compared to the usefulness I still have to understand - yes.
>>
>> Other option: what about merging [2] into [3], i.e. let
>> xnintr_irq_handler deal with the translation IRQ number -> cookie?
> 
> In that case, the nucleus must keep track of all the irqs, i.e. some_struct 
> irqs[IPIPE_NR_IRQS]. Ok, the rthal_realtime_irq[] may be removed here from 
> hal.
> But there is already the per-irq array in ipipe_domain struct. Having got [1] 
> and [2] merged, we would have this array as the only one and avoid the use of 
> rthal_realtime_irq[] at all. Although, the ipipe_domain would become a bit 
> more heavy :) Well, but [2] into [3] is leeeess intrusive on the other hand.

Due to the intrusiveness, I would vote for a [2]->[3] merge.

One issue remains in any case: the HAL currently maintains a /proc entry
for the registered IRQs. It reports if a handler is registered and the
IRQ hits per CPU. As I think this entry should also report the
registered driver names in the future, we have to hand the management
over to whatever part traces all registered handlers. Is this acceptable
from the layering point of view?

Jan



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

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Dmitry Adamushko]

On Tuesday 01 November 2005 10:49, you wrote:

> > In that case, the nucleus must keep track of all the irqs, i.e.
> > some_struct irqs[IPIPE_NR_IRQS]. Ok, the rthal_realtime_irq[] may be
> > removed here from hal.
> > But there is already the per-irq array in ipipe_domain struct. Having got
> > [1] and [2] merged, we would have this array as the only one and avoid
> > the use of rthal_realtime_irq[] at all. Although, the ipipe_domain would
> > become a bit more heavy :) Well, but [2] into [3] is leeeess intrusive on
> > the other hand.
>
> Due to the intrusiveness, I would vote for a [2]->[3] merge.

Yep, obviously.

What about something like this:

[hal/generic.c]

struct rthal_realtime_irq_t {

	struct xnintr_t *handlers; // or xnqueue_t handlers;
	unsigned long hits[RTHAL_NR_CPUS];

	// maybe something else

} rthal_realtime_irq[IPIPE_NR_IRQS];

either this array should be exported so to be available from the nucleus layer 
or should be moved into the nucleus layer completely, but so far I like the 
idea the HAL handles basic irq-related chores, if no then e.g. what to do 
with rthal_linux_irq, apc counterparts.

struct xnintr_t is extended as follows:

...
unsigned flags;		// e.g. IRQ_SHARED
const char *name;
struct xnintr_t *next; // or xnholder_t hlink;
};

actually, xniack_t iack field should gone or a policy on its use should be 
established. e.g. what if a few handlers that share the same irq want to set 
up its own iack handler. I see that it's not a part of the rtdm's 
request_irq() interface (always NULL so that the default one is used) but a 
part of the native and posix skins' interfaces (e.g. rt_intr_create).

Another thing is how different return values of ISR handlers should be 
combined:
e.g. RT_INTR_CHAINED vs. HANDLED

first handler reports CHAINED, the second one - HANDLED and some of them - 
ENABLE.

[nucleus.c]

xnintr_irq_handler(unsigned irq, void *cookie) -> xnintr_irq_handler(unsigned 
irq)

Thus, it may be passed into rthal_virtualize_irq() and called directly from 
the ipipe layer (we don't need that hal::irq_trampoline() any more).

xnintr_irq_handler(unsigned irq)
{
- xnintr_t *intr = (xnintr_t *)cookie;
+ xnintr_t *handlers = hal_realtime_irq(irq)->handlers; // or get a queue 
otherwise
...
- s = intr->isr(intr);
+ iterate through all the handlers
...
}

err, hopefully that looks not like a complete mess, anyway that's what on the 
top of my head at the moment :)

>
> One issue remains in any case: the HAL currently maintains a /proc entry
> for the registered IRQs. It reports if a handler is registered and the
> IRQ hits per CPU. As I think this entry should also report the
> registered driver names in the future, we have to hand the management
> over to whatever part traces all registered handlers. Is this acceptable
> from the layering point of view?

But the same can be done from the HAL if we're still going to keep the per-irq 
array there as well as basic realtime-irq-related chores. Just in that case, 
the HAL would be aware about some extended information, like names.

>
> Jan

---
Best regards,
Dmitry

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Philippe Gerum]

Jan Kiszka wrote:
> Dmitry Adamushko wrote:
> 
>>On Monday 31 October 2005 16:04, you wrote:
>>
>>
>>>Dmitry Adamushko wrote:
>>>
>>>
>>>>It seems to me now, that some parts of the hal will be involved
>>>>(rthal_irq_request/release()) since the nucleus itself doesn't keep track
>>>>of registered irqs.
>>>
>>>That's true. And it also raises another question to me: why do we have
>>>those two different IRQ models?
>>>
>>>The HAL only one handler per IRQ which get called with the triggering
>>>IRQ number. That handler will call the nucleus with an attached cookie.
>>>And on the other side is the nucleus which works with a xnintr_t per
>>>IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs,
>>>rescheduling, etc.
>>>
>>>I'm asking as this abstraction adds one trampoline call (at HAL level),
>>>thus may lead to more I-cache misses. Isn't it worth considering some
>>>HAL mechanisms based on more #defines and static inlines in this regard?
>>
>>
>>Let's take a look at what we have got currently:
>>
>>[1] 	ipipe_domain::irqs[IPIPE_NR_IRQS]	[ADEOS-IPIPE]
>>
>>the handler is defined as void (*handler)(unsigned irq);
>>
>>in our case, this is rthal_irq_trampoline() [2] , but can be different for 
>>some other cases;
>>
>>[2] 	rthal_irq_trampoline()				[HAL]
>>
>>struct rthal_realtime_irq[IPIPE_NR_IRQS]
>>
>>the handler is defined as void (*handler)(unsigned irq, void *cookie);
>>
>>this one normally does a simple thing, just calls xnintr_irq_handler() [3] as 
>>you have mentioned before.
>>
>>[3] 	xnintr_irq_handler()				[nucleus]
>> 
>>this routine calls a certain user's ISR as well as handles some 
>>nucleus-specific chores (re-scheduling, etc.)
>>
>>[4]	user's ISR						[user driver]
>>
>>does user-specific things
>>
>>Well, [3] is necessary anyway since some nucleus-related chores must be done 
>>and this is a correct layer for that (e.g. [2] knows nothing about 
>>scheduling).
>>
>>What can be theoretically merged is [1] + [2] (errr... I said theoretically, 
>>it's still not the case to kill me for just having said that :o). To this 
>>end, ipipe_domain should be extended in order to contain all the fields of 
>>[2]::struct rthal_realtime_irq (at least, handler(irq, cookie) + cookie).
>>btw, ipipe_domain::irqs may even contain a pointer to the slightly modified 
>>xnintr_t structure (which is really e.g. a circular list) that may be passed 
>>as "cockie" to the xnintr_irq_handler().
>>
>>The analogy is irq_desc_t vs. irqaction structures in Linux.
>>
>>This way, xnintr_irq_handler() can be called from adeos-ipipe layer directly 
>>without the [2] layer.
>>
>>But that change looks quite invasive to me so far since 
>>ipipe_domain::irqs::handler(irq - with a single parameter) is used all over 
>>the map.
>>
>>In our case, the relation between xnintr_irq_handler() and 
>>rthal_irq_trampoline() is 1:1. The first one does much more things that the 
>>second one which is really almost a pure redirection layer.
>>Hopefully, xnintr_irq_handler() is i-cache-hot as long as possible under high 
>>irq load. In this case, I guess, rthal_irq_trampoline() will be in cache as 
>>well (since it's really small) and the overhead is only about having one 
>>array indexing op. and issuing a call via a pointer to the function 
>>(xnintr_irq_handler() in our case).
>>Do you think that really gives a significant overhead? Well, maybe so. I'm not 
>>a profie here anyway...
>>
> 
> 
> ...compared to the usefulness I still have to understand - yes.
> 
> Other option: what about merging [2] into [3], i.e. let
> xnintr_irq_handler deal with the translation IRQ number -> cookie?
> 

That's an option, yes. The other one being to teach Adeos to pass an additional 
cookie, but in such a case, only the i-pipe series would be upgraded to allow 
that, which would be a bit rude to people still currently relying on the legacy 
oldgen patches for running Xenomai. This said, at some point in time, upgrading 
will be necessary though.

> Philippe, I guess your wisdom is required here. Are we missing some
> important point in your design right now?
> 

Mmm, for the wisdom thing, please see there: 
http://fr.wikipedia.org/wiki/Mahatma_Gandhi

For the design issue, I agree that the initial trampoline is just a waste of 
cache lines and cycles. The only thing to keep in mind is to preserve a sensible 
layering so that the whole thing is still able to run over the event-driven 
simulation engine we have, but AFAICS, fixing the xnarch layer everywhere would 
grant that.

> Jan
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Philippe Gerum]

Dmitry Adamushko wrote:
> On Monday 31 October 2005 16:04, you wrote:
> 
>>Dmitry Adamushko wrote:
>>
>>>It seems to me now, that some parts of the hal will be involved
>>>(rthal_irq_request/release()) since the nucleus itself doesn't keep track
>>>of registered irqs.
>>
>>That's true. And it also raises another question to me: why do we have
>>those two different IRQ models?
>>
>>The HAL only one handler per IRQ which get called with the triggering
>>IRQ number. That handler will call the nucleus with an attached cookie.
>>And on the other side is the nucleus which works with a xnintr_t per
>>IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs,
>>rescheduling, etc.
>>
>>I'm asking as this abstraction adds one trampoline call (at HAL level),
>>thus may lead to more I-cache misses. Isn't it worth considering some
>>HAL mechanisms based on more #defines and static inlines in this regard?
> 
> 
> Let's take a look at what we have got currently:
> 
> [1] 	ipipe_domain::irqs[IPIPE_NR_IRQS]	[ADEOS-IPIPE]
> 
> the handler is defined as void (*handler)(unsigned irq);
> 
> in our case, this is rthal_irq_trampoline() [2] , but can be different for 
> some other cases;
> 
> [2] 	rthal_irq_trampoline()				[HAL]
> 
> struct rthal_realtime_irq[IPIPE_NR_IRQS]
> 
> the handler is defined as void (*handler)(unsigned irq, void *cookie);
> 
> this one normally does a simple thing, just calls xnintr_irq_handler() [3] as 
> you have mentioned before.
> 
> [3] 	xnintr_irq_handler()				[nucleus]
>  
> this routine calls a certain user's ISR as well as handles some 
> nucleus-specific chores (re-scheduling, etc.)
> 
> [4]	user's ISR						[user driver]
> 
> does user-specific things
> 
> Well, [3] is necessary anyway since some nucleus-related chores must be done 
> and this is a correct layer for that (e.g. [2] knows nothing about 
> scheduling).
> 
> What can be theoretically merged is [1] + [2] (errr... I said theoretically, 
> it's still not the case to kill me for just having said that :o). To this 
> end, ipipe_domain should be extended in order to contain all the fields of 
> [2]::struct rthal_realtime_irq (at least, handler(irq, cookie) + cookie).
> btw, ipipe_domain::irqs may even contain a pointer to the slightly modified 
> 

This would mean changing a core Adeos prototype, though.

xnintr_t structure (which is really e.g. a circular list) that may be passed
> as "cockie" to the xnintr_irq_handler().
> 
> The analogy is irq_desc_t vs. irqaction structures in Linux.
> 
> This way, xnintr_irq_handler() can be called from adeos-ipipe layer directly 
> without the [2] layer.
> 
> But that change looks quite invasive to me so far since 
> ipipe_domain::irqs::handler(irq - with a single parameter) is used all over 
> the map.
> 

I'd really prefer making one invasive change early in the process of addressing 
the issue than several kludges later to work around structural shortcomings, so 
no problem, go wild, I'm all ears.

> In our case, the relation between xnintr_irq_handler() and 
> rthal_irq_trampoline() is 1:1. The first one does much more things that the 
> second one which is really almost a pure redirection layer.
> Hopefully, xnintr_irq_handler() is i-cache-hot as long as possible under high 
> irq load. In this case, I guess, rthal_irq_trampoline() will be in cache as 
> well (since it's really small) and the overhead is only about having one 
> array indexing op. and issuing a call via a pointer to the function 
> (xnintr_irq_handler() in our case).
> Do you think that really gives a significant overhead? Well, maybe so. I'm not 
> a profie here anyway...
> 
> 
>>Jan
> 
> 
> ---
> Best regards,
> Dmitry
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 

Philippe.

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Jan Kiszka]

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

Philippe Gerum wrote:
> Dmitry Adamushko wrote:
>> On Monday 31 October 2005 16:04, you wrote:
>>
>>> Dmitry Adamushko wrote:
>>>
>>>> It seems to me now, that some parts of the hal will be involved
>>>> (rthal_irq_request/release()) since the nucleus itself doesn't keep
>>>> track
>>>> of registered irqs.
>>>
>>> That's true. And it also raises another question to me: why do we have
>>> those two different IRQ models?
>>>
>>> The HAL only one handler per IRQ which get called with the triggering
>>> IRQ number. That handler will call the nucleus with an attached cookie.
>>> And on the other side is the nucleus which works with a xnintr_t per
>>> IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs,
>>> rescheduling, etc.
>>>
>>> I'm asking as this abstraction adds one trampoline call (at HAL level),
>>> thus may lead to more I-cache misses. Isn't it worth considering some
>>> HAL mechanisms based on more #defines and static inlines in this regard?
>>
>>
>> Let's take a look at what we have got currently:
>>
>> [1]     ipipe_domain::irqs[IPIPE_NR_IRQS]    [ADEOS-IPIPE]
>>
>> the handler is defined as void (*handler)(unsigned irq);
>>
>> in our case, this is rthal_irq_trampoline() [2] , but can be different
>> for some other cases;
>>
>> [2]     rthal_irq_trampoline()                [HAL]
>>
>> struct rthal_realtime_irq[IPIPE_NR_IRQS]
>>
>> the handler is defined as void (*handler)(unsigned irq, void *cookie);
>>
>> this one normally does a simple thing, just calls xnintr_irq_handler()
>> [3] as you have mentioned before.
>>
>> [3]     xnintr_irq_handler()                [nucleus]
>>  
>> this routine calls a certain user's ISR as well as handles some
>> nucleus-specific chores (re-scheduling, etc.)
>>
>> [4]    user's ISR                        [user driver]
>>
>> does user-specific things
>>
>> Well, [3] is necessary anyway since some nucleus-related chores must
>> be done and this is a correct layer for that (e.g. [2] knows nothing
>> about scheduling).
>>
>> What can be theoretically merged is [1] + [2] (errr... I said
>> theoretically, it's still not the case to kill me for just having said
>> that :o). To this end, ipipe_domain should be extended in order to
>> contain all the fields of [2]::struct rthal_realtime_irq (at least,
>> handler(irq, cookie) + cookie).
>> btw, ipipe_domain::irqs may even contain a pointer to the slightly
>> modified
> 
> This would mean changing a core Adeos prototype, though.
> 
> xnintr_t structure (which is really e.g. a circular list) that may be
> passed
>> as "cockie" to the xnintr_irq_handler().
>>
>> The analogy is irq_desc_t vs. irqaction structures in Linux.
>>
>> This way, xnintr_irq_handler() can be called from adeos-ipipe layer
>> directly without the [2] layer.
>>
>> But that change looks quite invasive to me so far since
>> ipipe_domain::irqs::handler(irq - with a single parameter) is used all
>> over the map.
>>
> 
> I'd really prefer making one invasive change early in the process of
> addressing the issue than several kludges later to work around
> structural shortcomings, so no problem, go wild, I'm all ears.
> 

Oh, we have green light for some /real/ changes! ;)

Well, one advantage of a cookie inside the ipipe patch is that also the
data locality would increase, especially for the trivial case of only
one handler being installed. Then we would be able to handle down the
user's xnintr_t structure, and that one would already make it into the
caches by adeos traversing the pipe...

Jan


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

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Dmitry Adamushko]

On Tuesday 01 November 2005 12:58, you wrote:

> > as "cockie" to the xnintr_irq_handler().
> >
> > The analogy is irq_desc_t vs. irqaction structures in Linux.
> >
> > This way, xnintr_irq_handler() can be called from adeos-ipipe layer
> > directly without the [2] layer.
> >
> > But that change looks quite invasive to me so far since
> > ipipe_domain::irqs::handler(irq - with a single parameter) is used all
> > over the map.
>
> I'd really prefer making one invasive change early in the process of
> addressing the issue than several kludges later to work around structural
> shortcomings, so no problem, go wild, I'm all ears.
>

If we only want to get rid of the trampoline-thing then [2] + [3] would work 
out (btw, I have sent a message this morning where I tried to provide even 
some pseudo-code :) 

But if we want to (think that we may) gain the adventage of having a more 
flexible irq-related support from the ipipe layer, then yep, those changes 
might look worthy. I thought that this way, we would even get rid of another 
per-irq (rthal_realtime_irq) array in hal/generic.c, maybe even from 
rthal_linux_irq too. The sole one is provided by the ipipe_domain structure 
and a set of generic interfaces e.g. via system.h so that the HAL or another 
layer may get access of it.

e.g.

the "cookie" remains opaque for the ipipe but when requested by 
HAL::rthal_irq_request() or NUCLEUS::xnintr_irq_handler() it's treated as a 
chain of ISR handlers.


---
Best regards,
Dmitry

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Jan Kiszka]

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

Dmitry Adamushko wrote:
> On Tuesday 01 November 2005 12:58, you wrote:
> 
>>> as "cockie" to the xnintr_irq_handler().
>>>
>>> The analogy is irq_desc_t vs. irqaction structures in Linux.
>>>
>>> This way, xnintr_irq_handler() can be called from adeos-ipipe layer
>>> directly without the [2] layer.
>>>
>>> But that change looks quite invasive to me so far since
>>> ipipe_domain::irqs::handler(irq - with a single parameter) is used all
>>> over the map.
>> I'd really prefer making one invasive change early in the process of
>> addressing the issue than several kludges later to work around structural
>> shortcomings, so no problem, go wild, I'm all ears.
>>
> 
> If we only want to get rid of the trampoline-thing then [2] + [3] would work 
> out (btw, I have sent a message this morning where I tried to provide even 
> some pseudo-code :) 
> 
> But if we want to (think that we may) gain the adventage of having a more 
> flexible irq-related support from the ipipe layer, then yep, those changes 
> might look worthy. I thought that this way, we would even get rid of another 
> per-irq (rthal_realtime_irq) array in hal/generic.c, maybe even from 
> rthal_linux_irq too. The sole one is provided by the ipipe_domain structure 
> and a set of generic interfaces e.g. via system.h so that the HAL or another 
> layer may get access of it.
> 
> e.g.
> 
> the "cookie" remains opaque for the ipipe but when requested by 
> HAL::rthal_irq_request() or NUCLEUS::xnintr_irq_handler() it's treated as a 
> chain of ISR handlers.
> 

Yep, that's also what I had in mind about potential ipipe changes and
their use in the nucleus.

Jan



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

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Philippe Gerum]

Jan Kiszka wrote:
> Dmitry Adamushko wrote:
> 
>>On Tuesday 01 November 2005 12:58, you wrote:
>>
>>
>>>>as "cockie" to the xnintr_irq_handler().
>>>>
>>>>The analogy is irq_desc_t vs. irqaction structures in Linux.
>>>>
>>>>This way, xnintr_irq_handler() can be called from adeos-ipipe layer
>>>>directly without the [2] layer.
>>>>
>>>>But that change looks quite invasive to me so far since
>>>>ipipe_domain::irqs::handler(irq - with a single parameter) is used all
>>>>over the map.
>>>
>>>I'd really prefer making one invasive change early in the process of
>>>addressing the issue than several kludges later to work around structural
>>>shortcomings, so no problem, go wild, I'm all ears.
>>>
>>
>>If we only want to get rid of the trampoline-thing then [2] + [3] would work 
>>out (btw, I have sent a message this morning where I tried to provide even 
>>some pseudo-code :) 
>>
>>But if we want to (think that we may) gain the adventage of having a more 
>>flexible irq-related support from the ipipe layer, then yep, those changes 
>>might look worthy. I thought that this way, we would even get rid of another 
>>per-irq (rthal_realtime_irq) array in hal/generic.c, maybe even from 
>>rthal_linux_irq too. The sole one is provided by the ipipe_domain structure 
>>and a set of generic interfaces e.g. via system.h so that the HAL or another 
>>layer may get access of it.
>>
>>e.g.
>>
>>the "cookie" remains opaque for the ipipe but when requested by 
>>HAL::rthal_irq_request() or NUCLEUS::xnintr_irq_handler() it's treated as a 
>>chain of ISR handlers.
>>
> 
> 
> Yep, that's also what I had in mind about potential ipipe changes and
> their use in the nucleus.
> 

Ok, let's go for those changes this way:

1. The I-pipe series needs to be updated so that an opaque cookie is passed to 
the handler; since we have a change in the interface, the 1.1 series has to be 
started for this purpose.

2. In order to let the people running the legacy RTAI/fusion and Xenomai 2.0.x 
series a reasonable amount of time to upgrade their patchset, the IRQ layer 
updates (sharing and trampoline suppression) will go to the Xenomai 2.1 dev 
branch. IOW, Xenomai 2.1 will be exclusively based on the I-pipe 1.1 series, 
which also means that Xenomai support for the oldgen Adeos and I-pipe 1.0 
patches will be discontinued after the Xenomai 2.0.x series is closed.

3. Changes in the IRQ layer will be made at nucleus level, which is the most 
efficient way to provide them.

It should be noted that as part of the build system refactoring, the real-time 
HAL has become a static portion of the Linux kernel, with its generic part being 
moved to the nucleus. IOW, the proposed changes will basically end up as 
redispatching some code inside the nucleus.

-- 

Philippe.

RE: [Xenomai-core] [RFC] support for sharing IRQs

[Bernard Dautrevaux]

 

> -----Message d'origine-----
> De : xenomai-core-bounces@domain.hid
> [mailto:xenomai-core-bounces@domain.hid] De la part de Philippe Gerum
> Envoyé : mardi 1 novembre 2005 18:30
> À : Jan Kiszka
> Cc : xenomai-core
> Objet : Re: [Xenomai-core] [RFC] support for sharing IRQs
	....
> 
> Ok, let's go for those changes this way:
> 
> 1. The I-pipe series needs to be updated so that an opaque 
> cookie is passed to the handler; since we have a change in 
> the interface, the 1.1 series has to be started for this purpose.
> 
> 2. In order to let the people running the legacy RTAI/fusion 
> and Xenomai 2.0.x series a reasonable amount of time to 
> upgrade their patchset, the IRQ layer updates (sharing and 
> trampoline suppression) will go to the Xenomai 2.1 dev 
> branch. IOW, Xenomai 2.1 will be exclusively based on the 
> I-pipe 1.1 series, which also means that Xenomai support for 
> the oldgen Adeos and I-pipe 1.0 patches will be discontinued 
> after the Xenomai 2.0.x series is closed.

I agree with all that is said in this post; however there is just a smal
problem: some very useful tool for xenomai application debug and tune is
LTT; however the only available Adeos+LTT patch is not an ipipe one, but an
old linux-2.6.9 kernel patch.

At least the LTT support should be available with an ipipe-based Adeos-1.1
patch for 2.6.9 (waiting for LTT to support a more recent kernel), so that
LTT is not lost for xenomai (as it seems to be in fact for RTAI). 

Bernard

> 3. Changes in the IRQ layer will be made at nucleus level, 
> which is the most efficient way to provide them.
> 
> It should be noted that as part of the build system 
> refactoring, the real-time HAL has become a static portion of 
> the Linux kernel, with its generic part being moved to the 
> nucleus. IOW, the proposed changes will basically end up as 
> redispatching some code inside the nucleus.
> 
> -- 
> 
> Philippe.
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 
> 

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Philippe Gerum]

Bernard Dautrevaux wrote:
>  
> 
> 
>>-----Message d'origine-----
>>De : xenomai-core-bounces@domain.hid
>>[mailto:xenomai-core-bounces@domain.hid] De la part de Philippe Gerum
>>Envoyé : mardi 1 novembre 2005 18:30
>>À : Jan Kiszka
>>Cc : xenomai-core
>>Objet : Re: [Xenomai-core] [RFC] support for sharing IRQs
> 
> 	....
> 
>>Ok, let's go for those changes this way:
>>
>>1. The I-pipe series needs to be updated so that an opaque 
>>cookie is passed to the handler; since we have a change in 
>>the interface, the 1.1 series has to be started for this purpose.
>>
>>2. In order to let the people running the legacy RTAI/fusion 
>>and Xenomai 2.0.x series a reasonable amount of time to 
>>upgrade their patchset, the IRQ layer updates (sharing and 
>>trampoline suppression) will go to the Xenomai 2.1 dev 
>>branch. IOW, Xenomai 2.1 will be exclusively based on the 
>>I-pipe 1.1 series, which also means that Xenomai support for 
>>the oldgen Adeos and I-pipe 1.0 patches will be discontinued 
>>after the Xenomai 2.0.x series is closed.
> 
> 
> I agree with all that is said in this post; however there is just a smal
> problem: some very useful tool for xenomai application debug and tune is
> LTT; however the only available Adeos+LTT patch is not an ipipe one, but an
> old linux-2.6.9 kernel patch.
> 
> At least the LTT support should be available with an ipipe-based Adeos-1.1
> patch for 2.6.9 (waiting for LTT to support a more recent kernel), so that
> LTT is not lost for xenomai (as it seems to be in fact for RTAI). 
> 

LTT has been undergoing a significant refactoring recently, so there has been 
little incentive to go for a combo Adeos+LTT patch over a moving target, this is 
the reason why Alex - the LTT support maintainer for Xenomai - has focused on a 
2.6.9 kernel featuring the previous LTT architecture, and this was a good 
decision. Upgrading this combo will be done in the I-pipe 1.1 timeframe over the 
newest LTT support, for sure, basically to get rid of the oldgen Adeos patches 
for Xenomai completely.

RTAI had problem maintaining the LTT support because of the lack of a 
maintainer; we do have one. This said, the best way you could contribute to this 
is crafting a prototype combo between I-pipe 1.0 and a recent LTT core (i.e. the 
one that relies on the refactored relayfs stuff), especially if you do consider 
this support as a critical feature. I guess that Alex would be fine working on 
this base later.

> Bernard
> 
> 
>>3. Changes in the IRQ layer will be made at nucleus level, 
>>which is the most efficient way to provide them.
>>
>>It should be noted that as part of the build system 
>>refactoring, the real-time HAL has become a static portion of 
>>the Linux kernel, with its generic part being moved to the 
>>nucleus. IOW, the proposed changes will basically end up as 
>>redispatching some code inside the nucleus.
>>
>>-- 
>>
>>Philippe.
>>
>>_______________________________________________
>>Xenomai-core mailing list
>>Xenomai-core@domain.hid
>>https://mail.gna.org/listinfo/xenomai-core
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
> 


-- 

Philippe.

[Xenomai-core] LTT support on Xenomai (was part of support for sharing IRQs)

[Bernard Dautrevaux]

> -----Message d'origine-----
> De : Philippe Gerum [mailto:rpm@xenomai.org
> Envoyé : mercredi 2 novembre 2005 15:19
> À : Bernard Dautrevaux
> Cc : xenomai@xenomai.org; karim@domain.hid
> Objet : Re: [Xenomai-core] [RFC] support for sharing IRQs
> 
> Bernard Dautrevaux wrote:
> >  
> > 
> > 
> >>-----Message d'origine-----
> >>De : xenomai-core-bounces@domain.hid
> >>[mailto:xenomai-core-bounces@domain.hid] De la part de Philippe Gerum 
> >>Envoyé : mardi 1 novembre 2005 18:30 À : Jan Kiszka Cc : 
> xenomai-core 
> >>Objet : Re: [Xenomai-core] [RFC] support for sharing IRQs
> > 
> > 	....
> > 
> > At least the LTT support should be available with an 
> ipipe-based Adeos-1.1
> > patch for 2.6.9 (waiting for LTT to support a more recent 
> kernel), so that
> > LTT is not lost for xenomai (as it seems to be in fact for RTAI). 
> > 
> 
> LTT has been undergoing a significant refactoring recently, 

Do you mean there is something more recent than ltt-0.9.6-pre4 ?

If this is true where can this be found?

> so there has been 
> little incentive to go for a combo Adeos+LTT patch over a 
> moving target, this is 
> the reason why Alex - the LTT support maintainer for Xenomai 
> - has focused on a 
> 2.6.9 kernel featuring the previous LTT architecture, and 
> this was a good 
> decision. 

This restrain then to use oldgen Adeos architecture, as LTT is only
available on 2.6.9 and ipipe only from 2.6.13; is there anything preventing
having ipipe on 2.6.9 (apart from workload of course)?
 
> Upgrading this combo will be done in the I-pipe 1.1 
> timeframe over the 
> newest LTT support, for sure, basically to get rid of the 
> oldgen Adeos patches 
> for Xenomai completely.

That for sure will be nice.

> RTAI had problem maintaining the LTT support because of the lack of a 
> maintainer; we do have one. This said, the best way you could 
> contribute to this 
> is crafting a prototype combo between I-pipe 1.0 and a recent 
> LTT core (i.e. the 
> one that relies on the refactored relayfs stuff), especially 
> if you do consider 
> this support as a critical feature. I guess that Alex would 
> be fine working on 
> this base later.

This is something we may look at, but need access to this new-gen LTT,
hopefuly supporting recent Linux kernel, at least 2.6.13.

BTW the rapid evolution of 2.6 is perhaps a benefit for some people, but to
maintain kernel-dependent extensions, it seems to be more a nightmare than
anything else... 

> -- 
> 
> Philippe.
> 
>

Bernard 

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Dmitry Adamushko]

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


> >> [...]

> >>e.g.
> >>
> >>the "cookie" remains opaque for the ipipe but when requested by
> >>HAL::rthal_irq_request() or NUCLEUS::xnintr_irq_handler() it's treated
as a
> >>chain of ISR handlers.
> >>
> >
> >
> > Yep, that's also what I had in mind about potential ipipe changes and
> > their use in the nucleus.
> >
>
> Ok, let's go for those changes this way:
>
> 1. The I-pipe series needs to be updated so that an opaque cookie
ispassed to
> the handler; since we have a change in the interface, the 1.1 serieshas
to be
> started for this purpose.
>
> 2. In order to let the people running the legacy RTAI/fusion and
> Xenomai 2.0.x
> series a reasonable amount of time to upgrade their patchset, the IRQ
layer
> updates (sharing and trampoline suppression) will go to the Xenomai 2.1
dev
> branch. IOW, Xenomai 2.1 will be exclusively based on the I-pipe 1.1
series,
> which also means that Xenomai support for the oldgen Adeos and I-pipe 1.0

> patches will be discontinued after the Xenomai 2.0.x series is closed.
>
> 3. Changes in the IRQ layer will be made at nucleus level, which is the
most
> efficient way to provide them.
>

Ok, I'd take this task (err.. since I'm not doing anything useful for
Xenomai at the moment). Although, I may start not earlier than next week.
Jan, since you have come up with the initial proposol and maybe you need
get that new code working asap, it's up to you to handle it on your own :o)
Just let me know in that case.


>
> --
>
> Philippe.
>

---
Best regards,
Dmitry

[-- Attachment #2: Type: text/html, Size: 1995 bytes --]

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Jan Kiszka]

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

Dmitry Adamushko wrote:
>>>> [...]
> 
>>>> e.g.
>>>>
>>>> the "cookie" remains opaque for the ipipe but when requested by
>>>> HAL::rthal_irq_request() or NUCLEUS::xnintr_irq_handler() it's treated
> as a
>>>> chain of ISR handlers.
>>>>
>>>
>>> Yep, that's also what I had in mind about potential ipipe changes and
>>> their use in the nucleus.
>>>
>> Ok, let's go for those changes this way:
>>
>> 1. The I-pipe series needs to be updated so that an opaque cookie
> ispassed to
>> the handler; since we have a change in the interface, the 1.1 serieshas
> to be
>> started for this purpose.
>>
>> 2. In order to let the people running the legacy RTAI/fusion and
>> Xenomai 2.0.x
>> series a reasonable amount of time to upgrade their patchset, the IRQ
> layer
>> updates (sharing and trampoline suppression) will go to the Xenomai 2.1
> dev
>> branch. IOW, Xenomai 2.1 will be exclusively based on the I-pipe 1.1
> series,
>> which also means that Xenomai support for the oldgen Adeos and I-pipe 1.0
> 
>> patches will be discontinued after the Xenomai 2.0.x series is closed.
>>
>> 3. Changes in the IRQ layer will be made at nucleus level, which is the
> most
>> efficient way to provide them.
>>
> 
> Ok, I'd take this task (err.. since I'm not doing anything useful for
> Xenomai at the moment). Although, I may start not earlier than next week.
> Jan, since you have come up with the initial proposol and maybe you need
> get that new code working asap, it's up to you to handle it on your own :o)
> Just let me know in that case.
> 

Thanks for the helping hand. I will be really happy if you could realise
this.

It's also not yet burning on our side. I guess we will be busy enough to
get a few devices running, to have ALL running with potentially shared
IRQs can be scheduled later.

Hope we will be able to continue with more detailed discussions tomorrow
evening!

Jan


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

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Philippe Gerum]

Jan Kiszka wrote:
> Dmitry Adamushko wrote:
> 
>>Hi Jan,
>>
>>
>>>I have some code hanging around here which implements IRQ sharing at
>>>skin level for an experimental in-house development over Xenomai. The
>>>code is smart enough to register an IRQ sharing trampoline handler only
>>>in case sharing is actually practiced for a specific line.
>>
>>Could you be a bit more specific on what is meant by "...sharing is
>>actually practiced for a specific line"?
> 
> 
> Ok, one have to remind that my existing code is built on top of the
> non-sharing xnintr_xxx API. This means that I had to define a trampoline
> ISR which does the loop over all registered end-user ISRs. And this
> intermediate handler is only involved when A) the IRQ is sharable and B)
> there is actually more than one ISR registered for it.
> 
> This "smartness" becomes obsolete when we embed a doubly-linked list
> into xnintr_t and already iterate over it in xnintr_irq_handler().
> 
> 
>>To my knowledge, the matter is only about whether a certain device (driver)
>>permits the earlier obtained irq line to be shared with other devices.
>>i.e. a driver [1] may succeed with an irq registration request in case
>>another driver [2] already holds this line but both [1] and [2] have
>>specified a SA_SHIRQ flag.
> 
> 
> Yep.
> 
> 
>>
>>>I think it would be possible to break this out and generate a mainline
>>>patch. Anyway, the question for me is where to put this best, at skin
>>>(RTDM?) or at nucleus level? Both is technically feasible, but which way
>>>is desired? (I would vote for the nucleus...)
>>
>>If we have a policy that all the drivers should be implemented on top of
>>RTDM, then, it can be done there. If no (and I guess so), this feature
>>should be common and I'd vote for the nucleus.
> 
> 
> Drivers should be built over RTDM, that's true. But there may still be
> driver-like applications, also in user space that attach directly to the
> IRQs via the various skin APIs. I think it would be good to let them
> live side-by-side with RTDM drivers or other IRQ-using applications.
> 
> 
>>It seems to me now, that some parts of the hal will be involved
>>(rthal_irq_request/release()) since the nucleus itself doesn't keep track
>>of registered irqs.
> 
> 
> That's true. And it also raises another question to me: why do we have
> those two different IRQ models?
> 
> The HAL only one handler per IRQ which get called with the triggering
> IRQ number. That handler will call the nucleus with an attached cookie.
> And on the other side is the nucleus which works with a xnintr_t per
> IRQ. The xnintr_irq_handler() deals with things like re-enabling IRQs,
> rescheduling, etc.
> 
> I'm asking as this abstraction adds one trampoline call (at HAL level),
> thus may lead to more I-cache misses. Isn't it worth considering some
> HAL mechanisms based on more #defines and static inlines in this regard?
> 

While we are at it, we could just move the HAL's trampoline part to the 
arch/system.h support. Two things to keep in mind: Adeos does not provide 
cookies (yeah, what a pity), but passes an IRQ number the xnarch level doesn't 
grok. Some low-level prototypes would have to be fixed and the cookie array 
moved, but basically, getting rid of the initial trampoline seems like a good 
idea since it brings nothing in the picture.

> Jan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Philippe Gerum]

Dmitry Adamushko wrote:
> 
> Hi Jan,
> 
>  >
>  > I have some code hanging around here which implements IRQ sharing at
>  > skin level for an experimental in-house development over Xenomai. The
>  > code is smart enough to register an IRQ sharing trampoline handler only
>  > in case sharing is actually practiced for a specific line.
> 
> Could you be a bit more specific on what is meant by "...sharing is 
> actually practiced for a specific line"?
> 
> To my knowledge, the matter is only about whether a certain device 
> (driver) permits the earlier obtained irq line to be shared with other 
> devices.
> i.e. a driver [1] may succeed with an irq registration request in case 
> another driver [2] already holds this line but both [1] and [2] have 
> specified a SA_SHIRQ flag.
> 
> 
>  > I think it would be possible to break this out and generate a mainline
>  > patch. Anyway, the question for me is where to put this best, at skin
>  > (RTDM?) or at nucleus level? Both is technically feasible, but which way
>  > is desired? (I would vote for the nucleus...)
> 
> If we have a policy that all the drivers should be implemented on top of 
> RTDM, then, it can be done there. If no (and I guess so), this feature 
> should be common and I'd vote for the nucleus.

Actually, now that we have a decent driver model built in, I will enforce the 
rule that all Xenomai mainline drivers must be based on RTDM, because we do need 
such a common platform to prevent braindamage calling interfaces hysteria. This 
will be a good opportunity to see how flexible the thing is when confronted to 
the needs of various hw and semantics.

> It seems to me now, that some parts of the hal will be involved 
> (rthal_irq_request/release()) since the nucleus itself doesn't keep 
> track of registered irqs.
> 
> 
>  >
>  > Jan
>  >
> 
> ---
> Best regards,
> Dmitry
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core


-- 

Philippe.

Re: [Xenomai-core] [RFC] support for sharing IRQs

[Jan Kiszka]

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

Philippe Gerum wrote:
> Dmitry Adamushko wrote:
>>
>> Hi Jan,
>>
>>  >
>>  > I have some code hanging around here which implements IRQ sharing at
>>  > skin level for an experimental in-house development over Xenomai. The
>>  > code is smart enough to register an IRQ sharing trampoline handler
>> only
>>  > in case sharing is actually practiced for a specific line.
>>
>> Could you be a bit more specific on what is meant by "...sharing is
>> actually practiced for a specific line"?
>>
>> To my knowledge, the matter is only about whether a certain device
>> (driver) permits the earlier obtained irq line to be shared with other
>> devices.
>> i.e. a driver [1] may succeed with an irq registration request in case
>> another driver [2] already holds this line but both [1] and [2] have
>> specified a SA_SHIRQ flag.
>>
>>
>>  > I think it would be possible to break this out and generate a mainline
>>  > patch. Anyway, the question for me is where to put this best, at skin
>>  > (RTDM?) or at nucleus level? Both is technically feasible, but
>> which way
>>  > is desired? (I would vote for the nucleus...)
>>
>> If we have a policy that all the drivers should be implemented on top
>> of RTDM, then, it can be done there. If no (and I guess so), this
>> feature should be common and I'd vote for the nucleus.
> 
> Actually, now that we have a decent driver model built in, I will
> enforce the rule that all Xenomai mainline drivers must be based on
> RTDM, because we do need such a common platform to prevent braindamage
> calling interfaces hysteria. This will be a good opportunity to see how
> flexible the thing is when confronted to the needs of various hw and
> semantics.
> 

So far the rtdm_irq_xxx API consists of pure static inlines. If we
decide to move IRQ sharing support only into that layer, it would
materialise into real code and another trampoline. So, I still vote for
a generic support at nucleus level. :)

Jan




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