From: "Sarnath Kannan" <sparc64@rediffmail.com>
To: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Re: EPIC Vs OpenPIC (RFC)
Date: 4 Nov 2001 10:45:14 -0000 [thread overview]
Message-ID: <20011104104514.19103.qmail@mailweb23.rediffmail.com> (raw)
Somehow I feel that Patching or changing
the openPIC code would make it shabby.
Why should we change open_pic code,
just because that EPIC is non-conforming ?
The best is to rewrite open_pic code for
EPIC. ( ofcourse, we can reuse code. )
I dont find anything wrong with open_pic
interface. If people dont follow standards,
we dont make standards comply with them. We
make them comply with standards.
Sarnath
On Sat, 03 Nov 2001 Dag Nygren wrote :
>
> > Mark A. Greer wrote:
> >
> >
> > This is along the lines that I was thinking except
> add a struct member to specify
> > whether edge or level sensitive--i.e., separate
> members for hi/lo and edge/level
>
> Actually this evolved after I posted it :-), after I
> started
> to modify open_pic.c
>
> > What exactly is the "IrqEnable" for? Is this so you
> can set up the IRQ but not
> > enable it? Then the driver can enable it later and
> its set up correctly (e.g.,
> > I2C)??
>
> Not really, it was more or less a mistake in the first
> draft. Would there be a
> need
> for that ?
>
> > Doesn't the new struct eliminate the need for
> "RegOffset"?
>
> Have to think about that when implementing the stuff.
>
> > And as you noted,
> > "programmer_switch_irq" probably isn't needed either.
> Right?
>
> Yep, and I also came up with another scheme for the
> cascading as the
> special handling for chrp is actually.....drum roll....
> a cascade!
> And it would remove the i8259 refs from the openpic
> stuff.
>
> > If you're up to it, how about implementing, testing,
> then posting a patch for
> > everyone to check out??
>
> I'm trying, but I am a bit scared of destroying too
> much of the open_pic
> code...
>
> Here is the newest suggestion for that interface:
>
> typedef enum irq_polarity_en {
> OP_IRQ_POS = 1,
> OP_IRQ_NEG = 0
> } irq_polarity_type;
>
> typedef enum irq_sense_en {
> OP_IRQ_LEVEL = 1,
> OP_IRQ_EDGE = 0
> } irq_sense_type;
>
> typedef struct op
PICIrq;
> u_int Vector;
> u_char Priority;
> irq_sense_type IrqSense;
> irq_polarity_type IrqPolarity;
> irq_polarity_type IrqPolarity;
> int (*CascadeHandler)();
> } openpic_irq_def;
>
> typedef struct openpic_def_str {
> struct OpenPIC *OpenPIC_Addr;
> int main_pic;
> u_char RegOffset; /* 0 for "standard", 16
> for MPC107 */
> int programmer_switch_irq;
> openpic_irq_def *IRQdef; /* The lovest vector
> first in the table !!! */
> } openpic_def;
>
> Comments?
>
>
> Dag
>
>
>
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next reply other threads:[~2001-11-04 10:45 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-04 10:45 Sarnath Kannan [this message]
2001-11-04 14:27 ` EPIC Vs OpenPIC (RFC) Dag Nygren
-- strict thread matches above, loose matches on Subject: below --
2001-11-04 14:45 Sarnath Kannan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20011104104514.19103.qmail@mailweb23.rediffmail.com \
--to=sparc64@rediffmail.com \
--cc=linuxppc-embedded@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).