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
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,
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
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]
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
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,
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
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.
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
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
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
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
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
13 matches
Mail list logo
