more multiple dec21140 on ppc <fixed>

[Till Straumann]

gregory.menke at gsfc.nasa.gov wrote:
> 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?

Sounds reasonable to me - the only suggestion would be the
introduction of a BSP - specific translation INTERRUPT_LINE <-> name
(which could be as simple as adding BSP_PCI_IRQ_LOWEST_OFFSET)

-- Till

PS: Hope you saw the other message: the openpic_init() bug
has already been fixed (a while ago) and AFAIK, the fix
has made it into the trees (although not yet into 20030128).
Sorry, I had completely forgotten about that possibility :-(

> 
> See you,
> 
> Gregm
>