VerdiniMX8M Mini - native sleep pin

Technical Support
, ,
1

hi! is there a native pin on Verdin iMX8M Mini always going High (or Low) when entering sleep mode? without any further mod. on the tree?
Thanks

2

Greetings @amartins,

Is your objective to have a pin to detect when the system is in sleep mode? Or to have a pin to wake the device up from sleep mode?

If it’s the latter, we do have designated wake-up pins as documented here: Suspend/Resume (Linux) | Toradex Developer Center

Or is your goal something else entirely?

Best Regards,
Jeremias

3

Thanks for your reply Jeremias,
the objective is to detect when the system is going to sleep mode.

4

I see. After doing some looking I believe the pin you want is CTRL_SLEEP_MOCI, which is pin 256 on the Verdin i.MX8M Mini. According to the datasheet this pin works as follows:

Enable signal for the power rails on the carrier board
peripherals which need to be turned off during sleep mode. It is
only high during running mode. The signal is standard GPIO
with an on-module 10k pull-down resistors. The signal is
defined during the power up sequence. The signal can be left
floating on carrier board.

Does this sound like it would satisfy your requirements?

EDIT: I just learned that this pin may not be fully functional as documented yet and our team is working on implementing this behavior in our software.

Best Regards,
Jeremias

5

Yes I’m aware of this pin (CTRL_SLEEP_MOCI), but also aware it’s not working as supposed (there’s another thread related to this issue…). Any idea if it will be solved soon?

6

At the moment I don’t have a good timeline to give you on when the functionality of this pin will be completed.

Just to elaborate on your use-case more. Why do you want to detect when the system goes into sleep/suspend? Is it just to inform, maybe trigger something, or something else entirely?

Best Regards,
Jeremias

7

You can create a customized service related to suspend and modify the state of any pin configured as GPIO using Libgpiod.

8

I need to wake-up/sleep some peripherials, CTRL_SLEEP_MOCI would be best solution if available.
We can use any GPIO to do that. The thing is we’re using the 10" Riverdi DSI display - and it is always powered from the Dahlia board (through the DSI adapter) - it’s easy to control the display power via a gpio, but when waking up the display driver starts sending signals to display before the GPIO goes high, and thus the display does not work anymore (only from a fresh start).

9

We will explore the Libgpiod option, thanks.

10

The thing is we’re using the 10" Riverdi DSI display - and it is always powered from the Dahlia board (through the DSI adapter) - it’s easy to control the display power via a gpio, but when waking up the display driver starts sending signals to display before the GPIO goes high, and thus the display does not work anymore (only from a fresh start).

I see, if I recall correctly this is a bit of a tricky thing. Each display adapter and display driver needs their own specific work to get sleep/suspend behavior working right. I can see our team is looking at each display adapter individually in this regard. But, it’s hard to give an approximation when the DSI adapter specifically will be looked at, on top of all the other work needed surrounding CTRL_SLEEP_MOCI.

Best Regards,
Jeremias

11

Thanks for your reply.
I think it’s only a matter of giving power to the display at the correct time - when sleeping I can disconnect the ribbon cable from DSI adapter and plug again before wake-up and display works fine this way.

12

I think it’s only a matter of giving power to the display at the correct time

Well in theory you are correct. But getting this behavior working correctly in software is not trivial and a whole different beast compared to just disconnecting and reconnecting the ribbon cable.

For one if you take a look at the DSI adapter here it’s basically just all passive electronic components. Meaning there’s not really a nice way to send a signal in software to the adapter telling it when to stop and re-enable the power. Furthermore, the actual display itself would need to be properly reinitialized during this process. Of course disconnecting and re-connecting the display as you have would reinitialize everything on the display.

It’s not impossible but certainly not trivial and would need some work to get the behavior correct.

Best Regards,
Jeremias