On Thu, 2017-03-09 at 15:45 +0100, Hans de Goede wrote:
> > Sounds like a plan!
> >
> > Since extcon patches are landed already mainstream it might make
> > sense
> > to send it as usual to all maintainers.
>
> Ack, so to be clear we should use gpiod_get not gpiod_get_index with
> the acpi mapping table, right ? The reason I'm asking is that my
> test devices only have the id pin which has index 0 so in my
> experience with soc_button_array it will work with both
> (the button with index 0 would even work with gpiod_get_index).
TL;DR -- right.
So, now simple and clean example:
_CRS:
GpioIo(...) { pin #5 }
GpioIo(...) { pin #3, pin #4, pin #2 }
GpioIo(...) { pin #15 }
If we assume each line represents one function (connection ID):
"func0"
"func1"
"func2"
we would see that index is needed only when we would like to get access
to pin #4 or pin #2 of "func1".
Was:
gpiod_get_index(..., NULL, <index_in_CRS>);
where index is 0,1, or 2 *with second index assumed 0*!
Now, what we actually is doing we mapping connection ID to the first
index and can use index to access mentioned above pins:
gpiod_get_index(..., "<funcX>", <secondary_index_in_CRS>);
For example, for pin #2 or #4
gpiod_get_index(..., "func1", 2); // pin #2
gpiod_get_index(..., "func1", 1); // pin #4
Thus,
gpiod_get_index(..., "func1", 0); // pin #3
Or just for the first (virtual) column:
gpiod_get(..., "<funcX>");
where pin #5, #3 or #15 is accessible.
--
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
