mbox series

[RFC,0/1] CCF 64-bit transition

Message ID 20221206112827.115674-1-demonsingur@gmail.com
Headers
Series CCF 64-bit transition |

Message

Cosmin Tanislav Dec. 6, 2022, 11:28 a.m. UTC 
  I sent this as an RFC to get input from the maintainers, since I doubt
this is in a state to be accepted right away and it has not been thoroughly
tested.

Internally, we've been using a simpler way of scaling the clocks for both
providers and consumers, but it doesn't fit too well in the CCF.

Making the switch to 64-bit integers in the CCF would let us upstream more
of our drivers without needing a 64-bit system.

I've thought of some ways to improve this or make the transition easier,
but I need input before moving onto implementing them.

a)

Add a _32 suffix to the old API, and move the clk.h and clk-provider.h
headers to clk-internal.h and clk-provider-internal.h.

Add new clk.h and clk-provider.h headers that include the
clk-internal.h and clk-provider-internal.h header, and use macros to alias
the _32 suffixed API to the old unsuffixed names.

Add new clk-64.h and clk-provider-64.h headers that include the
clk-internal.h and clk-provider-internal.h header, and use macros to alias
the _64 suffixed API to the old unsuffixed names.

Drivers could transition to the 64-bit API by simply swapping the headers
that they include (and, obviously, testing). Code changes will still be
necessary to swap long for u64, but at least the API interaction will be
kept as close as possible.

b)

Introduce a clk_rate_t type. In case we will ever need to change the
definition again, it will be easier. I have no good ideas for a naming
scheme for the new API that will make use of this new type.

Cosmin Tanislav (1):
  clk: core: use 64-bit integers

 drivers/clk/clk.c            | 564 +++++++++++++++++++++++++++--------
 include/linux/clk-provider.h |  90 ++++++
 include/linux/clk.h          |  44 +++
 3 files changed, 578 insertions(+), 120 deletions(-)