| Message ID | 1413913655-22351-1-git-send-email-dianders@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Am Dienstag, 21. Oktober 2014, 10:47:32 schrieb Doug Anderson: > The rockchip pinctrl driver uses irq_gc_set_wake() but doesn't setup > the .wake_enabled member. That means that we can never actually use a > pin for wakeup. When "irq_set_irq_wake()" tries to call through it > will always get a failure from set_irq_wake_real() and will then set > wake_depth to 0. Assuming you can resume you'll later get an error > message about "Unbalanced IRQ x wake disable". The change itself looks reasonable. But now being able to read the docs for it, it doesn't look like all gpios are able to wake the system. On the rk3288 it seems to be only the pins from gpio0 that can do this (similar for different banks on the other Rockchip SoCs) - see PMU_WAKEUP_CFG0 and PMU_WAKEUP_CFG1[1]. So I guess we'll need something more eloquent to handle this. Heiko > > Signed-off-by: Doug Anderson <dianders@chromium.org> > Tested-by: Chris Zhong <zyw@rock-chips.com> > --- > Changes in v2: None > > drivers/pinctrl/pinctrl-rockchip.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/pinctrl/pinctrl-rockchip.c > b/drivers/pinctrl/pinctrl-rockchip.c index 016f457..230d8f3 100644 > --- a/drivers/pinctrl/pinctrl-rockchip.c > +++ b/drivers/pinctrl/pinctrl-rockchip.c > @@ -1563,6 +1563,7 @@ static int rockchip_interrupts_register(struct > platform_device *pdev, gc->chip_types[0].chip.irq_unmask = > irq_gc_mask_set_bit; > gc->chip_types[0].chip.irq_set_wake = irq_gc_set_wake; > gc->chip_types[0].chip.irq_set_type = rockchip_irq_set_type; > + gc->wake_enabled = IRQ_MSK(bank->nr_pins); > > irq_set_handler_data(bank->irq, bank); > irq_set_chained_handler(bank->irq, rockchip_irq_demux);
Heiko, On Thu, Oct 23, 2014 at 9:43 AM, Heiko Stübner <heiko@sntech.de> wrote: > Am Dienstag, 21. Oktober 2014, 10:47:32 schrieb Doug Anderson: >> The rockchip pinctrl driver uses irq_gc_set_wake() but doesn't setup >> the .wake_enabled member. That means that we can never actually use a >> pin for wakeup. When "irq_set_irq_wake()" tries to call through it >> will always get a failure from set_irq_wake_real() and will then set >> wake_depth to 0. Assuming you can resume you'll later get an error >> message about "Unbalanced IRQ x wake disable". > > The change itself looks reasonable. But now being able to read the docs for > it, it doesn't look like all gpios are able to wake the system. > > On the rk3288 it seems to be only the pins from gpio0 that can do this > (similar for different banks on the other Rockchip SoCs) - see PMU_WAKEUP_CFG0 > and PMU_WAKEUP_CFG1[1]. > > So I guess we'll need something more eloquent to handle this. I think long term we're going to need something more elegant, yes. ...but it turns out that as long as you're not in the low, low power state that all pins can wake up the system. Check out "Table 4-5 Power Domain Status Summary in all Work Mode". In Mode 3 (called "sleep") all GPIOs can wake the system up. This is the mode that Chris's current suspend/resume patch uses (actually, it doesn't quite get all the way to that mode yet, but that's the target). It would be ideal if we could get to Mode 4 (called "poweroff"), but when I talked to Rockchip they were a little hesitant about promising that it would work. For one thing: I'm also not 100% certain that today's boards are designed to handle Mode 4. You need to make sure that anything connected to a pin other that GPIO0 can handle whatever state the CPU leaves those pins in mode 4. You also need to make extra certain that all wakeup pins are on GPIO0 (wasn't the case with the first board I worked with). Also: I think you're supposed to turn off VDD_LOG in mode 4. See the line that says "The power off mode turns off the power of all VD_LOGIC externally." On the schematic I'm looking at right now (based on rk808 EVB) I think there is no way to turn off VDD_LOG (without killing RAM). ...my thought was to take this simple patch and eventually work something out. NOTE: One unresolved thing with the current series (this series + Chris's) is that pretty much any interrupt can wake up the system. Even typing on the UART seems to do it. Somehow we're not masking interrupts in a way that prevents this, but I haven't tracked it down yet. I don't think it's related to this patch.
Am Donnerstag, 23. Oktober 2014, 09:55:27 schrieb Doug Anderson: > Heiko, > > On Thu, Oct 23, 2014 at 9:43 AM, Heiko Stübner <heiko@sntech.de> wrote: > > Am Dienstag, 21. Oktober 2014, 10:47:32 schrieb Doug Anderson: > >> The rockchip pinctrl driver uses irq_gc_set_wake() but doesn't setup > >> the .wake_enabled member. That means that we can never actually use a > >> pin for wakeup. When "irq_set_irq_wake()" tries to call through it > >> will always get a failure from set_irq_wake_real() and will then set > >> wake_depth to 0. Assuming you can resume you'll later get an error > >> message about "Unbalanced IRQ x wake disable". > > > > The change itself looks reasonable. But now being able to read the docs > > for > > it, it doesn't look like all gpios are able to wake the system. > > > > On the rk3288 it seems to be only the pins from gpio0 that can do this > > (similar for different banks on the other Rockchip SoCs) - see > > PMU_WAKEUP_CFG0 and PMU_WAKEUP_CFG1[1]. > > > > So I guess we'll need something more eloquent to handle this. > > I think long term we're going to need something more elegant, yes. > ...but it turns out that as long as you're not in the low, low power > state that all pins can wake up the system. > > Check out "Table 4-5 Power Domain Status Summary in all Work Mode". > In Mode 3 (called "sleep") all GPIOs can wake the system up. This is > the mode that Chris's current suspend/resume patch uses (actually, it > doesn't quite get all the way to that mode yet, but that's the > target). It would be ideal if we could get to Mode 4 (called > "poweroff"), but when I talked to Rockchip they were a little hesitant > about promising that it would work. You're right ... didn't read far enough it seems, so this patch also Reviewed-by: Heiko Stuebner <heiko@sntech.de> > NOTE: One unresolved thing with the current series (this series + > Chris's) is that pretty much any interrupt can wake up the system. > Even typing on the UART seems to do it. Somehow we're not masking > interrupts in a way that prevents this, but I haven't tracked it down > yet. I don't think it's related to this patch. I guess the interrupts that aren't wakeup sources should then get masked when going to sleep? Heiko
Am Dienstag, 21. Oktober 2014, 10:47:32 schrieb Doug Anderson: > The rockchip pinctrl driver uses irq_gc_set_wake() but doesn't setup > the .wake_enabled member. That means that we can never actually use a > pin for wakeup. When "irq_set_irq_wake()" tries to call through it > will always get a failure from set_irq_wake_real() and will then set > wake_depth to 0. Assuming you can resume you'll later get an error > message about "Unbalanced IRQ x wake disable". > > Signed-off-by: Doug Anderson <dianders@chromium.org> > Tested-by: Chris Zhong <zyw@rock-chips.com> I've added all 4 patches to a v3.19-pinctrl/next branch. As I'm still looking at the suspend pinctrl changes I'll wait for this before I send this to LinusW. Heiko
diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c index 016f457..230d8f3 100644 --- a/drivers/pinctrl/pinctrl-rockchip.c +++ b/drivers/pinctrl/pinctrl-rockchip.c @@ -1563,6 +1563,7 @@ static int rockchip_interrupts_register(struct platform_device *pdev, gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit; gc->chip_types[0].chip.irq_set_wake = irq_gc_set_wake; gc->chip_types[0].chip.irq_set_type = rockchip_irq_set_type; + gc->wake_enabled = IRQ_MSK(bank->nr_pins); irq_set_handler_data(bank->irq, bank); irq_set_chained_handler(bank->irq, rockchip_irq_demux);