drivers: counter: add set value and 64b ticks

[XenuIsWatching]

This also introduces an api for set the counter time.

Also, this set frequency to be 64 bits rather than 32 bits, as counters,
such as those that use fractional adders, tick at resolutions
greater than 4294967295Hz. This changes the freq in the common info
to a uint64_t. This retains the existing counter_get_freq function which
will still return a 32bit value. This also adds a counter_get_freq_64
function to get a 64bit value for the frequency. Unfortunately, I do not
have a 'public' driver that uses this.

Add inline helper functions for converting ticks to nanoseconds.

Also implement an inline helper for converting microseconds or
nanoseconds with a 64bit tick value.

this was a split from #89127

[etienne-lms]

I think commit drivers: counter: stm32: introduce counter set value api should be split in 2 commits: one for the generic part (counter.h) and one for the STM32 driver. That is not a strong opinion, maybe maintainer is fine as-is.

[XenuIsWatching]

@etienne-lms looking through your comments on formatting, i see the same issues ALL throughout this counter.h, I'll just add a commit and the head which "runs clang-format" on counter.h

[etienne-lms]

For commit "drivers: counter: run clang-format on counter.h" I leave it to maintainer to tell if the commit is worth it.
LGTM.

[XenuIsWatching]

something I just realized is that the alarm callbacks will need a 64b tick value (as well as likely the top values)

[XenuIsWatching]

something I just realized is that the alarm callbacks will need a 64b tick value (as well as likely the top values)

thinking even more bout this... it gets rather complicated for counter drivers which do not use a 64b tick register and to support 64b across the board (top value, alarm ticks, values, max top values)... I'm beginning to think maybe it would be better to just have a KConfig (maybe CONFIG_COUNTER_64BITS) that selects a typedef for either a uint32_t or a uint64_t such as counter_ticks_t which is then used throughout the driver, rather than having to worry about if you need to use the 32b api or the 64b api and having 32b or 64b in some alarm callbacks (and others)

I also can't see a reason to really still have the 32b apis around if you know you've got a 64b counter

such as

typedef int (*counter_api_set_value)(const struct device *dev, uint32_t ticks);

would just simply become

typedef int (*counter_api_set_value)(const struct device *dev, counter_ticks_t ticks);

as well as

typedef void (*counter_alarm_callback_t)(const struct device *dev, uint8_t chan_id, uint32_t ticks,
					 void *user_data);

would become

typedef void (*counter_alarm_callback_t)(const struct device *dev, uint8_t chan_id, counter_ticks_t ticks,
					 void *user_data);

....and the other places where ticks, top values are defined...

[jhedberg]

@XenuIsWatching there are some merge conflicts which require a rebase

[kartben]

[...] it just seems odd and rather useless in first place as having something 64b ticks supported and then just returning 32b ticks within alarm and top values when they really can be 64b really seems odd.

I don't necessarily disagree that the API initially introduced was probably poorly designed, but that doesn't make the change "less" breaking :/ (just similar to if we rename an API that has a typo in it... this does fix the oddity, but breaks folks).

[XenuIsWatching]

@XenuIsWatching there are some merge conflicts which require a rebase

[...] it just seems odd and rather useless in first place as having something 64b ticks supported and then just returning 32b ticks within alarm and top values when they really can be 64b really seems odd.

I don't necessarily disagree that the API initially introduced was probably poorly designed, but that doesn't make the change "less" breaking :/ (just similar to if we rename an API that has a typo in it... this does fix the oddity, but breaks folks).

I understand that, but it should never be too late to do it right :)

[XenuIsWatching]

@XenuIsWatching there are some merge conflicts which require a rebase

done

[sylvioalves]

@kartben based on your comments, should this be tagged with "breaking API changes" and also added into dev review or TSC meeting? Asking this due to upcoming feature freeze.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud