From: "Mark A. Greer" <mgreer@mvista.com>
To: Dag Nygren <dag@newtech.fi>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: EPIC Vs OpenPIC (RFC)
Date: Fri, 02 Nov 2001 15:35:26 -0700 [thread overview]
Message-ID: <3BE31FAE.32941913@mvista.com> (raw)
In-Reply-To: 20011102201747.17244.qmail@dag.newtech.fi
Dag Nygren wrote:
> > Sarnath, Dag, Andrew,
> >
> > What I think you guys are discovering is an artifact of the inadequate
> > interface to openpic_init()--its wider than just a 8259/107 problem. This has
> > been discussed before and some ideas kick around.
> >
> > Since you guys seem to have the time & motivation, why don't you go back &
> > check out the mail archives for that/those discussion(s). If you like what
> > was talked about there, go with it or come up with a better solution and post
> > it here for everyone to comment on. It would be really nice to have a more
> > flexible interface to openpic_init(), et. al.
>
> Would something like this be sufficient/good as interface ?:
>
> typedef enum irq_level_en
> {OP_IRQ_HIGH=1,
> OP_IRQ_LOW=0}
> irq_level_type;
>
> typedef enum irq_enable_en
> {OP_IRQ_ON=1,
> OP_IRQ_OFF=0}
> irq_enable_type;
>
> typedef struct openpic_irq_def_str {
> u_int PICIrq;
> u_int LinuxIrq;
> u_char Priority;
> irq_level_type IrqLevel;
> irq_enable_type IrqEnable;
> } openpic_irq_def;
>
> typedef struct openpic_def_str {
> struct OpenPIC *OpenPIC_Addr;
> int main_pic;
> u_char RegOffset; /* 0 for "standard", 16 for MPC107 */
> char *chrp_ack;
> int programmer_switch_irq; /* Not really needed with the
> Priority/IRQ poss. */
> openpic_irq_def *IRQdef;
> } openpic_def;
>
> extern void openpic_init(*openpic_def);
>
> If so, I could try to implement it in the current open_pic.c
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.
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)??
Doesn't the new struct eliminate the need for "RegOffset"? And as you noted,
"programmer_switch_irq" probably isn't needed either. Right?
If you're up to it, how about implementing, testing, then posting a patch for
everyone to check out??
Mark
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2001-11-02 22:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-02 15:25 Re: EPIC Vs OpenPIC Vs MontaVista Sarnath Kannan
2001-11-02 17:41 ` Mark A. Greer
2001-11-02 20:17 ` EPIC Vs OpenPIC (RFC) Dag Nygren
2001-11-02 22:35 ` Mark A. Greer [this message]
2001-11-03 6:51 ` Dag Nygren
-- strict thread matches above, loose matches on Subject: below --
2001-11-04 10:45 Sarnath Kannan
2001-11-04 14:27 ` Dag Nygren
2001-11-04 14:45 Sarnath Kannan
2001-11-04 15:02 ` Dag Nygren
2001-11-04 15:06 ` Dag Nygren
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=3BE31FAE.32941913@mvista.com \
--to=mgreer@mvista.com \
--cc=dag@newtech.fi \
--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).