[coreboot] Resource allocation

Myles Watson mylesgw at gmail.com
Wed Nov 12 17:25:38 CET 2008

> -----Original Message-----
> From: coreboot-bounces at coreboot.org [mailto:coreboot-bounces at coreboot.org]
> On Behalf Of ron minnich
> Sent: Wednesday, November 12, 2008 9:12 AM
> To: Coreboot
> Subject: Re: [coreboot] Resource allocation
> On Wed, Nov 12, 2008 at 7:39 AM, Peter Stuge <peter at stuge.se> wrote:
> > Myles Watson wrote:
> >> Yes.  Instead of having each PNP device in the SuperIO be its own
> >> device in the dts,
> >
> > In which dts?
> >
> >
> >> there is just one ioport device.  That's why all of the PNP devices
> >> get created as dynamic devices.
> >
> > I would like the superio dts to express the hardware and have all
> > LDNs. For simplicity I think it makes sense to have a complete static
> > definition of superios in dts and not have to do any dynamic probing
> > of them in a chip that will never change anyway.
> >
> > The board dts must then say which of these LDNs are actually
> > implemented. alix1c has no parallell port for example, but has GPIOs.
> > Desktop boards have some other ports, but not GPIOs.
> >
> > Dynamic superio probing only makes any sense to me if it can be used
> > verbatim on each and every superio, which I don't think is the case..
> > Is that false?
> >
> yes, but having a single superio device structure in the static tree
> is what requires dynamic devices. We're not probing.
> We are actually just creating devices on demand. Those are two
> different things.
> Plus, the weird thing on a superio: even if you don't want a function
> (e.g. serial) it's important to make sure you turn certain pnp
> functions off in some cases --
> so you may want that pnp function controlled, even if you do not use it.
> Remember the rule: one dts -> one device.

I forgot the rule.  I'm down the path of creating static devices for each
PNP device. :(

> So we have one superio device. To create a real device for each of the
> superio pnp functions, the code does this:
> void pnp_enable_devices(struct device *base_dev, struct device_operations
> *ops,
>                         unsigned int functions, struct pnp_info *info)
> {
>         struct device_path path;
>         struct device_id id = {.type = DEVICE_ID_PNP };
>         struct device *dev;
>         int i;
>         path.type = DEVICE_PATH_PNP;
>         path.pnp.port = base_dev->path.pnp.port;
>         /* Setup the ops and resources on the newly allocated devices. */
>         for (i = 0; i < functions; i++) {
>                 path.pnp.device = info[i].function;
>                 dev = alloc_find_dev(base_dev->bus, &path, &id);
> so we get a new dynamic device for each pnp function.

Which has absolutely no knowledge of the dts.  We could, however, create an
initialization function that copies all of the information from the dts into
the specific device.  It just has to be done before resource allocation,
which means that pnp_enable_devices needs to be split and renamed.
> Making one device for each pnp function, we will need one dts for each
> pnp function. This is very easy to do, although it will be a bit of
> work. But now is the time to do it if we want to do it. I am not
> convinced we want to do it.

I have a generic pnp dts which has members io,irq,io2,irq2,drq

> I'd rather put the effort into getting the k8 to work, but I don't see
> how this is blocking the k8.

The problem is that since these resources don't get matched with the dts,
they don't get set to the right values.  The SuperIO doesn't get configured
at all correctly.  Since they are dynamic resources, the mess up the
resource allocation algorithm and make it so that the resources can't be

Although it is possible that something else is blocking k8, this seems like
a bad thing to me.  It will be a lot easier to see what's wrong with the
rest when this is fixed.


More information about the coreboot mailing list