All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
* Re: Re: "OpenPIC versus EPIC" in MPC8240 !
@ 2001-11-07 14:11 Sarnath  Kannan
  2001-11-11 23:56 ` ashish anand
  0 siblings, 1 reply; 4+ messages in thread
From: Sarnath  Kannan @ 2001-11-07 14:11 UTC (permalink / raw
  To: Dan Malek; +Cc: linuxppc-embedded


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: "OpenPIC versus EPIC" in MPC8240 !
  2001-11-07 14:11 Re: "OpenPIC versus EPIC" in MPC8240 ! Sarnath  Kannan
@ 2001-11-11 23:56 ` ashish anand
  0 siblings, 0 replies; 4+ 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] 4+ messages in thread

* Re: Re: "OpenPIC versus EPIC" in MPC8240 !
@ 2001-11-12  8:41 Sarnath  Kannan
  0 siblings, 0 replies; 4+ messages in thread
From: Sarnath  Kannan @ 2001-11-12  8:41 UTC (permalink / raw
  To: ashish anand; +Cc: linuxppc-embedded


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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Re: "OpenPIC versus EPIC" in MPC8240 !
@ 2001-11-13  4:00 Sarnath  Kannan
  0 siblings, 0 replies; 4+ messages in thread
From: Sarnath  Kannan @ 2001-11-13  4:00 UTC (permalink / raw
  To: Dan Malek; +Cc: linuxppc-embedded


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-11-13  4:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-11-07 14:11 Re: "OpenPIC versus EPIC" in MPC8240 ! Sarnath  Kannan
2001-11-11 23:56 ` ashish anand
  -- strict thread matches above, loose matches on Subject: below --
2001-11-12  8:41 Sarnath  Kannan
2001-11-13  4:00 Sarnath  Kannan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.