cvs commit: src/usr.sbin/acpi/acpidump acpi.c acpidump.c acpidump.h

[Nate Lawson]

Takanori Watanabe wrote:
> In message <416329F0.3060301 at root.org>, Nate Lawson $B$5$s$$$o$/(B:
> 
>>This request is for the SSDT.  Our requirements are:
>>
>>1. Leave default table
>>2. Override with a new one
>>3. Ignore the table (pretend it doesn't exist)
>>
>>The last one isn't possible with the current API.  I've hacked up 
>>similar functionality by returning a no-op SSDT in 
>>AcpiOsTableOverride().  But this isn't an ideal solution.
>>
>>Thanks,
>>Nate
> 
> First of all, is that true that all SSDT's are always loaded 
> automatically?

Yes, all tables are loaded automatically, including the SSDTs.

> ACPI 3.0 Thermal model requires SSDT dynamic loading,it seems.
> (Section 11.6)

I haven't had time to read the 3.0 spec yet.  I'm sure ACPI-CA (and 
FreeBSD) will require a lot of updating to meet its new features like 
hotplug cpu, ram, etc.

> If so, it may cause trouble when all SSDT's and an original DSDT
> are compounded into a DSDT.

The only problem with the current approach is that SSDTs that appear 
dynamically will be ignored if the DSDT has been overridden.  Since 
neither ACPI-CA nor FreeBSD supports dynamic SSDTs yet and most device 
drivers don't support hotplug, this is not even close to being relevant yet.

The first thing to do is commit my ACPI hotplug patches that dynamically 
reprobe legacy devices, including ACPI devices like batteries and 
docking stations as well as legacy devices like ATA drives, floppy, etc. 
  The only problem is that the maintainers of device drivers will have 
to implement a way to get events to their children and associate their 
child device_t's with an ACPI_HANDLE.  For instance, I can't deliver a 
hotplug event to an ATAPI CDROM drive or floppy drive since they aren't 
associated with the ACPI namespace yet.  If you want to add that 
support, great.  It basically involves using ACPI_SCAN_CHILDREN() 
similar to sys/dev/fdc/fdc_acpi.c to associate handles with child 
devices and then handling device_probe/attach events for the child's 
device_t.

For instance, here is the device tree for my laptop, with *'s next to 
devices which don't yet have a device_t/ACPI_HANDLE association:

         Device (PCI0)
             Device (IDE0)
                 Device (PRIM)*
                     Device (MSTR)*
                 Device (SCND)*
                     Device (MSTR)*
             Device (PCI1)
                 Device (DOCK)
                     Device (IDE1)*
                         Device (PRIM)*
                             Device (MSTR)*
             Device (LPC)
                 Device (FDC)
                     Device (FDD0)* (needs to be added to fd ivars)

The hotplug patches call device_attach/detach on those handles when 
getting a notify that the device is going to be ejected.  The driver 
then just needs to handle that internally (similar to atacontrol detach, 
for instance.)

I won't be able to implement the device driver support but am happy to 
help anyone who wants to do so.  The hotplug patches can go in without 
device driver support but be a no-op for now for devices which aren't 
aware of it.

> I think ACPI-CA itself can override any SSDT by checking existing
> SSDT header passed to AcpiOsTableOverride.

I'm not sure what you mean here but I agree that AcpiOsTableOverride() 
should be able to decide whether to override an SSDT or not.  All I'm 
asking for is a special return code from AcpiOsTableOverride() that 
means "ignore this table completely" so I don't have to provide a fake 
empty table to get this effect.

-Nate