GPIO Driver for Skylake-Y PCH
Hi, I have a hardware platform with Skylake i7-6500 CPU and Skylake-Y PCH southbridge, running 4.8.5 kernel fc25. The platform has 12 GPIO pins, however, none are available. gpio-pch driver does not support D31:F2 device that manages GPIO. Am I missing something here? Cheers, --Alex
On Fri, 14 Jun 2019 10:58:53 -0700, "Alexander Ivanov" said:
I have a hardware platform with Skylake i7-6500 CPU and Skylake-Y PCH southbridge, running 4.8.5 kernel fc25. The platform has 12 GPIO pins, however, none are available. gpio-pch driver does not support D31:F2 device that manages GPIO.
Am I missing something here?
Well.. my copy of drivers/gpio/gpio-pch.c has this near line 440: static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, { 0, } }; MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id); Though I'm having a hard time aligning that with "D31:F2". Are you confusing a PCI address with a PCI ID, or is this on a non-PCI bus?
Valdis, Thanks for quick response! On Fri, 14 Jun 2019 11:46 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Fri, 14 Jun 2019 10:58:53 -0700, "Alexander Ivanov" said:
I have a hardware platform with Skylake i7-6500 CPU and Skylake-Y PCH southbridge, running 4.8.5 kernel fc25. The platform has 12 GPIO pins, however, none are available. gpio-pch driver does not support D31:F2 device that manages GPIO.
Am I missing something here?
Well.. my copy of drivers/gpio/gpio-pch.c has this near line 440:
static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, { 0, } }; MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id);
Though I'm having a hard time aligning that with "D31:F2". Are you confusing a PCI address with a PCI ID, or is this on a non-PCI bus?
No, I believe I am not. This borrowed from Intel doc (https://lab.whitequark.org/files/gpioke/Intel-332690-004EN.pdf, see Ch 2) It is a PCI device with 8086/9d20 IDs. --Alex ps. I apologize, I mistyped "D31:F2" it's supposed to be D31:F1.
On Fri, 14 Jun 2019 12:01:28 -0700, you said:
static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, { 0, } }; MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id);
It is a PCI device with 8086/9d20 IDs.
Give this patch a try, if it works I'll push it upstream for you... diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c index 1d99293096f2..19884b5b2a74 100644 --- a/drivers/gpio/gpio-pch.c +++ b/drivers/gpio/gpio-pch.c @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume); static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) },
On Fri, 14 Jun 2019 12:09 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Fri, 14 Jun 2019 12:01:28 -0700, you said:
static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, { 0, } }; MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id);
It is a PCI device with 8086/9d20 IDs.
Give this patch a try, if it works I'll push it upstream for you...
diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c index 1d99293096f2..19884b5b2a74 100644 --- a/drivers/gpio/gpio-pch.c +++ b/drivers/gpio/gpio-pch.c @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume);
static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) },
I did try this. It did not enumerate. There is one little detail. This device is hidden by default in motherboard FW. However, I manually un-hide it before trying to enumerate the device. gpio-pch driver's patched as you described, built out-of-tree and loaded. Then, I un-hide the device and rescan the bus: # echo 1 > /sys/bus/pcie/rescan On Fri, 14 Jun 2019 12:13 -07:00, Bjørn Mork <bjorn@mork.no> wrote:
"Valdis Klētnieks" <valdis.kletnieks@vt.edu> writes:
Though I'm having a hard time aligning that with "D31:F2". Are you confusing a PCI address with a PCI ID, or is this on a non-PCI bus?
"D31:F2" is device 31, function 2. We're used to see this as "1f.2".
The question is really: Is there such a device in the system? And if so: What's the ID? That's easy to find out:
lspci -vvvnns 0:1f.2
Device is indeed there: lspci -vvvnns 1f.1 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M] ps. I misstyped device address in my original post, it is supposed to be function 1 not 2: d31:f1.
On Fri, 14 Jun 2019 13:25 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote:
On Fri, 14 Jun 2019 12:09 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Fri, 14 Jun 2019 12:01:28 -0700, you said:
static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, { 0, } }; MODULE_DEVICE_TABLE(pci, pch_gpio_pcidev_id);
It is a PCI device with 8086/9d20 IDs.
Give this patch a try, if it works I'll push it upstream for you...
diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c index 1d99293096f2..19884b5b2a74 100644 --- a/drivers/gpio/gpio-pch.c +++ b/drivers/gpio/gpio-pch.c @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume);
static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) },
I did try this. It did not enumerate. There is one little detail. This device is hidden by default in motherboard FW. However, I manually un-hide it before trying to enumerate the device.
gpio-pch driver's patched as you described, built out-of-tree and loaded. Then, I un-hide the device and rescan the bus:
# echo 1 > /sys/bus/pcie/rescan
On Fri, 14 Jun 2019 12:13 -07:00, Bjørn Mork <bjorn@mork.no> wrote:
"Valdis Klētnieks" <valdis.kletnieks@vt.edu> writes:
Though I'm having a hard time aligning that with "D31:F2". Are you confusing a PCI address with a PCI ID, or is this on a non-PCI bus?
"D31:F2" is device 31, function 2. We're used to see this as "1f.2".
The question is really: Is there such a device in the system? And if so: What's the ID? That's easy to find out:
lspci -vvvnns 0:1f.2
Device is indeed there: lspci -vvvnns 1f.1 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M]
ps. I misstyped device address in my original post, it is supposed to be function 1 not 2: d31:f1.
gpio-pch depends on X86_32 || MIPS || COMPILE_TEST config GPIO_PCH tristate "Intel EG20T PCH/LAPIS Semiconductor IOH(ML7223/ML7831) GPIO" depends on X86_32 || MIPS || COMPILE_TEST select GENERIC_IRQ_CHIP the platform at hand, is not X86_32 nor MIPS. It means gpi-pch requires CONFIG_COMPILE_TEST (to compile drivers which wont load....). Sure enough, even when driver enumerates, it fails to map BAR: [ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12 Any suggestions on what driver (if any available) should be used instead?
"Alexander Ivanov" <amivanov@fastmail.com> writes:
Device is indeed there:
lspci -vvvnns 1f.1 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M]
ps. I misstyped device address in my original post, it is supposed to be function 1 not 2: d31:f1.
gpio-pch depends on X86_32 || MIPS || COMPILE_TEST
config GPIO_PCH tristate "Intel EG20T PCH/LAPIS Semiconductor IOH(ML7223/ML7831) GPIO" depends on X86_32 || MIPS || COMPILE_TEST select GENERIC_IRQ_CHIP
the platform at hand, is not X86_32 nor MIPS. It means gpi-pch requires CONFIG_COMPILE_TEST (to compile drivers which wont load....). Sure enough, even when driver enumerates, it fails to map BAR:
[ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12
This seems to be from an older kernel, but anyway: pch_gpio_probe() attempts to map BAR 1. Your device does not have any such resource. So it fails.
Any suggestions on what driver (if any available) should be used instead?
I wouldn't know. But I believe your device looks too different to be compatible with whatever devices this driver was made for. Bjørn
On Fri, 14 Jun 2019 15:40:59 -0700, "Alexander Ivanov" said: (Adding likely knowledgeable people to the recipients) Jean, Andy, Linus: The situation thus far: Alexander has a system with this GPIO on it:
lspci -vvvnns 1f.1 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M]
The obvious first thing to try was: diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c index 1d99293096f2..19884b5b2a74 100644 --- a/drivers/gpio/gpio-pch.c +++ b/drivers/gpio/gpio-pch.c @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume); static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) }, and that died thusly when attempted to load: [ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12 So obviously an older kernel. Not sure what release Alexander is on, but a 'git log' against this week's linux-next tree didn't show anything that was an obvious fix for a similar problem. Any ideas?
On Sat, 15 Jun 2019 12:31 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Fri, 14 Jun 2019 15:40:59 -0700, "Alexander Ivanov" said:
(Adding likely knowledgeable people to the recipients)
Jean, Andy, Linus: The situation thus far: Alexander has a system with this GPIO on it:
lspci -vvvnns 1f.1 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M]
The obvious first thing to try was:
diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c index 1d99293096f2..19884b5b2a74 100644 --- a/drivers/gpio/gpio-pch.c +++ b/drivers/gpio/gpio-pch.c @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume);
static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) },
and that died thusly when attempted to load:
[ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12
So obviously an older kernel. Not sure what release Alexander is on, but a 'git log' against this week's linux-next tree didn't show anything that was an obvious fix for a similar problem.
This is fedora 25 running 4.8.6 kernel.
Any ideas?
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Sat, Jun 15, 2019 at 12:38:34PM -0700, Alexander Ivanov wrote:
On Sat, 15 Jun 2019 12:31 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Fri, 14 Jun 2019 15:40:59 -0700, "Alexander Ivanov" said:
(Adding likely knowledgeable people to the recipients)
Jean, Andy, Linus: The situation thus far: Alexander has a system with this GPIO on it:
lspci -vvvnns 1f.1 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M]
The obvious first thing to try was:
diff --git a/drivers/gpio/gpio-pch.c b/drivers/gpio/gpio-pch.c index 1d99293096f2..19884b5b2a74 100644 --- a/drivers/gpio/gpio-pch.c +++ b/drivers/gpio/gpio-pch.c @@ -439,6 +439,7 @@ static SIMPLE_DEV_PM_OPS(pch_gpio_pm_ops, pch_gpio_suspend, pch_gpio_resume);
static const struct pci_device_id pch_gpio_pcidev_id[] = { { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x8803) }, + { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x9d20) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8014) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8043) }, { PCI_DEVICE(PCI_VENDOR_ID_ROHM, 0x8803) },
and that died thusly when attempted to load:
[ 105.965846] pci 0000:00:1f.1: [8086:9d20] type 00 class 0x058000 [ 105.965928] pci 0000:00:1f.1: reg 0x10: [mem 0xfd000000-0xfdffffff 64bit] [ 105.967084] pci 0000:00:1f.1: BAR 0: assigned [mem 0x7d000000-0x7dffffff 64bit] [ 105.978037] pch_gpio 0000:00:1f.1: pch_gpio_probe : pci_iomap FAILED [ 105.978194] pch_gpio 0000:00:1f.1: pch_gpio_probe Failed returns -12 [ 105.978317] pch_gpio: probe of 0000:00:1f.1 failed with error -12
So obviously an older kernel. Not sure what release Alexander is on, but a 'git log' against this week's linux-next tree didn't show anything that was an obvious fix for a similar problem.
This is fedora 25 running 4.8.6 kernel.
That kernel was released in October of 2016. Quite old and obsolete and totally and completely insecure. Please update to the latest version of Fedora. thanks, greg k-h
On Sat, 15 Jun 2019 12:38:34 -0700, "Alexander Ivanov" said:
This is fedora 25 running 4.8.6 kernel.
It probably won't fix the problem, but you should upgrade if at all possible. You're not getting any security patches for 25. 30 is the current release, with 31 due out fairly soon.
On Sat, 15 Jun 2019 18:50 -07:00, Valdis Klētnieks <valdis.kletnieks@vt.edu> wrote:
On Sat, 15 Jun 2019 12:38:34 -0700, "Alexander Ivanov" said:
This is fedora 25 running 4.8.6 kernel.
It probably won't fix the problem, but you should upgrade if at all possible. You're not getting any security patches for 25. 30 is the current release, with 31 due out fairly soon.
I know. However, it isn't up to me. We have hundreds such units and I heard about plans to upgrade to 30 'soon'. I'm going to give it a try with 30 on my development board, just out of curiosity. For the problem at hand though, I'd likely have to find an external GPIO board that can generate an interrupt on GPIO pin toggle. Anyway, thanks for trying to help.
"Alexander Ivanov" <amivanov@fastmail.com> writes:
We have hundreds such units and I heard about plans to upgrade to 30 'soon'.
Quite off-topic, but I just had to comment on such plans: Fedora is the wrong distro for you. You should be planning for RHEL instead. Or a similar stable distro. Fedora is a distro for those who don't need to plan the next upgrade, but just can (and will) do it whenever there is a new release. Bjørn
On Sat, Jun 15, 2019 at 03:30:24PM -0400, Valdis Klētnieks wrote:
On Fri, 14 Jun 2019 15:40:59 -0700, "Alexander Ivanov" said:
(Adding likely knowledgeable people to the recipients)
Jean, Andy, Linus: The situation thus far: Alexander has a system with this GPIO on it:
How come that this device is GPIO? I mean what makes you, guys, to come to this conclusion?
lspci -vvvnns 1f.1 00:1f.1 Memory controller [0580]: Intel Corporation Device [8086:9d20] (rev 21) Subsystem: Gigabyte Technology Co., Ltd Device [1458:1000] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Region 0: Memory at 7d000000 (64-bit, non-prefetchable) [size=16M]
The obvious first thing to try was:
...which is obviously wrong. See above. P.S. Agree with Greg that one must update kernel either to LTS or to latest supported one. -- With Best Regards, Andy Shevchenko
On Mon, 17 Jun 2019 09:39 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
How come that this device is GPIO? I mean what makes you, guys, to come to this conclusion?
Intel document 332996-002EN [1] chapter 28 says GPP_* groups are accessible through the PCH Sideband Interface, while 332690-004EN [2] defines P2SB at d31.f1 Obviously, I am wrong here. However, the question stands, is there linux kernel support for Intel PCH GPIO? [1] http://www.intel.cn/content/dam/www/public/us/en/documents/datasheets/6th-ge... [2] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/100-...
On Mon, Jun 17, 2019 at 05:00:54PM -0700, Alexander Ivanov wrote:
On Mon, 17 Jun 2019 09:39 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
How come that this device is GPIO? I mean what makes you, guys, to come to this conclusion?
Intel document 332996-002EN [1] chapter 28 says GPP_* groups are accessible through the PCH Sideband Interface, while 332690-004EN [2] defines P2SB at d31.f1
Obviously, I am wrong here. However, the question stands, is there linux kernel support for Intel PCH GPIO?
Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, the drivers for which are available under drivers/pinctrl/intel. What you are looking for is located under PINCTRL_SUNRISEPOINT configuration option.
[1] http://www.intel.cn/content/dam/www/public/us/en/documents/datasheets/6th-ge... [2] https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/100-...
-- With Best Regards, Andy Shevchenko
On Tue, 18 Jun 2019 11:40:34 +0300, Andy Shevchenko said:
Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, the drivers for which are available under drivers/pinctrl/intel. What you are looking for is located under PINCTRL_SUNRISEPOINT configuration option.
Thanks for the info, it's often unclear where to look - when the hardware has a PCH and documentation that says it has GPIO, and there's an in-tree driver called gpio_pch, it's easy to fail to look in the right place :)
On Tue, Jun 18, 2019 at 10:48:45AM -0400, Valdis Klētnieks wrote:
On Tue, 18 Jun 2019 11:40:34 +0300, Andy Shevchenko said:
Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, the drivers for which are available under drivers/pinctrl/intel. What you are looking for is located under PINCTRL_SUNRISEPOINT configuration option.
Thanks for the info, it's often unclear where to look - when the hardware has a PCH and documentation that says it has GPIO, and there's an in-tree driver called gpio_pch, it's easy to fail to look in the right place :)
Citing in-kernel documentation: --- 8< --- 8< ---- 8< --- Electrical properties of the pin such as biasing and drive strength may be placed at some pin-specific register in all cases or as part of the GPIO register in case (B) especially. This doesn't mean that such properties necessarily pertain to what the Linux kernel calls "GPIO". -- With Best Regards, Andy Shevchenko
On Tue, 18 Jun 2019 08:58 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
On Tue, Jun 18, 2019 at 10:48:45AM -0400, Valdis Klētnieks wrote:
On Tue, 18 Jun 2019 11:40:34 +0300, Andy Shevchenko said:
Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, the drivers for which are available under drivers/pinctrl/intel. What you are looking for is located under PINCTRL_SUNRISEPOINT configuration option.
Thanks for the info, it's often unclear where to look - when the hardware has a PCH and documentation that says it has GPIO, and there's an in-tree driver called gpio_pch, it's easy to fail to look in the right place :)
Thank you for the info, indeed. I'm going to give it a try.
Citing in-kernel documentation:
--- 8< --- 8< ---- 8< ---
Electrical properties of the pin such as biasing and drive strength may be placed at some pin-specific register in all cases or as part of the GPIO register in case (B) especially. This doesn't mean that such properties necessarily pertain to what the Linux kernel calls "GPIO".
Given the amount of related (and not so much) documentation, it's hard to miss. That's what this newsgroup for :) Thank you for helping!
On Tue, 18 Jun 2019 01:41 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
Obviously, I am wrong here. However, the question stands, is there linux kernel support for Intel PCH GPIO?
Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, the drivers for which are available under drivers/pinctrl/intel. What you are looking for is located under PINCTRL_SUNRISEPOINT configuration option.
My box is updated with current Fedora distro and now running 5.0.9-301.fc30.x86_64. It's also said that the box has Sunrisepoint chipset. For this chipset, 5.0.9 kernel support following devices: static const struct acpi_device_id spt_pinctrl_acpi_match[] = { { "INT344B", (kernel_ulong_t)&sptlp_soc_data }, { "INT345D", (kernel_ulong_t)&spth_soc_data }, { } }; [ https://elixir.bootlin.com/linux/v5.0.9/source/drivers/pinctrl/intel/pinctrl... ] I believe the box has INT344B device attached to acpi bus proper: $ sudo ls -la /sys/bus/acpi/devices/INT344* ... lrwxrwxrwx. 1 root root 0 Jun 20 11:47 /sys/bus/acpi/devices/INT344B:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT344B:00 Drivers seem loaded: $ lsmod | grep pin pinctrl_sunrisepoint 28672 0 pinctrl_intel 28672 1 pinctrl_sunrisepoint However, I don't see any gpio devices. $ ls /dev/gpio* ls: cannot access '/dev/gpio*': No such file or directory $ ls /sys/bus/gpio/devices/ $ What am I still missing?
On Thu, Jun 20, 2019 at 02:02:11PM -0700, Alexander Ivanov wrote:
On Tue, 18 Jun 2019 01:41 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
Obviously, I am wrong here. However, the question stands, is there linux kernel support for Intel PCH GPIO?
Yes. Most of the SoCs from Intel use GPIO IP based on Chassis specification, the drivers for which are available under drivers/pinctrl/intel. What you are looking for is located under PINCTRL_SUNRISEPOINT configuration option.
My box is updated with current Fedora distro and now running 5.0.9-301.fc30.x86_64. It's also said that the box has Sunrisepoint chipset. For this chipset, 5.0.9 kernel support following devices:
static const struct acpi_device_id spt_pinctrl_acpi_match[] = { { "INT344B", (kernel_ulong_t)&sptlp_soc_data }, { "INT345D", (kernel_ulong_t)&spth_soc_data }, { } };
[ https://elixir.bootlin.com/linux/v5.0.9/source/drivers/pinctrl/intel/pinctrl... ]
I believe the box has INT344B device attached to acpi bus proper:
$ sudo ls -la /sys/bus/acpi/devices/INT344* ... lrwxrwxrwx. 1 root root 0 Jun 20 11:47 /sys/bus/acpi/devices/INT344B:00 -> ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT344B:00
Usually to check this is better to run grep -H 15 /sys/bus/acpi/devices/*/status which return you the list of *present and available* ACPI devices.
Drivers seem loaded:
$ lsmod | grep pin pinctrl_sunrisepoint 28672 0 pinctrl_intel 28672 1 pinctrl_sunrisepoint
However, I don't see any gpio devices.
$ ls /dev/gpio* ls: cannot access '/dev/gpio*': No such file or directory $ ls /sys/bus/gpio/devices/ $
What am I still missing?
Two items: - CONFIG_GPIO_SYSFS (deprecated!) - that this is an old way to access to GPIO chips, the correct one is to use character device; libgpiod tools will help you with that -- With Best Regards, Andy Shevchenko
On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
Usually to check this is better to run grep -H 15 /sys/bus/acpi/devices/*/status which return you the list of *present and available* ACPI devices.
It looks like INT344B device is neither present nor available. This device isn't in the list returned by above grep. Its status actually returns 0. What could be reasons for that?
to use character device; libgpiod tools will help you with that
It's good to know there is C library for handling gpio. But this is user-land thing. I'm interested in kernel's means to handle gpios. And for experiments I'd rather use tools/gpio/. Anyway, I can figure out how to use kernel API. At the moment though I need to understand what's wrong with my platform and how can I fix/make it work. Thx!
On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote:
On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
Usually to check this is better to run grep -H 15 /sys/bus/acpi/devices/*/status which return you the list of *present and available* ACPI devices.
It looks like INT344B device is neither present nor available. This device isn't in the list returned by above grep. Its status actually returns 0. What could be reasons for that?
Any idea why would otherwise 'visible' [1] device appear unavailable and not present [2]? I cannot see anything obviously wrong in kernel traces either. [1] # tree /sys/bus/acpi/devices/INT344B\:00/ /sys/bus/acpi/devices/INT344B:00/ ├── hid ├── modalias ├── path ├── power │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_time │ ├── runtime_status │ └── runtime_suspended_time ├── status ├── subsystem -> ../../../../../bus/acpi └── uevent [2] # cat /sys/bus/acpi/devices/INT344B\:00/status 0
On Mon, Jun 24, 2019 at 11:39:42AM -0700, Alexander Ivanov wrote:
On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote:
On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
Usually to check this is better to run grep -H 15 /sys/bus/acpi/devices/*/status which return you the list of *present and available* ACPI devices.
It looks like INT344B device is neither present nor available. This device isn't in the list returned by above grep. Its status actually returns 0. What could be reasons for that?
Any idea why would otherwise 'visible' [1] device appear unavailable and not present [2]? I cannot see anything obviously wrong in kernel traces either.
[1] # tree /sys/bus/acpi/devices/INT344B\:00/ /sys/bus/acpi/devices/INT344B:00/ ├── hid ├── modalias ├── path ├── power │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_time │ ├── runtime_status │ └── runtime_suspended_time ├── status ├── subsystem -> ../../../../../bus/acpi └── uevent
[2] # cat /sys/bus/acpi/devices/INT344B\:00/status 0
There is no issue with kernel. ACPI tables provided by firmware, so, vendor of your firmware decided to turn off this device. -- With Best Regards, Andy Shevchenko
On Tue, Jun 25, 2019 at 1:08 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
On Mon, Jun 24, 2019 at 11:39:42AM -0700, Alexander Ivanov wrote:
On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote:
On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
Usually to check this is better to run grep -H 15 /sys/bus/acpi/devices/*/status which return you the list of *present and available* ACPI devices.
It looks like INT344B device is neither present nor available. This device isn't in the list returned by above grep. Its status actually returns 0. What could be reasons for that?
Any idea why would otherwise 'visible' [1] device appear unavailable and not present [2]? I cannot see anything obviously wrong in kernel traces either.
[1] # tree /sys/bus/acpi/devices/INT344B\:00/ /sys/bus/acpi/devices/INT344B:00/ ├── hid ├── modalias ├── path ├── power │ ├── autosuspend_delay_ms │ ├── control │ ├── runtime_active_time │ ├── runtime_status │ └── runtime_suspended_time ├── status ├── subsystem -> ../../../../../bus/acpi └── uevent
[2] # cat /sys/bus/acpi/devices/INT344B\:00/status 0
There is no issue with kernel. ACPI tables provided by firmware, so, vendor of your firmware decided to turn off this device.
In Linux we usually respect users and contributors more than vendors, so if there are users that need to access this device and the firmware doesn't let them, but there is a way for us to fix that, then we should provide the tools. But I guess that would happen in the ACPI core? Yours, Linus Walleij
On Tue, Jun 25, 2019 at 04:10:23PM +0200, Linus Walleij wrote:
On Tue, Jun 25, 2019 at 1:08 PM Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
On Mon, Jun 24, 2019 at 11:39:42AM -0700, Alexander Ivanov wrote:
On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov <amivanov@fastmail.com> wrote:
On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
There is no issue with kernel. ACPI tables provided by firmware, so, vendor of your firmware decided to turn off this device.
In Linux we usually respect users and contributors more than vendors, so if there are users that need to access this device and the firmware doesn't let them, but there is a way for us to fix that, then we should provide the tools.
But I guess that would happen in the ACPI core?
Linus, there is another problem, if we even work around this (you should ask Rafael, indeed), the MMIO resources, provided by the table is solely generated by BIOS. The IP, AFAIK, has a possibility to be reallocated in the address space. The user will need BIOS to clarify that, it can't be done in OS (GPIO is exposed as not a PCI device). -- With Best Regards, Andy Shevchenko
On Tue, 25 Jun 2019 04:08 -07:00, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
There is no issue with kernel. ACPI tables provided by firmware, so, vendor of your firmware decided to turn off this device.
It took me (or rather the vendor) to update the firmware and enable INT344B controller. After update, the system enumerates gpio controller [ 4.236944] sunrisepoint-pinctrl INT344B:00: intel_gpio_probe init done All is good! Thank you for helping!
On Wed, Aug 28, 2019 at 02:04:44PM -0700, Alexander Ivanov wrote:
It took me (or rather the vendor) to update the firmware and enable INT344B controller. After update, the system enumerates gpio controller
How did you get them to update the firmware? I have a similar problem with iTCO_wdt on Intel NUC not being enabled. -- Valentin
"Valdis Klētnieks" <valdis.kletnieks@vt.edu> writes:
Though I'm having a hard time aligning that with "D31:F2". Are you confusing a PCI address with a PCI ID, or is this on a non-PCI bus?
"D31:F2" is device 31, function 2. We're used to see this as "1f.2". The question is really: Is there such a device in the system? And if so: What's the ID? That's easy to find out: lspci -vvvnns 0:1f.2 Bjørn
participants (7)
-
Alexander Ivanov -
Andy Shevchenko -
Bjørn Mork -
Greg KH -
Linus Walleij -
Valdis Klētnieks -
Valentin Vidić