On Mon, Sep 30, 2019 at 12:13:14PM +0200, Cédric Le Goater wrote:
> On 30/09/2019 08:14, David Gibson wrote:
> > On Mon, Sep 30, 2019 at 07:28:45AM +0200, Cédric Le Goater wrote:
> >> On 30/09/2019 03:49, David Gibson wrote:
> >>> On Fri, Sep 27, 2019 at 12:16:49PM +0200, Greg Kurz wrote:
> >>>> On Fri, 27 Sep 2019 15:50:16 +1000
> >>>> David Gibson <da...@gibson.dropbear.id.au> wrote:
> >>>>
> >>>>> This method essentially represents code which belongs to the interrupt
> >>>>> controller, but needs to be called on all possible intcs, rather than
> >>>>> just the currently active one. The "dual" version therefore calls
> >>>>> into the xics and xive versions confusingly.
> >>>>>
> >>>>> Handle this more directly, by making it instead a method on the intc
> >>>>> backend, and always calling it on every backend that exists.
> >>>>>
> >>>>> While we're there, streamline the error reporting a bit.
> >>>>>
> >>>>> Signed-off-by: David Gibson <da...@gibson.dropbear.id.au>
> >>> [snip]
> >>>>> @@ -525,6 +469,30 @@ static void spapr_irq_check(SpaprMachineState
> >>>>> *spapr, Error **errp)
> >>>>> /*
> >>>>> * sPAPR IRQ frontend routines for devices
> >>>>> */
> >>>>> +int spapr_irq_cpu_intc_create(SpaprMachineState *spapr,
> >>>>> + PowerPCCPU *cpu, Error **errp)
> >>>>> +{
> >>>>> + if (spapr->xive) {
> >>>>> + SpaprInterruptController *intc = SPAPR_INTC(spapr->xive);
> >>>>> + SpaprInterruptControllerClass *sicc =
> >>>>> SPAPR_INTC_GET_CLASS(intc);
> >>>>> +
> >>>>> + if (sicc->cpu_intc_create(intc, cpu, errp) < 0) {
> >>>>> + return -1;
> >>>>> + }
> >>>>> + }
> >>>>> +
> >>>>> + if (spapr->ics) {
> >>>>> + SpaprInterruptController *intc = SPAPR_INTC(spapr->ics);
> >>>>> + SpaprInterruptControllerClass *sicc =
> >>>>> SPAPR_INTC_GET_CLASS(intc);
> >>>>> +
> >>>>> + if (sicc->cpu_intc_create(intc, cpu, errp) < 0) {
> >>>>> + return -1;
> >>>>> + }
> >>>>> + }
> >>>>> +
> >>>>
> >>>> Instead of these hooks, what about open-coding
> >>>> spapr_xive_cpu_intc_create()
> >>>> and xics_spapr_cpu_intc_create() directly here, like you already did for
> >>>> the
> >>>> ICS and the XIVE objects in spapr_irq_init() ?
> >>>
> >>> I'd prefer not to. The idea is I want to treat this as basically:
> >>>
> >>> foreach_possible_intc(intc)
> >>> intc::cpu_intc_create(...)
> >>>
> >>> If I find time I might indeed replace the explicit ics and xive
> >>> pointers with just an array of SpaprInterruptController *.
> >>
> >> Or you could use object_child_foreach() and check for the type. If we had
> >> a helper object_child_foreach_type(), we could use it elsewhere.
> >
> > I thought about that, but I don't think it quite works. The
> > complication is that the xics device is made explicitly a child of the
> > machine, but the xive device has mmio, so it's a SusBusDevice sitting
> > on the root bus instead.
>
> PnvXscom works fine with Devices and SysBusDevices.
Uh... what's an example of it working with a SysBusDevice? All the
implementors of PNV_XSCOM_INTERFACE I could find were instantiated
with object_initialize_child() making them explicitly children of the
chip. The SPAPR_XIVE is instantiated with qdev_create(NULL,
TYPE_SPAPR_XIVE), making it a child of the root bus, not the machine,
I believe.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
