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
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.
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.
Does that make sense, or did I not answer the question you were actually
asking?
--
Jeffrey Hugo
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
