[PATCH 6/9] MPIC MSI allocator

[Michael Ellerman]

On Wed, 2006-12-13 at 12:23 -0600, Olof Johansson wrote:
> On Wed, 13 Dec 2006 21:40:03 +1100 Michael Ellerman <michael at ellerman.id.au> wrote:
> 
> > To support MSI on MPIC we need a way to reserve and allocate hardware irq
> > numbers, this patch implements an allocator for that. It looks like we'll
> > end up with several backends based on the MPIC, so the allocator is attached
> > to the struct mpic, not the msi backend.
> > 
> > Signed-off-by: Michael Ellerman <michael at ellerman.id.au>
> 
> > +static void mpic_msi_auto_reserve_hwirqs(struct mpic *mpic)
> > +{
> > +	irq_hw_number_t hwirq;
> > +	struct irq_host_ops *ops = mpic->irqhost->ops;
> > +	struct device_node *np;
> > +	int flags, index, i;
> > +	struct of_irq oirq;
> > +
> > +	/* Reserve source numbers we know are reserved in the HW */
> 
> How do we know? Reserved on what HW? Sure looks system/platform
> dependent to me.

I agree. It's a fall-back position, we first check for the
"msi-available" property, and if that's not there we try to guess. New
firmwares should define "msi-available", but we don't want to wait for
that to happen, if it really bothers you we could have a
CONFIG_MPIC_MSI_DODGY_ALLOCATOR_GUESSING_ENABLE :)

So 0-7, 42-45 and 100-104 are known to be reserved on various revisions
of MPIC (and if there's more we can add them), and then we go through
the whole device tree and reserve anything that's already got an irq
mapped.

> 
> > +	for (i = 0;   i < 8;   i++)
> > +		__mpic_msi_reserve_hwirq(mpic, i);
> > +	for (i = 42;  i < 26;  i++)
>              ^^^^^^^^^^^^^^^
> 
> Is this some sort of check to see if we're awake? :)

Hehe. No it's proof that I wasn't awake when I wrote it, that's late
night hacking for you :)

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20061214/c3b5e6c6/attachment.pgp>