(unknown)

(unknown)

[Peter Denison]

Following the change to strict ACPI resource checking, I'm getting error 
messages about the i2c_i801 driver conflicting:

[    5.892659] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
[    5.892711] ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG [0x400-0x40f]
[    5.892755] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

Clearly the resource checking is the right way to go, so I started to 
investigate an ACPI-capable driver for the i801 I2C bus. The i2c-scmi 
driver looks plausible, but doesn't work immediately. (Note that the 
asus_atk0110 driver works fine for the sensors via ACPI, but there are 
other devices on the I2C bus e.g. DIMM SPDs)

The ACPI tables on this box (ASUS P5K-E) don't have a defined EC, or any 
device with PNP0C09, ACPI0001 or ACPI0005 HIDs. They do however, define 
the SMRG region and a series of methods to access the I2C bus.

I'd like some recommendation for the best approach:

a) Tweak the DSDT for myself to provide a device which will conform to a 
standard, then use a standard driver. Obviously not a very palatable 
solution for others.

b) Some form of automatic fixup when the ACPI tables are parsed, although 
the method names appear a little arbitrary - it's not simply a case of a 
missing _HID.

c) Forget about it, use acpi_enforce_resources=lax, and just hope I never 
get an unlocked race (not preferred!)

d) Something else I clearly haven't thought of (most likely)

Clearly the ACPI tables lacking the bus device is a problem fairly 
particular to this hardware, and the fix is likely to be targetted, but 
I'd like to make it as universal as possible. If I can get an ACPI driver 
working, and fix this for more than just myself, then brilliant.

-- 
Peter Denison <peterd at marshadder dot org>

Re: ACPI: If an ACPI driver is available for this device, you should use it instead of the native drive

[Len Brown]

On Mon, 16 Aug 2010, Peter Denison wrote:

> Following the change to strict ACPI resource checking, I'm getting error
> messages about the i2c_i801 driver conflicting:
> 
> [    5.892659] i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) ->
> IRQ 18
> [    5.892711] ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with
> ACPI region SMRG [0x400-0x40f]
> [    5.892755] ACPI: If an ACPI driver is available for this device, you
> should use it instead of the native driver
> 
> Clearly the resource checking is the right way to go, so I started to
> investigate an ACPI-capable driver for the i801 I2C bus. The i2c-scmi driver
> looks plausible, but doesn't work immediately. (Note that the asus_atk0110
> driver works fine for the sensors via ACPI, but there are other devices on the
> I2C bus e.g. DIMM SPDs)
> 
> The ACPI tables on this box (ASUS P5K-E) don't have a defined EC, or any
> device with PNP0C09, ACPI0001 or ACPI0005 HIDs. They do however, define the
> SMRG region and a series of methods to access the I2C bus.
> 
> I'd like some recommendation for the best approach:
> 
> a) Tweak the DSDT for myself to provide a device which will conform to a
> standard, then use a standard driver. Obviously not a very palatable solution
> for others.

Avoid hacking a DSDT except for debugging,
because it is a 'solution' that can neither
scale, nor be properly supported.

> b) Some form of automatic fixup when the ACPI tables are parsed, although the
> method names appear a little arbitrary - it's not simply a case of a missing
> _HID.

Conceivable in a platform driver to recognize vendor specific AML,
but in the generic ACPI code, no way.

> c) Forget about it, use acpi_enforce_resources=lax, and just hope I never get
> an unlocked race (not preferred!)

Quite possibly it is safe on this box.
Unfortunately, it is not only un-safe in general, but when it is unsafe
the consequences can be severe.

> d) Something else I clearly haven't thought of (most likely)
> 
> Clearly the ACPI tables lacking the bus device is a problem fairly particular
> to this hardware, and the fix is likely to be targetted, but I'd like to make
> it as universal as possible. If I can get an ACPI driver working, and fix this
> for more than just myself, then brilliant.

cheers,
Len Brown, Intel Open Source Technology Center