Messages in this thread | | | Date | Mon, 27 Aug 2018 19:46:52 -0600 | From | Lina Iyer <> | Subject | Re: [PATCH v2 1/5] drivers: pinctrl: qcom: add wakeup capability to GPIO |
| |
On Mon, Aug 27 2018 at 18:26 -0600, Bjorn Andersson wrote: >On Mon 27 Aug 09:56 PDT 2018, Lina Iyer wrote: > >> On Sun, Aug 26 2018 at 08:33 -0600, Linus Walleij wrote: >> > On Fri, Aug 17, 2018 at 6:39 PM Lina Iyer <ilina@codeaurora.org> wrote: >> > >> > > QCOM SoC's that have Power Domain Controller (PDC) chip in the always-on >> > > domain can wakeup the SoC, when interrupts and GPIOs are routed to the >> > > its interrupt controller. Only select GPIOs that are deemed wakeup >> > > capable are routed to specific PDC pins. During low power state, the >> > > pinmux interrupt controller may be non-functional but the PDC would be. >> > > The PDC can detect the wakeup GPIO is triggered and bring the TLMM to an >> > > operational state. >> > > >> > > Interrupts that are level triggered will be detected at the TLMM when >> > > the controller becomes operational. Edge interrupts however need to be >> > > replayed again. >> > > >> > > Request the corresponding PDC IRQ, when the GPIO is requested as an IRQ, >> > > but keep it disabled. During suspend, we can enable the PDC IRQ instead >> > > of the GPIO IRQ, which may or not be detected. >> > > >> > > Signed-off-by: Lina Iyer <ilina@codeaurora.org> >> > > --- >> > > Changes in v1: >> > > - Trigger GPIO in h/w from PDC IRQ handler >> > > - Avoid big tables for GPIO-PDC map, pick from DT instead >> > > - Use handler_data >> > >> > Just for the record this is an impressive and much needed patch >> > set, no other SoC developer has yet taken on the task of making this >> > work so I very much appreciate that Qualcomm show the way. >> > >> > > +static int msm_gpio_pdc_pin_request(struct irq_data *d) >> > > +static int msm_gpio_pdc_pin_release(struct irq_data *d) >> > > +static int msm_gpio_irq_reqres(struct irq_data *d) >> > > +{ >> > (...) >> > > + if (gpiochip_lock_as_irq(gc, irqd_to_hwirq(d))) { >> > (...) >> > > +static void msm_gpio_irq_relres(struct irq_data *d) >> > > +{ >> > > + gpiochip_unlock_as_irq(gc, irqd_to_hwirq(d)); >> > > +} >> > >> > FYI Hans Verkuil is working on a patch set that moves the >> > lock/unlock as IRQ call to the irqchip request() and release() >> > functions so we can switch a GPIO irqchip line from IRQ >> > mode to say output at runtime without too much trouble. >> > (CEC needs this.) >> > >> Thanks, I will look into Hans's RFCv2. But what would help me would be >> to avoid creating the IRQ for the GPIO itself (I have the latent IRQ), >> if I could just return that instead in gpio_to_irq(), it might be >> easier. I understand ->to_irq() is supposed to be a translate function >> only, I can avoid the dance of enabling and diabling the PDC IRQ on >> suspend and resume. >> > >I did implement gpio_to_irq() like this in the PMIC gpio/mpp drivers and >we've since concluded that we need to move this to some hierarchical >interrupt controller, because people like Linus expect to be able to say > > interrupts = <&gpio_controller 1 IRQ_TYPE_EDGE_RISING> > >which is something used all over the place with the TLMM driver today.
Does it have to be &gpio_controller, can it be another interrupt controller?
Say, interrupts-extended = <&pdc 1 IRQ_TYPE_EDGE_RISING>;
-- Lina
| |