Remove custom Silicon Labs sleep management

[stevew817]

Description

Standardize on the mbed sleep manager by removing the sleepmodes API, and statically redirecting hal_sleep to EM1 and hal_deepsleep to EM2. This should resolve #5423, #5005 and #4082.

@0xc0170 @bulislaw

Status

READY

Migrations

If users were calling blockSleepmode and unblockSleepmode:

• (un)blockSleepmode(EM0) and (un)blockSleepmode(EM1): don't call anymore
• (un)blockSleepmode(EM2) and below: replace with sleep_manager_(un)lock_deep_sleep() from mbed_sleep.h

[bulislaw]

Looks good, I'm not 100% sure the locking is necessary as we lock the deep sleep in our driver layer. It also seem to conform with our new sleep HAL API https://github.com/ARMmbed/mbed-os/blob/feature-hal-spec-sleep/hal/sleep_api.h

[0xc0170]

Standardize on the mbed sleep manager by removing the sleepmodes API, and statically redirecting hal_sleep to EM1 and hal_deepsleep to EM2. This should resolve #5423, #5005 and #4082.

+1 for addressing those issues.

In the most cases in this patch, the changes in HAL could be removals. It should be functional either way. Is that correct?

For instance i2c hal implementation does not need to touch deepsleep here, as I2C object does. Same could be applied to spi, pwmout, serial.

[stevew817]

@0xc0170 Yes, should be functional either way. I'm not sure what the preferred means is in mbed-OS, actually. Do you just always disable deepsleep when doing 'something', or do you leave it up to the driver to figure out whether the current operation is supported in deepsleep or not?

Comes to mind:

• EFM32 has a low-energy UART which is available during deepsleep. If you disable deepsleep for all Serial operations in the CPP driver layer, then the point of having LEUART is basically moot.
• EFM32 has an I2C peripheral which under some circumstances can operate in deepsleep

Yes, I'm making a case for leaving it up to the driver, since it is the silicon vendor who should know best what is possible during deepsleep and what is not.

[0xc0170]

@0xc0170 Yes, should be functional either way. I'm not sure what the preferred means is in mbed-OS, actually. Do you just always disable deepsleep when doing 'something', or do you leave it up to the driver to figure out whether the current operation is supported in deepsleep or not?

Fair points. Only disabling deepsleep for drivers that require high speed freq clocks (very limited cases where it could potentially run, then question is what speed can be achieved, and other factors). The model was simplified. Therefore drivers like SPI, I2C, Serial lock deep sleep

Yes, I'm making a case for leaving it up to the driver, since it is the silicon vendor who should know best what is possible during deepsleep and what is not.

I haven't seen this in the code, might have overlooked. Ane example, If serial object locks deepsleep while transferring data and waiting for interrupt, and in HAL there is a check if its LPUART, then it would in the idle loop enter deepsleep anyway?

[stevew817]

I haven't seen this in the code, might have overlooked.

Here, for example: https://github.com/ARMmbed/mbed-os/pull/5581/files#diff-a61dbd2ee4b7dbd1c40906a404f3629bL2119

If the LEUART is ran off of the LF clock, and its baud rate is supported by the LF clock, then deepsleep is not blocked by the driver.

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 626
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5581/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

[mbed-ci]

Test : SUCCESS

Build number : 448
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5581/448

[mbed-ci]

Exporter Build : SUCCESS

Build number : 253
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5581/

[bulislaw]

@0xc0170 do you think it makes sense to push the locking to HAL implementation rather than have it in driver? So we can leverage different HW capabilities?

[0xc0170]

@stevew817 Can you please rebase, there is conflict now due to your earlier patches that got in yesterday

@0xc0170 do you think it makes sense to push the locking to HAL implementation rather than have it in driver? So we can leverage different HW capabilities?

As it is , driver provides generic locking, HAL can extend it if it provides more granular selection, as we can see within this patch.

[stevew817]

@0xc0170 Rebased.

[0xc0170]

/morph build

[mbed-ci]

Build : ABORTED

Build number : 639
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5581/

[stevew817]

@0xc0170 Can you restart CI?

[0xc0170]

/morph build

[mbed-ci]

Build : SUCCESS

Build number : 646
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5581/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

[mbed-ci]

Test : SUCCESS

Build number : 468
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5581/468

[mbed-ci]

Exporter Build : SUCCESS

Build number : 285
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5581/