On Fri, Apr 29, 2016 at 2:03 AM, Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
> On Thursday 28 April 2016 11:34:38 Andy Lutomirski wrote:
>> On 04/28/2016 03:23 AM, Mika Westerberg wrote:
>> >Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
>> >PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:
>> >
>> > Device (SBUS)
>> > {
>> > OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
>> > Field (SMBI, ByteAcc, NoLock, Preserve)
>> > {
>> > HSTS, 8,
>> > Offset (0x02),
>> > HCON, 8,
>> > HCOM, 8,
>> > TXSA, 8,
>> > DAT0, 8,
>> > DAT1, 8,
>> > HBDR, 8,
>> > PECR, 8,
>> > RXSA, 8,
>> > SDAT, 16
>> > }
>> >
>> >There are also bunch of ASL methods that that the BIOS can use to access
>> >these fields. Most of the systems in question ASL methods accessing the
>> >SMBI OpRegion are never used.
>> >
>> >Now, because of this SMBI OpRegion many systems fail to load the SMBus
>> >driver with an error looking like one below:
>> >
>> > ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F
>> > conflicts with OpRegion 0x0000000000003040-0x000000000000304F
>> > (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255)
>> > ACPI: If an ACPI driver is available for this device, you should use
>> > it instead of the native driver
>> >
>> >The reason is that this SMBI OpRegion conflicts with the PCI BAR used by
>> >the SMBus driver.
>> >
>> >It turns out that we can install a custom SystemIO address space handler
>> >for the SMBus device to intercept all accesses through that OpRegion. This
>> >allows us to share the PCI BAR with the ASL code if it for some reason is
>> >using it. We do not expect that this OpRegion handler will ever be called
>> >but if it is we print a warning and execute the read/write operation under
>> >a lock which prevents ASL and OS from messing each other.
>>
>> Tested-by: Andy Lutomirski <luto@xxxxxxxxxx> # Dell XPS 13 9350
>>
>> This successfully works around:
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=110041
>>
>> but the BIOS people should still fix their ASL. Sigh.
>>
>> On the Dell laptop, the observable effect is that the driver loads and finds
>> the iTCO thing.
>>
>> Pali, this may be considerably more useful on your laptop.
>
> Andy, I am right that I will be able to load i2c-i801.ko driver without
> acpi_enforce_resources=lax parameter?
Yes, and it works on my laptop.
>
> If yes, then it sounds good! Finally I would be able to bind
> lis3lv02d_i2c.ko driver for accelerometer which is on my E6440 machine.
>
> Andy, is there any way to tell i2c-i801.ko driver that on i2c bus (which
> that driver exports) is present some i2c device? Months ago I got list
> of Latitude machines on which i2c address is that accelerometer present.
>
> It is possible to hardcode that mapping (DMI name of laptop --> i2c
> address) into dell-laptop driver, so i2c-i801.ko and lis3lv02d_i2c.ko
> will be automatically loaded and lis3l binded correctly to i801 i2c address?
I don't know how this part works, but I doubt that doing it in
dell-laptop will be convenient. After all, dell-laptop can load
before i2c-i801.
Jean and Wolfram: is there a quirk mechanism to add i2c devices that
aren't directly enumerable but are known to exist due to DMI?
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
