console on POWER4 not working with 2.6.15
Milton Miller
miltonm at bga.com
Thu Dec 22 07:21:08 EST 2005
On Thu Dec 22 04:56:28 EST 2005, Olaf Hering wrote:
> I finally managed to find the culprit.
>
> good: 25635c71e44111a6bd48f342e144e2fc02d0a314
> bad: f9bd170a87948a9e077149b70fb192c563770fdf
>
> ...
> powerpc: Merge i8259.c into arch/powerpc/sysdev
>
> This changes the parameters for i8259_init so that it takes two
> parameters: a physical address for generating an interrupt
> acknowledge cycle, and an interrupt number offset. i8259_init
> now sets the irq_desc[] for its interrupts; all the callers
> were doing this, and that code is gone now. This also defines
> a CONFIG_PPC_I8259 symbol to select i8259.o for inclusion, and
> makes the platforms that need it select that symbol.
...
> PCI: Probing PCI hardware
> +Failed to request PCI IO region on PCI domain 0000
That caught my eye.
It turns out that xics calls the 8259 init at arch_initcall before the
pci has probed the first bus. The ppc64 version did not request the
resources it was using, but the combined version picked this up from
the ppc side.
If we defer the 8259 init to subsys_initcall, or even look for it after
we setup the first io resource from the pci code, it may solve this
problem.
I noticed the commit did not touch xics.c. Looking further I see that
the move of the 8259 irq_desc setup code into i8259_init undoes the
combined xics_8259_pic descriptors.
Perhaps this should be made more like the mpic code?
Just detect the cascade, call the cascaded irq controller, eoi, and
return?
From there I think xics_mask_and_ack can disappear or become empty.
Also, is there a reason we are not looking for a intack pci bridge
property?
Ok enough for someone on vacation.
milton
More information about the Linuxppc64-dev
mailing list