| Message ID | 20171124093045.5961-1-linus.walleij@linaro.org |
|---|---|
| Headers | show |
| Series | Make gpio_keys accept board descriptors | expand |
Hi Linus, On Fri, Nov 24, 2017 at 10:30:40AM +0100, Linus Walleij wrote: > The goal I'm working toward is to rid the kernel of the global > GPIO numberspace. > > This means GPIO lines should be references by the local offset > on the GPIO chip. > > This patch set starts to move gpio_keys toward using GPIO > look-up tables instead of global GPIO numbers to find their > GPIOs. > > As an example I did (I think) the necessary patches to > convert DaVinci and i.MX to use this. There are several users > also x86 platform devices. > > Strategy: > > - Merge the patch to input/keyboard/gpio_keys* to support > using descriptors from board files. > > - Refactor the whole universe to get proper names on GPIO > chips, and reference the GPIO lines with local offsets using > tables, as in the example patches in this series. These > can trickle in after the first patch is merged in Input. > The work to be done can be seen if you type: > git grep gpio_keys_platform_data > > - When all are refactored, remove the "gpio" and "active low" > members from the platform data and delete the associated > legacy GPIO handling in the input driver for gpio_keys. > > Posting this with the examples to get buy-in from Dmitry > before I go and spend time refactoring the world. I think this is a worthy goal, but I wonder if we could get static GPIO descriptors work with fwnode_get_named_gpiod() so we could retire the platform data parsing altogether. We'd need to extend static device properties to have notion of children though. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Nov 26, 2017 at 12:33 AM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > I think this is a worthy goal, but I wonder if we could get static GPIO > descriptors work with fwnode_get_named_gpiod() I think that will just work, I can try it on something and see. > so we could retire the > platform data parsing altogether. We'd need to extend static device > properties to have notion of children though. So we are talking about these static device properties I assume? /** * struct gpiod_lookup - lookup table * @chip_label: name of the chip the GPIO belongs to * @chip_hwnum: hardware number (i.e. relative to the chip) of the GPIO * @con_id: name of the GPIO from the device's point of view * @idx: index of the GPIO in case several GPIOs share the same name * @flags: mask of GPIO_* values * * gpiod_lookup is a lookup table for associating GPIOs to specific devices and * functions using platform data. */ struct gpiod_lookup { const char *chip_label; u16 chip_hwnum; const char *con_id; unsigned int idx; enum gpio_lookup_flags flags; }; struct gpiod_lookup_table { struct list_head list; const char *dev_id; struct gpiod_lookup table[]; }; The fact that keys are modeled as children in DTS/ACPI DSDT more of a pecularity to these description languages providing opaque configuration nodes. E.g. these children reflects struct gpio_keys_button being a child of struct gpio_keys_platform_data in the board files. But it is only one device, "gpio-keys" in the Linux device model. The buttons/keys are not devices. Likewise, in device tree the buttons are not really devices under the "gpio-keys" device, they are just property nodes in the device tree conveniently set in a hierarchy to contain the information. I bet ACPI works the same. Since GPIO descriptors (like clocks, regulators ...) are associated with the device, this becomes problematic: these children are not devices. So they need to be associated with the device to begin with. In that case, I would opt to just use the unsigned int idx field for determining child number from the descriptor table, use con_id for naming the child and we are back at essentially the same structure as a backend for fwnode. Due to the complexity of fwnode requireing an entire parser for fwnode_operations etc it's a bit of heavy lifting so I need to think and experiment some more. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Dmitry, On Sun, Nov 26, 2017 at 12:33 AM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Fri, Nov 24, 2017 at 10:30:40AM +0100, Linus Walleij wrote: > > The goal I'm working toward is to rid the kernel of the global > > GPIO numberspace. > > > > This means GPIO lines should be references by the local offset > > on the GPIO chip. > > > > This patch set starts to move gpio_keys toward using GPIO > > look-up tables instead of global GPIO numbers to find their > > GPIOs. > > > > As an example I did (I think) the necessary patches to > > convert DaVinci and i.MX to use this. There are several users > > also x86 platform devices. (...) > I think this is a worthy goal, but I wonder if we could get static GPIO > descriptors work with fwnode_get_named_gpiod() so we could retire the > platform data parsing altogether. We'd need to extend static device > properties to have notion of children though. Do we have this now? I've looked at Heikki's et al work on software nodes but I cannot see whether we are there now. We have fwnode_create_software_node() and friends, but I haven't seen if this can be used with input and GPIO descriptors are still a bit on the side. I can create a lot of properties but not really add a descriptor table as a software node as far as I can tell. I'm also a bit lost on whether it will be possible to get there sadly :/ Yours, Linus Walleij
On Wed, Aug 26, 2020 at 03:20:14PM +0200, Linus Walleij wrote: > Hi Dmitry, > > On Sun, Nov 26, 2017 at 12:33 AM Dmitry Torokhov > <dmitry.torokhov@gmail.com> wrote: > > On Fri, Nov 24, 2017 at 10:30:40AM +0100, Linus Walleij wrote: > > > > The goal I'm working toward is to rid the kernel of the global > > > GPIO numberspace. > > > > > > This means GPIO lines should be references by the local offset > > > on the GPIO chip. > > > > > > This patch set starts to move gpio_keys toward using GPIO > > > look-up tables instead of global GPIO numbers to find their > > > GPIOs. > > > > > > As an example I did (I think) the necessary patches to > > > convert DaVinci and i.MX to use this. There are several users > > > also x86 platform devices. > (...) > > I think this is a worthy goal, but I wonder if we could get static GPIO > > descriptors work with fwnode_get_named_gpiod() so we could retire the > > platform data parsing altogether. We'd need to extend static device > > properties to have notion of children though. > > Do we have this now? I've looked at Heikki's et al work > on software nodes but I cannot see whether we are there now. > > We have fwnode_create_software_node() and friends, but > I haven't seen if this can be used with input and GPIO descriptors > are still a bit on the side. I can create a lot of properties but > not really add a descriptor table as a software node as far as > I can tell. I'm also a bit lost on whether it will be possible > to get there sadly :/ I'm sorry but I'm not completely sure what is this about? Are software nodes still missing something that would prevent us from for example using them to describe the GPIO information exactly the same way it is described in DT? I don't know if that is what we want, but I'm just trying to understand what is still missing? Dmitry? If there is still something missing, then let's fix that. thanks, -- heikki
On Wed, Aug 26, 2020 at 05:35:43PM +0300, Heikki Krogerus wrote: > On Wed, Aug 26, 2020 at 03:20:14PM +0200, Linus Walleij wrote: > > Hi Dmitry, > > > > On Sun, Nov 26, 2017 at 12:33 AM Dmitry Torokhov > > <dmitry.torokhov@gmail.com> wrote: > > > On Fri, Nov 24, 2017 at 10:30:40AM +0100, Linus Walleij wrote: > > > > > > The goal I'm working toward is to rid the kernel of the global > > > > GPIO numberspace. > > > > > > > > This means GPIO lines should be references by the local offset > > > > on the GPIO chip. > > > > > > > > This patch set starts to move gpio_keys toward using GPIO > > > > look-up tables instead of global GPIO numbers to find their > > > > GPIOs. > > > > > > > > As an example I did (I think) the necessary patches to > > > > convert DaVinci and i.MX to use this. There are several users > > > > also x86 platform devices. > > (...) > > > I think this is a worthy goal, but I wonder if we could get static GPIO > > > descriptors work with fwnode_get_named_gpiod() so we could retire the > > > platform data parsing altogether. We'd need to extend static device > > > properties to have notion of children though. > > > > Do we have this now? I've looked at Heikki's et al work > > on software nodes but I cannot see whether we are there now. > > > > We have fwnode_create_software_node() and friends, but > > I haven't seen if this can be used with input and GPIO descriptors > > are still a bit on the side. I can create a lot of properties but > > not really add a descriptor table as a software node as far as > > I can tell. I'm also a bit lost on whether it will be possible > > to get there sadly :/ > > I'm sorry but I'm not completely sure what is this about? Are software > nodes still missing something that would prevent us from for example > using them to describe the GPIO information exactly the same way it is > described in DT? I don't know if that is what we want, but I'm just > trying to understand what is still missing? Dmitry? No, my changes to improve the fwnode handling of references have landed, a while ago, so now I need to refresh the series of patches to gpiolib I was working on around Plumbers time last year. Linus seemed mostly OK with them, so it just a matter of finding time and picking this up again. Thanks. -- Dmitry
On Wed, Aug 26, 2020 at 6:12 PM Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > my changes to improve the fwnode handling of references have landed, > a while ago, so now I need to refresh the series of patches to gpiolib I > was working on around Plumbers time last year. Linus seemed mostly OK > with them, so it just a matter of finding time and picking this up > again. OK I'll be happy to help of course, I am fixing board files to use GPIO descriptors a bit all over the place but then I am only fixing the GPIO problem, and this approach is more ambitious so I am excited if we can move it forward. Yours, Linus Walleij