On Wed, 2017-03-08 at 13:46 +0200, Andy Shevchenko wrote:
> On Wed, 2017-03-08 at 12:27 +0100, Hans de Goede wrote:
> > On 08-03-17 11:30, Andy Shevchenko wrote:
> > > On Wed, 2017-03-08 at 10:08 +0100, Hans de Goede wrote:
> > > > On 07-03-17 14:55, Hans de Goede wrote:
> > > > Unfortunately it no longer works, there are 2 problems:
> > > >
> > > > 1) "Input: soc_button_array - Add GPIO ACPI mapping table"
> > > > should
> > > > also replace:
> > > >
> > > > desc = gpiod_get_index(dev, info->name, info-
> > > > >acpi_index,
> > > > GPIOD_ASIS);
> > > >
> > > > with:
> > > >
> > > > desc = gpiod_get(dev, info->name, GPIOD_ASIS);
> > > >
> > > > At which point we can also drop the acpi_index field from the
> > > > buttoninfo struct
> > > > altogether.
> Obviously not.
However this statement still true, you seems to be right about indexes.
What a horrible mess :-)
Below corrections to my initial view.
> Just really small pseudo ASL to consider:
>
> _CRS:
>
> GpioIo(...) { pin #5 }
> GpioIo(...) { pin #3, pin #4, pin #2 }
> GpioIo(...) { pin #15 }
>
> In Linux (for example) [index, connection ID]:
>
> index 0 "reset" (pin #2)
> index 1 "func1" (pin #4)
> index 2 "func2" (pin #3)
An this is completely reversed, should be
index 2 "reset" (pin #2)
index 1 "func1" (pin #4)
index 0 "func2" (pin #3)
> index 3 "enable" (pin #5)
> index 4 "ready" (pin #15)
Both above should have indexes 0 on Linux side!
> Mapping Linux <-> _CRS (either from _DSD or hard coded mapping table):
>
> index 0 pin #2 to 1,2
> index 1 pin #4 to 1,1
> index 2 pin #3 to 1,0
> index 3 pin #5 to 0,0
> index 4 pin #15 to 2,0
Ditto.
So, basically with GPIO ACPI mapping table we have to replace indexes in
most cases to 0, which effectively means drop of _index() variant of
gpiod_get() calls. And here you are right.
Sorry for my broken picture.
--
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
