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

[Shawn Guo <shawn.guo@xxxxxxxxxx>]

On Thu, Mar 04, 2021 at 02:37:12PM +0800, Shawn Guo wrote:
> > > > 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?
...
> > > 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.

Oh, if I should look at the index in sc8180x_pdc_map[], { .gpio = 24, .wakeirq = 37 }
sits on 6 or 7 depending on indexing starts from 0 or 1.  Then question
becomes how 14 turns to 6 or 7.

Shawn