* "OpenPIC versus EPIC" in MPC8240 !
@ 2001-11-01 10:13 Sarnath Kannan
2001-11-01 17:13 ` Dan Malek
0 siblings, 1 reply; 9+ messages in thread
From: Sarnath Kannan @ 2001-11-01 10:13 UTC (permalink / raw)
To: linuxppc-embedded
Dear reader,
I am trying to enable interrupts on the sandpoint X2
board hosting MPC8240, in Mode 1.
I decided to use OPenPIC code (openpic.c) for EPIC,
as the MPC8240 manual claims that EPIC is an OpenPIC standard. But I find some disparities between the way EPIC's registers are organised and the way OpenPIC data
structures are declared.( openpic_defs.h )
According the OpenPIC data structure,
"OpenPIC_Source" resides at offset 0x50000
whereas the EPIC ( section 11 of MPC8240 manual)
says the it resides at 0x50200 ( See page 11-5)
So, there is absolutely no gaurantee that
openPIC code would work for EPIC, Am i right ?
One more, If some1 could give me a clear picture
of interrupt routing on sandpoint board, it would
be very useful.
From what i read, I have understood the following
Please correct me if I am wrong.
1. The INTA ( used by Function 0 of Winbond -
PCI/ISA bridge) is connected to IRQ0 of EPIC.
2. The PCI interrupts (INTx) are connected to the
remaining PINs of EPIC in some order. ( I dont
know which order they are connected )
Any help would be appreciated. Meanwhile, I am
reading the sandpoint manual also..( This one, I add
inorder to avoid replies like "RTFM")
Thanks for any help guys
Sarnath
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "OpenPIC versus EPIC" in MPC8240 !
2001-11-01 10:13 Sarnath Kannan
@ 2001-11-01 17:13 ` Dan Malek
0 siblings, 0 replies; 9+ messages in thread
From: Dan Malek @ 2001-11-01 17:13 UTC (permalink / raw)
To: Sarnath Kannan; +Cc: linuxppc-embedded
Sarnath Kannan wrote:
> Dear reader,
> I am trying to enable interrupts on the sandpoint X2
> board hosting MPC8240, in Mode 1.
The Sandpoint interrupt structure for both X2 and X3 are supported
in the linuxppc kernel. The MPC107/EPIC are supported on other boards
as well. Due to the way Linux supports interrupts, only one Sandpoint
board interrupt mode is supported. Read the comments in
arch/ppc/kernel/sandpoint_setup.c for instructions.
There are many features of EPIC that are not currently supported using
the current OpenPIC functions, but it does work as a standard interrupt
controller on Sandpoint.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "OpenPIC versus EPIC" in MPC8240 !
2001-11-07 14:11 Sarnath Kannan
@ 2001-11-11 23:56 ` ashish anand
0 siblings, 0 replies; 9+ messages in thread
From: ashish anand @ 2001-11-11 23:56 UTC (permalink / raw)
To: Sarnath Kannan, linuxppc-embedded
Sarnath Kannan wrote:
sorry for jumping in between as i was out on long leave.
there is absoluetely no relation of bogus interrupts
with "openpic_init" is populating reserved memory areas of EPIC.
even i agree "openpic_init" is populating reserved memory areas of EPIC may
need a second thought.
you should refrain from saying so firmly without tech. support for that.
Best Regards
Ashish
> Its not a "HACK" dan. Its a bug. Just verify
> the register layout of OpenPIC and EPIC. You
> will find that "openpic_init" is populating
> reserved memory areas of EPIC. No wonder, we get
> bogus interrupts. You can verify this in the code.
> Moreover Had the code really wanted seperation
> of vector spaces of OpenPIC and EPIC, it should have
> called "openpic_init" with
> "offset value = "NUM_8259_INTERRUPTS"
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "OpenPIC versus EPIC" in MPC8240 !
2001-11-12 8:41 Sarnath Kannan
@ 2001-11-12 16:41 ` Dan Malek
2001-11-12 16:51 ` Dag Nygren
0 siblings, 1 reply; 9+ messages in thread
From: Dan Malek @ 2001-11-12 16:41 UTC (permalink / raw)
To: Sarnath Kannan; +Cc: ashish anand, linuxppc-embedded
Sarnath Kannan wrote:
> Hi Ashish,
> what I felt was, populating reserved areas
> is a bug.
It's only a bug if we don't know we are doing this and
it is causing problems. We know we can do what we
are doing without trouble. I'm not trying to
justify this hack or claim it is the proper solution.
It just happens to work, allows us to take advantage of
existing software functions, and someday it may be changed.
When someone like you shows up and your only concern or
contribution is to fix this function, then do it. I don't
want to hear why you think someone else did it wrong or what
someone else should do to make it better. Just fix the damn
thing! When someone like me is trying to do hundreds of things
to get a board port done, using any existing code is exactly
what I'm going to do. For EPIC I could take advantage of a
bunch of existing code instead of discussing why it should
change, or rewriting and testing on a whole bunch of other platforms
that doesn't help me make progress. If you have the time to
rewirte and test it on _everything_ affected, go right ahead.
> I has said that this could be a __possible__
> cause for getting bogus interrupts. I would
> say there is 80% possibility.
You are just digging a deeper hole. Bugs are either 100% there
or not there at all. There isn't an 80% possibility of a bug.......
The _conditions_ under which a bug can appear are variable,
but a bug is a bug.
> Moreover if u can read the EPIC manual,
> u can notice that IVPR and SVPR both start
> at offset 0x50200. ( So the IVPR space is
> not a continous 24 entries. It is actually
> overalapped and discontinous )
If you actually _understood_ what you read, you would notice
this register space has different functions depending upon
the configuration of the EPIC and the design of the hardware
surrounding it. You will also notice that because of the way
we initialize and utilize the openpic and interrupt management
functions that we properly configure the interrupt source registers
for the board design.
> I have no idea of hurting people. But if a bug
> is pointed out, there is no harm in accepting it.
More importanly, you should do something constructive and fix it.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "OpenPIC versus EPIC" in MPC8240 !
2001-11-12 16:41 ` Dan Malek
@ 2001-11-12 16:51 ` Dag Nygren
2001-11-12 16:58 ` Dan Malek
0 siblings, 1 reply; 9+ messages in thread
From: Dag Nygren @ 2001-11-12 16:51 UTC (permalink / raw)
To: Dan Malek; +Cc: Sarnath Kannan, ashish anand, linuxppc-embedded, dag
> > I have no idea of hurting people. But if a bug
> > is pointed out, there is no harm in accepting it.
>
> More importanly, you should do something constructive and fix it.
I thiught I did that, but noone seems to be interested.. ;-)
Dag
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "OpenPIC versus EPIC" in MPC8240 !
2001-11-12 16:51 ` Dag Nygren
@ 2001-11-12 16:58 ` Dan Malek
2001-11-12 18:00 ` Dag Nygren
0 siblings, 1 reply; 9+ messages in thread
From: Dan Malek @ 2001-11-12 16:58 UTC (permalink / raw)
To: Dag Nygren; +Cc: Sarnath Kannan, ashish anand, linuxppc-embedded
Dag Nygren wrote:
> I thiught I did that, but noone seems to be interested.. ;-)
Yeah :-). I was hoping Paul or someone else would make a suggestion.
A few of us (and people more interested and affected by OpenPIC other
than me) had discussed some other, slightly more pleasing hacks.....
Right now I'm swamped with other projects, although I have some
Sandpoint work on my list and when I do that I will incorporate
what you have done.
Thanks.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "OpenPIC versus EPIC" in MPC8240 !
2001-11-12 16:58 ` Dan Malek
@ 2001-11-12 18:00 ` Dag Nygren
0 siblings, 0 replies; 9+ messages in thread
From: Dag Nygren @ 2001-11-12 18:00 UTC (permalink / raw)
To: Dan Malek
Cc: Dag Nygren, Sarnath Kannan, ashish anand, linuxppc-embedded, dag
> Dag Nygren wrote:
>
>
> > I thiught I did that, but noone seems to be interested.. ;-)
>
> Yeah :-). I was hoping Paul or someone else would make a suggestion.
> A few of us (and people more interested and affected by OpenPIC other
> than me) had discussed some other, slightly more pleasing hacks.....
> Right now I'm swamped with other projects, although I have some
> Sandpoint work on my list and when I do that I will incorporate
> what you have done.
>
> Thanks.
Thanks to you,
i know it is not perfect, but it certainly is better than the
current solution...
Dag
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "OpenPIC versus EPIC" in MPC8240 !
@ 2001-11-13 6:42 James F Dougherty
2001-11-13 7:17 ` Dag Nygren
0 siblings, 1 reply; 9+ messages in thread
From: James F Dougherty @ 2001-11-13 6:42 UTC (permalink / raw)
To: dan, dag, jfd; +Cc: sparc64, ashisha, linuxppc-embedded, dag
I've been watching this thread for quite some
time now. I spoke with Dan about adding some
changes to this code last summer. I ran into
some issues with OpenPIC as well on our MPC8240
platform.
If you guys would like to forward me your changes,
I can merge your changes into mine (or see if they
are relevant) and give you an interim release.
Might I ask, could you describe the architecture
of your MPC8240 IRQ mapping and IO devices?
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: "OpenPIC versus EPIC" in MPC8240 !
2001-11-13 6:42 "OpenPIC versus EPIC" in MPC8240 ! James F Dougherty
@ 2001-11-13 7:17 ` Dag Nygren
0 siblings, 0 replies; 9+ messages in thread
From: Dag Nygren @ 2001-11-13 7:17 UTC (permalink / raw)
To: James F Dougherty; +Cc: dan, dag, sparc64, ashisha, linuxppc-embedded, dag
>
> I've been watching this thread for quite some
> time now. I spoke with Dan about adding some
> changes to this code last summer. I ran into
> some issues with OpenPIC as well on our MPC8240
> platform.
>
>
> If you guys would like to forward me your changes,
> I can merge your changes into mine (or see if they
> are relevant) and give you an interim release.
>
> Might I ask, could you describe the architecture
> of your MPC8240 IRQ mapping and IO devices?
My changes doesn't specifically touch the MPC8240 code
but are included in my port for ths VG4-board.
This board uses a MPC107, which also is an EPIC.
The stuff was posted in this NG (and also linux-developers)
and I think you can find it there. If not give me another
mail , and I will send it to you.
What it does is really only changing the interface to
openpic_init() to something more versatile/generic/useful(?).
The interface structure could/should probably be further
abstracted to multilevel cascades (any of those out there ?)
as Dan sort of pointed out, but this is a start anyway.
The appropriate files for you from the port should be
the following:
openpic2.c and openpic2.h.
You could check the vg4_setup.c for an example of
how to use the interface.
Your mileage may vary, but it works perfectly on my board.
BRGDS
Dag
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2001-11-13 7:17 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-11-13 6:42 "OpenPIC versus EPIC" in MPC8240 ! James F Dougherty
2001-11-13 7:17 ` Dag Nygren
-- strict thread matches above, loose matches on Subject: below --
2001-11-12 8:41 Sarnath Kannan
2001-11-12 16:41 ` Dan Malek
2001-11-12 16:51 ` Dag Nygren
2001-11-12 16:58 ` Dan Malek
2001-11-12 18:00 ` Dag Nygren
2001-11-07 14:11 Sarnath Kannan
2001-11-11 23:56 ` ashish anand
2001-11-01 10:13 Sarnath Kannan
2001-11-01 17:13 ` Dan Malek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).