Re: [PATCH] rtc: omap: Support ext_wakeup configuration

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi,

On 08.04.2016 19:16, Grygorii Strashko wrote:
On 04/08/2016 06:14 PM, Tony Lindgren wrote:
* Grygorii Strashko <grygorii.strashko@xxxxxx> [160408 03:41]:
Hi Tony,

On 04/05/2016 01:40 AM, Tony Lindgren wrote:
Hi,

* Marcin Niestroj <m.niestroj@xxxxxxxxxxxxxxxx> [160404 08:57]:
Support configuration of ext_wakeup sources. This patch makes it
possible to enable ext_wakeup and set it's polarity, depending on board
configuration. AM335x's dedicated PMIC (tps65217) uses ext_wakeup to
notify about power-button presses. Handling power-button presses enables
to recover from RTC-only power states correctly.

I suggest you just set this pin up as a minimal gpiochip. That way
we can use the standard binding :) And if we get lucky, this pin can
also trigger during runtime.


Following my comments on v2 of this patch I propose to rollback to
this version of the patch.

It seems doesn't fit in gpiochip, it's more likely irqchip, but since
rtc can't generate IRQ there are nor reasons for these genetic
experiments and RTC's specific bindings looks more suitable, at least for me.

Hmm well gpiochips typically are irqchip too. IMO the generic binding
here sounds like "gpio-wakeup" as it's an input with polarity and with
an optional interrupt.

Plain irqchip would work too in this case if there are no other GPIO
specific features. Some other RTCs may have more GPIO like features.

In any case, setting the ext_wakeup up as an irqchip means that the
RTC controller can be used as a dedicated wakeirq with Linux :)

It can't :( It can't generate IRQ when state of ext_wakeup line has
been changed.


Are you guys sure there's no wake pin events during runtime? AFAIK
the RTCs just typically produce an interrupt when programmed to
do so, they don't know the state of the SoC.


I do not think that It can be fit in gpiochip or irqchip -
in my opinion right way is to proceed with bindings proposed by
Marcin in this patch v1.

But, probably, it could fit in pinctrl:
- this is pin's configuration
- this is one-time configuration
- or - configuration which can be applied before suspend
   and resorted after suspend.

if you still wanna try some generic framework.


pinctrl bindings looks ok for our use case (enable/disable input,
configure debounce), except I don't see any way to pass polarity
(active low/high) to the driver.

--
Marcin Niestroj
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux