On Wed, Nov 12, 2008 at 11:46 AM, Peter Stuge <span dir="ltr"><<a href="mailto:peter@stuge.se">peter@stuge.se</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">ron minnich wrote:<br>
> > Dynamic superio probing only makes any sense to me if it can be used<br>
> > verbatim on each and every superio<br>
><br>
</div><div class="Ih2E3d">> yes, but having a single superio device structure in the static<br>
> tree is what requires dynamic devices. We're not probing.<br>
> We are actually just creating devices on demand. Those are two<br>
> different things.<br>
<br>
</div>Right. Who knows what should be demanded? I would like the mainboard<br>
dts to be the source.<br>
<div class="Ih2E3d"><br>
<br>
> Plus, the weird thing on a superio: even if you don't want a<br>
> function (e.g. serial) it's important to make sure you turn certain<br>
> pnp functions off in some cases --<br>
> so you may want that pnp function controlled, even if you do not<br>
> use it.<br>
<br>
</div>Yes, that's why I think all functions of the chip should be listed<br>
somewhere (superio dts) but the ones that actually are enabled<br>
somewhere else (mainboard dts)..<br>
<div class="Ih2E3d"><br>
<br>
> Remember the rule: one dts -> one device.<br>
<br>
</div>I tend to like one dts -> one chip. But as long as dtses can pull in<br>
other dtses we both win.<br>
<br>
<br>
..<br>
<div class="Ih2E3d">> so we get a new dynamic device for each pnp function.<br>
><br>
> Making one device for each pnp function, we will need one dts for<br>
> each pnp function. This is very easy to do, although it will be a<br>
> bit of work. But now is the time to do it if we want to do it. I am<br>
> not convinced we want to do it.<br>
<br>
</div>It will end up being a lot of files, which is a little clumsy. I'd<br>
like to roll it into one file..<br>
<br>
I guess we've gone back and forth on this. I guess dtc is the<br>
bottleneck because it only deals with one struct per input file?<br>
<div class="Ih2E3d"><br>
<br>
> I'd rather put the effort into getting the k8 to work,<br>
<br>
</div>Or GeodeLX, C7, or Core2. There's plenty of unfinished stuff in v3<br>
now. :) SCNR.</blockquote><div><br>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.<br>
<br>-Corey<br></div></div>