Re: CVS commit: src/sys/dev/acpi

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

Paul Goyette wrote:
> On Fri, 4 Dec 2009, Quentin Garnier wrote:
> 
>>> IMO, very few devices should attach at acpi, but autoconfiguration
>>> should use ACPI data, when it is available, for the "direct"
>>> configuration of devices that we would otherwise have to probe for.
>>
>> Was there ever a disagreement on that?
> 
> Well, one place where this might not work is for ACPI-accessible i2c
> busses!  The acpi code might well be manipulating the bus without
> obeying any i2c_acquire_bus() locking mechanism implemented in the
> "native" pci-based drivers, with unpredictable results.  (Consider the
> case where an acpitz might be using an i2c-connected sensor...)

For this case, the ACPI driver gives the BIOS a chance to handle mutex
access SMBus in OS runtime. The purpose of ACPI CMI is to coordinate
access to the SMBus controller between OSPM and SMI. Bad things will
happen if the EC tries to read the fan speed at the same time that you
do, for example.

Further, the ACPI PCI driver has to be linked with the native PCI driver
to coordinate this i2c bus locking between the drivers.

This is a point where I am not sure if the ACPI PCI devices should be
attached before or after the native PCI drivers attached.


>> I fail to see how the API that was just committed will not result in a
>> #if NACPI > 0 block every time it is used.
> 
> Yeah, and that would be, ahem, ugly.

Side-note: This has been changed to #if NACPICA > 0

If the whole file depends on 'acpi' in files.acpi it already
belongs to the acpi context and #if NACPICA > 0 blocks make no sense to me.

Files outside of sys/dev/acpi using ACPI code should generally have
#if NACPICA > 0 blocks.

Further, jmcneill@ stated earlier he does not want to see any acpi code
in sys/dev/pci/


Christoph - who wonder's why this discussion started after commit
instead of after presenting the patch on tech-kern.