m68k: Convert to genirq (WIP)

m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

	Hi all,

Now sparc32 has beaten me, I pushed out my work in progress of converting m68k
to use the generic hardirq framework:

git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git m68k-genirq
http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-genirq

It contains the following commits:

  [1] ide-{cd,floppy,tape}, keyboard: Do not include <linux/irq.>
  [2] m68k/irq: Rename irq_controller to irq_chip
  [3] m68k/irq: Kill irq_node_t typedef, always use struct irq_node
  [4] m68k/irq: Rename irq_node to irq_data
  [5] m68k/irq: Switch irq_chip methods to "struct irq_data *data"
  [6] m68k/irq: Rename setup_irq() to m68k_setup_irq() and make it static
  [7] m68k/irq: Extract irq_set_chip()
  [8] m68k/irq: Add genirq support
  [9] m68k/atari: Convert Atari to genirq

  [1] is a temporary(?) fix to avoid redefinitions during the remainder of
      the series,
  [2-7] refactor the current m68k irq framework to match the generic hardirq
        framework more closely w.r.t. to its (platform) users,
  [8] adds generic hardirq support to the core, which can be enabled through
      a config option, so both legacy and generic hardirq can coexist at the
      source level during the migration,
  [9] converts Atari to use generic hardirqs.

It's working on ARAnyM[*], which means user (non-autovectored) interrupts are
working.

Next on my list is Amiga, which will cover autovectored and chained interrupts.

Hopefully I'll have enough confidence after that to blindly convert the other
platforms I cannot test myself ;-)
Of course any help is welcome, especially for Mac (with its maze of interrupt
controllers) and Q40 (with its weird ISA interrupt mapping). The remainder of
the platforms seems to be fairly standard and simple.

Thanks!

P.S. The branch m68k-genirq may be rebased in the future.

[*] There are 2 warnings during boot though:

| NR_IRQS:72
| ------------[ cut here ]------------
| WARNING: at linux/kernel/irq/chip.c:559 0x2a191a()
| Modules linked in:
| Call Trace: [<0002767e>] warn_slowpath_common+0x4c/0x64
|  [<0004e81c>] irq_set_chip+0x0/0x66
|  [<000276aa>] warn_slowpath_null+0x14/0x1a
|  [<0004e728>] __irq_set_handler+0x11c/0x13c
|  [<0004ec7e>] handle_level_irq+0x0/0x9c
|  [<00003ef4>] m68k_setup_irq_controller+0x3c/0x50
|  [<0004ec7e>] handle_level_irq+0x0/0x9c
|  [<0004e81c>] irq_set_chip+0x0/0x66
|  [<00027dc8>] printk+0x0/0x1a
|  [<00322022>] __alloc_bootmem+0x0/0x1a
|  [<0031dea4>] atari_init_IRQ+0x2a/0xe8
|  [<0004ec7e>] handle_level_irq+0x0/0x9c
|  [<0031c450>] init_IRQ+0x28/0x2e
|  [<00027dc8>] printk+0x0/0x1a
|  [<0031a012>] start_kernel+0x196/0x3b0
|  [<0031931e>] _sinittext+0x31e/0x9c0
| 
| ---[ end trace 139ce121c98e96c9 ]---

and:

| ------------[ cut here ]------------
| WARNING: at linux/kernel/irq/handle.c:130 handle_irq_event_percpu+0xe6/0x148()
| irq 3 handler nfeth_interrupt+0x0/0x126 enabled interrupts
| Modules linked in:
| Call Trace: [<00027670>] warn_slowpath_common+0x3e/0x64
|  [<0002767e>] warn_slowpath_common+0x4c/0x64
|  [<0002770c>] warn_slowpath_fmt+0x2a/0x32
|  [<0004d01a>] handle_irq_event_percpu+0xe6/0x148
|  [<0004d01a>] handle_irq_event_percpu+0xe6/0x148
|  [<00009d64>] nfeth_interrupt+0x0/0x126
|  [<00027dc8>] printk+0x0/0x1a
|  [<0004d09c>] handle_irq_event+0x20/0x2c
|  [<0004ecce>] handle_level_irq+0x50/0x9c
|  [<002496b8>] schedule+0x0/0x31e
|  [<00006782>] do_IRQ+0x2e/0x44
|  [<00027dc8>] printk+0x0/0x1a
|  [<00003eb4>] __m68k_handle_int+0xe/0x12
|  [<000026e2>] auto_irqhandler_fixup+0x4/0x6
|  [<00027dc8>] printk+0x0/0x1a
|  [<00002c46>] default_idle+0x0/0xe
|  [<00002b0c>] cpu_idle+0x16/0x22
|  [<00002b18>] kernel_thread+0x0/0x4e
|  [<00248610>] rest_init+0x5c/0x62
|  [<0031a220>] start_kernel+0x3a4/0x3b0
|  [<000106aa>] ssincos+0x27e/0x2ac
|  [<000106aa>] ssincos+0x27e/0x2ac
|  [<0031931e>] _sinittext+0x31e/0x9c0
| 
| ---[ end trace 139ce121c98e96cb ]---

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

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> | NR_IRQS:72
> | ------------[ cut here ]------------
> | WARNING: at linux/kernel/irq/chip.c:559 0x2a191a()
> | Modules linked in:
> | Call Trace: [<0002767e>] warn_slowpath_common+0x4c/0x64
> |  [<0004e81c>] irq_set_chip+0x0/0x66
> |  [<000276aa>] warn_slowpath_null+0x14/0x1a
> |  [<0004e728>] __irq_set_handler+0x11c/0x13c
> |  [<0004ec7e>] handle_level_irq+0x0/0x9c
> |  [<00003ef4>] m68k_setup_irq_controller+0x3c/0x50
> |  [<0004ec7e>] handle_level_irq+0x0/0x9c
> |  [<0004e81c>] irq_set_chip+0x0/0x66
> |  [<00027dc8>] printk+0x0/0x1a
> |  [<00322022>] __alloc_bootmem+0x0/0x1a
> |  [<0031dea4>] atari_init_IRQ+0x2a/0xe8
> |  [<0004ec7e>] handle_level_irq+0x0/0x9c
> |  [<0031c450>] init_IRQ+0x28/0x2e
> |  [<00027dc8>] printk+0x0/0x1a
> |  [<0031a012>] start_kernel+0x196/0x3b0
> |  [<0031931e>] _sinittext+0x31e/0x9c0
> |
> | ---[ end trace 139ce121c98e96c9 ]---

