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