On Thu, 25 Sep 2008 18:40:28 -0500 Milton Miller [EMAIL PROTECTED] wrote:
(I trimmed the cc list for the implementation discussion).
Yep, good thing.
snip
Whoops, my bad, in the non threaded case, there's no
mask at all, only an unmask+eoi at the end, maybe that's
an oversight!
On Thu, 25 Sep 2008 07:15:17 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
On Wed, 2008-09-24 at 14:35 +0200, Sebastien Dugue wrote:
Hi Ben,
On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt [EMAIL
PROTECTED] wrote:
On Wed, 2008-09-24 at 04:58 -0500, Milton
On Thu, 2008-09-25 at 09:18 +0200, Sebastien Dugue wrote:
Ok, that's the right approach then. It should work. I don't know
what
the specific problems with HEA are at this stage.
Yep, except as it behaves in way that the current -rt fasteoi flow
cannot handle.
We probably need to make
On Thu, 25 Sep 2008 07:14:07 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
There may be some implicit assumption in that we expect the cpu
priority to be returned to normal by the EOI, but there is nothing in
the hardware that requires the EOI to come from the same cpu as
On Thu, 25 Sep 2008 17:22:41 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
On Thu, 2008-09-25 at 09:18 +0200, Sebastien Dugue wrote:
Ok, that's the right approach then. It should work. I don't know
what
the specific problems with HEA are at this stage.
Yep, except as
Do you mean creating a custom fasteoi handler into xics.c? Also, it's
not clear to me from looking at the code how you go about changing the
cpu priority.
Yup. I think the priority is the CPPR.. Milton can give you more
details, if not, I'll pick it up tomorrow when at the office.
Ben.
On Thu, 25 Sep 2008 18:36:19 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
Do you mean creating a custom fasteoi handler into xics.c? Also, it's
not clear to me from looking at the code how you go about changing the
cpu priority.
Yup. I think the priority is the CPPR..
On Wed, 24 Sep 2008 11:42:15 -0500 Milton Miller [EMAIL PROTECTED] wrote:
On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote:
Hi Milton,
On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller
[EMAIL PROTECTED] wrote:
On Mon Sep 15 at 18:04:06 EST in 2008, Sebastien Dugue wrote:
When
(I trimmed the cc list for the implementation discussion).
On Wed, 24 Sep 2008 11:42:15 -0500 Milton Miller
[EMAIL PROTECTED] wrote:
On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote:
Hi Milton,
On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller
[EMAIL PROTECTED] wrote:
Jan-Bernd wrote:
Ben, can you / your team look into the implementation
of the set_irq_type functionality needed for XICS?
I'm not volunteering to look at or implement any changes for how xics
works with generic irq, but I'm trying to understand what the rt kernel
is trying to accomplish with
On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
The per-interrupt mask and unmask calls have to go through RTAS, a
single-threaded global context, which in addition to increasing
path length will really limit scalability. The interrupt controller
poll and reject facilities are
On Sep 24, 2008, at 5:17 AM, Benjamin Herrenschmidt wrote:
On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
The per-interrupt mask and unmask calls have to go through RTAS, a
single-threaded global context, which in addition to increasing
path length will really limit scalability. The
Hi Milton,
On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller [EMAIL PROTECTED]
wrote:
Jan-Bernd wrote:
Ben, can you / your team look into the implementation
of the set_irq_type functionality needed for XICS?
I'm not volunteering to look at or implement any changes for how xics
Hi Ben,
On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
The per-interrupt mask and unmask calls have to go through RTAS, a
single-threaded global context, which in addition to increasing
path
On Sep 24, 2008, at 7:30 AM, Sebastien Dugue wrote:
Hi Milton,
On Wed, 24 Sep 2008 04:58:22 -0500 (CDT) Milton Miller
[EMAIL PROTECTED] wrote:
On Mon Sep 15 at 18:04:06 EST in 2008, Sebastien Dugue wrote:
When entering the low level handler, level sensitive interrupts are
masked, then eio'd
There may be some implicit assumption in that we expect the cpu
priority to be returned to normal by the EOI, but there is nothing in
the hardware that requires the EOI to come from the same cpu as
accepted the interrupt for processing, with the exception of the IPI
which is per-cpu (and
On Wed, 2008-09-24 at 14:35 +0200, Sebastien Dugue wrote:
Hi Ben,
On Wed, 24 Sep 2008 20:17:47 +1000 Benjamin Herrenschmidt [EMAIL PROTECTED]
wrote:
On Wed, 2008-09-24 at 04:58 -0500, Milton Miller wrote:
The per-interrupt mask and unmask calls have to go through RTAS, a
On Wed, 2008-09-24 at 11:42 -0500, Milton Miller wrote:
I was trying to understand why the mask and early eoi, but I guess its
to handle other more limited interrupt controllers where the interrupts
stack in hardware instead of software.
No Milton, we must do it that way, because the EOI
On Sep 24, 2008, at 4:16 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-09-24 at 11:42 -0500, Milton Miller wrote:
I was trying to understand why the mask and early eoi, but I guess its
to handle other more limited interrupt controllers where the
interrupts
stack in hardware instead of
Hi,
I think these are the functional changes that need to be included in
the ibmebus driver. We'll add a RT flag in the final version to enable
these changes only for RT-Linux for now.
Ben, can you / your team look into the implementation
of the set_irq_type functionality needed for XICS?
On Thu, 18 Sep 2008 09:53:54 +0200 Christoph Raisch [EMAIL PROTECTED] wrote:
Sebastien Dugue [EMAIL PROTECTED] wrote on 15.09.2008 10:04:06:
[PATCH HACK] powerpc: quick hack to get a functional eHEA with
hardirq preemption
Sebastien Dugue
to:
15.09.2008 10:07
Cc:
Sebastien Dugue [EMAIL PROTECTED] wrote on 18.09.2008 11:27:13:
It would be really interresting to know if the eHCA exhibits the same
problem under -rt as it's the only other user of the ibmebus.
Unfortunately I don't have the hardware to test.
eHCA is very close from the interrupt
On Thu, 18 Sep 2008 12:42:05 +0200 Christoph Raisch [EMAIL PROTECTED] wrote:
Sebastien Dugue [EMAIL PROTECTED] wrote on 18.09.2008 11:27:13:
It would be really interresting to know if the eHCA exhibits the same
problem under -rt as it's the only other user of the ibmebus.
On Mon, Sep 15, 2008 at 03:13:32PM +0200, Sebastien Dugue wrote:
[...]
we are a bit worried about putting this into the mainstream part of non real
time linux.
Heck, I sure do not want this to be applied mainstream nor into any tree.
The sole purpose of this patch was to trigger some
Hi Anton,
On Tue, 16 Sep 2008 15:59:47 +0400 Anton Vorontsov [EMAIL PROTECTED] wrote:
On Mon, Sep 15, 2008 at 03:13:32PM +0200, Sebastien Dugue wrote:
[...]
we are a bit worried about putting this into the mainstream part of non
real
time linux.
Heck, I sure do not want
Hi,
we are a bit worried about putting this into the mainstream part of non
real time linux.
There interrupts work perfectly fine, and it was a bit of a challenge to
get there for all
cases / configurations / machines.
Could you try to enable these changes only for RT-Linux via a real-time
Hi,
we are a bit worried about putting this into the mainstream part of non real
time linux. There interrupts work perfectly fine, and it was a bit of a
challenge to get there for all cases / configurations / machines.
Could you try to enable these changes only for RT-Linux via a real-time
Hi Thomas, Jan-Bernd, Christoph,
On Mon, 15 Sep 2008 14:35:16 +0200 Thomas Klein [EMAIL PROTECTED] wrote:
Hi,
we are a bit worried about putting this into the mainstream part of non real
time linux.
Heck, I sure do not want this to be applied mainstream nor into any tree.
The sole
28 matches
Mail list logo
