[v2,1/4] pinctrl: rockchip: Set wake_enabled
diff mbox

Message ID 1413913655-22351-1-git-send-email-dianders@chromium.org
State New, archived
Headers show

Commit Message

Douglas Anderson Oct. 21, 2014, 5:47 p.m. UTC
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>
---
Changes in v2: None

 drivers/pinctrl/pinctrl-rockchip.c | 1 +
 1 file changed, 1 insertion(+)

Comments

Heiko Stübner Oct. 23, 2014, 4:43 p.m. UTC | #1
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);
Douglas Anderson Oct. 23, 2014, 4:55 p.m. UTC | #2
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.
Heiko Stübner Oct. 23, 2014, 11:55 p.m. UTC | #3
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
Heiko Stübner Oct. 29, 2014, 9:29 p.m. UTC | #4
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

Patch
diff mbox

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);