From: Grant Grundler <grundler@cup.hp.com>
To: parisc-linux@thepuffingroup.com
Subject: [parisc-linux] Thoughts on arch/parisc/irq.c
Date: Wed, 25 Aug 1999 17:49:54 -0700 [thread overview]
Message-ID: <199908260049.RAA11578@milano.cup.hp.com> (raw)
In-Reply-To: Your message of "Wed, 25 Aug 1999 14:15:47 PDT." <37C432D3.C9BC0D7F@thepuffingroup.com>
linux/arch/parisc/kernel/irq.c:irq_alloc()/request_irq() seems to be
the method to allocate EIRR bits and register ISRs with PA ext_intr
handler. Dino will call this to initialize it's own EIM register (IAR0).
But to program IAR0 Dino also needs the processor HPA of whatever
processor it is supposed to interrupt.
Is there an interface to return HPAs?
(BTW - anyone else modifying gecko/dino.c?)
Support for PCI 2.2 Message Signalled Interrupts requires
a similar interface - Dino can support this if the interface
were present and PCI drivers wanted to use it.
More thoughts on basic PA interrupt handling:
o Do GBD or other psuedo drivers need to reserve EIRR bits?
Ie soft interrupts to reschedule work at lower SPL levels.
o associating SPL levels to specific EIRR bits allows changing SPL
much faster. ie. if EIRR bit 1 is used for SPL2, then setting
bit 1 in the SPL5 bit mask to disable EIRR bit 1 from generating
an interrupt makes it very easy to change from SPL2 to SPL5.
Eg. SPLHI just disables all EIRR bits.
o PA2.0 architecture defines EIRR to be 64-bits wide.
irq_alloc() and request_irq() hard code 31.
Using a #define with "ifdef" around it for 32/64 bit
differences would be better. Just trying to make the
transition that direction easier.
o Each processor can have it's own EIRR switch table.
Thus, "irq_action[]" could be an an array hanging off a per processor
data structure. This is interesting for large configurations where
the 31 bits aren't enough and sharing isn't supported.
o EIRR bits can be shared just like IRQ lines. A wrapper gets
put into the irq_action[] field when sharing is required
(eg run out of EIRR bits to hand out). The wrapper function
simple calls all ISR's registered for a given EIRR bit.
This can be ignored for now since A-class/712/715 etc
configurations probably won't need this.
grant
Grant Grundler
Communications Infrastructure Computer Operations
+1.408.447.7253
next parent reply other threads:[~1999-08-26 0:47 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <37C432D3.C9BC0D7F@thepuffingroup.com>
1999-08-26 0:49 ` Grant Grundler [this message]
1999-08-26 1:16 ` [parisc-linux] Thoughts on arch/parisc/irq.c Alan Cox
1999-08-26 2:13 ` Grant Grundler
1999-08-26 12:06 ` Alan Cox
1999-08-26 15:26 ` Philipp Rumpf
1999-08-26 16:43 ` LaMont Jones
1999-08-26 17:13 ` Grant Grundler
1999-08-26 17:48 ` Alex deVries
1999-08-26 18:12 ` Philipp Rumpf
1999-08-26 15:16 ` Philipp Rumpf
[not found] <199908261629.JAA12121@milano.cup.hp.com>
1999-08-26 16:38 ` Alan Cox
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=199908260049.RAA11578@milano.cup.hp.com \
--to=grundler@cup.hp.com \
--cc=parisc-linux@thepuffingroup.com \
/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