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... > > 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. > Does that make sense, or did I not answer the question you were actually > asking? > It does. Regards, Bjorn
