On Thu, Aug 29, 2019 at 05:59:26PM +0300, Andy Shevchenko wrote:
> Yes. That driver should be in use assuming properly crafted firmware.
I have the latest available firmware for this NUC but there is no such table
and loading wdat_wdt module does not find anything.
Seems I'm out of luck with
On Thu, Aug 29, 2019 at 01:49:31PM +0300, Andy Shevchenko wrote:
> This actually should be done other way around, i.e. enabling ACPI WDAT table
> will get you watchdog and this is *highly* recommended way.
If I understand correctly you are suggesting to try the wdat_wdt driver instead?
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
On Thu, 29 Aug 2019 00:47 -07:00, Valentin Vidić
wrote:
> 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
On Thu, Aug 29, 2019 at 09:47:42AM +0200, Valentin Vidić wrote:
> 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
On Tue, 25 Jun 2019 04:08 -07:00, Andy Shevchenko
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
On Tue, Jun 25, 2019 at 04:10:23PM +0200, Linus Walleij wrote:
> On Tue, Jun 25, 2019 at 1:08 PM Andy Shevchenko
> 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
> > > wrote:
> > > > On Fri, 21 Jun 2019 03:12
On Tue, Jun 25, 2019 at 1:08 PM Andy Shevchenko
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
> > wrote:
> > >
> > > On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko
> > > wrote:
> > > >
> > > > Usually to
On Mon, Jun 24, 2019 at 11:39:42AM -0700, Alexander Ivanov wrote:
> On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov
> wrote:
> >
> > On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko
> > wrote:
> > >
> > > Usually to check this is better to run
> > > grep -H 15
On Fri, 21 Jun 2019 10:39 -07:00, Alexander Ivanov
wrote:
>
> On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko
> 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.
>
On Fri, 21 Jun 2019 03:12 -07:00, Andy Shevchenko
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
On Thu, Jun 20, 2019 at 02:02:11PM -0700, Alexander Ivanov wrote:
> On Tue, 18 Jun 2019 01:41 -07:00, Andy Shevchenko
> 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
On Tue, 18 Jun 2019 01:41 -07:00, Andy Shevchenko
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
On Tue, 18 Jun 2019 08:58 -07:00, Andy Shevchenko
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
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
>
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.
On Mon, Jun 17, 2019 at 05:00:54PM -0700, Alexander Ivanov wrote:
> On Mon, 17 Jun 2019 09:39 -07:00, Andy Shevchenko
> 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_*
On Mon, 17 Jun 2019 09:39 -07:00, Andy Shevchenko
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
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
"Alexander Ivanov" 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
On Sat, 15 Jun 2019 18:50 -07:00, Valdis Klētnieks
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
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, Jun 15, 2019 at 12:38:34PM -0700, Alexander Ivanov wrote:
>
>
> On Sat, 15 Jun 2019 12:31 -07:00, 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
On Sat, 15 Jun 2019 12:31 -07:00, 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:
>
> > lspci
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
"Alexander Ivanov" 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-
On Fri, 14 Jun 2019 13:25 -07:00, Alexander Ivanov
wrote:
>
>
> On Fri, 14 Jun 2019 12:09 -07:00, Valdis Klētnieks
> 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,
On Fri, 14 Jun 2019 12:09 -07:00, Valdis Klētnieks
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) },
> > > {
"Valdis Klētnieks" 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
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,
Valdis,
Thanks for quick response!
On Fri, 14 Jun 2019 11:46 -07:00, Valdis Klētnieks
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
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
>
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
33 matches
Mail list logo
