zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.45k stars 6.4k forks source link

Wakeup source API in hwinfo #74272

Open RomainPelletant opened 2 months ago

RomainPelletant commented 2 months ago

Is your enhancement proposal related to a problem? Please describe. AFAIK, there is no API to know the wakeup source.

Describe the solution you'd like hwinfo seems to be the right place as it is already used to provide reset cause.

It shall provide:

/** Wakeup sources*/
#define WAKEUP_GPIO             BIT(0)
#define WAKEUP_UART             BIT(1)
#define WAKEUP_I2C              BIT(2)
#define WAKEUP_SPI              BIT(3)
#define WAKEUP_CAN              BIT(4)
#define WAKEUP_RTC              BIT(5)
#define WAKEUP_USB              BIT(6)
#define WAKEUP_ETHERNET             BIT(7)
#define WAKEUP_WIFI             BIT(8)
#define WAKEUP_BLUETOOTH            BIT(9)

int z_impl_hwinfo_get_wakeup_source(struct wakeup_source *source);

int z_impl_hwinfo_clear_wakeup_source(void);

int z_impl_hwinfo_get_supported_wakeup_source(uint32_t *supported);

struct wakeup_source {
    uint32_t  wakeup_source;
    uint8_t source_instance;
};

Could be enabled by KCONFIG : CONFIG_HWINFO_WAKEUP_SOURCE_SUPPORT

In could be brought by pm_device.

Do you see any cases not covered by this -very simple- API? Adding custom field for extra informations?

Thanks for your support

henrikbrixandersen commented 2 months ago

I am not sure HWINFO is the right place for this. While the reset cause can typically be obtained from one location in an SoC, the wakeup source cannot.

RomainPelletant commented 2 months ago

Thanks for your message. From this point of view, it makes no real sense to add it into hwinfo module.

This glue is close to hw so it shall be implemented in drivers, probably in a dedicated module.

Some flags should be cleaned up before going to sleep so an application API (or adding these calls in PM section) to correctly handle flags might be useful.

Finally, the more I think about it, the more I find interesting to get wake-up sources from DTS to handle flags cleanup "automatically".

I come back with few more details. In the meantime, if someone has good ideas : I'd be glad to read them :)

RomainPelletant commented 4 days ago

I made a PR proposal for GPIO wakeup in GPIO API. I don't see any other API already existing which could be relevant. No clear flag function. Do you see better way to implement it?