Relax us ticker frequency requirement + test update

[mprse]

Description

This change is required by the Samsung S111(S5JS100). On this board timer clock used for us ticker operates at 26MHz.
According to current requirements, 8 MHz is the top limit for us ticker timer.

This change relaxes top limit to 100 MHz, but only for 32-bit timers.

Ticker common layer schedules one interrupt per timer rollover to trace elapsed time. We need to ensure that this operation is not performed too frequently. I.e. in case of 16-bit timer at 32 MHz, the timer rollover will happen after ~2 ms. This may cause that there will be no time for other tasks. That is why we increase the top limit, but only for 32-bit timers.

Pull request type

[X] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@bulislaw @jamesbeyond @fkjagodzinski @maciejbocianski

[mprse]

Updated documentation: PR ARMmbed/mbed-os-5-docs#1123.

[0xc0170]

CI started

[mbed-ci]

Test run: FAILED

Summary: 1 of 4 test jobs failed
Build number : 1
Build artifacts

Failed test jobs:

• jenkins-ci/mbed-os-ci_unittests

[mprse]

Test run: FAILED

@0xc0170 Looks not related.

[kjbracey]

Recent optimisations in #10609 were relying on the current limits.

But as long as this limit is only lifted for wide timers, I believe it doesn't break that. Maybe you could double-check - see _us_is_small_enough macro in mbed_wait_api.h.

(I can imagine this being relaxed a bit more in future - maybe it isn't specific to 32-bit, maybe it could be a combined check of width+speed to ensure wrap time is greater than 8ms.)

[0xc0170]

Will restart tests once we have 5.13.3 RC tested

[0xc0170]

CI restarted

[mbed-ci]

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 2
Build artifacts

[mprse]

Recent optimisations in #10609 were relying on the current limits.

But as long as this limit is only lifted for wide timers, I believe it doesn't break that. Maybe you could double-check - see _us_is_small_enough macro in mbed_wait_api.h.

(I can imagine this being relaxed a bit more in future - maybe it isn't specific to 32-bit, maybe it could be a combined check of width+speed to ensure wrap time is greater than 8ms.)

@kjbracey-arm Thanks for the review.

Previously the worst case was for 16 bit counter @ 8 MHz. In this case, we have a rollover after ~ 8ms.
Now we relaxed max freq only for 32-bit counters, so the worst case is for 32 bit counter @ 100 MHz which gives rollover after ~42 949 ms. Should be okay.