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 at 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