On 09.08.2021 21:48, Sam Protsenko wrote: >>> +/* Will be extracted to bindings header once proper clk driver is implemented */ >>> +#define OSCCLK 1 >>> +#define DOUT_UART 2 >>> +#define CLK_NR_CLKS 3 >>> + >>> +/* Fixed rate clocks generated outside the SoC */ >>> +static struct samsung_fixed_rate_clock exynos850_fixed_rate_ext_clks[] __initdata = { >>> + FRATE(OSCCLK, "fin_pll", NULL, 0, 26000000), >>> +}; >>> + >>> +/* >>> + * Model the UART clock as a fixed-rate clock for now, to make serial driver >>> + * work. This clock is already configured in the bootloader. >>> + */ >>> +static const struct samsung_fixed_rate_clock exynos850_peri_clks[] __initconst = { >>> + FRATE(DOUT_UART, "DOUT_UART", NULL, 0, 200000000), >>> +}; >>> + >>> +static const struct of_device_id ext_clk_match[] __initconst = { >>> + { .compatible = "samsung,exynos850-oscclk" }, >> >> One more thing - I am not sure anymore if this is correct. AFAIR, we >> wanted to drop compatibles for external clocks. >> > I'll remove oscclk from the clock driver and device tree. It's not > needed right now anyway, as that driver is just a stub. > > But I'd still like to know the proper way to define external clocks. I > can see that in exynos7.dtsi and exynos5433.dtsi there is just regular > fixed clock defined for "oscclk" (or "fin_pll"), and then that clock > is referenced in corresponding clock driver by its > 'clock-output-names' property. I guess that approach is the > recommended one? Yes, we should use generic "fixed-clock" in DT to model the external root clock. Registering the external clock from within the CMU driver is a legacy method that predates generic "fixed-clock" and should be avoided. That said I think this temporary stub driver is not needed at all, you could well define a fixed clock in DT and reference it in the UART node, as Krzysztof suggested. -- Regards, Sylwester