whitespace-challenged diff --git a/arch/m68k/kernel/ints.c
b/arch/m68k/kernel/ints.c
index f4804f3..8d8a1e9 100644
--- a/arch/m68k/kernel/ints.c
+++ b/arch/m68k/kernel/ints.c
@@ -285,7 +285,7 @@ void m68k_setup_irq_controller(struct irq_chip *chip,
        for (i = 0; i < cnt; i++) {
                irq_set_chip(irq + i, chip);
                if (handle)
-                       irq_set_handler(i, handle);
+                       irq_set_handler(irq + i, handle);
        }
 }

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

Re: m68k: Convert to genirq (WIP)

[Thomas Gleixner]

Geert,

On Sat, 28 May 2011, Geert Uytterhoeven wrote:

> 	Hi all,
> 
> Now sparc32 has beaten me, I pushed out my work in progress of converting m68k
> to use the generic hardirq framework:

That leaves only s390 in the rain, but I don't expect that they
replace their magic interrupt opcode ever :)

> git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git m68k-genirq
> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-genirq
> 
> It contains the following commits:
> 
>   [1] ide-{cd,floppy,tape}, keyboard: Do not include <linux/irq.>
>   [2] m68k/irq: Rename irq_controller to irq_chip
>   [3] m68k/irq: Kill irq_node_t typedef, always use struct irq_node
>   [4] m68k/irq: Rename irq_node to irq_data
>   [5] m68k/irq: Switch irq_chip methods to "struct irq_data *data"
>   [6] m68k/irq: Rename setup_irq() to m68k_setup_irq() and make it static
>   [7] m68k/irq: Extract irq_set_chip()
>   [8] m68k/irq: Add genirq support
>   [9] m68k/atari: Convert Atari to genirq
> 
>   [1] is a temporary(?) fix to avoid redefinitions during the remainder of
>       the series,
>   [2-7] refactor the current m68k irq framework to match the generic hardirq
>         framework more closely w.r.t. to its (platform) users,
>   [8] adds generic hardirq support to the core, which can be enabled through
>       a config option, so both legacy and generic hardirq can coexist at the
>       source level during the migration,
>   [9] converts Atari to use generic hardirqs.

Very sensible approach! Patches are looking good so far! Feel free to
add Acked-by-me!

Thanks,

	tglx

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

Hi Thomas,

On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Next on my list is Amiga, which will cover autovectored and chained interrupts.

Plain chained interrupts should be handled by calling irq_set_chained_handler()
to register an irq_flow_handler_t, and let the handler call
generic_handle_irq() for
each successive interrupt, right?

However, on Amiga we have interrupts (IRQ_AMIGA_PORTS and
IRQ_AMIGA_EXTER) that are a combination of chained (for the CIA interrupt
controllers) and shared level interrupts (for motherboard hardware and
Zorro expansion
boards).
But irq_set_chained_handler() sets IRQ_NOREQUEST, i.e. the interrupt cannot
be requested anymore via request_irq(), so this rules out using it with shared
level interrupts.

What's the preferred way to handle this? Is there are standard way, or should I
write my own specialized irq_flow_handler_t that handles both?

In the old scheme, we just registered the chain handlers with
request_irq(), so they
worked nicely together with the shared level interrupts (cfr.
arch/m68k/amiga/cia.c)

Thanks!

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

Re: m68k: Convert to genirq (WIP)

[Thomas Gleixner]

Geert,

On Tue, 31 May 2011, Geert Uytterhoeven wrote:
> On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > Next on my list is Amiga, which will cover autovectored and chained interrupts.
> 
> Plain chained interrupts should be handled by calling irq_set_chained_handler()
> to register an irq_flow_handler_t, and let the handler call
> generic_handle_irq() for
> each successive interrupt, right?
> 
> However, on Amiga we have interrupts (IRQ_AMIGA_PORTS and
> IRQ_AMIGA_EXTER) that are a combination of chained (for the CIA interrupt
> controllers) and shared level interrupts (for motherboard hardware and
> Zorro expansion
> boards).
> But irq_set_chained_handler() sets IRQ_NOREQUEST, i.e. the interrupt cannot
> be requested anymore via request_irq(), so this rules out using it with shared
> level interrupts.
> 
> What's the preferred way to handle this? Is there are standard way, or should I
> write my own specialized irq_flow_handler_t that handles both?
> 
> In the old scheme, we just registered the chain handlers with
> request_irq(), so they
> worked nicely together with the shared level interrupts (cfr.
> arch/m68k/amiga/cia.c)

You still can setup all those handlers setup via request_irq() and
handle the demux part by calling generic_handle_irq() from the handler
which deals with that demux hardware. irq_set_chained_handler() is
merily an optimization which does not apply to potentially shared
primary interrupts.

Thanks,

	tglx

Re: m68k: Convert to genirq (WIP)

[Finn Thain]

On Sat, 28 May 2011, Geert Uytterhoeven wrote:

> Of course any help is welcome, especially for Mac

What kind of help are you looking for? I read through your patch series 
but I'm not sure how much work is left. Probably I need to look at a 
genirq reference implementation to get an idea of the goal...

> (with its maze of interrupt controllers)

Perhaps we do not need to model that complexity in generic irq terms?

The mac port could probably make good use of the irq startup and shutdown 
hooks though.

Finn

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Fri, Jun 3, 2011 at 13:20, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Sat, 28 May 2011, Geert Uytterhoeven wrote:
>> Of course any help is welcome, especially for Mac
>
> What kind of help are you looking for? I read through your patch series
> but I'm not sure how much work is left. Probably I need to look at a
> genirq reference implementation to get an idea of the goal...

