more multiple dec21140 on ppc <fixed>

[gregory.menke at gsfc.nasa.gov]

Valette Eric writes:
 > gregory.menke at gsfc.nasa.gov wrote:
 > > gregory.menke at gsfc.nasa.gov writes:
 > >  > 
 > >  >  > gregory.menke at gsfc.nasa.gov writes:
 > >  >  >  > 
 > >  >  >  > Till Straumann writes:
 > >  >  >  >  > gregory.menke at gsfc.nasa.gov wrote:
 > >  >  >  >  > > (sorry Till, I sent a copy to to alone by accident...)
 > >  >  >  >  > > 
 > >  >  >  >  > > 
 > >  >  >  >  > > I'm still working on it and have little more to report except that its
 > >  >  >  >  > > increasingly looking like something isn't quite configured right in
 > >  >  >  >  > > MPIC or the PBC.  
 > >  >  >  >  > > 
 > >  >  >  >  > > Shifting the onboard dec to MPIC irq 2 (which its supposed to be wired
 > >  >  >  >  > > to) causes it to stop receiving interrupts (and I am changing its
 > >  >  >  >  > > INTERRUPT_LINE value to 2, with name = 18).  I've only been able to
 > >  >  >  >  > > make the onboard dec operate under its ISA irq 10.
 > >  >  >  >  > > 
 > >  >  >  >  > 
 > >  >  >  >  > Hmm - I cannot reproduce your problem on my mvme2306 board.
 > >  >  >  >  > Here's what works (with both, the original dec21140.c and the
 > >  >  >  >  > modified version you sent me a couple of days ago) on my board:
 > >  >  >  > 
 > >  > 
 > >  > Till, now I understand what you mean by not wanting a struct sockaddr
 > >  > for interrupts, I just learned about the pci swizzle...  I agree with
 > >  > you.
 > >  > 
 > >  > If I have the onboard ethernet on ISA 10, and the cpci board vectored
 > >  > for service on all 4 cpci interrupt lines, with the onboard ethernet
 > >  > pinging continuously, I will sometimes see MPIC irq 11 asserts.  It
 > >  > seems like something is stopping the MPIC from receiving/servicing the
 > >  > interrupts, possibly unless MPIC irq 0 is coincidentally being
 > >  > signalled.  I wonder if it might be a subtle inservice/ack problem...
 > >  > 
 > > 
 > > 
 > > The problem was the polarities and senses arguments to openpic_init
 > > were reversed.  This apparently doesn't interfere with MPIC irq 0, but
 > > on the ppc it appears to mess up the other irq's.  Perhaps the
 > > different openpic on Till's vme board handles the situation enough
 > > differently so the bug is masked.  I've confirmed this by successfully
 > > running the onboard ethernet on mpic irq 2.
 > 
 > This might well be board dependend. I even think that I have had two 
 > different MCP750 board revision with different incompatible polarity for 
 > IDE. I was forced to test the revision and change the setting depending 
 > on the board revision to run linux...
 > 
 > One was booting and the other just loop asserting the interrupt always 
 > looking the bott while the same binary was working fine on the other 
 > board...

I've seen some IDE strangeness on mcp750's as well.  In our case, we
cannot boot with the root filesystem on an IDE on any of our 4 750
units running 2.4.19.  Though once booted, all of them use the IDE
just fine.  We have to either use a scsi or nfs root.  The nfs case is
accidentally beneficial for driver developers because when the machine
locks, theres no filesystem check on restart- which is nice.

Maybe when I get some time I'll have a look at the isr setup code.


Till, if I've not bored you to death with this thread- I have a
nominally working shared IRQ arrangement for the dec driver.  Right
now it operatesb both the onboard and cpci dec units.  In both cases
it will use interrupt_line as the interrupt name if supplied or it
will derive the interrupt name from the bus and device #'s if not,
sort of like how Linux does.  I have confirmed operation by
simultaneously pinging the onboard and cpci interfaces, and moving the
cpci board between slots- its working fine.  The code does not support
any drivers other than the dec21140 and does not offer any interrupt
sharing services to the rest of RTEMS.

All dec units hooked to the same interrupt name share it, and are
polled for service at interrupt-time.  Units on different lines are
serviced completely independently.  The next step is to consolidate
the rx/tx threads, perhaps one pair per interrupt line being used by
dec boards, but thats enough for this week.

This is probably enough to roll with to support multiple dec units on
the 750 and I think its probably quite adapable to the x86 and/or
other platforms that use it.  I think there may be some board
dependent irq routing for the name discovery code, but that could
probably be ifdef'ed without horrible problems.

Do you think this is a reasonable approach pending the introduction of
the generic irq management code?

See you,

Gregm