Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1390828 > unrolled thread

Re: OpRegion conflicts for Skylake LPSS

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: OpRegion conflicts for Skylake LPSS Ben Gamari <ben@smart-cactus.org> - 2016-04-29 09:40 +0200
    Re: OpRegion conflicts for Skylake LPSS Mika Westerberg <mika.westerberg@linux.intel.com> - 2016-04-29 09:50 +0200
      Re: OpRegion conflicts for Skylake LPSS Ben Gamari <ben@smart-cactus.org> - 2016-05-01 00:50 +0200
        Re: OpRegion conflicts for Skylake LPSS Mika Westerberg <mika.westerberg@linux.intel.com> - 2016-05-02 12:40 +0200

#1390828 — Re: OpRegion conflicts for Skylake LPSS

[Multipart message — attachments visible in raw view] — view raw

Ben Gamari <ben@smart-cactus.org> writes:

> [ Unknown signature status ]
> Mika Westerberg <mika.westerberg@linux.intel.com> 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.

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?

Cheers,

- Ben

[toc] | [next] | [standalone]

#1390833

On Fri, Apr 29, 2016 at 09:30:27AM +0200, Ben Gamari wrote:
> Ben Gamari <ben@smart-cactus.org> writes:
> 
> > [ Unknown signature status ]
> > Mika Westerberg <mika.westerberg@linux.intel.com> 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.

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.

> 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.

[toc] | [prev] | [next] | [standalone]

#1391715

[Multipart message — attachments visible in raw view] — view raw

Mika Westerberg <mika.westerberg@linux.intel.com> writes:

> On Fri, Apr 29, 2016 at 09:30:27AM +0200, Ben Gamari wrote:
>> Ben Gamari <ben@smart-cactus.org> writes:
>> 
>> > [ Unknown signature status ]
>> > Mika Westerberg <mika.westerberg@linux.intel.com> 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.

>> 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.

Cheers,

- Ben

[toc] | [prev] | [next] | [standalone]

#1392111

On Sun, May 01, 2016 at 12:47:58AM +0200, Ben Gamari wrote:
> Mika Westerberg <mika.westerberg@linux.intel.com> writes:
> 
> > On Fri, Apr 29, 2016 at 09:30:27AM +0200, Ben Gamari wrote:
> >> Ben Gamari <ben@smart-cactus.org> writes:
> >> 
> >> > [ Unknown signature status ]
> >> > Mika Westerberg <mika.westerberg@linux.intel.com> 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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web