I could use help in the form of converting the various m68k subplatforms over to
genirq.

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

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Now sparc32 has beaten me, I pushed out my work in progress of converting m68k
> to use the generic hardirq framework:
>
> git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git m68k-genirq
> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-genirq

> Next on my list is Amiga, which will cover autovectored and chained interrupts.

I rebased to 3.0-rc1 and added (not in that order):
  [10] m68k/irq: Add m68k_setup_irq_controller()
  [11] m68k/irq: Adding missing "irq" offset in m68k_setup_irq_controller()
  [12] m68k/irq: Fix auto and user chips and handlers
  [13] m68k/amiga: Refactor amiints.c
  [14] m68k/amiga: Convert Amiga to genirq
  [15] m68k/amiga: Optimize interrupts using chain handlers

It works on Amiga now, too. It can still use some optimizations in the
irq_{enable,disable,ack,mask,mask_ack,unmask} area, as my BogoMIPS
rating dropped by ca 2.5% and is now under 16, for a 25 MHz 68040.

BTW, the second warning on Atari is still there.

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

Re: m68k: Convert to genirq (WIP)

[Brad Boyer]

On Fri, Jun 03, 2011 at 09:20:23PM +1000, Finn Thain wrote:
> On Sat, 28 May 2011, Geert Uytterhoeven wrote:
> > Of course any help is welcome, especially for Mac
> 
> What kind of help are you looking for? I read through your patch series 
> but I'm not sure how much work is left. Probably I need to look at a 
> genirq reference implementation to get an idea of the goal...

If there are any good documents on genirq, I would like to look at it
as well. I didn't see anything obvious in Documentation/ in the tree.

> > (with its maze of interrupt controllers)
> 
> Perhaps we do not need to model that complexity in generic irq terms?
> 
> The mac port could probably make good use of the irq startup and shutdown 
> hooks though.

If we could really map all the interrupt controllers, we could probably
cut down on the largest interrupt number. Most Macs really only have
20 or 30 actual interrupt sources. The problem is the two or three
layers of cascaded mess. None of them have just a single layer. Just
getting rid of the fixed global mapping could take us down to 64 since
nothing has both Baboon and PSC, but we have unique numbers for them.
We have 3 whole blocks of 8 just for PSC, even though that's just in
two models. We don't even know what most of those do, if anything.

We would probably need to move everything to platform devices if we
do that so that drivers don't need to use hard-coded interrupts. I
suppose we really should do that anyway.

	Brad Boyer
	flar@allandria.com

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Sun, Jun 5, 2011 at 08:27, Brad Boyer <flar@allandria.com> wrote:
> On Fri, Jun 03, 2011 at 09:20:23PM +1000, Finn Thain wrote:
>> On Sat, 28 May 2011, Geert Uytterhoeven wrote:
>> > Of course any help is welcome, especially for Mac
>>
>> What kind of help are you looking for? I read through your patch series
>> but I'm not sure how much work is left. Probably I need to look at a
>> genirq reference implementation to get an idea of the goal...
>
> If there are any good documents on genirq, I would like to look at it
> as well. I didn't see anything obvious in Documentation/ in the tree.

Documentation/DocBook/genericirq.tmpl

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

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Sat, Jun 4, 2011 at 19:56, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> Now sparc32 has beaten me, I pushed out my work in progress of converting m68k
>> to use the generic hardirq framework:
>>
>> git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git m68k-genirq
>> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-genirq
>
>> Next on my list is Amiga, which will cover autovectored and chained interrupts.
>
> I rebased to 3.0-rc1 and added (not in that order):
>  [10] m68k/irq: Add m68k_setup_irq_controller()
>  [11] m68k/irq: Adding missing "irq" offset in m68k_setup_irq_controller()
>  [12] m68k/irq: Fix auto and user chips and handlers
>  [13] m68k/amiga: Refactor amiints.c
>  [14] m68k/amiga: Convert Amiga to genirq
>  [15] m68k/amiga: Optimize interrupts using chain handlers
>
> It works on Amiga now, too. It can still use some optimizations in the
> irq_{enable,disable,ack,mask,mask_ack,unmask} area, as my BogoMIPS
> rating dropped by ca 2.5% and is now under 16, for a 25 MHz 68040.

Seems like everything (Atari/ARAnyM and Amiga) still works when using
handle_simple_irq instead of handle_level_irq.
As a bonus, BogoMIPS is above 16 again.

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

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Wed, Jun 15, 2011 at 21:44, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Sat, Jun 4, 2011 at 19:56, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>> Now sparc32 has beaten me, I pushed out my work in progress of converting m68k
>>> to use the generic hardirq framework:
>>>
>>> git://git.kernel.org:/pub/scm/linux/kernel/git/geert/linux-m68k.git m68k-genirq
>>> http://git.kernel.org/?p=linux/kernel/git/geert/linux-m68k.git;a=shortlog;h=refs/heads/m68k-genirq
>>
>>> Next on my list is Amiga, which will cover autovectored and chained interrupts.
>>
>> I rebased to 3.0-rc1 and added (not in that order):
>>  [10] m68k/irq: Add m68k_setup_irq_controller()
>>  [11] m68k/irq: Adding missing "irq" offset in m68k_setup_irq_controller()
>>  [12] m68k/irq: Fix auto and user chips and handlers
>>  [13] m68k/amiga: Refactor amiints.c
>>  [14] m68k/amiga: Convert Amiga to genirq
>>  [15] m68k/amiga: Optimize interrupts using chain handlers
>>
>> It works on Amiga now, too. It can still use some optimizations in the
>> irq_{enable,disable,ack,mask,mask_ack,unmask} area, as my BogoMIPS
>> rating dropped by ca 2.5% and is now under 16, for a 25 MHz 68040.
>
> Seems like everything (Atari/ARAnyM and Amiga) still works when using
> handle_simple_irq instead of handle_level_irq.
> As a bonus, BogoMIPS is above 16 again.

With handle_simple_irq(), we no longer need to define irq_{,un}mask() methods
in our irq_chips. Hence the "old" m68k platform interrupt code seems to be much
closer to genirq than I thought...

