TI am625 deepsleep wakeup from main domain

TI am625 deepsleep wakeup from main domain

[Fuzzey, Martin]

Hi all,

I have deep sleep entry and exit working on TI AM625 using the RTC or
MCU domain GPIO using the upstream 6.6 kernel plus [0]
However I am unable to get it to work using a MAIN domain GPIO
(nothing happens and no measurable change in power consumption on
wakeup attempt).

To do that I also applied 3717194f2492 "Input: gpio-keys - add system
suspend support for dedicated wake irqs"
(which is already in mainline but not -6.6)

Then in DT (based on the TI docs)
&main_pmx0 {
    /* attempt at GPIO domain wakeup - when working move to SoC dtsi */
    compatible = "ti,am654-padconf";
    interrupt-parent = <&gic500>;
    interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
    interrupt-controller;
    #interrupt-cells = <1>;

    pinctrl_flb_carrier_gpio_keys: flb-gpiokeys-grp {
        pinctrl-single,pins = <
            AM62X_IOPAD(0x1a8, PIN_INPUT,  7) /*(D20)
MCASP0_AFSX.GPIO1_12 -  SODIMM 32 */
        >;
    };
};

gpio-keys {
    compatible = "gpio-keys";
    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_flb_carrier_gpio_keys>;

    key-gpio {
        interrupts-extended = <&main_gpio1 12 IRQ_TYPE_EDGE_BOTH>,
<&main_pmx0 0x1a8>;
        interrupt-names = "irq", "wakeup";
        label = "GPIO Button";
        linux,code = <KEY_WAKEUP>;
        wakeup-source;
    };
};

(The reason for overriding the compatible on the the pinmux mode is
that the pinctrl_single driver already has the appropriate bits for
that compatible
sure it's a hack but should be ok for testing):

static const struct pcs_soc_data pinctrl_single_am654 = {
    .flags = PCS_QUIRK_SHARED_IRQ | PCS_CONTEXT_LOSS_OFF,
    .irq_enable_mask = (1 << 29),   /* WKUP_EN */
    .irq_status_mask = (1 << 30),   /* WKUP_EVT */
};

static const struct of_device_id pcs_of_match[] = {
...
    { .compatible = "ti,am654-padconf", .data = &pinctrl_single_am654 },
...
};

With this I see that bit 29 (WKUP_EN) of the pad config register is
being set but it doesn't wake up..
I do get input events when not suspended (so that should eliminate bad
hardware) and have checked that the button GPIO line still has power
in suspend.

Am I missing any other pieces here?

One thing I don't really understand is how the DM firmware knows what
wakeup sources should be enabled.

Any help much appreciated,

Martin


[0] https://lore.kernel.org/all/20230804115037.754994-1-d-gole@ti.com/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: TI am625 deepsleep wakeup from main domain

[Dhruva Gole]

Hi,

On Feb 17, 2024 at 17:15:39 +0100, Fuzzey, Martin wrote:
> Hi all,
> 
> I have deep sleep entry and exit working on TI AM625 using the RTC or
> MCU domain GPIO using the upstream 6.6 kernel plus [0]
> However I am unable to get it to work using a MAIN domain GPIO
> (nothing happens and no measurable change in power consumption on
> wakeup attempt).

Your observation is absolutely expected behaviour. Explaining in detail
below...

> 
> To do that I also applied 3717194f2492 "Input: gpio-keys - add system
> suspend support for dedicated wake irqs"
> (which is already in mainline but not -6.6)

Yes, this is one of the missing pieces, but an even more important thing
is io isolation is missing.


> 
> Then in DT (based on the TI docs)
> &main_pmx0 {
>     /* attempt at GPIO domain wakeup - when working move to SoC dtsi */
>     compatible = "ti,am654-padconf";
>     interrupt-parent = <&gic500>;
>     interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
>     interrupt-controller;
>     #interrupt-cells = <1>;
> 
>     pinctrl_flb_carrier_gpio_keys: flb-gpiokeys-grp {
>         pinctrl-single,pins = <
>             AM62X_IOPAD(0x1a8, PIN_INPUT,  7) /*(D20)
> MCASP0_AFSX.GPIO1_12 -  SODIMM 32 */
>         >;
>     };
> };
> 
> gpio-keys {
>     compatible = "gpio-keys";
>     pinctrl-names = "default";
>     pinctrl-0 = <&pinctrl_flb_carrier_gpio_keys>;
> 
>     key-gpio {
>         interrupts-extended = <&main_gpio1 12 IRQ_TYPE_EDGE_BOTH>,
> <&main_pmx0 0x1a8>;
>         interrupt-names = "irq", "wakeup";
>         label = "GPIO Button";
>         linux,code = <KEY_WAKEUP>;
>         wakeup-source;
>     };
> };
> 
> (The reason for overriding the compatible on the the pinmux mode is
> that the pinctrl_single driver already has the appropriate bits for
> that compatible
> sure it's a hack but should be ok for testing):
> 
> static const struct pcs_soc_data pinctrl_single_am654 = {
>     .flags = PCS_QUIRK_SHARED_IRQ | PCS_CONTEXT_LOSS_OFF,
>     .irq_enable_mask = (1 << 29),   /* WKUP_EN */
>     .irq_status_mask = (1 << 30),   /* WKUP_EVT */
> };
> 
> static const struct of_device_id pcs_of_match[] = {
> ...
>     { .compatible = "ti,am654-padconf", .data = &pinctrl_single_am654 },
> ...
> };
> 
> With this I see that bit 29 (WKUP_EN) of the pad config register is
> being set but it doesn't wake up..

That's good to know.

> I do get input events when not suspended (so that should eliminate bad
> hardware) and have checked that the button GPIO line still has power
> in suspend.

Umm how have you checked that it has power in suspend, I'm not sure?
The concept of IO daisychain is that GPIO controller itself WILL lose
power, however the "pad" associated with that particular GPIO stays
alive and has the ability to generate an interrupt to the DM which can
trigger the resume.

> 
> Am I missing any other pieces here?

The missing piece is the set_io_isolation [0]. I had removed that chunk
of code from V7 because we couldn't arrive at a satisfactory conclusion
as to where isolation should be set and removed. You can refer to V6 of
the same patch series [1] for more context.

Just for testing and if it's urgent, you can try and apply the V6 series
and it may just work for you...  I don't currently have a -next branch
with all of my patches applied otherwise would've shared.
The patches thus may not cleanly apply and may need a bit of merge
conflict resolutions.
If I get some time I'll try to apply necessary patches on -next sometime
later, but can't say when exactly due to other things at hand rn.

> 
> One thing I don't really understand is how the DM firmware knows what
> wakeup sources should be enabled.

Great qn. The DM wouldn't really know what wakeup sources are enabled,
so it just assumes today that wakeup can potentially come from any
hardware supported wakeup sources - IO daisychain / wakup UART/ reset
button etc...
It's Linux job in this context to properly configure and enable the
wakeup source that it wants to wakeup from in low power mode like
deepsleep. The DM will get the wake IRQ directly as long as linux has
setup the wakeup source properly, which does seem to be the case
according to what you've setup. You were only missing the io isolation
bits most likely.

I would also urge you to pick the latest boot binaries from ti-u-boot as
there's strong dependency on the correct OPTEE, ATF, other firmwares
that are all packaged as part of the boot bins. We hope to upstream the
remaining few patches to u-boot soon.

[0] https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/firmware/ti_sci.c?h=ti-linux-6.1.y-cicd#n1868
[1] https://lore.kernel.org/all/20230803064247.503036-5-d-gole@ti.com/

-- 
Best regards,
Dhruva Gole <d-gole@ti.com>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: TI am625 deepsleep wakeup from main domain

[Fuzzey, Martin]

Hi Dhruva,

Thank you *very* much for that.

TLDR: Enabling IO isolation indeed makes it work.

On Mon, 19 Feb 2024 at 16:15, Dhruva Gole <d-gole@ti.com> wrote:
>
> Yes, this is one of the missing pieces, but an even more important thing
> is io isolation is missing.
>
>
> >
> > I do get input events when not suspended (so that should eliminate bad
> > hardware) and have checked that the button GPIO line still has power
> > in suspend.
>
> Umm how have you checked that it has power in suspend, I'm not sure?
> The concept of IO daisychain is that GPIO controller itself WILL lose
> power, however the "pad" associated with that particular GPIO stays
> alive and has the ability to generate an interrupt to the DM which can
> trigger the resume.
>

I just meant that I put a scope on the IO line connected to the wakeup
button  end made sure I still got an edge when pressing it in suspend.
Of course that doesn't say anything about the power state of the GPIO
module in the SoC itself but does ensure there were no board level
power / regulator issues.

> >
> > Am I missing any other pieces here?
>
> The missing piece is the set_io_isolation [0]. I had removed that chunk
> of code from V7 because we couldn't arrive at a satisfactory conclusion
> as to where isolation should be set and removed. You can refer to V6 of
> the same patch series [1] for more context.
>
> Just for testing and if it's urgent, you can try and apply the V6 series
> and it may just work for you...  I don't currently have a -next branch
> with all of my patches applied otherwise would've shared.
> The patches thus may not cleanly apply and may need a bit of merge
> conflict resolutions.


I manually merged ti_sci_cmd_set_io_isolation() and its call from
ti_sci_suspend()
and ti_sci_resume() and that was enough.

>
> deepsleep. The DM will get the wake IRQ directly as long as linux has
> setup the wakeup source properly, which does seem to be the case
> according to what you've setup. You were only missing the io isolation
> bits most likely.
>

Yes indeed,
thanks again!

>
> I would also urge you to pick the latest boot binaries from ti-u-boot as
> there's strong dependency on the correct OPTEE, ATF, other firmwares
> that are all packaged as part of the boot bins. We hope to upstream the
> remaining few patches to u-boot soon.

Yes, for the benefit of the list here's my config

I'm using OPTEE from the TI 09.01.00.08 BSP (which is upstream 4.0.0 it seems).
It didn't work correctly with a locally built upstream 4.1.0 (no local
patches) - only one core came out of suspend.
Not sure if it's a problem with 4.1.0 or the way I'm building it.
I'll try the 4.0.0 tag with a local build but it's not that urgent from me.

ATF works with both the upstream v2.10.0 tag and the TI binary from
the BSP above.

The TI binary firmware is from tag 09.02.00.003

If it will all land in u-boot soon I'll likely wait for that.

Regards,

Martin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: TI am625 deepsleep wakeup from main domain

[Tony Lindgren]

* Fuzzey, Martin <martin.fuzzey@flowbird.group> [240220 11:09]:
> Hi Dhruva,
> 
> Thank you *very* much for that.
> 
> TLDR: Enabling IO isolation indeed makes it work.

Have you guys also tested with current Linux v6.8-rc6 or Linux next?

The wkup_uart0 change is in Linux next now as is the gpio-keys wakeup
change. Would be nice to see what all is still missing :)

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel