On Fri, Apr 29, 2016 at 2:00 PM, Pali Rohár <pali.rohar@xxxxxxxxx> wrote:
> On Friday 29 April 2016 20:10:23 Andy Lutomirski wrote:
>> 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.
>
> Looks like it is working also 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?
>
> Maybe something like i2c_register_board_info()?
Maybe. i think that wants to be called before the adapter shows up, though.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
