On Tue, Mar 14, 2000 at 02:36:42AM -0500, Nathan J. Williams wrote:

 > Spurred on my my recent success with USB on my pc164, I decided to
 > give it a whirl on a PWS500au I have access to - a genuine Deq machine
 > with USB[1]. 

It's worth noting that there are others ... the DS10 and DS20 also have
USB, and maybe the 264DP.

 > I first stumbled over the code in dec_550.c:dec_550_intr_map() that
 > punts mapping an interrupt for PCI bus 0 device 7 function *. I tried
 > changing that to not punt for function 3, the USB function. 
 > At this point I started really losing; the interrupt line from
 > pa_attach args had the totally unreasonable value 234 (though the
 > intr_pin was 1, which is okay).

...it's also worth noting that the same occurs on the DS10 and DS20.

 > I noticed that the SRM ISA configuration table had an entry for USB,
 > which seemed a trifle odd, as it's not a ISA device. It was listed [2]
 > with IRQ 10 and no other resources.

Hm.  It could very well be that the USB interrupt IS actually hooked up
to that ISA IRQ.  It could be very convenient to do so, as you point out,
since the USB controller is in the same package as the PCI-ISA bridge
and IDE controller (which has its interrupts wired to compatibility
mode).

 > I hacked up dec_550_inter_map() to use various other interrupt line
 > values (3, 2, 1, 0). I expected intersting stuff at 2, since there's
 > an offset of 8, giving 10, the value in the isacfg table. Instead, I
 > didn't get anything until 0 (the same value used by the on-board ethernet):

Right, well, Alpha interrupts don't quite work this way.  ISA IRQs are
not the same as PCI IRQs on the Alpha.  They don't live in the same
number space at all.

I suspect what we're really going to need here is an
ohci_machdep_compat_intr_establish(), much like the pciide driver uses.
It would be nice to be able to read the configured value from the isacfg
table, but I don't know how to do that.

 > * What's up with the interrupt line having a bad value? I'm wondering
 >   if SRM is just bypassing device 7, since it's mostly used in Digital
 >   Unix for the IDE controller, which has the wacky ISA-compat
 >   interrupts and I/O mapping. 

It could be that, or it could be encoded to indicate which ISA IRQ its
using.  Dunno for sure.

 > * If SRM is ignoring it, how should we (a) detect this and (b) pick
 >   another interrupt to use? I'm still unclear on why the interrupt
 >   lines 3, 2, and 1 failed, but I haven't yet gone into the guts of
 >   the interrupt controller, either. 

Well, like I said, PCI interrupts and ISA interrupts live in a completely
different space on the Alpha (at least, on most of them; notable exceptions
are the AXPpci33/Multia, AlphaStation 200/400, and Sable, which is just
*completely* alien :-).

 > 1. The D/UX 4.0 USB support seems pretty superficial - it probes the
 >    controller, but nothing else, and doesn't notice devices being
 >    plugged or unplugged.

What version of DUh 4?  4.0D?  Later?

 > tlp0 at pci0 dev 3 function 0: DECchip 21143 Ethernet, pass 3.0
 > dec_550_intr_map: about to map bus 0 dev 3 func 0 pin 1 line 0
 > tlp0: interrupting at dec 550 irq 8
 > tlp0: DEC , Ethernet address 08:00:2b:86:8d:a6
 > nsphy0 at tlp0 phy 5: DP83840 10/100 media interface, rev. 1
 > nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > tlp0: 10baseT, 10baseT-FDX, 10base2, 10base5

Oh cool.  I'd like very much to be able to test tlp driver changes on
this box :-)

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>