[01/16,v2] pmac_zilog: fix unexpected irq

On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be 
masked. This can be a problem when pmac_zilog starts up.

For example, the serial debugging code in arch/m68k/kernel/head.S may be 
used beforehand. It disables the SCC interrupts at the chip but doesn't 
ack them. Then when a pmac_zilog port is opened and SCC chip interrupts 
become enabled, the machine locks up with "unexpected interrupt" because 
request_irq() hasn't happened yet.

Fix this by setting the interrupt enable bits only after the handler is 
installed and before it is uninstalled. Also move this bit flipping into a 
separate pmz_interrupt_control() routine. Replace all instances of these 
operations with calls to this routine.

Signed-off-by: Finn Thain <fthain@telegraphics.com.au>

---

Re-implemented since v1 using a simpler approach that avoids messing with 
the Master Interrupt Enable bit. As well as the ifdef problem, it turns 
out that v1 was not sufficient to entirely fix the problem.

This patch has been tested on a PowerBook 520 but no PowerMacs yet.

Hi Finn,

On Tue, Dec 6, 2011 at 16:13, Finn Thain <fthain@telegraphics.com.au> wrote:
> +static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable)
> +{
> +       if (enable) {
> +               uap->curregs[1] |= INT_ALL_Rx | TxINT_ENAB;
> +               if (!ZS_IS_EXTCLK(uap))
> +                       uap->curregs[1] |= EXT_INT_ENAB;
> +       } else {
> +               uap->curregs[1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);

Should there be a call to zssync() here?
The old code always did that after disabling interrupts.

> +       }
> +       write_zsreg(uap, R1, uap->curregs[1]);
> +}
> +
>  static struct tty_struct *pmz_receive_chars(struct uart_pmac_port *uap)
>  {
>        struct tty_struct *tty = NULL;
> @@ -339,9 +351,7 @@ static struct tty_struct *pmz_receive_ch
>
>        return tty;
>  flood:
> -       uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
> -       write_zsreg(uap, R1, uap->curregs[R1]);
> -       zssync(uap);

Cfr. e.g. here.

> +       pmz_interrupt_control(uap, 0);
>        pmz_error("pmz: rx irq flood !\n");
>        return tty;
>  }

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

On Wed, 7 Dec 2011 02:13:41 +1100 (EST)
Finn Thain <fthain@telegraphics.com.au> wrote:

> 
> On most 68k Macs the SCC IRQ is an autovector interrupt and cannot be 
> masked. This can be a problem when pmac_zilog starts up.
> 
> For example, the serial debugging code in arch/m68k/kernel/head.S may be 
> used beforehand. It disables the SCC interrupts at the chip but doesn't 
> ack them. Then when a pmac_zilog port is opened and SCC chip interrupts 
> become enabled, the machine locks up with "unexpected interrupt" because 
> request_irq() hasn't happened yet.
> 
> Fix this by setting the interrupt enable bits only after the handler is 
> installed and before it is uninstalled. Also move this bit flipping into a 
> separate pmz_interrupt_control() routine. Replace all instances of these 
> operations with calls to this routine.
> 
> Signed-off-by: Finn Thain <fthain@telegraphics.com.au>

Nice

Acked-by: Alan Cox <alan@linux.intel.com>

On Tue, 6 Dec 2011, Geert Uytterhoeven wrote:

> Hi Finn,
> 
> On Tue, Dec 6, 2011 at 16:13, Finn Thain <fthain@telegraphics.com.au> wrote:
> > +static void pmz_interrupt_control(struct uart_pmac_port *uap, int enable)
> > +{
> > +       if (enable) {
> > +               uap->curregs[1] |= INT_ALL_Rx | TxINT_ENAB;
> > +               if (!ZS_IS_EXTCLK(uap))
> > +                       uap->curregs[1] |= EXT_INT_ENAB;
> > +       } else {
> > +               uap->curregs[1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
> 
> Should there be a call to zssync() here?

I don't think so. Though I should have mentioned the change in the patch 
header.

> The old code always did that after disabling interrupts.

pmz_load_zsregs(), pmz_set_termios() and pmz_suspend() don't do it.

sunzilog only does it on sparc64 and only when writing to the data 
register or writing command modifiers to the control register ("On 64-bit 
sparc we only need to flush single writes to ensure completion.")

I can't find any purpose for control register reads in the chip manual.

The zssync() calls following some WR1 writes originate here: 
http://git.kernel.org/?p=linux/kernel/git/tglx/history.git;a=commitdiff;h=9e9d9f693c7def3900725c04c6b64311655eea51

So I don't see any need for control register reads but hopefully Ben can 
say for sure.

Reading the patch now I notice that I dropped a pmz_maybe_update_regs() or 
pmz_load_zsregs() in the suspend path. I will send a new patch.

Finn

> 
> > +       }
> > +       write_zsreg(uap, R1, uap->curregs[1]);
> > +}
> > +
> >  static struct tty_struct *pmz_receive_chars(struct uart_pmac_port *uap)
> >  {
> >        struct tty_struct *tty = NULL;
> > @@ -339,9 +351,7 @@ static struct tty_struct *pmz_receive_ch
> >
> >        return tty;
> >  flood:
> > -       uap->curregs[R1] &= ~(EXT_INT_ENAB | TxINT_ENAB | RxINT_MASK);
> > -       write_zsreg(uap, R1, uap->curregs[R1]);
> > -       zssync(uap);
> 
> Cfr. e.g. here.
> 
> > +       pmz_interrupt_control(uap, 0);
> >        pmz_error("pmz: rx irq flood !\n");
> >        return tty;
> >  }
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds
>