On Wed, Nov 12, 2008 at 11:46 AM, Peter Stuge peter@stuge.se wrote:
ron minnich wrote:
Dynamic superio probing only makes any sense to me if it can be used verbatim on each and every superio
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.
Right. Who knows what should be demanded? I would like the mainboard dts to be the source.
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.
Yes, that's why I think all functions of the chip should be listed somewhere (superio dts) but the ones that actually are enabled somewhere else (mainboard dts)..
Remember the rule: one dts -> one device.
I tend to like one dts -> one chip. But as long as dtses can pull in other dtses we both win.
..
so we get a new dynamic device for each pnp function.
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.
It will end up being a lot of files, which is a little clumsy. I'd like to roll it into one file..
I guess we've gone back and forth on this. I guess dtc is the bottleneck because it only deals with one struct per input file?
I'd rather put the effort into getting the k8 to work,
Or GeodeLX, C7, or Core2. There's plenty of unfinished stuff in v3 now. :) SCNR.
C7 I'll be getting back to ASAP, I've got lots of other things on my plate right this moment though. It's mostly done, just needs a few more bugs tracked down and squashed. Also, for some reason, doing early_mtrr_init() like via epia-cn does in v3 completely breaks booting.
-Corey