summaryrefslogtreecommitdiffstats
path: root/drivers/nubus
diff options
context:
space:
mode:
authorFinn Thain <fthain@telegraphics.com.au>2017-10-26 22:45:24 -0400
committerGeert Uytterhoeven <geert@linux-m68k.org>2017-11-09 23:02:57 +0100
commit8ee90c5c3fd1af8e68133defb15cfc66c1de3f88 (patch)
treea857593df0974184f139050f47410bc36ebb570e /drivers/nubus
parent7a0bb4427024f426668f3ed63542328135282422 (diff)
downloadop-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 'drivers/nubus')
-rw-r--r--drivers/nubus/nubus.c13
1 files changed, 0 insertions, 13 deletions
diff --git a/drivers/nubus/nubus.c b/drivers/nubus/nubus.c
index df431e8..4f50f30 100644
--- a/drivers/nubus/nubus.c
+++ b/drivers/nubus/nubus.c
@@ -18,11 +18,6 @@
#include <asm/setup.h>
#include <asm/page.h>
#include <asm/hwtest.h>
-#include <asm/mac_via.h>
-#include <asm/mac_oss.h>
-
-extern void via_nubus_init(void);
-extern void oss_nubus_init(void);
/* Constants */
@@ -840,14 +835,6 @@ static int __init nubus_init(void)
if (!MACH_IS_MAC)
return 0;
- /* Initialize the NuBus interrupts */
- if (oss_present) {
- oss_nubus_init();
- } else {
- via_nubus_init();
- }
-
- /* And probe */
pr_info("NuBus: Scanning NuBus slots.\n");
nubus_devices = NULL;
nubus_boards = NULL;
OpenPOWER on IntegriCloud