linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Michal Ostrowski <mostrows@watson.ibm.com>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller.
Date: Tue, 30 May 2006 07:28:36 +1000	[thread overview]
Message-ID: <1148938117.5959.24.camel@localhost.localdomain> (raw)
In-Reply-To: <1148935262.25048.31.camel@brick>

On Mon, 2006-05-29 at 16:41 -0400, Michal Ostrowski wrote:
> The following set of patches is aimed at killing the
> ppc64_interrupt_controller global variable, and similarly that various
> global variables used to tweak the parameters of virtual IRQ re-mapping.
> Instead each platform can use a single function to configure IRQ
> re-mapping in "init_early()".

 .../...

Hi ! Interesting.. I've start looking at reworking that with a slightly
different approach though...

We need irq controller instances (which we get from the genirq patch
from Ingo & Thomas Gleixner), and we decided that interrupt controller
nodes are mandatory in the device-tree thus we can do something like:

- Each interrupt controller instance, when allocated, requests a certain
number of interrupts and gets that allocated (gets an offset allocated).
It can locally use the virtual irq remapping too, I'm still toying with
the best way to deal with that. This interrupt controller structure is
associated to the device-node of the controller (or the root node of the
tree if no controller node is found)

 - Interrupt 0..15 are reserved. 0 is always invalid. Only ISA PICs that
carry legacy devices can request those (by passing a special flag to the
allocation routine). Any other gets remapped (including powermac MPICs).
That will avoid endless problems that we never properly solved with
legacy drivers and the fact that Linus decided that 0 should be the
invalid interrupt number on all platforms

 - Provide in prom_parse.c functions for obtaining the PIC node and
local interrupt number of a given device based on a passed-in array
matching the semantics of an "interrupts" property and a parent node.
Along with a helper that may just take a child node. The former is
needed for PCI devices that have no device node. Provide a
pci_ppc_map_interrupt() that takes a pci_dev and does the interrupt
mapping, either by using the standard OF approach if a device-node is
present, or walking up the PCI tree while doing standard swizzling until
it reaches a device node

 - Mapping from a virtual number to a local number can be done by a
helper that does the offset and possible virq mapping if requested by
the controller. Same goes with inverse mapping. Mapping is done locally
by the controller code using that helper.

Ben.

  parent reply	other threads:[~2006-05-29 21:28 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-29 20:41 [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller Michal Ostrowski
2006-05-29 20:42 ` [PATCH 1/8] Formalize virtual-IRQ remapping configuration mostrows
2006-05-29 20:42 ` [PATCH 2/8] PIC discovery re-organization mostrows
2006-05-29 20:42 ` [PATCH 4/8] Avoid use of ppc64_interrupt_controller mostrows
2006-05-29 20:42 ` [PATCH 3/8] " mostrows
2006-05-29 20:42 ` [PATCH 8/8] Kill the ppc64_interrupt_controller global symbol mostrows
2006-05-29 20:42 ` [PATCH 7/8] Cleaner checks for MPIC on pSeries mostrows
2006-05-29 20:50   ` Olof Johansson
2006-05-29 20:42 ` [PATCH 6/8] Avoid use of ppc64_interrupt_controller mostrows
2006-05-29 20:42 ` [PATCH 5/8] " mostrows
2006-05-29 21:28 ` Benjamin Herrenschmidt [this message]
2006-05-29 23:08   ` [RFC/PATCH 0/8] Overhaul of virt IRQ configuration. / Kill ppc64_interrupt_controller Michal Ostrowski
2006-05-30 13:54   ` Michal Ostrowski
2006-05-30 22:13     ` Benjamin Herrenschmidt
2006-05-30 22:53       ` Michal Ostrowski
2006-05-30 23:10         ` Benjamin Herrenschmidt
2006-05-29 21:56 ` Paul Mackerras

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=1148938117.5959.24.camel@localhost.localdomain \
    --to=benh@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mostrows@watson.ibm.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;
as well as URLs for NNTP newsgroup(s).