On Wed, May 16, 2012 at 04:46:57PM +0300, Gleb Natapov wrote: > On Tue, May 15, 2012 at 07:18:10PM -0400, Kevin O'Connor wrote: > > As in the other recent discussion, a struct can be built by the BIOS > > and a pointer passed in via a dynamic SSDT (eg, BDAT). Whatever data > > is needed can then be passed in via that struct. > > > I saw that, but I don't get why doing it this way instead of defining > the object in AML and patching it? I can define Name(S4VL, 0x2) and path > 0x2 to whatever QEMU wants me to use, or I can patch Package directly > like I did.
If it has to be patched anyway (eg, to remove _S3 definition) then, yes, might as well do the whole thing via patching. > > Why? Just put the definitions in ssdp_pcihp.dsl instead of > > acpi-dsdt.dsl - there's no real difference. > Fine by me. I verified and Windows/Linux can cope with _Sx definitions > being in SSDT. If we a going to move all the code that needs patching to > this file may we should rename it to something like ssdp_dynamic.dsl? Agreed. BTW, what's the background to the requirement to configure the Sx sleep levels? As we've discussed some time back, I'm leery of building custom QEMU->SeaBIOS interfaces just so SeaBIOS can then reencode into ACPI for the OS. > > The QEMU_CFG_FILE_DIR is just a list of "names" and "sizes" for each > > "port". There's no fundamental limitation to the interface. If QEMU > > has a limit, we should just fix that. > > > Each time Seabios wants to read a file it need to iterate over all/most > existing files. Yes. I'd like to change this in SeaBIOS by caching the "romfile" entries. It would actually simplify the code. >I can understand advantage of using files for code that > is shared between coreboot and qemu since files is what real HW uses, > but for QEMU internal code it is just overhead for the sake of it. The real benefit to using QEMU_CFG_FILE_DIR is that we can get at the size of the data in a standard way. Without that, each new data item has to have its own fw_cfg reading code which is just a waste. >I do > not have strong fillings about this issue. If you think that files is > the only way forward may be you should communicate this to QEMU and put > a comment in hw/fw_cfg.h explaining that and increasing FW_CFG_FILE_SLOTS > to some ridiculously large value. I've been meaning to build a qemu patch that puts all fw_cfg entries in QEMU_CFG_FILE_DIR. (There's no harm in making names for the existing hard-coded fw_cfg "ports".) Unfortunately, I haven't gotten around to it. :-( -Kevin