On Tue, 10 Aug 2021 at 10:55, Sylwester Nawrocki [off-list ref] wrote:

On 09.08.2021 21:48, Sam Protsenko wrote:

quoted

quoted

quoted

+/* 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.

Thanks for confirming this. I'll go with generic fixed clock in my
clock patch series then.

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.

Ok, I'll remove the stub clock driver in v3. Using fixed clock in
device tree for serial seems to work fine.

--
Regards,
Sylwester

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel