Re: Preempt Real-time for ARM

2005-02-10 Thread Eugeny S. Mints
Russell King wrote: On Wed, Feb 09, 2005 at 09:41:10AM -0800, Daniel Walker wrote: All I want to do is integrate the common IRQ threading code. To do that I need things , from Russell, like per descriptor locks .. And I need things , from Ingo, like pulling out the IRQ threading code..

Re: Preempt Real-time for ARM

2005-02-10 Thread Eugeny S. Mints
Russell King wrote: On Wed, Feb 09, 2005 at 09:41:10AM -0800, Daniel Walker wrote: All I want to do is integrate the common IRQ threading code. To do that I need things , from Russell, like per descriptor locks .. And I need things , from Ingo, like pulling out the IRQ threading code..

Re: Preempt Real-time for ARM

2005-02-09 Thread Russell King
On Wed, Feb 09, 2005 at 09:41:10AM -0800, Daniel Walker wrote: > All I want to do is integrate the common IRQ threading code. To do that > I need things , from Russell, like per descriptor locks .. And I need > things , from Ingo, like pulling out the IRQ threading code.. I've said why

Re: Preempt Real-time for ARM

2005-02-09 Thread Daniel Walker
On Wed, 2005-02-09 at 04:50, Russell King wrote: > What you'll find is that the ARM interrupt structure is designed to > efficiently meet the requirements of our wide range of hardware interrupt > controllers, with chained interrupt controllers, with as low latency as > possible. > > In

Re: Preempt Real-time for ARM

2005-02-09 Thread Thomas Gleixner
Russell, On Wed, 2005-02-09 at 12:50 +, Russell King wrote: > > > We have done the conversion to the generic irq handling and it works > > > fine on a couple of machines. > > > > great - this would be a much preferred approach indeed. > > Well, I remain unconvinced about the generic irq

Re: Preempt Real-time for ARM

2005-02-09 Thread Russell King
On Wed, Feb 09, 2005 at 12:31:40PM +0100, Ingo Molnar wrote: > > * Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > > On Sat, 2005-02-05 at 10:36 -0800, Daniel Walker wrote: > > > > > The biggest point of discussion relates to the interrupts in threads > > > implementation. It is largely

Re: Preempt Real-time for ARM

2005-02-09 Thread Thomas Gleixner
On Wed, 2005-02-09 at 12:31 +0100, Ingo Molnar wrote: > > I'm just waiting until the new SMP bits are there before I have > > another go and clean up the missing SMP bits. > > any chances for (most of) these bits going upstream as well? In any > case, the -RT tree can be a testbed for this. I

Re: Preempt Real-time for ARM

2005-02-09 Thread Ingo Molnar
* Thomas Gleixner <[EMAIL PROTECTED]> wrote: > On Sat, 2005-02-05 at 10:36 -0800, Daniel Walker wrote: > > > The biggest point of discussion relates to the interrupts in threads > > implementation. It is largely identical to what is implemented in the > > generic irq handling. However, ARM

Re: Preempt Real-time for ARM

2005-02-09 Thread Thomas Gleixner
On Sat, 2005-02-05 at 10:36 -0800, Daniel Walker wrote: > The biggest point of discussion relates to the interrupts in threads > implementation. It is largely identical to what is implemented in the > generic irq handling. However, ARM doesn't not implement generic irq > handling, and will not

Re: Preempt Real-time for ARM

2005-02-09 Thread Thomas Gleixner
On Sat, 2005-02-05 at 10:36 -0800, Daniel Walker wrote: The biggest point of discussion relates to the interrupts in threads implementation. It is largely identical to what is implemented in the generic irq handling. However, ARM doesn't not implement generic irq handling, and will not

Re: Preempt Real-time for ARM

2005-02-09 Thread Ingo Molnar
* Thomas Gleixner [EMAIL PROTECTED] wrote: On Sat, 2005-02-05 at 10:36 -0800, Daniel Walker wrote: The biggest point of discussion relates to the interrupts in threads implementation. It is largely identical to what is implemented in the generic irq handling. However, ARM doesn't not

Re: Preempt Real-time for ARM

2005-02-09 Thread Thomas Gleixner
On Wed, 2005-02-09 at 12:31 +0100, Ingo Molnar wrote: I'm just waiting until the new SMP bits are there before I have another go and clean up the missing SMP bits. any chances for (most of) these bits going upstream as well? In any case, the -RT tree can be a testbed for this. I guess

Re: Preempt Real-time for ARM

2005-02-09 Thread Russell King
On Wed, Feb 09, 2005 at 12:31:40PM +0100, Ingo Molnar wrote: * Thomas Gleixner [EMAIL PROTECTED] wrote: On Sat, 2005-02-05 at 10:36 -0800, Daniel Walker wrote: The biggest point of discussion relates to the interrupts in threads implementation. It is largely identical to what is

Re: Preempt Real-time for ARM

2005-02-09 Thread Thomas Gleixner
Russell, On Wed, 2005-02-09 at 12:50 +, Russell King wrote: We have done the conversion to the generic irq handling and it works fine on a couple of machines. great - this would be a much preferred approach indeed. Well, I remain unconvinced about the generic irq handling.

Re: Preempt Real-time for ARM

2005-02-09 Thread Daniel Walker
On Wed, 2005-02-09 at 04:50, Russell King wrote: What you'll find is that the ARM interrupt structure is designed to efficiently meet the requirements of our wide range of hardware interrupt controllers, with chained interrupt controllers, with as low latency as possible. In essence, I'm

Re: Preempt Real-time for ARM

2005-02-09 Thread Russell King
On Wed, Feb 09, 2005 at 09:41:10AM -0800, Daniel Walker wrote: All I want to do is integrate the common IRQ threading code. To do that I need things , from Russell, like per descriptor locks .. And I need things , from Ingo, like pulling out the IRQ threading code.. I've said why per-IRQ

Preempt Real-time for ARM

2005-02-05 Thread Daniel Walker
This is a release of Preempt Real-time for ARM . It includes everything up to CONFIG_PREEMPT_RT , and all of the latency tracing except interrupts off timing. The timing also excludes syscalls. This patch includes only a port to OMAP boards. However, it should be straight forward to get it working

Preempt Real-time for ARM

2005-02-05 Thread Daniel Walker
This is a release of Preempt Real-time for ARM . It includes everything up to CONFIG_PREEMPT_RT , and all of the latency tracing except interrupts off timing. The timing also excludes syscalls. This patch includes only a port to OMAP boards. However, it should be straight forward to get it working