> From: "David A. Gatwood" <dgatwood@apple.com>
> Date: Mon, 17 Sep 2001 13:26:05 -0700
> To: John Ruschmeyer <jruschme@mac.com>
> Cc: Takeshi Shibagaki <sibagaki@lsi.melco.co.jp>, port-mac68k@netbsd.org,
> briggs@wasabisystems.com
> Subject: Re: Mac68k and IDE
> 
> On Sunday, September 16, 2001, at 09:12 AM, John Ruschmeyer wrote:
> 
>>> From: Takeshi Shibagaki <sibagaki@lsi.melco.co.jp>
>>>>>> Maybe, I guess some machines don't work if byte-order problem is
>>>>>> solved. Interrupt problem must be solved. In the case My LC630 works
>>>>>> when ether card exists in LC-PDS slot, but in the case no exist in
>>>>>> LC-PDS not works.
>>> 
>>> John> Actually, this make some sense. According to Ken Nakata's
>>> comments, the
>>> IDE
>>> John> controller generates a NUBUS interrupt but without the proper
>>> bits set.
>>> His
>>> John> answer on the Q630 was to daisy chain an interrupt handler on
>>> the Nubus
>>> John> interrupt that would check the IDE status, call wdintr() as
>>> necessary,
>>> and
>>> John> then call the original Nubus interrupt handler. On the PB150 and
>>> 190, he
>>> John> just added a normal nubus interrupt.
>>> 
>>> I understand Ken's comment because I also see Linux codes and Ken is
>>> my friend(but I met him only at once :-)).
>>> 
>>> There is no difference in Q630 and PB150,PB190 in Linux codes. Problem
>>> is no interrupt at nubus slot, but I don't know the point which
>>> interrupt has stopped at nubus or via.
>> 
>> One thing which is interesting (and I hope Alan or someone can clear
>> up) is
>> that you say the IDE genereates a NuBUS interrupt on slot F on the 630.
>> This
>> contradicts a comment in via.c, however, which talks about using that
>> for an
>> internal video interrupt since no "real-world" Mac uses slot F.
>> 
>> It would be interesting to sort this one out, if only to fix the
>> comment.
> 
> At least in the PPC-based follow-ons to the 630, based on MkLinux
> sources, slot f is listed as the "f108 interrupt",  This includes a
> number of interrupts, including ATA0, ATA1, and VBL (video).  Once you
> receive a slot F interrupt, it is necessary to identify the source(s)
> that generated it.

That clairifes the following comment in arch/mac68k/mac68k/via.c:

/*      
 * Nubus slot interrupt routines and parameters for slots 9-15.  Note
 * that for simplicity of code, "v2IRQ0" for internal video is treated
 * as a slot 15 interrupt; this slot is quite fictitious in real-world
 * Macs.  See also GMFH, pp. 165-167, and "Monster, Loch Ness."
 */

> It should be noted that MkLinux does a check for slot F interrupt
> sources when any slot interrupt is received, though, even if the slot F
> bit is not set, because for some reason, we were losing interrupts when
> we didn't do that.  Your mileage may vary.

Which explains the big difference between Ken Nakata's way of handling
interrupts and Takeshi's. Ken inserted his check in front of the Nubus
interrupt handling routine. Takeshi, however, just sets up a simple slot F
interrupt.

This may explain why Takeshi seems to get differing results depending on
whether or not an Ethernet card is installed.

Further, I wonder if setting up a slot C interrupt for the PB 150/190 IDE
controller is incorrect and we should just check the WDC status on every
Nubus interrupt. Unfortunately, I don't have the hardware to check that one.

> The interrupt for IDE must be ACKed on the device itself, as those via
> registers are read-only, but I'm sure you guys know that, since you've
> been doing NuBus interrupts a lot longer than I have.

Should be okay.
 
> Note that I don't speak for Apple on this, and I'm just going by
> comments in the MkLinux source code, which were based on vague
> recollections of what I'd actually found, which may or may not be
> correct.  Given the slight hardware differences between the Q630 and the
> Performa 6214, you may or may not experience the same issues, etc.  Use
> this information at your own risk.  YMMV, AOSTCA, NAIAA, SRMA, SSFD.

It explains some discrepancies in the various pieces of code.

BTW, what do AOSTCA, et al. mean? I recognize YMMV, but that's it.

<<<john>>>