| Message ID | 20190124202205.7940-1-ilina@codeaurora.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | qcom: support wakeup capable GPIOs | expand |
On Thu, Jan 24, 2019 at 9:22 PM Lina Iyer <ilina@codeaurora.org> wrote: > This is a bug fix submission of the v1 posted here [1]. The discussion on how > to represent the wakeup-parent interrupt controller is on-going [2] here. The > reiew comments in [1], from Doug and Stephen are addressed in this patch. > > The series attempts to add GPIO chip in hierarchy with PDC interrupt controller > that can detect and wakeup the GPIOs routed to it, when the system is > suspend/deep sleep mode. I kind of start to get the hang of this now. This is starting to look finished. Some words on the hierarchical GPIO IRQs: I have started to look into hierarchical GPIO+irqchip since the usage of such is spreading. I have been on to Thierry patches trying to make him implement more generic helpers in the gpiolib irqchip library functions. In short I see the following: - Hierarchical gpiochips all have .alloc() and .translate() functions that look more or less the same. - They all fall down to remapping either tuples or entire ranges of IRQs from parent to child with a linear look-up table on allocation. So my idea would be to add support for this into the gpiolib hierarchical irqchip helper: by supplying a parent irqdomain and a list of translation tuples, we should be able to handle pretty much any hierarchical GPIO irqdomain (famous last words). Right now I am converting the IXP4xx platform to hierarchical IRQ from the ground up (it is not even using device tree so it is a bit of a challenge) but it seems to be working. So I will try to post this in some hopefully working form, and on top of those changes or before them introduce some helpers in the core for hierarchical irqs. Or I fail. Anyways, I do not think my ambitions for refactoring the helpers can stand in the way of support for these use cases and new hardware, so maybe we need to merge a few more hierarchical drivers just bypassing the gpiolib helpers. I don't want to block development, and I suspect Thierry might be getting annoyed at me at this point, so we should maybe just pile up a few more hierarchical chips so I can refactor them later. What do you think? Yours, Linus Walleij
On Mon, Jan 28 2019 at 07:19 -0700, Linus Walleij wrote: >On Thu, Jan 24, 2019 at 9:22 PM Lina Iyer <ilina@codeaurora.org> wrote: > >> This is a bug fix submission of the v1 posted here [1]. The discussion on how >> to represent the wakeup-parent interrupt controller is on-going [2] here. The >> reiew comments in [1], from Doug and Stephen are addressed in this patch. >> >> The series attempts to add GPIO chip in hierarchy with PDC interrupt controller >> that can detect and wakeup the GPIOs routed to it, when the system is >> suspend/deep sleep mode. > >I kind of start to get the hang of this now. This is starting to >look finished. Some words on the hierarchical GPIO IRQs: > >I have started to look into hierarchical GPIO+irqchip since >the usage of such is spreading. > >I have been on to Thierry patches trying to make him implement >more generic helpers in the gpiolib irqchip library functions. > >In short I see the following: > >- Hierarchical gpiochips all have .alloc() and .translate() functions > that look more or less the same. > Yes. >- They all fall down to remapping either tuples or entire ranges > of IRQs from parent to child with a linear look-up table on > allocation. > I would think this would be the generic case, unless its QCOM, where we would want to push the tuples up hierarchy :( >So my idea would be to add support for this into the gpiolib >hierarchical irqchip helper: by supplying a parent irqdomain >and a list of translation tuples, we should be able to handle >pretty much any hierarchical GPIO irqdomain (famous last >words). > We would read the tuples from DT? Also please consider Rob's idea of specifying hierarchy from [2]. >Right now I am converting the IXP4xx platform to hierarchical >IRQ from the ground up (it is not even using device tree >so it is a bit of a challenge) but it seems to be working. > >So I will try to post this in some hopefully working form, and >on top of those changes or before them introduce some >helpers in the core for hierarchical irqs. Or I fail. > Thanks, please copy me on the thread. I would not want to miss this. >Anyways, I do not think my ambitions for refactoring the >helpers can stand in the way of support for these use cases >and new hardware, so maybe we need to merge a few >more hierarchical drivers just bypassing the gpiolib >helpers. I don't want to block development, and I suspect >Thierry might be getting annoyed at me at this point, so >we should maybe just pile up a few more hierarchical >chips so I can refactor them later. > >What do you think? > I attempted refactoring the .alloc and .translate and for a generic case and it seemed like it would fit the bill very well. Will await your patches. Thanks, Lina