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

[Bjorn Andersson <bjorn.andersson@linaro.org>]

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