On Saturday 30 April 2016 02:56:14 Andy Lutomirski wrote:
> On Fri, Apr 29, 2016 at 2:42 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx>
> wrote:
> > 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.
>
> i2c_probe_optional_slaves may be a more appropriate place to put
> this.
>
> Also, is there any indication in your DSDT that this thing exists?
No :-( There is nothing which can tell us presence of accelerometer.
Dell people told me that on Latitude machines E6540, E6440, E6440 ATG,
E5250, E5450 and E5550 is accelerometer present on 0x29 address. So
there is no other way than hardcode those DMI strings and do manual
configuration...
Maybe it should go into dell-smo8800.ko driver. That one is ACPI and
from DSDT provides IRQ number (issued when laptop. fall)...
So maybe, we can guess, when SMO ACPI device is present there is
accelerometer on i2c bus, but we do not know exact address...
--
Pali Rohár
pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
