Re: Re: "OpenPIC versus EPIC" in MPC8240 !

Re: Re: "OpenPIC versus EPIC" in MPC8240 !

[Sarnath Kannan]

> It's not magic, just a bad software hack.  We tell the
> openpic that it has interrupts from 16 to 32, not from
> zero.  OpenPIC interrupt 16 matches EPIC interrupt zero.
   16-32 ? NumSources of OpenPIC = 24. It should be
either (0-23) or (16-40). 16-32 is noWhere.

> The interrupts zero to 15 are given to the 8259.
> The problem with this method is we can't get to some
> of the other EPIC features, but we are discussing
> alternatives.
>
  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"

sarnath


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Re: "OpenPIC versus EPIC" in MPC8240 !

[Sarnath Kannan]

Hi Ashish,
  what I felt was, populating reserved areas
is a bug. Thats what I accentuated. Moreover
I has said that this could be a __possible__
cause for getting bogus interrupts. I would
say there is 80% possibility.
 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 )
 The EPIC manual clearly says "EPIC" is __adopted__
from OpenPIC specification . It never says it
conforms to the OpenPIC spec.
  I have no idea of hurting people. But if a bug
is pointed out, there is no harm in accepting it.

  lets put an end to this topic. I no more
want to discuss anything about this.

Good Luck
Sarnath


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dan Malek]

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/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dag Nygren]

> >   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/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dan Malek]

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/

Re: "OpenPIC versus EPIC" in MPC8240 !

[Dag Nygren]

> 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/

Re: Re: "OpenPIC versus EPIC" in MPC8240 !

[Sarnath Kannan]

> 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.
   Yeah fine Dan ! First time, I thought these
details were left out. But later only I realized
that these things have been foreseen and deliberately
taken advantage of.  I apologize for all the
trouble.

Sarnath


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/