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() that
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 us
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
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 piec
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, 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()
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 A
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 interrup
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 ha
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 interrup
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.
Igno
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
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 inv
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 con
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 ca
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 mi
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 simple_ha
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
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
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 ca
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', 'lev
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 th
27 matches
Mail list logo
