Multiple dec2114x units on ppc

gregory.menke at gsfc.nasa.gov gregory.menke at gsfc.nasa.gov
Wed Feb 26 04:54:20 UTC 2003


Till Straumann writes:
 > gregory.menke at gsfc.nasa.gov wrote:
 > > Till Straumann writes:
 > >  > Gregory.
 > >  > 
 > >  > First of all: could you append a copy of the dec2114x driver
 > >  > including your modifications?
 > > 
 > > Sure, see below.
 > > 
 > 
 > Hmm - forgive me a few comments:
 > 
 > 1) regarding your problem, I can't see how you connect to PCI irq 8
 >     (unless you somehow program the card's INTERRUPT_LINE prior to
 >     using the driver).
 > 
 >     It looks more like by default, PCI irq 10 is used for the second
 >     device (which should actually be OK if the card is indeed pulling
 >     INTC).

The onboard 21140 - unit 1 - is set by the firmware for INTERRUPT_LINE
10 and so falls through and works OK.  The cpci cards have
INTERRUPT_LINE = 255, and since I'm only working with 1 cpci card
(unit 2) right now, I then set whatever interrupt name I want to test.
This works- enough to test at least.  I'm defering all other
improvements until the vectoring is working.



 > 
 > 2) I suppose your application has a correct IF configuration for
 >     your second interface - your IF is brought up at some point,
 >     right? I assume you see the detection messages of both devices.

Yes.


 > 
 > 3) I particularly dislike (sorry) that you moved parts of the
 >     hardware initialization to the 'on()' handler (albeit the
 >     comment suggesting you should do so - it probably referred
 >     only to writing CSR7). Please undo this modification
 >     (see 4 why).
 > 
 > 4) In spite of the wrappers etc. the mods. do _not_ implement
 >     support for multiple devices correctly.
 >     This is actually a _very_ good example why having the
 >     'on'/'off' handlers in the API is a BAD BAD idea.

Well, OK- but I was following the comments.  I'll move it back since I
really dislike the wrappers too.  I know what you mean by the irq
sharing, I was waiting for the vectoring issue to get straightened out
before making the irq sharing more correct- that way I can do it from
a working configuration.  As it stands the onboard 21140 is still
working fine.

I'm not in the least religious about the irq api- in fact I really
don't care one bit about it- as long as it does what is necessary and
then gets out of the way.  I am prepared to tweak the rest of the
driver to better support a shared irq model once the vectoring is
working.

 > 
 > 
 > NOTE: since the BSP doesn't implement true IRQ sharing,
 >        you run into trouble as soon as different PCI
 >        devices (i.e. a dec2114x and some other device)
 >        share a common IRQ line.

It looks like managing the cpci vectoring in some kind of organized
way will be quite a pain.  It makes me almost want to defer it to the
user- if they want cpci devices, they must supply INTERRUPT_PIN and
INTERRUPT_LINE(for translation to interrupt name) for each device
they're going to use.  Its not pretty, but it would keep things
simpler.

 > Hope this is not too intrusive ;-)
 > 

Not at all, and many thanks!

Gregm




More information about the users mailing list