Hi,
On 08-03-17 18:01, Andy Shevchenko wrote:
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.
Ok, that explains why switching to gpiod_get() fixed things for me.
But I do believe that just not using a GPIO ACPI mapping table
at all for the soc_button_array driver, combined with using
gpiod_get_index() with a NULL con-id as you suggested is the best
solution for the soc_button_array driver.
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