Does this make sense?

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

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> | ------------[ cut here ]------------
> | WARNING: at linux/kernel/irq/handle.c:130 handle_irq_event_percpu+0xe6/0x148()
> | irq 3 handler nfeth_interrupt+0x0/0x126 enabled interrupts
> | Modules linked in:
> | Call Trace: [<00027670>] warn_slowpath_common+0x3e/0x64
> |  [<0002767e>] warn_slowpath_common+0x4c/0x64
> |  [<0002770c>] warn_slowpath_fmt+0x2a/0x32
> |  [<0004d01a>] handle_irq_event_percpu+0xe6/0x148
> |  [<0004d01a>] handle_irq_event_percpu+0xe6/0x148
> |  [<00009d64>] nfeth_interrupt+0x0/0x126
> |  [<00027dc8>] printk+0x0/0x1a
> |  [<0004d09c>] handle_irq_event+0x20/0x2c
> |  [<0004ecce>] handle_level_irq+0x50/0x9c
> |  [<002496b8>] schedule+0x0/0x31e
> |  [<00006782>] do_IRQ+0x2e/0x44
> |  [<00027dc8>] printk+0x0/0x1a
> |  [<00003eb4>] __m68k_handle_int+0xe/0x12
> |  [<000026e2>] auto_irqhandler_fixup+0x4/0x6
> |  [<00027dc8>] printk+0x0/0x1a
> |  [<00002c46>] default_idle+0x0/0xe
> |  [<00002b0c>] cpu_idle+0x16/0x22
> |  [<00002b18>] kernel_thread+0x0/0x4e
> |  [<00248610>] rest_init+0x5c/0x62
> |  [<0031a220>] start_kernel+0x3a4/0x3b0
> |  [<000106aa>] ssincos+0x27e/0x2ac
> |  [<000106aa>] ssincos+0x27e/0x2ac
> |  [<0031931e>] _sinittext+0x31e/0x9c0
> |
> | ---[ end trace 139ce121c98e96cb ]---

This is the WARN_ONCE(!irqs_disabled()) check.

static inline bool arch_irqs_disabled_flags(unsigned long flags)
{
        return (flags & ~ALLOWINT) != 0;
}

with flags = 0x2300. Due to the "special" value of ALLOWINT on Atari:

#if defined(MACH_ATARI_ONLY)
        /* block out HSYNC on the atari */
#define ALLOWINT        (~0x400)
#define MAX_NOINT_IPL   3
#else
        /* portable version */
#define ALLOWINT        (~0x700)
#define MAX_NOINT_IPL   0
#endif /* machine compilation types */

the test fails.

Would it harm to always use the "portable" version?
That one is used on multi-platform kernels anyway?
Or would it cause too many HBLANK interrupts?

BTW, MAX_NOINT_IPL is no longer used.

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

Re: m68k: Convert to genirq (WIP)

[Thomas Gleixner]

On Thu, 16 Jun 2011, Geert Uytterhoeven wrote:
> > Seems like everything (Atari/ARAnyM and Amiga) still works when using
> > handle_simple_irq instead of handle_level_irq.
> > As a bonus, BogoMIPS is above 16 again.
> 
> With handle_simple_irq(), we no longer need to define irq_{,un}mask() methods
> in our irq_chips. Hence the "old" m68k platform interrupt code seems to be much
> closer to genirq than I thought...
> 
> Does this make sense?

It makes sense, when your interrupt chips do not require any action
when an interrupt is handled. In that case you can avoid the hardware
access.

Thanks,

	tglx

Re: m68k: Convert to genirq (WIP)

[Michael Schmitz]

On Fri, Jun 17, 2011 at 7:45 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
Hi Geert,

> This is the WARN_ONCE(!irqs_disabled()) check.
>
> static inline bool arch_irqs_disabled_flags(unsigned long flags)
> {
>        return (flags & ~ALLOWINT) != 0;
> }
>
> with flags = 0x2300. Due to the "special" value of ALLOWINT on Atari:
>
> #if defined(MACH_ATARI_ONLY)
>        /* block out HSYNC on the atari */
> #define ALLOWINT        (~0x400)
> #define MAX_NOINT_IPL   3
> #else
>        /* portable version */
> #define ALLOWINT        (~0x700)
> #define MAX_NOINT_IPL   0
> #endif /* machine compilation types */
>
> the test fails.
>
> Would it harm to always use the "portable" version?
> That one is used on multi-platform kernels anyway?
> Or would it cause too many HBLANK interrupts?

I'd say it would cause too many unnecessary interrupts. At least with
the original Falcon hardware that was a problem (haven't ever tried
this on the CT60). Not sure I tried multi platform kernels in a long
time, either. For these, it would probably required to male ALLOWINT a
runtime optiion in order to avoid this problem (I seem to recall we
used the corresponding hbl interrrupt handler for this originally
since it only was a problem on Falcon, not on TT. Does the TT use IPL
1 and 2, Andreas?).

MAX_NOINT_IPL may not needed any longer because all interrupt and
signal return is now done from assembler code in entry.S, I guess.

Probably best to ignore the two lowest IRQ bits on Atari for the
purpose of this test since these are always going to be disabled.

Cheers,

  Michael


> BTW, MAX_NOINT_IPL is no longer used.
>
> 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
>

Re: m68k: Convert to genirq (WIP)

[Finn Thain]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1307 bytes --]


On Thu, 16 Jun 2011, Geert Uytterhoeven wrote:

> On Wed, Jun 15, 2011 at 21:44, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Sat, Jun 4, 2011 at 19:56, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>
> >> It works on Amiga now, too. It can still use some optimizations in 
> >> the irq_{enable,disable,ack,mask,mask_ack,unmask} area, as my 
> >> BogoMIPS rating dropped by ca 2.5% and is now under 16, for a 25 MHz 
> >> 68040.
> >
> > Seems like everything (Atari/ARAnyM and Amiga) still works when using 
> > handle_simple_irq instead of handle_level_irq. As a bonus, BogoMIPS is 
> > above 16 again.

Your bogomips benchmark would be the best-case penalty, right?

Have you tried say, sending a ping flood to measure throughput and 
latency?

> 
> With handle_simple_irq(), we no longer need to define irq_{,un}mask() 
> methods in our irq_chips. Hence the "old" m68k platform interrupt code 
> seems to be much closer to genirq than I thought...
> 
> Does this make sense?

If the simple irq model gets us closer to the goal and doesn't kill 
performance then it makes sense to me.

Finn

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Fri, Jun 17, 2011 at 05:45, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Thu, 16 Jun 2011, Geert Uytterhoeven wrote:
>> On Wed, Jun 15, 2011 at 21:44, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > On Sat, Jun 4, 2011 at 19:56, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> >> On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> >>
>> >> It works on Amiga now, too. It can still use some optimizations in
>> >> the irq_{enable,disable,ack,mask,mask_ack,unmask} area, as my
>> >> BogoMIPS rating dropped by ca 2.5% and is now under 16, for a 25 MHz
>> >> 68040.
>> >
>> > Seems like everything (Atari/ARAnyM and Amiga) still works when using
>> > handle_simple_irq instead of handle_level_irq. As a bonus, BogoMIPS is
>> > above 16 again.
>
> Your bogomips benchmark would be the best-case penalty, right?
>
> Have you tried say, sending a ping flood to measure throughput and
> latency?

No, I haven't compared network performance.

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

Re: m68k: Convert to genirq (WIP)

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> This is the WARN_ONCE(!irqs_disabled()) check.
>
> static inline bool arch_irqs_disabled_flags(unsigned long flags)
> {
>         return (flags & ~ALLOWINT) != 0;

That should be

          return (flags & 0x700) == 0x700;

It doesn't make sense to use ALLOWINT here, since arch_local_irq_disable
doesn't use it either.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k: Convert to genirq (WIP)

[Andreas Schwab]

Michael Schmitz <schmitzmic@googlemail.com> writes:

> Does the TT use IPL 1 and 2, Andreas?).

The TT has the same interrupts.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Fri, Jun 17, 2011 at 19:22, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
>> This is the WARN_ONCE(!irqs_disabled()) check.
>>
>> static inline bool arch_irqs_disabled_flags(unsigned long flags)
>> {
>>         return (flags & ~ALLOWINT) != 0;
>
> That should be
>
>          return (flags & 0x700) == 0x700;
>
> It doesn't make sense to use ALLOWINT here, since arch_local_irq_disable
> doesn't use it either.

Unfortunately this makes it worse:

| Calibrating delay loop... kernel BUG at kernel/posix-cpu-timers.c:1314!

BUG_ON(!irqs_disabled()) triggers as flags is 0x2619 there.

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

Re: m68k: Convert to genirq (WIP)

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> BUG_ON(!irqs_disabled()) triggers as flags is 0x2619 there.

Which is correct, since arch_local_irq_disable would set it to 2719.
You need to find out why arch_local_irq_disable wasn't called.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Sun, Jun 19, 2011 at 13:19, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
>> BUG_ON(!irqs_disabled()) triggers as flags is 0x2619 there.
>
> Which is correct, since arch_local_irq_disable would set it to 2719.
> You need to find out why arch_local_irq_disable wasn't called.

I don't think we ever explicitly disable interrupts in interrupt handlers.
The CPU disables all interupts of the same or lower level anyway.
As all Atari interrupts (except for hblank and vblank) run at level 6,
this is why flags & 0x700 == 0x600 above.

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

Re: m68k: Convert to genirq (WIP)

[Andreas Schwab]

Geert Uytterhoeven <geert@linux-m68k.org> writes:

> On Sun, Jun 19, 2011 at 13:19, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>>
>>> BUG_ON(!irqs_disabled()) triggers as flags is 0x2619 there.
>>
>> Which is correct, since arch_local_irq_disable would set it to 2719.
>> You need to find out why arch_local_irq_disable wasn't called.
>
> I don't think we ever explicitly disable interrupts in interrupt handlers.

Then the BUG_ON is wrong.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Fri, Jun 17, 2011 at 05:45, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Thu, 16 Jun 2011, Geert Uytterhoeven wrote:
>> On Wed, Jun 15, 2011 at 21:44, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > On Sat, Jun 4, 2011 at 19:56, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> >> On Sat, May 28, 2011 at 20:32, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> >>
>> >> It works on Amiga now, too. It can still use some optimizations in
>> >> the irq_{enable,disable,ack,mask,mask_ack,unmask} area, as my
>> >> BogoMIPS rating dropped by ca 2.5% and is now under 16, for a 25 MHz
>> >> 68040.
>> >
>> > Seems like everything (Atari/ARAnyM and Amiga) still works when using
>> > handle_simple_irq instead of handle_level_irq. As a bonus, BogoMIPS is
>> > above 16 again.
>
> Your bogomips benchmark would be the best-case penalty, right?
>
> Have you tried say, sending a ping flood to measure throughput and
> latency?

Results on Amiga 4000/040 (25 MHz 68040, 12 MiB Fast RAM) with Ariadne Ethernet,
running 3.0-rc7.

                              legacy m68k               genirq

bogomips:                     16.17 (lpj=80896)         16.02 (lpj=80128)

10x ping fast machine:        9034 ms                   9025 ms
  rtt min/avg/max/mdev (ms)   1.815/2.556/8.580/2.008   1.903/2.142/3.275/0.388

100x flood ping fast machine: 4654 ms                   3960 ms
  rtt min/avg/max/mdev (ms)   1.831/2.113/3.285/0.361   1.887/2.068/2.958/0.242
  pipe, ipg/ewma (ms)         10, 47.013/2.111          6, 40.005/1.989

wget 16 MiB image              86.99 KB/s               112.08 KB/s
                              104.31 KB/s               115.95 KB/s
                              109.56 KB/s               116.22 KB/s


/proc/interrupts (legacy m68k):

auto       1:          0 int1
auto       2:     152824 CIAA, ide0, eth0
auto       3:     133649 int3
auto       4:          0 int4
auto       5:          0 int5
auto       6:     193334 CIAB
amiga      8:          0 serial TX
amiga     12:     133649 fb vertb handler
amiga     19:          0 serial RX
cia       25:        240 amikbd
cia       27:     193334 timer


/proc/interrupts (genirq):

           CPU0
  2:      29503      auto  CIAA, ide0, eth0
  6:      93738      auto  CIAB
  8:          0     amiga  serial TX
 12:      64657     amiga  fb vertb handler
 13:          3     amiga
 19:          0     amiga  serial RX
 25:        788       cia  amikbd
 27:      93738       cia  timer
ERR:          0

I did some more refactoring which made the Mac conversion trivial (but
still untested).
I'll prepare it for publishing when the kids leave me alone ;-)

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

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Sun, Jun 5, 2011 at 08:27, Brad Boyer <flar@allandria.com> wrote:
> If we could really map all the interrupt controllers, we could probably
> cut down on the largest interrupt number. Most Macs really only have
> 20 or 30 actual interrupt sources. The problem is the two or three
> layers of cascaded mess. None of them have just a single layer. Just
> getting rid of the fixed global mapping could take us down to 64 since
> nothing has both Baboon and PSC, but we have unique numbers for them.
> We have 3 whole blocks of 8 just for PSC, even though that's just in
> two models. We don't even know what most of those do, if anything.

While looking into optimizing interrupts using chain handlers (which cannot
be shared), I noticed several of these cascades are hung on the same interrupt.
Hence we cannot use the optimization of chain handlers for them.

Knowing which are mutually exclusive helps a lot, but my Mac knowledge is
very limited.

I derived from the code this list of cascade handlers and the
interrupts they use:

baboon_irq
    IRQ_NUBUS_C

oss_irq
    OSS_IRQLEV_SCSI = IRQ_AUTO_2                conflict: via2_irq
    OSS_IRQLEV_SOUND = IRQ_AUTO_5               conflict: psc_irq

oss_nubus_irq
    OSS_IRQLEV_NUBUS = IRQ_AUTO_3               conflict: psc_irq

psc_irq
    IRQ_AUTO_3                                  conflict: oss_nubus_irq
    IRQ_AUTO_4
    IRQ_AUTO_5                                  conflict: oss_irq
    IRQ_AUTO_6                                  conflict: via1_irq

via1_irq
    OSS_IRQLEV_VIA1 = IRQ_AUTO_6 (on oss)       conflict: psc_irq

    IRQ_AUTO_1                                  conflict: iop_ism_irq
    IRQ_AUTO_6 (if via_alt_mapping)             conflict: psc_irq

via2_irq
    IRQ_AUTO_2                                  conflict: oss_irq

via_nubus_irq
    IRQ_MAC_NUBUS = IRQ_VIA2_1

These are other interrupts using in the Mac core code, which may use the same
interrupts as some of the cascades above:

iop_ism_irq
    OSS_IRQLEV_IOPISM = 1 = IRQ_AUTO_1 (on oss) conflict: via1_irq
    IRQ_VIA2_0 (on !oss)

mac_nmi_handler
    IRQ_AUTO_7

timer handler
    IRQ_MAC_TIMER_1 = IRQ_VIA1_6

So baboon and PSC are mutually exclusive? But they don't conflict w.r.t. to
interrupt lines anyway, so they're not an issue.

>From the code, OSS and VIA are also mutually exclusive (except for via1_irq)?

But PSC can coexist with OSS? That's where most of the conflicts are.

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

Re: m68k: Convert to genirq (WIP)

[Finn Thain]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 323 bytes --]


On Mon, 8 Aug 2011, Geert Uytterhoeven wrote:

> I did some more refactoring which made the Mac conversion trivial (but
> still untested).
> I'll prepare it for publishing when the kids leave me alone ;-)

I'd be happy to test it.

Finn

> 
> Gr{oetje,eeting}s,
> 
>                         Geert

Re: m68k: Convert to genirq (WIP)

[Finn Thain]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2650 bytes --]


On Wed, 10 Aug 2011, Geert Uytterhoeven wrote:
> 
> While looking into optimizing interrupts using chain handlers (which 
> cannot be shared), I noticed several of these cascades are hung on the 
> same interrupt. Hence we cannot use the optimization of chain handlers 
> for them.
> 
> Knowing which are mutually exclusive helps a lot, but my Mac knowledge 
> is very limited.
> 
> I derived from the code this list of cascade handlers and the interrupts 
> they use:
> 
> baboon_irq
>     IRQ_NUBUS_C
> 
> oss_irq
>     OSS_IRQLEV_SCSI = IRQ_AUTO_2                conflict: via2_irq
>     OSS_IRQLEV_SOUND = IRQ_AUTO_5               conflict: psc_irq

PSC and OSS are mutually exclusive.

VIA2 and OSS are also mutually exlusive.

> 
> oss_nubus_irq
>     OSS_IRQLEV_NUBUS = IRQ_AUTO_3               conflict: psc_irq
> 
> psc_irq
>     IRQ_AUTO_3                                  conflict: oss_nubus_irq
>     IRQ_AUTO_4
>     IRQ_AUTO_5                                  conflict: oss_irq
>     IRQ_AUTO_6                                  conflict: via1_irq
> 
> via1_irq
>     OSS_IRQLEV_VIA1 = IRQ_AUTO_6 (on oss)       conflict: psc_irq
> 
>     IRQ_AUTO_1                                  conflict: iop_ism_irq

iop_ism_irq is only used with OSS.

>     IRQ_AUTO_6 (if via_alt_mapping)             conflict: psc_irq

via_alt_mapping is not used with PSC.

> 
> via2_irq
>     IRQ_AUTO_2                                  conflict: oss_irq
> 
> via_nubus_irq
>     IRQ_MAC_NUBUS = IRQ_VIA2_1
> 
> These are other interrupts using in the Mac core code, which may use the same
> interrupts as some of the cascades above:
> 
> iop_ism_irq
>     OSS_IRQLEV_IOPISM = 1 = IRQ_AUTO_1 (on oss) conflict: via1_irq

