Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1183438 > unrolled thread

Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable Thomas Gleixner <tglx@linutronix.de> - 2015-07-14 10:20 +0200
    Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable Manuel Lauss <manuel.lauss@gmail.com> - 2015-07-14 11:00 +0200
      Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable Ralf Baechle <ralf@linux-mips.org> - 2015-07-14 11:10 +0200
        Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable Thomas Gleixner <tglx@linutronix.de> - 2015-07-14 12:00 +0200

#1183438 — Re: [patch 08/12] MIPS/alchemy: Remove pointless irqdisable/enable

On Tue, 14 Jul 2015, Manuel Lauss wrote:

> On Mon, Jul 13, 2015 at 10:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > bcsr_csc_handler() is a cascading interrupt handler. It has a
> > disable_irq_nosync()/enable_irq() pair around the generic_handle_irq()
> > call. The value of this disable/enable is zero because its a complete
> > noop:
> >
> > disable_irq_nosync() merily increments the disable count without
> > actually masking the interrupt. enable_irq() soleley decrements the
> > disable count without touching the interrupt chip. The interrupt
> > cannot arrive again because the complete call chain runs with
> > interrupts disabled.
> >
> > Remove it.
> 
> Is there another patch this one depends on?  The DB1300 board doesn't

No.

> boot (i.e. interrupts from the cpld aren't serviced) with this patch applied:
> (irq 136 is the first serviced by the bcsr cpld):
> 
> irq 136: nobody cared (try booting with the "irqpoll" option)

That's weird. Looking deeper, enable_irq() actually calls
chip->unmask() unconditionally. So it seems the chip is sensitive to
that.

Does the following patch on top fix things again?

Thanks,

	tglx
----
diff --git a/arch/mips/alchemy/devboards/bcsr.c b/arch/mips/alchemy/devboards/bcsr.c
index 3a24f2d6ecfd..ec47abe580c6 100644
--- a/arch/mips/alchemy/devboards/bcsr.c
+++ b/arch/mips/alchemy/devboards/bcsr.c
@@ -88,8 +88,11 @@ EXPORT_SYMBOL_GPL(bcsr_mod);
 static void bcsr_csc_handler(unsigned int irq, struct irq_desc *d)
 {
 	unsigned short bisr = __raw_readw(bcsr_virt + BCSR_REG_INTSTAT);
+	struct irq_chip *chip = irq_desc_get_chip(d);
 
+	chained_irq_enter(chip, d);
 	generic_handle_irq(bcsr_csc_base + __ffs(bisr));
+	chained_irq_exit(chip, d);
 }
 
 static void bcsr_irq_mask(struct irq_data *d)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1183474

On Tue, Jul 14, 2015 at 10:16 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Tue, 14 Jul 2015, Manuel Lauss wrote:
>
>> On Mon, Jul 13, 2015 at 10:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> > bcsr_csc_handler() is a cascading interrupt handler. It has a
>> > disable_irq_nosync()/enable_irq() pair around the generic_handle_irq()
>> > call. The value of this disable/enable is zero because its a complete
>> > noop:
>> >
>> > disable_irq_nosync() merily increments the disable count without
>> > actually masking the interrupt. enable_irq() soleley decrements the
>> > disable count without touching the interrupt chip. The interrupt
>> > cannot arrive again because the complete call chain runs with
>> > interrupts disabled.
>> >
>> > Remove it.
>>
>> Is there another patch this one depends on?  The DB1300 board doesn't
>
> No.
>
>> boot (i.e. interrupts from the cpld aren't serviced) with this patch applied:
>> (irq 136 is the first serviced by the bcsr cpld):
>>
>> irq 136: nobody cared (try booting with the "irqpoll" option)
>
> That's weird. Looking deeper, enable_irq() actually calls
> chip->unmask() unconditionally. So it seems the chip is sensitive to
> that.
>
> Does the following patch on top fix things again?
>
> Thanks,
>
>         tglx
> ----
> diff --git a/arch/mips/alchemy/devboards/bcsr.c b/arch/mips/alchemy/devboards/bcsr.c
> index 3a24f2d6ecfd..ec47abe580c6 100644
> --- a/arch/mips/alchemy/devboards/bcsr.c
> +++ b/arch/mips/alchemy/devboards/bcsr.c
> @@ -88,8 +88,11 @@ EXPORT_SYMBOL_GPL(bcsr_mod);
>  static void bcsr_csc_handler(unsigned int irq, struct irq_desc *d)
>  {
>         unsigned short bisr = __raw_readw(bcsr_virt + BCSR_REG_INTSTAT);
> +       struct irq_chip *chip = irq_desc_get_chip(d);
>
> +       chained_irq_enter(chip, d);
>         generic_handle_irq(bcsr_csc_base + __ffs(bisr));
> +       chained_irq_exit(chip, d);
>  }
>
>  static void bcsr_irq_mask(struct irq_data *d)


Yes.  Add #include <linux/irqchip/chained_irq.h> on top and it works again.
This hardware is problematic, an older variant with identical verilog
code in the cpld's
irq unit works fine without this.

Thanks,
    Manuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1183479

On Tue, Jul 14, 2015 at 10:55:08AM +0200, Manuel Lauss wrote:

> On Tue, Jul 14, 2015 at 10:16 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Tue, 14 Jul 2015, Manuel Lauss wrote:
> >
> >> On Mon, Jul 13, 2015 at 10:46 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >> > bcsr_csc_handler() is a cascading interrupt handler. It has a
> >> > disable_irq_nosync()/enable_irq() pair around the generic_handle_irq()
> >> > call. The value of this disable/enable is zero because its a complete
> >> > noop:
> >> >
> >> > disable_irq_nosync() merily increments the disable count without
> >> > actually masking the interrupt. enable_irq() soleley decrements the
> >> > disable count without touching the interrupt chip. The interrupt
> >> > cannot arrive again because the complete call chain runs with
> >> > interrupts disabled.
> >> >
> >> > Remove it.
> >>
> >> Is there another patch this one depends on?  The DB1300 board doesn't
> >
> > No.
> >
> >> boot (i.e. interrupts from the cpld aren't serviced) with this patch applied:
> >> (irq 136 is the first serviced by the bcsr cpld):
> >>
> >> irq 136: nobody cared (try booting with the "irqpoll" option)
> >
> > That's weird. Looking deeper, enable_irq() actually calls
> > chip->unmask() unconditionally. So it seems the chip is sensitive to
> > that.
> >
> > Does the following patch on top fix things again?
> >
> > Thanks,
> >
> >         tglx
> > ----
> > diff --git a/arch/mips/alchemy/devboards/bcsr.c b/arch/mips/alchemy/devboards/bcsr.c
> > index 3a24f2d6ecfd..ec47abe580c6 100644
> > --- a/arch/mips/alchemy/devboards/bcsr.c
> > +++ b/arch/mips/alchemy/devboards/bcsr.c
> > @@ -88,8 +88,11 @@ EXPORT_SYMBOL_GPL(bcsr_mod);
> >  static void bcsr_csc_handler(unsigned int irq, struct irq_desc *d)
> >  {
> >         unsigned short bisr = __raw_readw(bcsr_virt + BCSR_REG_INTSTAT);
> > +       struct irq_chip *chip = irq_desc_get_chip(d);
> >
> > +       chained_irq_enter(chip, d);
> >         generic_handle_irq(bcsr_csc_base + __ffs(bisr));
> > +       chained_irq_exit(chip, d);
> >  }
> >
> >  static void bcsr_irq_mask(struct irq_data *d)
> 
> 
> Yes.  Add #include <linux/irqchip/chained_irq.h> on top and it works again.
> This hardware is problematic, an older variant with identical verilog
> code in the cpld's
> irq unit works fine without this.

So shall I merge both patches and the header file change together or?

  Ralf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1183562

On Tue, 14 Jul 2015, Ralf Baechle wrote:
> On Tue, Jul 14, 2015 at 10:55:08AM +0200, Manuel Lauss wrote:
> > Yes.  Add #include <linux/irqchip/chained_irq.h> on top and it works again.
> > This hardware is problematic, an older variant with identical verilog
> > code in the cpld's
> > irq unit works fine without this.
> 
> So shall I merge both patches and the header file change together or?

Yes please.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web