On Sun, May 01, 2016 at 12:47:58AM +0200, Ben Gamari wrote: > Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> writes: > > > On Fri, Apr 29, 2016 at 09:30:27AM +0200, Ben Gamari wrote: > >> Ben Gamari <ben@xxxxxxxxxxxxxxxx> writes: > >> > >> > [ Unknown signature status ] > >> > Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> writes: > >> > > >> >> On Tue, Apr 26, 2016 at 02:44:13AM +0200, Ben Gamari wrote: > >> >>> > >> > snip > >> > > >> >>> It looks very much like these are describing the same device. Perhaps > >> >>> the lpss driver should be binding to this ACPI node? Or perhaps this is > >> >>> a firmware issue? Any guidance would be greatly appreciated. > >> >> > >> >> Can you send me full acpidump of that machine? > >> > > >> > It can be found at > >> > https://github.com/bgamari/dell-e7470-dsdt/blob/master/acpi.log. > >> > > >> Did this provide any insight? Let me know if more information would be > >> helpful. > > > > Sorry about the delay. > > > No worries. > > > The GEXP device is most probably a GPIO expander that is connected to > > one of the I2C buses. And it indeed looks to use directly the I2C host > > controller registers so kernel rightfully complains about that. > > > > Are you able to run Windows on that machine? If yes, it would be nice to > > know if the INT3446 I2C device is shown in the device manager. > > > I had the original SSD that came with the machine with the original > Windows 7 installation intact. I popped it in and found no such device. > I then updated to Windows 10 (albeit still booting with the legacy BIOS, > not EFI) and found that once again there is no such device shown in > device manager. That's what I would expect. ACPI spec says that if there is an OpRegion touching the same registers than PCI device the OS should not load any driver for that device. I guess this is exactly what Windows does. Linux does it also but it in addition it issues a scary warning which might get users thinking there is something wrong with their system. > >> Also, is there a way to simply allow the driver subsystem to allow > >> probing to proceed despite this resource conflict so that I can resume > >> debugging my original input device issue? > > > > Try to pass "acpi_enforce_resources=lax" in the kernel command line. > > Thanks, indeed this allows the driver to load. Unfortunately it didn't > take long to encounter further issues. > > The motivation for all of this is to get the touchpad into I2C mode, since > currently it is merely exposed as a simple PS/2 device. Unfortunately it > seems that even Windows 10 doesn't use the touchpad's I2C mode (although > I suppose it's possible that this is guarded on UEFI boot; moreover > Windows appears to have proper support for configurating this touchpad > in PS/2 mode, which is unfortunately an ALPS devices). > > Looking at the DSDT it seems that enabling the I2C interface may require > the help of the embedded controller, the state of which is exposed in > the DSDT through a mysteriously-named SDS1 field. It looks like this > field could take on a number of values which identify a variety of > different touchpads. Given that it looks like GPIO pin states may be > determined by the value of this field I'm a bit reluctant to go fiddling > around with it. > > I do wish that firmware weren't such a nightmare. +1 -- 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
