Haswell systems & i801 i2c driver

Haswell systems & i801 i2c driver

[Prarit Bhargava]

When loading the i801 i2c bus driver on an i5-46xx CPU, and this chipset
http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/8-series-chipset-pch-datasheet.pdf

I see the following warning:

i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
ACPI: resource 0000:00:1f.3 [io  0xefa0-0xefbf] conflicts with ACPI region SMBI
[io 0xefa0-0xefaf]
ACPI: This conflict may cause random problems and system instability
ACPI: If an ACPI driver is available for this device, you should use it instead
of the native driver

It seems like the BIOS/ACPI defines a region, SMBI, which is defined for the
SMBus to use, but there is no ACPI driver available for the SMBus (at least
AFAICT).

I'm using "acpi_enforce_resources=lax" as a kernel parameter to work around
the issue but was wondering if there was a more robust fix planned for this
problem?  If not -- anyone want to point me in the right direction of a fix?

Thanks,

P.

Re: Haswell systems & i801 i2c driver

[Bjorn Helgaas]

[+cc Rafael, Matthew, linux-acpi]

Hi Prarit,

On Mon, Apr 7, 2014 at 12:00 PM, Prarit Bhargava <prarit-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> When loading the i801 i2c bus driver on an i5-46xx CPU, and this chipset
> http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/8-series-chipset-pch-datasheet.pdf
>
> I see the following warning:
>
> i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> ACPI: resource 0000:00:1f.3 [io  0xefa0-0xefbf] conflicts with ACPI region SMBI
> [io 0xefa0-0xefaf]
> ACPI: This conflict may cause random problems and system instability
> ACPI: If an ACPI driver is available for this device, you should use it instead
> of the native driver
>
> It seems like the BIOS/ACPI defines a region, SMBI, which is defined for the
> SMBus to use, but there is no ACPI driver available for the SMBus (at least
> AFAICT).

Is this on a production BIOS?  It seems like a BIOS bug to expose a
PCI device with resources that are used by ACPI.  The spec you pointed
to does mention an "SMBus Disable" bit (sec 10.1.54) that claims to
disable PCI config space for this device.  Maybe the BIOS forgot to
set that?

If we (the Linux PCI core) discovered this device (00:1f.3), we
believe we own it and can assign a driver to it and potentially change
the resources assigned to it.

Changing the [io  0xefa0-0xefbf] BAR would likely break the SMBI
opregion because the AML using it wouldn't know about the change.

Assigning a driver, e.g., i801_smbus, seems likely to cause conflicts
with the AML that uses the SMBI opregion.  These could be difficult to
reproduce and debug.

If this is on a shipping BIOS, we might need to figure out some way to
handle it.  I don't remember anything in the ACPI spec that talks
about issues like this, but maybe we should add something in PCI that
notices if there's an ACPI device with the same resources and marks
the PCI device to keep us from moving it or assigning a driver (maybe
the warning you're seeing already handles the driver part?)

Bjorn

Re: Haswell systems & i801 i2c driver

[Matthew Garrett]

> If this is on a shipping BIOS, we might need to figure out some way to
> handle it.  I don't remember anything in the ACPI spec that talks
> about issues like this, but maybe we should add something in PCI that
> notices if there's an ACPI device with the same resources and marks
> the PCI device to keep us from moving it or assigning a driver (maybe
> the warning you're seeing already handles the driver part?)

This is, sadly, pretty typical. SMBus devices are often exposed via PCI
even though they're accessed directly via AML. The current behaviour
seems about as good as it gets - we warn the user that this could cause
problems, and they can pass a kernel parameter that allows them to do it
anyway.

-- 
Matthew Garrett <matthew.garrett@nebula.com>

Re: Haswell systems & i801 i2c driver

[Jean Delvare]

On Mon, 7 Apr 2014 20:30:39 +0000, Matthew Garrett wrote:
> > If this is on a shipping BIOS, we might need to figure out some way to
> > handle it.  I don't remember anything in the ACPI spec that talks
> > about issues like this, but maybe we should add something in PCI that
> > notices if there's an ACPI device with the same resources and marks
> > the PCI device to keep us from moving it or assigning a driver (maybe
> > the warning you're seeing already handles the driver part?)
> 
> This is, sadly, pretty typical. SMBus devices are often exposed via PCI
> even though they're accessed directly via AML. The current behaviour
> seems about as good as it gets - we warn the user that this could cause
> problems, and they can pass a kernel parameter that allows them to do it
> anyway.

The proper way to handle it at the BIOS level is to expose the SMBus to
the OS by implementing the ACPI SMBus CMI as supported by the i2c-scmi
driver. Unfortunately most BIOS do not bother implementing that
interface, effectively locking the OS out of the SMBus controller and
everything behind it. This has been a major pain for years :(

-- 
Jean Delvare
SUSE L3 Support

Re: Haswell systems & i801 i2c driver

[Prarit Bhargava]

On 04/07/2014 04:56 PM, Jean Delvare wrote:
> On Mon, 7 Apr 2014 20:30:39 +0000, Matthew Garrett wrote:
>>> If this is on a shipping BIOS, we might need to figure out some way to
>>> handle it.  I don't remember anything in the ACPI spec that talks
>>> about issues like this, but maybe we should add something in PCI that
>>> notices if there's an ACPI device with the same resources and marks
>>> the PCI device to keep us from moving it or assigning a driver (maybe
>>> the warning you're seeing already handles the driver part?)
>>
>> This is, sadly, pretty typical. SMBus devices are often exposed via PCI
>> even though they're accessed directly via AML. The current behaviour
>> seems about as good as it gets - we warn the user that this could cause
>> problems, and they can pass a kernel parameter that allows them to do it
>> anyway.
> 
> The proper way to handle it at the BIOS level is to expose the SMBus to
> the OS by implementing the ACPI SMBus CMI as supported by the i2c-scmi
> driver. Unfortunately most BIOS do not bother implementing that
> interface, effectively locking the OS out of the SMBus controller and
> everything behind it. This has been a major pain for years :(

Hey Jean, Thanks for the info.

I'm about to RFC an algorithm patch for the i801 ACPI SBUS.  I dunno if it is
really a good thing to do outside of Intel or if we should wait for a CMI.  OTOH
it seems to work and your comment that "This has been a major pain for years"
worries me that we'll never see a solution.

P.
> 

RE: Haswell systems & i801 i2c driver

[Heasley, Seth]

Hi Prarit,

> When loading the i801 i2c bus driver on an i5-46xx CPU, and this chipset
> http://www.intel.com/content/dam/www/public/us/en/documents/datash
> eets/8-series-chipset-pch-datasheet.pdf
> 
> I see the following warning:
> 
> i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> ACPI: resource 0000:00:1f.3 [io  0xefa0-0xefbf] conflicts with ACPI region
> SMBI [io 0xefa0-0xefaf]
> ACPI: This conflict may cause random problems and system instability
> ACPI: If an ACPI driver is available for this device, you should use it instead of
> the native driver
> 
> It seems like the BIOS/ACPI defines a region, SMBI, which is defined for the
> SMBus to use, but there is no ACPI driver available for the SMBus (at least
> AFAICT).
> 
> I'm using "acpi_enforce_resources=lax" as a kernel parameter to work
> around the issue but was wondering if there was a more robust fix planned
> for this problem?  If not -- anyone want to point me in the right direction of a
> fix?

>From what I understand (mostly from Jean), this is a BIOS issue that we work around with the acpi_enforce_resources parameter.  So if you want to drive an actual fix for it, it'll need to be lobbed at BIOS folks.

Regards,
Seth