Hi,
On 09-03-17 16:03, Andy Shevchenko wrote:
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.
Ah, I understand so the meaning of index changes and
we should always pass 0 for resources where there
is one gpio per resource. Yes that explains why I
needed to switch to plain gpiod_get for the
soc_button_array to work and the same goes
for extcon-int3496 as that also has one gpio
per resource.
Ok I will test with that fixed and get back to you.
Regards,
Hans
--
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
