qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure


From: Benjamin Herrenschmidt
Subject: Re: [Qemu-ppc] [PATCH v2 3/7] ppc/pnv: Add XSCOM infrastructure
Date: Mon, 05 Sep 2016 17:11:53 +1000

On Mon, 2016-09-05 at 13:39 +1000, David Gibson wrote:
> > +static XScomDevice *xscom_find_target(XScomState *s, uint32_t
> pcb_addr,
> > +                                      uint32_t *range)
> > +{
> > +    BusChild *bc;
> > +
> > +    QTAILQ_FOREACH(bc, &s->bus->bus.children, sibling) {
> > +        DeviceState *qd = bc->child;
> > +        XScomDevice *xd = XSCOM_DEVICE(qd);
> > +        unsigned int i;
> > +
> > +        for (i = 0; i < MAX_XSCOM_RANGES; i++) {
> > +            if (xd->ranges[i].addr <= pcb_addr &&
> > +                (xd->ranges[i].addr + xd->ranges[i].size) >
> pcb_addr) {
> > +                *range = i;
> > +                return xd;
> > +            }
> > +        }
> > +    }
> 
> Hmm.. you could set up a SCOM local address space using the
> infrastructure in memory.c, rather than doing your own dispatch.

There are pros and cons to this approach. The memory.c stuff comes with
quite a lot of baggage, not all of it very shinny to be honest ;-) I
still *hate* how it forces upon us a whole 128-bit integer arithmetic
library just so that it can represent 1_0000_0000_0000_0000 ... 

It would be make more sense to use inclusive start/end instead and
stick to 64-bits.

That being said, we could do that. We'd have to shift the XSCOM
addresses left by 3 since each address is an 8 bytes reigster and
forbid non-8-bytes accesses.

Ben.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]