Hey,
This email is targeted mostly to the CLK subsystem/framework.
We've included the IIO subsystem as well, as the drivers that we'll consider writing will be added under
drivers/iio/frequency and register as [OF] CLK providers.
The reason for including them under IIO, is typically the fact that we prefer/like the sysfs control that IIO has.
Long-story-short (the intro wasn't too short), we have some CLK chips that we're writing some drivers for, that go up to
32 Ghz. And we have a few more of them that go above 4.29 Ghz.
The standard `clk_{get,set}_rate()` support only `unsigned long` (u32).
Internally (in our tree) we use an mechanism (not upstreamed) for working around the 4.29 Ghz cap, by providing
multipliers/scales.
And some get/set variants, called `clk_{get,set}_rate_scaled()`
Examples:
https://github.com/analogdevicesinc/linux/blob/master/include/linux/clk/clkscale.h
https://github.com/analogdevicesinc/linux/commit/f61a67ec65b9191021d7afa56d39abe955ac0d41#diff-118886429c94e6577fbe5fe58b98e498
But, we thought we'd start a discussion/RFC about potentially switching from u32 (or unsigned long) to u64 (unsigned
long long) types.
That would allow for significantly higher frequencies than 4.29Ghz just via `clk_{get,set}_rate()`
There are some hurdles to do it, as many drivers should need some investigation/changing.
I'd be willing to help with the conversion if that's a plan.
Whatever the consensus would be (switching to u64, or implementing a clock_scale struct/mechanism) is fine from my side.
We would find a way to adapt our drivers to either variant.
Internally (in our group), there is a preference to the switch to u64.
Thanks
Alex
