My understanding is that if we do not use syscon, then there is noif there was only the LGM SoC then I would say: drop regmap
point in using regmap because this driver uses simple 32 bit register
access. Can directly read/write registers using readl() & writel().
Would you agree ?
however, last year a driver for the GRX350/GRX550 SoCs was proposed: 
this was never updated but it seems to use the same "framework" as the
with this in mind I am for keeping regmap support because.
I think it will be easier to add support for old SoCs like
GRX350/GRX550 (but also VRX200), because the PLL sub-driver (I am
assuming that it is similar on all SoCs) or some other helpers can be
re-used across various SoCs instead of "duplicating" code (where one
variant would use regmap and the other readl/writel).
so when my x86 kernel maintainer enables CONFIG_INTEL_LGM_CGU_CLK then+ select OF_EARLY_FLATTREE
there's not a single other "select OF_EARLY_FLATTREE" in driver/clk
I'm not saying this is wrong but it makes me curious why you need this
We need OF_EARLY_FLATTREE for LGM. But adding a new x86
platform for LGM is discouraged because that would lead to too
many platforms. Only differentiating factor for LGM is CPU model
ID but it can differentiate only at run time. So i had no option
other then enabling it with some LGM specific core system module
driver and CGU seemed perfect for this purpose.
OF_EARLY_FLATTREE is enabled as well.
does this hurt any existing x86 platform? if not: why can't we enable
it for x86 unconditionally?
I went through meson & qcom regmap clock code. Agree, it can be
reused for mux, divider and gate. But as mentioned above, i am now
considering to move away from using regmap.
thank you for evaluating them. let's continue the discussion above
whether regmap should be used - after that we decide (if needed) which
regmap implementation to use