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 at ti.com>