via1_irq is remapped to IRQ_AUTO_6 on OSS.

>     IRQ_VIA2_0 (on !oss)
> 
> mac_nmi_handler
>     IRQ_AUTO_7
> 
> timer handler
>     IRQ_MAC_TIMER_1 = IRQ_VIA1_6
> 
> So baboon and PSC are mutually exclusive? But they don't conflict w.r.t. to
> interrupt lines anyway, so they're not an issue.
> 
> From the code, OSS and VIA are also mutually exclusive (except for via1_irq)?
> 
> But PSC can coexist with OSS? That's where most of the conflicts are.

Hope this helps...

Finn

> 
> 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
> 

Re: m68k: Convert to genirq (WIP)

[Brad Boyer]

On Wed, Aug 10, 2011 at 08:53:16PM +1000, Finn Thain wrote:
> On Wed, 10 Aug 2011, Geert Uytterhoeven wrote:
> > While looking into optimizing interrupts using chain handlers (which 
> > cannot be shared), I noticed several of these cascades are hung on the 
> > same interrupt. Hence we cannot use the optimization of chain handlers 
> > for them.
> > 
> > Knowing which are mutually exclusive helps a lot, but my Mac knowledge 
> > is very limited.

The only simple rules are that OSS only exists on one model, the Mac IIfx,
the PSC only exists on two (three, sort of) models: the Quadra 660AV
(which is also the Centris 660AV) and the Quadra 840AV, and the Baboon
only exists on one m68k model, the Powerbook 190 (it also exists on the
PowerBook 5300, but that is ppc).

What's messy is VIA2/RBV, which gets very complicated. The only simple
thing there is that the Mac IIfx doesn't have any of that because it
has OSS instead.

> > I derived from the code this list of cascade handlers and the interrupts 
> > they use:
> > 
> > baboon_irq
> >     IRQ_NUBUS_C
> > 
> > oss_irq
> >     OSS_IRQLEV_SCSI = IRQ_AUTO_2                conflict: via2_irq
> >     OSS_IRQLEV_SOUND = IRQ_AUTO_5               conflict: psc_irq
> 
> PSC and OSS are mutually exclusive.
> 
> VIA2 and OSS are also mutually exlusive.
> 
> > 
> > oss_nubus_irq
> >     OSS_IRQLEV_NUBUS = IRQ_AUTO_3               conflict: psc_irq
> > 
> > psc_irq
> >     IRQ_AUTO_3                                  conflict: oss_nubus_irq
> >     IRQ_AUTO_4
> >     IRQ_AUTO_5                                  conflict: oss_irq
> >     IRQ_AUTO_6                                  conflict: via1_irq
> > 
> > via1_irq
> >     OSS_IRQLEV_VIA1 = IRQ_AUTO_6 (on oss)       conflict: psc_irq
> > 
> >     IRQ_AUTO_1                                  conflict: iop_ism_irq
> 
> iop_ism_irq is only used with OSS.

Not strictly true, but it's mapped onto IRQ_VIA2_0 in the other case.

> 
> >     IRQ_AUTO_6 (if via_alt_mapping)             conflict: psc_irq
> 
> via_alt_mapping is not used with PSC.
> 
> > 
> > via2_irq
> >     IRQ_AUTO_2                                  conflict: oss_irq
> > 
> > via_nubus_irq
> >     IRQ_MAC_NUBUS = IRQ_VIA2_1
> > 
> > These are other interrupts using in the Mac core code, which may use the same
> > interrupts as some of the cascades above:
> > 
> > iop_ism_irq
> >     OSS_IRQLEV_IOPISM = 1 = IRQ_AUTO_1 (on oss) conflict: via1_irq
> 
> via1_irq is remapped to IRQ_AUTO_6 on OSS.
> 
> >     IRQ_VIA2_0 (on !oss)
> > 
> > mac_nmi_handler
> >     IRQ_AUTO_7
> > 
> > timer handler
> >     IRQ_MAC_TIMER_1 = IRQ_VIA1_6
> > 
> > So baboon and PSC are mutually exclusive? But they don't conflict w.r.t. to
> > interrupt lines anyway, so they're not an issue.
> > 
> > From the code, OSS and VIA are also mutually exclusive (except for via1_irq)?
> > 
> > But PSC can coexist with OSS? That's where most of the conflicts are.
> 
> Hope this helps...

More help is always good. Hope I've been helpful as well.

	Brad Boyer
	flar@allandria.com

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Wed, Aug 10, 2011 at 12:53, Finn Thain <fthain@telegraphics.com.au> wrote:
>> via1_irq
>>     OSS_IRQLEV_VIA1 = IRQ_AUTO_6 (on oss)       conflict: psc_irq
>>
>>     IRQ_AUTO_1                                  conflict: iop_ism_irq

>> iop_ism_irq
>>     OSS_IRQLEV_IOPISM = 1 = IRQ_AUTO_1 (on oss) conflict: via1_irq
>
> via1_irq is remapped to IRQ_AUTO_6 on OSS.

According to via_register_interrupts(), it requests both:

        if (via_alt_mapping) {
                if (request_irq(IRQ_AUTO_1, via1_irq, 0, "software",
                                (void *)via1))
                        pr_err("Couldn't register %s interrupt\n", "software");
                if (request_irq(IRQ_AUTO_6, via1_irq, 0, "via1", (void *)via1))
                        pr_err("Couldn't register %s interrupt\n", "via1");
        } else {
                if (request_irq(IRQ_AUTO_1, via1_irq, 0, "via1", (void *)via1))
                        pr_err("Couldn't register %s interrupt\n", "via1");
        }

Hence IRQ_AUTO_1 must be shared, and we cannot use an optimized chain
handler for via1_irq() nor iop_ism_irq(). This is the only remaining conflict
I see.

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

Re: m68k: Convert to genirq (WIP)

[Finn Thain]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1725 bytes --]


On Fri, 26 Aug 2011, Geert Uytterhoeven wrote:

> On Wed, Aug 10, 2011 at 12:53, Finn Thain <fthain@telegraphics.com.au> wrote:
> >> via1_irq
> >>     OSS_IRQLEV_VIA1 = IRQ_AUTO_6 (on oss)       conflict: psc_irq
> >>
> >>     IRQ_AUTO_1                                  conflict: iop_ism_irq
> 
> >> iop_ism_irq
> >>     OSS_IRQLEV_IOPISM = 1 = IRQ_AUTO_1 (on oss) conflict: via1_irq
> >
> > via1_irq is remapped to IRQ_AUTO_6 on OSS.
> 
> According to via_register_interrupts(), it requests both:
> 
>         if (via_alt_mapping) {
>                 if (request_irq(IRQ_AUTO_1, via1_irq, 0, "software",
>                                 (void *)via1))
>                         pr_err("Couldn't register %s interrupt\n", "software");
>                 if (request_irq(IRQ_AUTO_6, via1_irq, 0, "via1", (void *)via1))
>                         pr_err("Couldn't register %s interrupt\n", "via1");
>         } else {
>                 if (request_irq(IRQ_AUTO_1, via1_irq, 0, "via1", (void *)via1))
>                         pr_err("Couldn't register %s interrupt\n", "via1");
>         }
> 
> Hence IRQ_AUTO_1 must be shared and we cannot use an optimized chain
> handler for via1_irq()

I'm pretty sure that the "software" request_irq can be removed. It has 
come up before --
http://marc.info/?l=linux-mac68k&m=110973724208746&w=2

Maybe Brad can shed some light on this (?)

I've just cloned and built your m68k-genirq branch. I will run some tests.

> nor iop_ism_irq().

via_register_interrupts() is not called on OSS.

Finn

> This is the only remaining conflict I see.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

Re: m68k: Convert to genirq (WIP)

[Geert Uytterhoeven]

On Fri, Aug 26, 2011 at 13:21, Finn Thain <fthain@telegraphics.com.au> wrote:
> On Fri, 26 Aug 2011, Geert Uytterhoeven wrote:
>> On Wed, Aug 10, 2011 at 12:53, Finn Thain <fthain@telegraphics.com.au> wrote:
>> >> via1_irq
>> >>     OSS_IRQLEV_VIA1 = IRQ_AUTO_6 (on oss)       conflict: psc_irq
>> >>
>> >>     IRQ_AUTO_1                                  conflict: iop_ism_irq
>>
>> >> iop_ism_irq
>> >>     OSS_IRQLEV_IOPISM = 1 = IRQ_AUTO_1 (on oss) conflict: via1_irq
>> >
>> > via1_irq is remapped to IRQ_AUTO_6 on OSS.
>>
>> According to via_register_interrupts(), it requests both:
>>
>>         if (via_alt_mapping) {
>>                 if (request_irq(IRQ_AUTO_1, via1_irq, 0, "software",
>>                                 (void *)via1))
>>                         pr_err("Couldn't register %s interrupt\n", "software");
>>                 if (request_irq(IRQ_AUTO_6, via1_irq, 0, "via1", (void *)via1))
>>                         pr_err("Couldn't register %s interrupt\n", "via1");
>>         } else {
>>                 if (request_irq(IRQ_AUTO_1, via1_irq, 0, "via1", (void *)via1))
>>                         pr_err("Couldn't register %s interrupt\n", "via1");
>>         }
>>
>> Hence IRQ_AUTO_1 must be shared and we cannot use an optimized chain
>> handler for via1_irq()
>
> I'm pretty sure that the "software" request_irq can be removed. It has
> come up before --
> http://marc.info/?l=linux-mac68k&m=110973724208746&w=2
>
> Maybe Brad can shed some light on this (?)
>
> I've just cloned and built your m68k-genirq branch. I will run some tests.

Thanks!

>> nor iop_ism_irq().
>
> via_register_interrupts() is not called on OSS.

You're right, I missed that.

>> This is the only remaining conflict I see.

Good, I'll convert them all to chain handlers.

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

Re: m68k: Convert to genirq (WIP)

[Brad Boyer]

On Fri, Aug 26, 2011 at 09:21:05PM +1000, Finn Thain wrote:
> 
> On Fri, 26 Aug 2011, Geert Uytterhoeven wrote:
> 
> > According to via_register_interrupts(), it requests both:
> > 
> >         if (via_alt_mapping) {
> >                 if (request_irq(IRQ_AUTO_1, via1_irq, 0, "software",
> >                                 (void *)via1))
> >                         pr_err("Couldn't register %s interrupt\n", "software");
> >                 if (request_irq(IRQ_AUTO_6, via1_irq, 0, "via1", (void *)via1))
> >                         pr_err("Couldn't register %s interrupt\n", "via1");
> >         } else {
> >                 if (request_irq(IRQ_AUTO_1, via1_irq, 0, "via1", (void *)via1))
> >                         pr_err("Couldn't register %s interrupt\n", "via1");
> >         }
> > 
> > Hence IRQ_AUTO_1 must be shared and we cannot use an optimized chain
> > handler for via1_irq()
> 
> I'm pretty sure that the "software" request_irq can be removed. It has 
> come up before --
> http://marc.info/?l=linux-mac68k&m=110973724208746&w=2
> 
> Maybe Brad can shed some light on this (?)

Sorry, not really. We don't have any good documentation on how the
alternate mapping really works on those systems. Anything that has
it internally is using custom chips instead of a real VIA6522, so
it's hard to say exactly how it behaves.

The real key of the alternate mapping is to move the timer interrupt
higher than all the other hardware. This and the ADB are about all
we really need from VIA1. It's possible one of the other interrupts
we don't use is still on IRQ1. It's hard to say without trying.

I think I have a couple systems that have this hardware, but they
are ones I haven't used much. If I can find some time I'll get the
Q950 I acquired recently up and running since it should have the
alternate mapping capability.

One potential option is to just take it out and see if anything
breaks with the change. We could add it back later if we find a
use for it.

	Brad Boyer
	flar@allandria.com