[coreboot] Resource allocation

[ron minnich]

On Thu, Nov 13, 2008 at 6:03 AM, Myles Watson <mylesgw at gmail.com> wrote:

> I agree that having this in the w83627hf/dts would be better, but dtc
> doesn't support that, right?  The best case for me would be having all of
> the PNP structures in the SIO dts:

doesn't support what? A hierarchy? It will support what we want.

But how do you propose to modify properties in the dts as we do now?

example

here is the (shortened for brevity) winbond/w83627 dts:

/{
    keyboard { io0="0x62"; io2 = "0x64"; /* whatever*/
    };
};

And in the mainboard

ioport at 2e {
   /config/("superio/winbond/w83627hf/pnp.dts");
  keyboard/io0 = "0x44";
};

Would that work for everyone?

It still leaves other issues but ...



>
> then being able to say in the mainboard dts:
>
>> +                             ioport at 2e {
>> +
> /config/("superio/winbond/w83627hf/dts");
>> +                                     pnp at 2 {
>> +                                             enabled;
>> +                                     };
>> +                                     pnp at 5 { /*KBD*/
>> +                                             enabled;
>> +                                     };
>> +                                     pnp at 9 {
>> +                                             disabled;
>> +                                     };
>> +                                     pnp at a {
>> +                                             enabled;
>> +                                     };
>
>
> That makes it clear which devices get created (all the ones mentioned in the
> dts.)  Then the SIO code can take care of special cases like devices that
> need to be set even when they're disabled.

yes, but this is *exactly* the model that people are objecting to in
the other thread. We kind of need to make up our mind here.

>
> While I'm wishing I'd like to use pnp at W83627HF_KBC instead of pnp at 5 and have
> that just work.  I think it might not be too hard, but it's a syntax error
> now.  It would definitely reduce the chance for mistakes.

I would rather not do this.

> That's right.  The problem is that there needs to be some generic way to
> pass this information to the resource code.

This is actually not even v2, it's v1. It did not work because you
have resources in that struct that don't
exist on many devices, and there are always new devices with new
resource types that break the model.

> Right now it allocates a new
> device for each of the SuperIO PNP functions, so there are dynamic devices
> for all of them.  I think that there should only be dynamic devices for
> things that get plugged in.

I am still not convinced this really matters.

ron