From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lina Iyer Subject: Re: [PATCH v2 0/8] qcom: support wakeup capable GPIOs Date: Wed, 30 Jan 2019 10:03:13 -0700 Message-ID: <20190130170313.GA6069@codeaurora.org> References: <20190124202205.7940-1-ilina@codeaurora.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Linus Walleij Cc: Stephen Boyd , Evan Green , Marc Zyngier , "linux-kernel@vger.kernel.org" , rplsssn@codeaurora.org, linux-arm-msm@vger.kernel.org, "thierry.reding@gmail.com" , Bjorn Andersson , Doug Anderson List-Id: linux-arm-msm@vger.kernel.org On Mon, Jan 28 2019 at 07:19 -0700, Linus Walleij wrote: >On Thu, Jan 24, 2019 at 9:22 PM Lina Iyer 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