diff options
| author | Finn Thain <fthain@telegraphics.com.au> | 2017-10-26 22:45:24 -0400 |
|---|---|---|
| committer | Geert Uytterhoeven <geert@linux-m68k.org> | 2017-11-09 23:02:57 +0100 |
| commit | 8ee90c5c3fd1af8e68133defb15cfc66c1de3f88 (patch) | |
| tree | a857593df0974184f139050f47410bc36ebb570e /arch/m68k | |
| parent | 7a0bb4427024f426668f3ed63542328135282422 (diff) | |
| download | op-kernel-dev-8ee90c5c3fd1af8e68133defb15cfc66c1de3f88.zip op-kernel-dev-8ee90c5c3fd1af8e68133defb15cfc66c1de3f88.tar.gz | |
m68k/mac: Disentangle VIA/RBV and NuBus initialization
The Nubus subsystem should not be concerned with differences between VIA,
RBV and OSS platforms. It should be portable across Macs and PowerMacs.
This goal has implications for the initialization code relating to bus
locking and slot interrupts.
During Nubus initialization, bus transactions are "unlocked": on VIA2 and
RBV machines, via_nubus_init() sets a bit in the via2[gBufB] register to
allow bus-mastering Nubus cards to arbitrate for the bus. This happens
upon subsys_initcall(nubus_init). But because nubus_init() has no effect
on card state, this sequence is arbitrary.
Moreover, when Penguin is used to boot Linux, the bus is already unlocked
when Linux starts. On OSS machines there's no attempt to unlock Nubus
transactions at all. (Maybe there's no benefit on that platform or maybe
no-one knows how.)
All of this demonstrates that there's no benefit in locking out
bus-mastering cards, as yet. (If the need arises, we could lock the bus
for the duration of a timing-critical operation.) NetBSD unlocks the
Nubus early (at VIA initialization) and we can do the same.
via_nubus_init() is also responsible for some VIA interrupt setup that
should happen earlier than subsys_initcall(nubus_init). And actually, the
Nubus subsystem need not be involved with slot interrupts: SLOT2IRQ
works fine because Nubus slot IRQs are geographically assigned
(regardless of platform).
For certain platforms with PDS slots, some Nubus IRQs may be platform
IRQs and this is not something that the NuBus subsystem should worry
about. So let's invoke via_nubus_init() earlier and make the platform
responsible for bus unlocking and interrupt setup instead of the NuBus
subsystem.
Tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Diffstat (limited to 'arch/m68k')
| -rw-r--r-- | arch/m68k/mac/oss.c | 8 | ||||
| -rw-r--r-- | arch/m68k/mac/via.c | 5 |
2 files changed, 4 insertions, 9 deletions
diff --git a/arch/m68k/mac/oss.c b/arch/m68k/mac/oss.c index 61906eb..21b8560 100644 --- a/arch/m68k/mac/oss.c +++ b/arch/m68k/mac/oss.c @@ -52,14 +52,6 @@ void __init oss_init(void) } /* - * Initialize OSS for Nubus access - */ - -void __init oss_nubus_init(void) -{ -} - -/* * Handle miscellaneous OSS interrupts. */ diff --git a/arch/m68k/mac/via.c b/arch/m68k/mac/via.c index 19ad46b..c38fab2 100644 --- a/arch/m68k/mac/via.c +++ b/arch/m68k/mac/via.c @@ -106,6 +106,7 @@ static int gIER,gIFR,gBufA,gBufB; static u8 nubus_disabled; void via_debug_dump(void); +static void via_nubus_init(void); /* * Initialize the VIAs @@ -238,6 +239,8 @@ void __init via_init(void) via2[vACR] &= ~0x03; /* disable port A & B latches */ } + via_nubus_init(); + /* Everything below this point is VIA2 only... */ if (rbv_present) @@ -359,7 +362,7 @@ int via_get_cache_disable(void) * Initialize VIA2 for Nubus access */ -void __init via_nubus_init(void) +static void __init via_nubus_init(void) { /* unlock nubus transactions */ |
