On Thu, 29 Nov 2007, Russell King - ARM Linux wrote:
> If people insist on adding the mask/unmask crap to it, the function
> might as well be deleted and be an alias for handle_level_IRQ. Because
> that's _precisely_ what you lot are turning it into.
>
> Ah, and looking at the changes to the
On Thu, 29 Nov 2007, Russell King - ARM Linux wrote:
If people insist on adding the mask/unmask crap to it, the function
might as well be deleted and be an alias for handle_level_IRQ. Because
that's _precisely_ what you lot are turning it into.
Ah, and looking at the changes to the file,
On Thu, 29 Nov 2007, Remy Bohmer wrote:
> I changed the interrupt handler from the simple_irq to the edge_irq,
> and it works...!!
> (I added a noop routine for that .ack part, because there is no ack)
>
> I believe I was too focussed on the masking bug in the RT kernel on
> the simple_irq()
Hello All,
I tested some more with the edge_triggered interrupt handler on AT91,
and I had already a long time a problem with the AT91SAM9261-EK kit,
that the DM9000 Ethernet controller did not work _at all_ on RT. I
just tried if the edge triggered interrupt handler works on that board
also. And
Hello Russell,
> While I realise that, I'm telling you that the _problem_ is being
> caused by the wrong handler being used.
Okay, I believe you... (someone told me once, Russell is right, and if
you do not believe him, he is still right ;-)
> SA1100 and PXA have exactly the same setup. They
On Thu, Nov 29, 2007 at 03:18:04PM +0100, Remy Bohmer wrote:
> Hello Russell,
>
> > If people insist on adding the mask/unmask crap to it, the function
> > might as well be deleted and be an alias for handle_level_IRQ. Because
> > that's _precisely_ what you lot are turning it into.
>
> First,
Hello Russell,
> If people insist on adding the mask/unmask crap to it, the function
> might as well be deleted and be an alias for handle_level_IRQ. Because
> that's _precisely_ what you lot are turning it into.
First, I want to make clear that I am just debugging a problem on RT
that does not
On Thu, 29 Nov 2007, Russell King - ARM Linux wrote:
> On Thu, Nov 29, 2007 at 12:27:30PM +0100, Remy Bohmer wrote:
>
> Ah, and looking at the changes to the file, the addition of the mask
> and unmask was done by someone who didn't understand what this was
> trying to do. So that change should
On Thu, Nov 29, 2007 at 12:27:30PM +0100, Remy Bohmer wrote:
> Hello Russell,
>
> > If 'no' then it's the right handler and the mask/unmask methods associated
> > with the interrupt will be no-ops.
>
> I completely understand what you keep on saying, but that would imply
> that the following
Hello Russell,
> If 'no' then it's the right handler and the mask/unmask methods associated
> with the interrupt will be no-ops.
I completely understand what you keep on saying, but that would imply
that the following piece of code in chip.c is completely bogus anyway!
(snip from mainline
On Thu, Nov 29, 2007 at 11:14:30AM +0100, Remy Bohmer wrote:
> I do not think Russell is right here with assuming that the wrong
> interrupt handler type is used. Looking at the behaviour of the
> mainline kernel (non-RT), the implementation is quite different: On
> mainline the
Hello Steven,
> Remy, sorry about this round-a-bout. But I don't have any of the hardware
> that this affects, and I'm just being cautious.
No problem, I expected this discussion when I submitted the patch. It
is logical that everybody is cautious on this subject. But still,
there is a bug here.
On Wed, Nov 28, 2007 at 03:19:14PM -0800, Daniel Walker wrote:
> On Wed, 2007-11-28 at 23:03 +, Russell King - ARM Linux wrote:
> > On Wed, Nov 28, 2007 at 04:13:07PM -0500, Steven Rostedt wrote:
> > >
> > >
> > > On Wed, 28 Nov 2007, Daniel Walker wrote:
> > >
> > > >
> > > > Ignoring the
On Wed, Nov 28, 2007 at 03:19:14PM -0800, Daniel Walker wrote:
On Wed, 2007-11-28 at 23:03 +, Russell King - ARM Linux wrote:
On Wed, Nov 28, 2007 at 04:13:07PM -0500, Steven Rostedt wrote:
On Wed, 28 Nov 2007, Daniel Walker wrote:
Ignoring the ARM side of things for
On Thu, Nov 29, 2007 at 11:14:30AM +0100, Remy Bohmer wrote:
I do not think Russell is right here with assuming that the wrong
interrupt handler type is used. Looking at the behaviour of the
mainline kernel (non-RT), the implementation is quite different: On
mainline the handle_simple_irq() in
Hello Steven,
Remy, sorry about this round-a-bout. But I don't have any of the hardware
that this affects, and I'm just being cautious.
No problem, I expected this discussion when I submitted the patch. It
is logical that everybody is cautious on this subject. But still,
there is a bug here.
Hello Russell,
If 'no' then it's the right handler and the mask/unmask methods associated
with the interrupt will be no-ops.
I completely understand what you keep on saying, but that would imply
that the following piece of code in chip.c is completely bogus anyway!
(snip from mainline 2.6.23)
On Thu, 29 Nov 2007, Russell King - ARM Linux wrote:
On Thu, Nov 29, 2007 at 12:27:30PM +0100, Remy Bohmer wrote:
Ah, and looking at the changes to the file, the addition of the mask
and unmask was done by someone who didn't understand what this was
trying to do. So that change should be
On Thu, Nov 29, 2007 at 12:27:30PM +0100, Remy Bohmer wrote:
Hello Russell,
If 'no' then it's the right handler and the mask/unmask methods associated
with the interrupt will be no-ops.
I completely understand what you keep on saying, but that would imply
that the following piece of
Hello Russell,
If people insist on adding the mask/unmask crap to it, the function
might as well be deleted and be an alias for handle_level_IRQ. Because
that's _precisely_ what you lot are turning it into.
First, I want to make clear that I am just debugging a problem on RT
that does not
On Thu, Nov 29, 2007 at 03:18:04PM +0100, Remy Bohmer wrote:
Hello Russell,
If people insist on adding the mask/unmask crap to it, the function
might as well be deleted and be an alias for handle_level_IRQ. Because
that's _precisely_ what you lot are turning it into.
First, I want to
Hello Russell,
While I realise that, I'm telling you that the _problem_ is being
caused by the wrong handler being used.
Okay, I believe you... (someone told me once, Russell is right, and if
you do not believe him, he is still right ;-)
SA1100 and PXA have exactly the same setup. They use
Hello All,
I tested some more with the edge_triggered interrupt handler on AT91,
and I had already a long time a problem with the AT91SAM9261-EK kit,
that the DM9000 Ethernet controller did not work _at all_ on RT. I
just tried if the edge triggered interrupt handler works on that board
also. And
On Thu, 29 Nov 2007, Remy Bohmer wrote:
I changed the interrupt handler from the simple_irq to the edge_irq,
and it works...!!
(I added a noop routine for that .ack part, because there is no ack)
I believe I was too focussed on the masking bug in the RT kernel on
the simple_irq() that I
On Wed, 2007-11-28 at 23:03 +, Russell King - ARM Linux wrote:
> On Wed, Nov 28, 2007 at 04:13:07PM -0500, Steven Rostedt wrote:
> >
> >
> > On Wed, 28 Nov 2007, Daniel Walker wrote:
> >
> > >
> > > Ignoring the ARM side of things for a sec, handle_simple_irq() will
> > > mask() the
On Wed, Nov 28, 2007 at 04:13:07PM -0500, Steven Rostedt wrote:
>
>
> On Wed, 28 Nov 2007, Daniel Walker wrote:
>
> >
> > Ignoring the ARM side of things for a sec, handle_simple_irq() will
> > mask() the interrupt in the special case that an interrupt is already in
> > the processes of being
On Wed, 28 Nov 2007, Daniel Walker wrote:
>
> Ignoring the ARM side of things for a sec, handle_simple_irq() will
> mask() the interrupt in the special case that an interrupt is already in
> the processes of being handled.. handle_simple_irq() also unmasks when
> it finishes handling an
On Wed, 2007-11-28 at 15:16 -0500, Steven Rostedt wrote:
>
> This could also simply be unique to the interrupt threads (only in RT). So
> perhaps the patch is OK.
>
> Remy, sorry about this round-a-bout. But I don't have any of the hardware
> that this affects, and I'm just being cautious.
On Wed, 28 Nov 2007, Russell King - ARM Linux wrote:
> On Wed, Nov 28, 2007 at 02:04:41PM -0500, Steven Rostedt wrote:
> > Thanks for the reply and this nice explanation.
> >
> > I'm taking this as a NACK.
> >
> > Daniel or Remy, could you find the offending users and make send patches
> > to
On Wed, Nov 28, 2007 at 02:04:41PM -0500, Steven Rostedt wrote:
> Thanks for the reply and this nice explanation.
>
> I'm taking this as a NACK.
>
> Daniel or Remy, could you find the offending users and make send patches
> to fix them.
Note that I'm not acking nor nacking the patch; I'm not
On Wed, 28 Nov 2007, Russell King - ARM Linux wrote:
> On Wed, Nov 28, 2007 at 03:38:11PM +0100, Remy Bohmer wrote:
> > Hello Daniel,
> >
> > > * Note: The caller is expected to handle the ack, clear, mask and
> > > * unmask issues if necessary.
> > > So we shouldn't need any flow
On Wed, Nov 28, 2007 at 03:38:11PM +0100, Remy Bohmer wrote:
> Hello Daniel,
>
> > * Note: The caller is expected to handle the ack, clear, mask and
> > * unmask issues if necessary.
> > So we shouldn't need any flow control unless there is some other
> > factors..
>
> This comment
On Wed, 2007-11-28 at 15:38 +0100, Remy Bohmer wrote:
> Hello Daniel,
>
> > * Note: The caller is expected to handle the ack, clear, mask and
> > * unmask issues if necessary.
> > So we shouldn't need any flow control unless there is some other
> > factors..
>
> This comment can be
Hello Kevin,
Just copied your mail to the list, maybe your solution is also worth looking at.
Remy
> I had a similar issue when using the chained GPIO interrupts on OMAP
> under PREEMPT_RT.
>
> I believe the chained handler itself is supposed to be doing the
> ack/unmask instead of the
Hello Daniel,
> * Note: The caller is expected to handle the ack, clear, mask and
> * unmask issues if necessary.
> So we shouldn't need any flow control unless there is some other
> factors..
This comment can be misinterpreted, I think. Who is assumed to be the
caller in this
Hello Daniel,
* Note: The caller is expected to handle the ack, clear, mask and
* unmask issues if necessary.
So we shouldn't need any flow control unless there is some other
factors..
This comment can be misinterpreted, I think. Who is assumed to be the
caller in this context?
Hello Kevin,
Just copied your mail to the list, maybe your solution is also worth looking at.
Remy
I had a similar issue when using the chained GPIO interrupts on OMAP
under PREEMPT_RT.
I believe the chained handler itself is supposed to be doing the
ack/unmask instead of the
On Wed, 2007-11-28 at 15:38 +0100, Remy Bohmer wrote:
Hello Daniel,
* Note: The caller is expected to handle the ack, clear, mask and
* unmask issues if necessary.
So we shouldn't need any flow control unless there is some other
factors..
This comment can be
On Wed, Nov 28, 2007 at 03:38:11PM +0100, Remy Bohmer wrote:
Hello Daniel,
* Note: The caller is expected to handle the ack, clear, mask and
* unmask issues if necessary.
So we shouldn't need any flow control unless there is some other
factors..
This comment can be
On Wed, 28 Nov 2007, Russell King - ARM Linux wrote:
On Wed, Nov 28, 2007 at 03:38:11PM +0100, Remy Bohmer wrote:
Hello Daniel,
* Note: The caller is expected to handle the ack, clear, mask and
* unmask issues if necessary.
So we shouldn't need any flow control unless
On Wed, 28 Nov 2007, Russell King - ARM Linux wrote:
On Wed, Nov 28, 2007 at 02:04:41PM -0500, Steven Rostedt wrote:
Thanks for the reply and this nice explanation.
I'm taking this as a NACK.
Daniel or Remy, could you find the offending users and make send patches
to fix them.
On Wed, Nov 28, 2007 at 02:04:41PM -0500, Steven Rostedt wrote:
Thanks for the reply and this nice explanation.
I'm taking this as a NACK.
Daniel or Remy, could you find the offending users and make send patches
to fix them.
Note that I'm not acking nor nacking the patch; I'm not involved
On Wed, 2007-11-28 at 15:16 -0500, Steven Rostedt wrote:
This could also simply be unique to the interrupt threads (only in RT). So
perhaps the patch is OK.
Remy, sorry about this round-a-bout. But I don't have any of the hardware
that this affects, and I'm just being cautious.
Ignoring
On Wed, 28 Nov 2007, Daniel Walker wrote:
Ignoring the ARM side of things for a sec, handle_simple_irq() will
mask() the interrupt in the special case that an interrupt is already in
the processes of being handled.. handle_simple_irq() also unmasks when
it finishes handling an interrupt
On Wed, Nov 28, 2007 at 04:13:07PM -0500, Steven Rostedt wrote:
On Wed, 28 Nov 2007, Daniel Walker wrote:
Ignoring the ARM side of things for a sec, handle_simple_irq() will
mask() the interrupt in the special case that an interrupt is already in
the processes of being handled..
On Wed, 2007-11-28 at 23:03 +, Russell King - ARM Linux wrote:
On Wed, Nov 28, 2007 at 04:13:07PM -0500, Steven Rostedt wrote:
On Wed, 28 Nov 2007, Daniel Walker wrote:
Ignoring the ARM side of things for a sec, handle_simple_irq() will
mask() the interrupt in the special
On Tue, 2007-11-27 at 07:25 -0800, Daniel Walker wrote:
> On Tue, 2007-11-27 at 10:11 -0500, Steven Rostedt wrote:
> > Thomas,
> >
> > Can you ACK or NACK this patch. I know you play with a bunch of
> > hardware that this patch may affect.
> >
>
> My two cents, I think it's needed (or
On Tue, 2007-11-27 at 10:11 -0500, Steven Rostedt wrote:
> Thomas,
>
> Can you ACK or NACK this patch. I know you play with a bunch of
> hardware that this patch may affect.
>
My two cents, I think it's needed (or something like it).. It looks like
handle_simple_irq normally expects a custom
Thomas,
Can you ACK or NACK this patch. I know you play with a bunch of
hardware that this patch may affect.
Thanks,
-- Steve
On Mon, 2007-11-26 at 14:45 +0100, Remy Bohmer wrote:
> Attached the same patch, but it also cleans the manage.c code a bit,
> because the IRQ types 'simple IRQ',
Thomas,
Can you ACK or NACK this patch. I know you play with a bunch of
hardware that this patch may affect.
Thanks,
-- Steve
On Mon, 2007-11-26 at 14:45 +0100, Remy Bohmer wrote:
Attached the same patch, but it also cleans the manage.c code a bit,
because the IRQ types 'simple IRQ',
On Tue, 2007-11-27 at 10:11 -0500, Steven Rostedt wrote:
Thomas,
Can you ACK or NACK this patch. I know you play with a bunch of
hardware that this patch may affect.
My two cents, I think it's needed (or something like it).. It looks like
handle_simple_irq normally expects a custom
On Tue, 2007-11-27 at 07:25 -0800, Daniel Walker wrote:
On Tue, 2007-11-27 at 10:11 -0500, Steven Rostedt wrote:
Thomas,
Can you ACK or NACK this patch. I know you play with a bunch of
hardware that this patch may affect.
My two cents, I think it's needed (or something like it)..
Attached the same patch, but it also cleans the manage.c code a bit,
because the IRQ types 'simple IRQ', 'level-IRQ' and 'FastEOI' were
handled differently while they should be handled the same.
Kind Regards,
Remy
2007/11/26, Remy Bohmer <[EMAIL PROTECTED]>:
> Hello,
>
> I use 2.6.23.1-rt5 on
Hello,
I use 2.6.23.1-rt5 on the Atmel AT91 series.
Interrupt threading on Preempt-RT and ARM works fine, except for
(edge-triggered) GPIO interrupts. There is a problem when a new
interrupt arives while the interrupt thread is handling the previous
interrupt. If this occurs the interrupt
Hello,
I use 2.6.23.1-rt5 on the Atmel AT91 series.
Interrupt threading on Preempt-RT and ARM works fine, except for
(edge-triggered) GPIO interrupts. There is a problem when a new
interrupt arives while the interrupt thread is handling the previous
interrupt. If this occurs the interrupt
Attached the same patch, but it also cleans the manage.c code a bit,
because the IRQ types 'simple IRQ', 'level-IRQ' and 'FastEOI' were
handled differently while they should be handled the same.
Kind Regards,
Remy
2007/11/26, Remy Bohmer [EMAIL PROTECTED]:
Hello,
I use 2.6.23.1-rt5 on the
56 matches
Mail list logo
