See patch
Am 11.03.2009 18:35, schrieb Stefan Reinauer:
See patch
Acked-by: Patrick Georgi patrick.georgi@coresystems.de
Just a question. Why?
(There is for example comple smbus IO and I dont know why, also I dont like it because it will collide with kernel driver)
Maybe would be better to have ACPI minimalistic, but usable.
Rudolf
Just a question. Why?
(There is for example comple smbus IO and I dont know why, also I dont like it because it will collide with kernel driver)
We might be working on other i945 based systems that might require those functions for enhanced features of the hardware.
I'll gladly disable the SMBus driver for now if there is trouble with it. It didn't seem to cause any trouble on our test systems?
Maybe would be better to have ACPI minimalistic, but usable.
Which parts are not usable?
Stefan
Stefan Reinauer wrote:
Maybe would be better to have ACPI minimalistic, but usable.
Which parts are not usable?
I think the intention was "the bare minimum" - as it stands that ACPI implementation is a bit, eh, fat.
I have to say it's the most readable ASL I've seen though.
Some of the fat could go into mainboard specific ASL rather than have everything in the chipset dirs. But maybe that's a bad idea? It does go against my idea of keeping code out of the mainboard dir..
Dunno..
//Peter
On 12.03.2009 18:41 Uhr, Peter Stuge wrote:
Stefan Reinauer wrote:
Maybe would be better to have ACPI minimalistic, but usable.
Which parts are not usable?
I think the intention was "the bare minimum" - as it stands that ACPI implementation is a bit, eh, fat.
Again. Which parts? What's fat? How would you solve things differently? Without wiping features that upcoming ports _are_ going to use?
Some analysis shows: - AMD serengeti cheetah has 1500 lines of mainboard specific code and 330 lines of chipset specific code. - Kontron 986LCD-M has 1800 lines of southbridge specific code, 400 lines of northbridge specific code and 500 lines of mainboard specific code.
So the mainboard specific stuff is 1/3 of that of a typical K8/K10 mainboard. Is that really too fat? The whole implementation is 50% bigger than the one on K8/K10 in lines of code.
It does a lot more, too. The final thing is going to do PCIe hotplug, laptop brightness control, vga output switching, etc.
I'm very willing to work with you guys on making this appealing to everyone. But your comments have not been extraordinarily helpful so far, I'm very sorry to say that.
I have to say it's the most readable ASL I've seen though.
Some of the fat could go into mainboard specific ASL rather than have everything in the chipset dirs. But maybe that's a bad idea?
The opposite. Some of the mainboard stuff actually needs to go to the component directories (like superio)
I don't think it makes much sense to go from a nice and modular implementation to a spaghetti code all duplicate mainboard centered one to safe 20 bytes of asl on a platform that might not necessarily need it.
It does go against my idea of keeping code out of the mainboard dir..
Absolutely. The mainboard directory should be selecting and configuring components and be otherwise empty.
Am 12.03.2009 18:41, schrieb Peter Stuge:
Some of the fat could go into mainboard specific ASL rather than have everything in the chipset dirs. But maybe that's a bad idea? It does go against my idea of keeping code out of the mainboard dir..
I decided the positions of some of the files. As a rule, I put everything that _could_ be generic into the chipset directories under the assumption, that it's more likely that if there's something mainboard specific, it will still be moved to the mainboard. Whereas, if the stuff resides in the mainboard directory, a new user will merely copy&edit it, instead of factoring out common parts into chipset directories.
I'm not sure that everything is where it belongs to (in fact, I'm rather sure some things are not), but this direction of movements is far more likely than the other.
Regards, Patrick Georgi
-
Patrick Georgi -
Patrick Georgi -
Peter Stuge -
Rudolf Marek -
Stefan Reinauer