From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
Andy Shevchenko <andy@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org, linux-acpi@vger.kernel.org,
Yauhen Kharuzhy <jekhor@gmail.com>
Subject: Re: [PATCH v2 3/3] pinctrl: cherryview: Ignore INT33FF UID 5 ACPI device
Date: Thu, 13 Jan 2022 13:43:08 +0200 [thread overview]
Message-ID: <YeAQTIRQeEuh+Dsv@smile.fi.intel.com> (raw)
In-Reply-To: <654fd7f2-6ac3-6c4b-9710-0e6360935aa0@redhat.com>
On Sat, Nov 27, 2021 at 10:49:55PM +0100, Hans de Goede wrote:
> On 11/26/21 19:12, Andy Shevchenko wrote:
> > On Thu, Nov 18, 2021 at 01:28:02PM +0200, Andy Shevchenko wrote:
> >> On Thu, Nov 18, 2021 at 11:56:50AM +0100, Hans de Goede wrote:
> >>> Many Cherry Trail DSDTs have an extra INT33FF device with UID 5,
> >>> the intel_pinctrl_get_soc_data() call will fail for this extra
> >>> unknown UID, leading to the following error in dmesg:
> >>>
> >>> cherryview-pinctrl: probe of INT33FF:04 failed with error -61
> >>>
> >>> Add a check for this extra UID and return -ENODEV for it to
> >>> silence this false-positive error message.
> >>
> >> Hmm... Interesting. Why do they have it?
> >> Give me some time to check this...
> >
> > _DDN in ACPI describes this as Virtual GPIO. The only documentation at hand
> > right now tells me that this is a "solution" to represent the "virtual GPIO"
> > as fifth community (no connection to any pads, minimum configuration, etc).
> >
> > The goal as far as I can see is "to convert a PME event generated by PCI device
> > to a GPIO interrupt".
> >
> > Seems like we better have a driver for it, but the only purpose of it is to
> > generate interrupts based on PME.
> >
> > I'll try to dig more may be next week, but for now I would like to postpone the
> > patch. Do you agree?
>
> Yes postponing merging this is fine. There is no hurry since this does
> not fix anything broken. I just wanted to get rid of the annoying log message :)
So, documentation says the following.
"Chassis GPIO does not support the notion of Virtual GPIOs. So a fifth GPIO
Community was added to provide virtual GPIOs. This virtual GPIO resides
inside PCU."
"Table 8‑19: Virtual GPIO Assignments in CHV
GPIO-V[x] Usage
[7] Reserved for PMC usage
[6] PME handling
[5] Reserved for PMC usage
[4] OTG PME
[3:1] In VLV2, was used for tx_modphy_common_mode_en.
In CHV, these are reserved for future use.
[0] SATA PME"
IOAPIC mapping:
"108 GPIO_virtual"
While at it, in case you want the mapping for direct IRQ:
1) GPIO North: eight interrupts used, connected to IOxAPIC IRQ51 to IRQ58.
2) GPIO Southwest: eight interrupts used, connected to IOxAPIC IRQ59 to IRQ66.
3) GPIO East: all sixteen interrupts used, connected to IOxAPIC IRQ67 to IRQ82.
4) GPIO Southeast: all sixteen interrupt used, connected to IOxAPIC IRQ92 to IRQ107.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2022-01-13 11:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-18 10:56 [PATCH v2 1/3] pinctrl: cherryview: Don't use pin/offset 0 to mark an interrupt line as unused Hans de Goede
2021-11-18 10:56 ` [PATCH v2 2/3] pinctrl: cherryview: Do not allow the same interrupt line to be used by 2 pins Hans de Goede
2021-11-18 11:14 ` Mika Westerberg
2021-11-26 18:13 ` Andy Shevchenko
2021-11-18 10:56 ` [PATCH v2 3/3] pinctrl: cherryview: Ignore INT33FF UID 5 ACPI device Hans de Goede
2021-11-18 11:28 ` Andy Shevchenko
2021-11-26 18:12 ` Andy Shevchenko
2021-11-27 21:49 ` Hans de Goede
2022-01-13 11:43 ` Andy Shevchenko [this message]
2021-11-18 11:14 ` [PATCH v2 1/3] pinctrl: cherryview: Don't use pin/offset 0 to mark an interrupt line as unused Mika Westerberg
2021-11-26 18:13 ` Andy Shevchenko
2021-11-18 11:26 ` Andy Shevchenko
2021-11-26 17:43 ` Andy Shevchenko
2021-11-27 21:48 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YeAQTIRQeEuh+Dsv@smile.fi.intel.com \
--to=andriy.shevchenko@intel.com \
--cc=andy@kernel.org \
--cc=hdegoede@redhat.com \
--cc=jekhor@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.