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
