On Mon, 08 Oct 2018 08:14:53 +0100, Stephen Boyd <swboyd@xxxxxxxxxxxx> wrote: > > Quoting Lina Iyer (2018-09-25 10:16:05) > > Thanks Linus, for bringing this to my attention. > > > > Hi Thierry, > > > > On Tue, Sep 25 2018 at 03:57 -0600, Thierry Reding wrote: > > >On Tue, Sep 25, 2018 at 10:48:39AM +0200, Linus Walleij wrote: > > >> Hi Thierry, > > >> > > >> thanks for working on the wakeup business! > > >> > > >> This patch gets me a bit confused on our different approaches > > >> toward wakeups in the kernel, so I included Lina, Marc and Ulf > > >> to see if we can get some common understanding. > > >> > > >> On Fri, Sep 21, 2018 at 12:25 PM Thierry Reding > > >> <thierry.reding@xxxxxxxxx> wrote: > > >> > > >> > The following is a set of patches that allow certain interrupts to be > > >> > used as wakeup sources on Tegra186 and later. To implement this, each > > >> > of the GPIO controllers' IRQ domain needs to become hierarchical, and > > >> > parented to the PMC domain. The PMC domain in turn implements a new > > >> > IRQ domain that is a child to the GIC IRQ domain. > > >> > > > >> > The above ensures that the interrupt chip implementation of the PMC is > > >> > called at the correct time. The ->irq_set_type() and ->irq_set_wake() > > >> > implementations program the PMC wake registers in a way to enable the > > >> > given interrupts as wakeup sources. > > >> > > > >> > This is based on a suggestion from Thomas Gleixner that resulted from > > >> > the following thread: > > >> > > > >> > https://lkml.org/lkml/2018/9/13/1042 > [...] > > > > > >Yes, there was some good discussion in that thread which helped me come > > >up with this solution. I think it's pretty elegant because it allows all > > >of this interaction to happen almost automatically via the existing > > >infrastructure. I'm not sure the same could be applied to the PDC, > > >though, because of the need to manually replay the interrupt. That's not > > >something I think can be done with just the simple parent/child > > >relationship that we use on Tegra. > > > > > I wasn't able to use the hierarchy because not all GPIOs and the summary > > line are routed to the PDC. But I am exploring options of hierarchy as > > well. > > > > From reading this thread (and https://lkml.org/lkml/2018/9/17/756) it > looks almost exactly the same. The only difference is that Nvidia Tegra > does the replay in hardware whereas Qualcomm SDM845 decided to replay > the irq in software. Either way, the gpio controller has two parent > domains, one is wakeup capable (PDC or PMC) and the other is not (GIC) > and some wakeup capable irqs only go through the PDC/PMC and then to the > GIC (e.g. RTC) instead of through gpio first. And it sounds like not all > gpios are wakeup capable in both designs. > > The plan to have the gpio to wakeup capable irq map live in DT for the > PMC sounds good too. That way, the wakeup domain alloc function can > figure things out and redirect gpios by itself while the gpio controller > doesn't need to do anything special besides ask for wakeup to be set and > fail if the parent can't support it. > > Can hierarchical irq domains entirely replace the chained irqchip code > in gpiolib? That would be interesting. I'm not convinced this is generally doable. Most GPIO blocks multiplex the signalling on a single parent interrupt, meaning that although you may be able to have a hierarchy extending to that point, it can't go any further (at which point you're back into chained-irq land). It doesn't mean it invalidates the above design, but it probably requires a bit of flexibility. I must admit having slightly lost track of the intricacies of the QC design, but we already have a set of interrupt controllers whose sole task is to generate wake-up events. They are well behaved though, in the sense that they will regenerate edges that the QC HW drops on the floor. The main issue I can see is that the QC HW relies on some signal other than the normal interrupt we can handle, and this completely breaks the very notion of a hierarchy. You need some "side-band signalling" which will re-inject the lost edges. That, on its own, is a bit of a deal-breaker. Thanks, M. -- Jazz is not dead, it just smell funny.
