On 6/12/07, ron minnich rminnich@gmail.com wrote:
On 6/7/07, Peter Stuge stuge-linuxbios@cdy.org wrote:
A device tree (not list) in code that
- is seeded by the mainboard dts, which lists all devices
- has device options set from defaults in device dts
- has device option overrides from mainboard dts
I have this almost done, just FYI.
it seems to work, but the error checking is incomplete.
But you can have something like this:
/{ north{ /config/("northbridge/intel/i440bxemulation"); }; };
The /config/ keyword (there has to be a better way to do keywords?) means: suck in northbridge/intel/i440bxemulation/dts. That file has a list of properties, well, currently only one: { dram = "no"; };
The "no" value for the dram property will provide a reasonable default if the dram property is not spec'ed. A mainboard value can override it. You probably want a number there.
The dtc generates the struct as described by the northbridge/intel/i440bxemulation/dts file: struct north { u32 dram; }; /*north*/ (i.e. this struct generation came ENTIRELY from the chip dts, and was emitted by the device tree compiler (dtc))
and, as it generates the initializations, you see this: struct north { .dram = {0|(0x6e<<24)|(0x6f<<16)|(0x00<<8)}, }; /*north*/
i.e. you only get u32's at present and, until we're sure we need something else, that's all you get. I hope people aren't going to start asking for types ...
So you can spec that a chip dts is to be used; that chip dts will cause a struct to be generated; the struct members in there can have a default value, set for that chip; and, the defaults can be over-ridden by mainboard settings.
Pretty much what we said we wanted, I think. But your Kconfig request is not in there, as supporting it will require: 1) dtc pass 2) kconfig pass 3) dtc pass again
I think.
The changes are backwards-compatible; current qemu target builds just fine.
Peter, is this it?
I can generate a patch if people want to look at the code. I admit it is rough, but gives us a starting point.
ron