Bernard Dautrevaux wrote:
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
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 i
Bernard Dautrevaux wrote:
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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
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 i
> >> [...]
> >>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
> > th
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.
> -Message d'origine-
> De : [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 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
&
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
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 lo
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
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 register
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 q
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
>> o
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 pra
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
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
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.
>>> Hopefull
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.
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
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 lo
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
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 register
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 q
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
>> o
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 pra
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
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
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.
>>> Hopefull
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
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
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:
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 f
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
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
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
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:
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 f
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
38 matches
Mail list logo
