Re: [PATCH] gpiolib: acpi: support override broken GPIO number in ACPI table

[Jeffrey Hugo <jhugo@codeaurora.org>]

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.