On Mon, Sep 26, 2011 at 08:04:24PM -0400, Kevin O'Connor wrote:
On Mon, Sep 26, 2011 at 10:04:13AM +0300, Michael S. Tsirkin wrote:
On Mon, Sep 26, 2011 at 12:40:18AM -0400, Kevin O'Connor wrote:
On Thu, Sep 22, 2011 at 09:09:49AM +0300, Michael S. Tsirkin wrote:
On Thu, Sep 22, 2011 at 12:35:13AM -0400, Kevin O'Connor wrote:
The code to generate basic SSDT code isn't that difficult (see build_ssdt and src/ssdt-proc.dsl). Is there a compelling reason to patch the DSDT versus just generating the necessary blocks in an SSDT?
I don't really care whether the code is in DSDT or SSDT, IMO there isn't much difference between build_ssdt and patching: main reason is build_ssdt uses offsets hardcoded to a specific binary (ssdt_proc and SD_OFFSET_* ) while I used a script to extract offsets.
Yes - your script to extract the offsets is nice.
If you still have doubts, it might make sense to merge just patch 1 - acpi: generate and parse mixed asl/aml listing
- as the first step.
With the infrastructure in place it will be easier to discuss the best way to use it.
I'm okay with your first patch.
BTW, any more comments with the rest of the patchset? If you just need to think about it, I understand.
However, I wish to tag a release before committing ACPI changes.
Sure. So you'll take this patchset from here or want me to ping you later?
There was a concern raised with two-pass PCI initialization that I need to follow up on before tagging.
The isa bridge? I thought that got fixed ...
-Kevin