drivers: clock_control: nrf: Use synthesized LF clock source in tests

[nordic-krch]

In tests k_busy_wait is used extensively. It measures delay using
cpu clock source (HF RC). It is less accurate than LF default clock
source (LF XTAL) which leads to tests failure where it is expected
that k_busy_wait(n) will give same (with microseconds accuracy) to
k_sleep(K_MSEC(1000*n)). By chosing LF SYNTH as the source for LF
clock (system clock), it is ensured that HF (cpu) and LF (system)
clocks have the same accuracy and k_sleep and k_busy_wait results
are aligned.

Fixes #24784 for testing.

Signed-off-by: Krzysztof Chruscinski krzysztof.chruscinski@nordicsemi.no

[pabigot]

I agree this should solve the problem, but it does it by selecting a test configuration that does not represent what applications do. I'm less sure that's a good idea as it hides the fact that there is, and will always be, a potential difference between these clock domains.

[carlescufi]

@pabigot @andyross @nordic-krch

Since the assumption that k_busy_wait() and k_sleep() are driven by the same clock is just not valid for Nordic platfroms (and likely for others as well, present or future), would it be better to introduce a new FREQUENCY_TOLERANCE variable that the test uses to extend its tolerance and that can be set to 0 for platforms that use the same clock.
Then you can have something like: check_timeout_drift() that uses FREQUENCY_TOLERANCE in all tests that combine busy waits with sleep.

[carlescufi]

@andyross could you please weigh in here?

[andyross]

Comments in #24784 (comment) -- I'd be personally happy with this patch, or its converse.

To nitpick: I guess stylewise I'd prefer a choice of name that conveys the implication and not just the details. The important thing to an app isn't what whether the source is "SYNTH" or "XTAL", it's that the "synth" choice is subject to temperature and semiconductor process skew where the crystal is tuned to more conventional tolerances.

As far as adding code to the test framework, that would work, but it doesn't seem much different than just adding a fudge factor for individual cases. These kind of long busy waits are pretty rare even in the tests.

[andyross]

But to be clear: I'd be fine with this as-is.

[andyross]

Actually, thinking on this a little more. I'm not quite fine with it as-is. The effect of the actual logic in this patch is to change the default value of a kconfig depending on whether or not ZTEST is set, which means that the test suite isn't going to be testing Zephyr as it is built by applications.

Now, this particular situation is a tiny edge case and not likely to be a problem. But design-wise that's sort of a no-no. We should define the kconfig, what it does, how it's used, and have the tests that need it use it just like apps would.