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

Shawn Guo
2021-03-04T07:01:01Z

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