drivers: counter: Add SAM0 basic counter support

[Sizurka]

This adds support for the basic timer counter (TC) found on SAM0 series parts. This driver only supports running the counter in 32 bit wide mode. Since this mode explicitly slaves the odd counters to the even ones, only instances of the even ones are defined.

Tested with tests/drivers/counter/counter_basic_api on SAMD21.

Compile tested on SAMR21 and SAMD20. but requires #15104 (and a bit of rebasing if that's merged)

This will also require a trivial rebase if #14794 is merged (the parameter is already there, just currently set to a default).

@benpicco: I compile tested this against SAME54, but you'd need to generate a tc_fixup_samd5x.h in the spirit of the sercom one. I just used the static definition:

#define MCLK_TC0 (&MCLK->APBAMASK.reg)
#define MCLK_TC0_MASK (MCLK_APBAMASK_TC0)

[benpicco]

Nice work!
On SAME54 the odd timer has to be enabled separately. Luckily both even and odd timers have to the same GCLK_ID (e.g. TC0_GCLK_ID == TC1_GCLK_ID) and they can be assumed to belong to the same APB group.

So all I had to do was to change .mclk_mask = MCLK_TC##n##_MASK to .mclk_pos = MCLK_TC##n##_Pos and add *cfg->mclk |= 1 << (cfg->mclk_pos + 1)

Thinking about it there is nothing that requires both timers to occupy consecutive bits in MCLK.
So no change to your code is needed, I just had to fixup my tc_fixup_samd5x.h - this should be a more robust solution.

With this, tests/drivers/counter/counter_basic_api runs successful on SAME54.

[zephyrbot]

All checks are passing now.

Review history of this comment for details about previous failed status.
Note that some checks might have not completed yet.

[Sizurka]

Note that the Kconfig error is due to token pasting (CONFIG_COUNTER_SAM0_TC32_##n##_DIVISOR) so it's spurious. Should I open a PR on the CI tools to add this symbol, even fore this is merged?

[benpicco]

tested both on samr21-xpro and same54-xpro

[benpicco]

I think the prescaler selection should go into the device tree - but I suppose you will touch up on this anyway once #15585 is merged.

[Sizurka]

Yeah, I'd do a clock-frequency property in the device tree for that. My original logic was that the frequency of the counter would be better as application controllable (vs defined by hardware), which makes it fit Kconfig better.

However, once the SoC clock tree is not an immutable thing, the prescaler should be configured the same way: meaning device tree specification and calculation derived from the requested frequency.

[nordic-krch]

looks ok