Hi Greg,
On Tue, Apr 7, 2020 at 6:57 AM Greg Ungerer <gerg@xxxxxxxxxxxxxx> wrote:
On 6/4/20 5:35 pm, Arnd Bergmann wrote:
On Mon, Apr 6, 2020 at 5:01 AM Stephen Boyd <sboyd@xxxxxxxxxx> wrote:
Quoting Arnd Bergmann (2020-04-05 05:45:20)
On Sun, Apr 5, 2020 at 4:51 AM Stephen Boyd <sboyd@xxxxxxxxxx> wrote:
There's one snag with doing this, and that's making sure that randconfig
builds don't select this option when some architecture or platform
implements 'struct clk' outside of the common clk framework. Introduce a
new config option 'HAVE_LEGACY_CLK' to indicate those platforms that
haven't migrated to the common clk framework and therefore shouldn't be
allowed to select this new config option. Also add a note that we hope
one day to remove this config entirely.
--- a/arch/m68k/Kconfig.cpu
+++ b/arch/m68k/Kconfig.cpu
text data bss dec hex filename
1934726 263616 83284 2281626 22d09a obj/vmlinux-before
1971989 266192 83308 2321489 236c51 obj/vmlinux-after
The coldfire clock implementation looks rather simple compared
to chips from the 2010s: most chips have only fixed clocks,
and three of them have one of two registers of clock gates.
It shouldn't be hard to convert, but enabling common-clk will
cause a noticeable kernel size increase on the fairly limited
hardware.
Simply enabling COMMON_CLK in m5475evb_defconfig
results in a 1.7% or 40KB growth in kernel size, plus there
would be additional dynamic memory usage:
There could certainly be some work done to reduce the code size of the
CCF. I haven't looked but perhaps we could save some memory by making
the basic types selectable too and then push a bunch of kconfig updates
through for that.
Right, that might help. Another possibility would be to support both
the common clk layer and the custom clk implementation on coldfire
until we remove the other custom implementations, by which point
even fewer people will care about coldfire.
Let's see what Geert and Greg think would be the best path for coldfire,
maybe the added 40KB is less of a problem after all.
Losing another 40k is not ideal, but not the end of the world.
It would not stop me running it on any platforms I regularly
run on. For sure some of the really old hardware just doesn't
have the RAM to spare.
Any way, I say we have to move forward and and move to using
the common clock framework for ColdFire sooner than later.
Fine for me.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
