Re: [PATCH 0/4] Mac IOP driver fixes

[Finn Thain <fthain@telegraphics.com.au>]

On Wed, 3 Jun 2020, Brad Boyer wrote:

> On Tue, Jun 02, 2020 at 01:48:22PM +1000, Finn Thain wrote:
> > 
> > Yes, I was aware of that issue. But the GTMFH 2ed. figure 9-14 
> > indicates that (on the IIfx) pin 12 in the drive connector is driven 
> > by the SWIM HDSEL pin instead of VIA1 Port A output. So, I wrote a 
> > patch to attempt to get the SWIM to drive this pin. But nothing worked 
> > because I never succeeded in putting the chip into bypass mode.
> 
> There does appear to be a bit in the mode register to directly control 
> the SEL line to the drive. Nothing in our code appears to use it. You 
> would write HEDSEL to mode0 to clear the line, and write HEDSEL to mode1 
> to set the line. However, it looks like the first bit in the setup 
> register controls if that line is input or output. Not sure why we have 
> it named S_INV_WDATA, but the state machine to the actual floppy drive 
> is way beyond my comprehension. I'll note that the swim3.c driver uses 
> the SELECT bit in the control register to do the same basic thing (and 
> it's the same bit value as HEDSEL in swim.c).
> 

I think that agrees with the patch I wrote a couple of years ago, back 
when I was working on this problem:

diff --git a/arch/m68k/mac/iop.c b/arch/m68k/mac/iop.c
index 392e57c2e5ea..ea77b983ccb9 100644
--- a/arch/m68k/mac/iop.c
+++ b/arch/m68k/mac/iop.c
@@ -130,6 +130,7 @@
 /* Non-zero if the IOPs are present */
 
 int iop_scc_present, iop_ism_present;
+EXPORT_SYMBOL(iop_ism_present);
 
 /* structure for tracking channel listeners */
 
diff --git a/drivers/block/swim.c b/drivers/block/swim.c
index 0e31884a9519..883ff1bc1ea0 100644
--- a/drivers/block/swim.c
+++ b/drivers/block/swim.c
@@ -27,6 +27,7 @@
 #include <linux/platform_device.h>
 
 #include <asm/mac_via.h>
+#include <asm/mac_iop.h>
 
 #define CARDNAME "swim"
 
@@ -135,7 +136,8 @@ struct iwm {
 
 /* bits in setup register */
 
-#define S_INV_WDATA	0x01
+#define S_Q3_OUTPUT	0x01 /* SWIM */
+#define S_INV_WDATA	0x01 /* SWIM 2 */
 #define S_3_5_SELECT	0x02
 #define S_GCR		0x04
 #define S_FCLK_DIV2	0x08
@@ -273,8 +275,13 @@ static inline void swim_select(struct swim __iomem *base, int sel)
 {
 	swim_write(base, phase, RELAX);
 
-	via1_set_head(sel & 0x100);
-
+	if (iop_ism_present) {
+		if (sel & 0x100)
+			swim_write(base, mode1, HEDSEL);
+		else
+			swim_write(base, mode0, HEDSEL);
+	} else
+		via1_set_head(sel & 0x100);
 	swim_write(base, phase, sel & CA_MASK);
 }
 
@@ -646,7 +653,12 @@ static int floppy_open(struct block_device *bdev, fmode_t mode)
 	else
 		fs->ref_count++;
 
-	swim_write(base, setup, S_IBM_DRIVE  | S_FCLK_DIV2);
+	if (iop_ism_present)
+		swim_write(base, setup, S_IBM_DRIVE | S_FCLK_DIV2 |
+					S_Q3_OUTPUT);
+	else
+		swim_write(base, setup, S_IBM_DRIVE | S_FCLK_DIV2);
+
 	udelay(10);
 	swim_drive(base, fs->location);
 	swim_motor(base, ON);

> I know we at least used to have a problem where the SCC ports only 
> worked if they were already in bypass mode. There was something we 
> weren't doing right about setting the bypass mode. I'm not sure if we 
> ever fixed it. If you turn off the "Compatible Mode" in the Serial 
> Switch control panel, does the Linux kernel SCC driver still work 
> afterwards? I know that was a problem at one point.
> 

Yes, it's still a problem. This relates directly to patch 2/4, so I asked 
Stan to confirm this before I sent the present patch series. Apparently 
the IOP_BYPASS bit is read-only. To effect a switch to bypass mode I 
believe that it is necessary to send the right message to the IOP kernel.

> > With regard to PowerBooks, we will need to power up the drive. And 
> > with regard to the IIfx, the A/UX iop.h header file indicates that, in 
> > bypass mode, the ISM registers have a 2-byte spacing (instead of 
> > 512-byte).
> 
> The notes I have indicate the SWIM registers are at the same spacing as 
> the SCC registers on the other IOP. That's definitely not 512-byte, so I 
> presume it's 2-byte spacing as that's what the SCC driver looks like it 
> does.
> 
> > But I wish I knew why the driver doesn't work on an LC III, which 
> > supposedly has a SWIM 2, just like the Quadra 800.
> 
> If I had to guess, the select line isn't in the same place. For example, 
> on the Mac Portable (which obviously isn't supported in Linux) that line 
> is apparently in VIA2 register B (as are most of the other bits that 
> normally show up in register A). Based on looking at the driver, being 
> unable to drive that line to the disk drive would break lots of stuff, 
> including the detection of the disk inserted in the drive.
> 

OK. I see that figure 9-11 has these details. I never noticed that, being 
that the Portable seemed to have no relevance.

We will have to experiment further to find out whether setting this bit 
has any effect on the LC III.