From: Shawn Guo <shawn.guo@linaro.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Jeffrey Hugo <jhugo@codeaurora.org>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Linus Walleij <linus.walleij@linaro.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Bartosz Golaszewski <bgolaszewski@baylibre.com>,
"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH] gpiolib: acpi: support override broken GPIO number in ACPI table
Date: Thu, 4 Mar 2021 14:37:12 +0800 [thread overview]
Message-ID: <20210304063711.GF17424@dragon> (raw)
In-Reply-To: <YD+yBmPrKm1n8Tjm@builder.lan>
On Wed, Mar 03, 2021 at 09:57:58AM -0600, Bjorn Andersson wrote:
> On Wed 03 Mar 09:10 CST 2021, Jeffrey Hugo wrote:
>
> > On 3/3/2021 2:43 AM, Shawn Guo wrote:
> > > On Tue, Mar 02, 2021 at 10:02:49PM -0700, Jeffrey Hugo wrote:
> > > > Sorry, just joining the thread now. Hopefully I'm addressing everything
> > > > targeted at me.
> > > >
> > > > I used to do kernel work on MSMs, then kernel work on server CPUs, but now I
> > > > do kernel work on AI accelerators. Never was on the firmware team, but I
> > > > have a lot of contacts in those areas. On my own time, I support Linux on
> > > > the Qualcomm laptops.
> > > >
> > > > Its not MS that needs to fix things (although there is plenty of things I
> > > > could point to that MS could fix), its the Qualcomm Windows FW folks. They
> > > > have told me a while ago they were planning on fixing this issue on some
> > > > future chipset, but apparently that hasn't happened yet. Sadly, once these
> > > > laptops ship, they are in a frozen maintenance mode.
> > > >
> > > > In my opinion, MS has allowed Qualcomm to get away with doing bad things in
> > > > ACPI on the Qualcomm laptops. The ACPI is not a true hardware description
> > > > that is OS agnostic as it should be, and probably violates the spec in many
> > > > ways. Instead, the ACPI is written against the Windows drivers, and has a
> > > > lot of OS driver crap pushed into it.
> > > >
> > > > The GPIO description is one such thing.
> > > >
> > > > As I understand it, any particular SoC will have a number of GPIOs supported
> > > > by the TLMM. 0 - N. Linux understands this. However, in the ACPI of the
> > > > Qualcomm Windows laptops, you will likely find atleast one GPIO number which
> > > > exceeds this N. These are "virtual" GPIOs, and are a construct of the
> > > > Windows Qualcomm TLMM driver and how it interfaces with the frameworks
> > > > within Windows.
> > > >
> > > > Some GPIO lines can be configured as wakeup sources by routing them to a
> > > > specific hardware block in the SoC (which block it is varies from SoC to
> > > > SoC). Windows has a specific weird way of handling this which requires a
> > > > unique "GPIO chip" to handle. GPIO chips in Windows contain 32 GPIOs, so
> > > > for each wakeup GPIO, the TLMM driver creates a GPIO chip (essentially
> > > > creating 32 GPIOs), and assigns the added GPIOs numbers which exceed N. The
> > > > TLMM driver has an internal mapping of which virtual GPIO number corresponds
> > > > to which real GPIO.
> > > >
> > > > So, ACPI says that some peripheral has GPIO N+X, which is not a real GPIO.
> > > > That peripheral goes and requests that GPIO, which gets routed to the TLMM
> > > > driver, and the TLMM driver translates that number to the real GPIO, and
> > > > provides the reference back to the peripheral, while also setting up the
> > > > special wakeup hardware.
> > > >
> > > > So, N+1 is the first supported wakup GPIO, N+1+32 is the next one, then
> > > > N+1+32+32, and so on.
> > >
> > > Jeffrey,
> > >
> > > Thanks so much for these great information!
> > >
> > > May I ask a bit more about how the virtual number N+1+32*n maps back to
> > > the real number (R)? For example of touchpad GPIO on Flex 5G, I think
> > > we have:
> > >
> > > N+1+32*n = 0x0280
> > > N = 191
>
> There's 190 GPIOs on SC8180x, but then the math doesn't add up to a
> whole number...
In pinctrl-sc8180x driver you wrote, it has sc8180x_pinctrl.ngpios = 191.
Which one of you should I listen to :)
BTW, if you read this number from DTS, I already sent you a series to
fix them.
https://lore.kernel.org/linux-gpio/20210303033106.549-1-shawn.guo@linaro.org/
>
> > > R = 24
> > >
> > > If my math not bad, n = 14. How does 14 map to 24?
> >
> >
> > So, if this was 845, the wakeup hardware would be the PDC. Only a specific
> > number of GPIOs are routed to the PDC. When the TLMM is powered off in
> > suspend, the PDC pays attention to the GPIOs that are routed to it, and are
> > configured in the PDC as wakeup sources. When the GPIO is asserted, the
> > signal to the TLMM gets lost, but the PDC catches it. The PDC will kick the
> > CPU/SoC out of suspend, and then once the wakup process is complete, replay
> > the GPIO so that the TLMM has the signal.
> >
>
> SC8180x has the same hardware design.
>
> > In your example, 14 would be the 14th GPIO that is routed to the PDC. You
> > would need SoC hardware documentation to know the mapping from PDC line 14
> > to GPIO line X. This is going to be SoC specific, so 845 documentation is
> > not going to help you for SC8XXX.
> >
> > Chances are, you are going to need to get this documentation from Qualcomm
> > (I don't know if its in IPCatalog or not), and put SoC specific lookup
> > tables in the TLMM driver.
> >
>
> I added the table in the driver, see sc8180x_pdc_map[], and it has gpio
> 14 at position 7, with the 14th entry being gpio 38 - which seems like
> an unlikely change from the reference schematics.
As it's clear that the real GPIO number is 24, and the only possible map
in sc8180x_pdc_map[] is:
{ .gpio = 24, wakeirq = 37 }
So we need to understand how 14 turns to 37.
Shawn
next prev parent reply other threads:[~2021-03-04 6:39 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-26 3:39 [PATCH] gpiolib: acpi: support override broken GPIO number in ACPI table Shawn Guo
2021-02-26 9:12 ` Andy Shevchenko
2021-02-26 9:39 ` Shawn Guo
2021-02-26 10:57 ` Andy Shevchenko
2021-02-26 11:19 ` Andy Shevchenko
2021-02-27 3:19 ` Shawn Guo
2021-03-01 12:17 ` Andy Shevchenko
2021-03-02 0:27 ` Shawn Guo
2021-03-02 12:21 ` Andy Shevchenko
2021-03-03 5:02 ` Jeffrey Hugo
2021-03-03 8:06 ` Andy Shevchenko
2021-03-03 8:45 ` Shawn Guo
2021-03-03 9:42 ` Andy Shevchenko
2021-03-03 17:08 ` Jeffrey Hugo
2021-03-03 9:43 ` Shawn Guo
2021-03-03 15:10 ` Jeffrey Hugo
2021-03-03 15:57 ` Bjorn Andersson
2021-03-03 17:32 ` Andy Shevchenko
2021-03-04 6:37 ` Shawn Guo [this message]
2021-03-04 6:59 ` Shawn Guo
2021-02-27 3:46 ` Shawn Guo
2021-03-01 12:19 ` Andy Shevchenko
2021-03-02 0:44 ` Shawn Guo
2021-03-02 10:36 ` Andy Shevchenko
2021-03-03 9:47 ` Andy Shevchenko
2021-03-04 19:32 ` Hans de Goede
2021-03-04 20:16 ` Andy Shevchenko
2021-03-05 1:14 ` Shawn Guo
2021-03-05 9:10 ` Hans de Goede
2021-03-05 10:08 ` Andy Shevchenko
2021-03-05 10:10 ` Andy Shevchenko
2021-03-05 11:26 ` Shawn Guo
2021-03-05 12:12 ` 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=20210304063711.GF17424@dragon \
--to=shawn.guo@linaro.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bgolaszewski@baylibre.com \
--cc=bjorn.andersson@linaro.org \
--cc=jhugo@codeaurora.org \
--cc=linus.walleij@linaro.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-msm@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).